ADMINISTRAÇÃO – ESTIMATIVA

ADMINISTRAÇÃO – ESTIMATIVA

Um projeto se inicia com um conjunto de atividades que são denominadas de planejamento de projeto.

OBJETIVO NO PLANEJAMENTO DE UM PROJETO.

O gerente de projeto encontra-se logo de cara com um dilema, pois são exigidas estimativas quantitativas, sem informações sólidas disponíveis, o que forneceria informações necessárias para as estimativas. O objetivo em planejamento de software é que seja fornecida uma estrutura que possibilite ao gerente jeto fazer estimativa de recursos, custo e prazo.

ESTIMATIVA

Para a estimativa dos recursos se exige experiência, acesso às informações e comprometimento com o. Existem diversas técnicas para estimar o tempo e o esforço de um projeto. Quando está em andamento, as suas estimativas deverão ser atualizadas regularmente, para ajudar no processo de planejamento com uso mais eficaz de seus recursos. Existem três parâmetros no cálculo do custo:

que são eles:

1. O custo de hardware e software;

2. Os custos com treinamento de pessoal e viagens;

3. Custo com esforço dos empregados.

O esforço dos empregados são dominantes em projeto. Contudo, os custos não se resume ao pagamento dos salários geral o custo total de operação na organização. Abaixo do custo total de esforço:

1. Custo do fornecimento de energia;

2. Custo com pessoal;

3. Custo com comunicações e operações em rede;

4. Custo com instalações;

5. Custo com encargos sociais e benefícios para os empregados.

Já o custo com computadores considerados relativamente baratos em relação ao valor total projeto, vão depender da localidade de desenvolvimento do projeto poderão vir de outros mercados. também poderão ser evitadas com o uso de tecnologias como a comunicação via computador. Ressaltamos que o cálculo do custo deve ser bem preciso. é importante destacarmos que existem fatores que podem afetar a estimativa de valor no projeto de softwares. O primeiro fator é a oportunidade de mercado, com preço baixo. O segundo é a incerteza de custo, pois se a organização estiver insegura, poderá ocorrer um aumento excessivo de preço. O terceiro são as condições contratuais, o cliente poderá querer os direitos sobre o código-fonte, tendo como meta a reutilização do código em outros projetos. O quarto são a volatilidade dos requisitos, se existir mudanças a organização poderá baixar ou aumentar os valores. O quinto ator é a saúde financeira da empresa, desenvolvedores poderão cobrar preços muito baixo para aquisição de novos contratos. Além disso, o escopo, os recursos e a reuzabilidade  são muito importantes quando estamos realizando um planejamento.

EM SOFTWARE

A primeira atividade a ser realizada é a determinação do escopo, nele se descreve a função, o desempenho, as restrições, as interfaces e a confiabilidade do software. Quando o planejador vem examinar a declaração de um escopo e adquirir as funções de software importantes chamado, decomposição. A função, o desempenho e as restrições deverão ser avaliados sempre em conjunto. Um dos aspectos menos precisos é a discussão da sua confiabilidade, existem medidas, mas, raramente são usadas nesta etapa.

RECURSOS

A estimativa dos recursos é a segunda parte de um planejamento. existi uma pirâmide que nos mostra os recursos de desenvolvimento. Na base as ferramentas de hardware e software. No nível mais elevado, o recurso de pessoal sempre é exigido, especificado em quatro partes: descrição, disponibilidade, tempo de recurso exigido e tempo de recurso para sua aplicação. As últimas partes são consideradas como informações de tempo.

RECURSOS (HUMANOS)

No escopo serão exigidas as qualificações de pessoal tanto para parte organizacional, como para parte técnica, para ser aplicada no projeto de software. Em alguns casos um projeto de software poderá ser realizado por uma única pessoal desde que este tenha conhecimento especifico e que venha a ter consultoria quando necessário de especialistas. Sendo assim, o número de pessoas exigidas em um projeto de software é definido depois que a estimativa de esforço de desenvolvimento for realizada.

HARDWARE

Em um projeto temos três categorias consideradas: o de desenvolvimento, o de produção e outros elementos do novo sistema. em um projeto são os computadores e seus periféricos utilizados em um projeto de software. Já o de produção será aquele em que será executado, o de desenvolvimento é utilizado por poder suportar a integração de vários usuários. Sendo assim, no planejamento deverá conter o espaço de tempo exigido para as providências com recursos. Outros elementos podem ser especificados o desenvolvimento , portanto, é de grande importância que cada elemento seja especificado.

SOFTWARE

Quando estamos em um projeto, precisamos nos auxiliar no desenvolvimento de um novo programa. O BOOTSTRAPPING é a aplicação mais antiga, ele executa uma rotina interna que testa a memória, os periféricos e colocam o sistema operacional em execução, deixando o equipamento pronto para utilização do usuário. Existem várias ferramentas que auxiliam os engenheiros. Essas ferramentas são denominado de CASE. Exemplo:

1. Ferramentas de Planejamento de Sistema de Informação;

2. Ferramentas de Gerenciamento de Projetos;

3. Ferramentas de Apoio;

4. Ferramentas de Análise e Projeto;

5. Ferramentas de Programação;

6. Ferramentas de Integração e teste;

7. Ferramentas de Construção de Protótipos e Simuladores;

8. Ferramentas de Manutenção;

9. Ferramenta de Framework.

REUSABILIDADE

A re-usabilidade em engenharia de software nada mais é do que a reutilização dos blocos de construção. que permitem a construção de grandes programas com um mínimo de desenvolvimento. No comércio, atualmente, existem várias bibliotecas de software reusáveis para que possam ser utilizadas, problemas em científicos e engenharia. Existem duas regras que o planejador de software deve considerar: A primeira é se cumpre os requisitos e o segundo é se exige alguma modificação antes que possa ser integrado ao sistema. A avaliação técnica é que vai determinar se precisa ou não da reutilização de algum bloco.

GERÊNCIA - PLANEJAMENTO

GERÊNCIA - PLANEJAMENTO

um bom trabalho no desenvolvimento de um software depende de um bom planejamento. o tempo é um fator importante, obriga aos gerentes a pensar sobre a forma como o projeto será iniciado, a necessidade de mão de obra específica para construção dos diversos outros fatores que serão necessários para o projeto.

Riscos (Análise)

O risco é uma questão importante no projeto, pois envolve mudanças de mentalidades, opiniões e ações dos gerentes de projeto. possui três pontos importantes. O que pode acontecer com o projeto final ou continuidade; a mudança, pode atrasar e trazer reflexos negativos ou positivos, e o último ponto que é pensar quais ferramentas e métodos serão utilizados.

Riscos (Identificação)

Para que possamos identificar os riscos no projeto temos identificar quais são óbvios no desenvolvimento de um projeto. Uma delas é o nível macroscópico, com os riscos técnicos e os riscos de negócios. Os riscos técnicos identificam problemas, o risco de negócios, pode destruir um projeto, tendo como base cinco fatores, o primeiro ter um bom projeto e não conseguir nenhum cliente, o segundo é ter um produto que não encaixar na empresa, o terceiro é você ter um bom produto, mas sua equipe de vendas não sabe vender, o quarto é a perda de apoio por parte da diretoria, e o quinto é a falta de orçamento ou de pessoal para realização do projeto.

As perguntas são:

Com relação ao pessoal, trata-se das melhores pessoas de que a empresa dispõe?;

As pessoas que estão no projeto possuem habilidades certas para o projeto?;

No projeto existem pessoas suficientes e à disposição?;

O pessoal envolvido no projeto está comprometido com toda duração do projeto?;

Existe alguma pessoa que irá trabalhar de maneira parcial no projeto?;

O pessoal do respectivo projeto foi treinado?;

Existirá uma rotatividade baixa entre os membros do projeto para ter continuidade?

Essas perguntas mostrarão ao gerente os riscos na composição de uma equipe.

RISCOS (PROJEÇÃO)

A projeção de risco, que podemos chamar de estimativa de risco, tenta classificar cada risco a partir de duas perspectivas: a probabilidade do risco ser real e as consequências dos riscos. São elas: o estabelecimento de uma escala que venha a refletir a probabilidade percebida de ocorrência, o delineamento das consequências, estimativa de impacto de risco no projeto e a notação global de precisão na projeção.

Riscos (Avaliação)

Em uma avaliação de riscos de projetos tentamos determinar uma ordem para eles, e começamos a pensar em como controlar ou evitá-los. Em um contexto de análise de riscos de software, um risco referente tem um ponto simples que denominamos de PONTO REFERENTE OU BREAK POINT, em que as decisões de continuidade do projeto ou de seu encerramento serão tomadas.

Durante uma avaliação de riscos podemos efetuar algumas etapas conforme abaixo:

1. Definir o nível de risco referente ao projeto;

2. Desenvolver relacionamento chama ri, a probabilidade de li e o impacto de xi;

3. Prever um conjunto de pontos que venha a definir uma região delimitada.

4. Se tentar prever associações combinadas de riscos que afetarão um nível referente.

RISCOS (MONITORAÇÃO/GERENCIAMENTO)

Na atividade de gerenciamento e monitoramento de riscos a descrição, probabilidade e os impactos de riscos associados a cada riscos são usados como base para o passo de gerenciamento dos riscos. Temos abaixo um esboço de um plano de administração e monitoramento dos riscos.

A primeira parte do esboço é a introdução, constituída de:

1. Escopo e propósito do documento;

2. Visão geral, subdividida em objetivo e prioridade de se evitar um risco;

3. Organização, subdividida em administração, responsabilidade, descrições;

4. Descrição para evitar riscos, subdividida em cronograma, referência e orçamento.

A segunda parte do esboço é análise de risco, constituída de:

1. Identificação, subdividida em exame dos riscos e classificação dos riscos;

2. Estimativa, subdividida em, probabilidade, consequência, critérios erros;

3. Avaliação, subdividida em métodos, limitações, riscos e resultado aplicados.

A terceira parte do esboço é a administração do risco constituída de:

1. Recomendações;

2. Opções para que se possa evitar o erro;

3. Recomendações para que se possa evitar o erro;

4. Procedimentos para monitoramento do risco.

5. E, por último, sendo a quarta parte do esboço temos os apêndices, constituídos de:

6. Estimativa risco/situação;

7. Plano risco/redução.

CRONOGRAMA PARA O PROJETO DE SOFTWARE

Para que possamos criar o cronograma de um projeto, precisamos delimitar tempo, pois um projeto tem que ter data final e uma divisão do esforço, dentro do prazo previsto para o projeto. O esforço em um projeto que tem que ser bem distribuído, para que se possa tirar melhor proveito de recursos e a data final bem analisada em consequência do aproveitamento real do esforço. Podemos considerar um cronograma de projeto muito mais importante do que a precisão na determinação dos custos do projeto. Porém, se um cronograma não obtiver êxito, poderá causar insatisfação no cliente, bem como problemas em recursos destinados ao projeto, proporcionando um aumento nas despesas e o encarecimento do projeto. Na determinação de um cronograma temos que perceber as relações entre pessoas/trabalho, ter uma definição de tarefas e paralelismo, distribuição dos esforços, métodos de determinação de cronograma e rastreamento/ controle de projeto.

AQUISIÇÃO DE SOFTWARE

Os gerentes de engenharia de software em muita das vezes precisam tomar decisões, tais como definir sobre a aquisição ou produção do software. Aqui ressaltamos que em alguns casos é necessária a compra de um software e a sua posterior adaptação pelos engenheiros de software às necessidades da empresa. Existem algumas etapas para se adquirir um software, e são definidas pela criticalidade do software a ser comprado e o custo final do software.

Quando necessitamos adquirir pacotes de software mais caros seguimos algumas diretrizes:

1. Criação de uma especificação funcional do software e de desempenho;

2. Estimativa de custo para desenvolver o software e a data da entrega;

3. Escolha de pacotes de software, que venham atender as especificações;

4. Criar um relatório para que se possa comparar os pacotes de software;

5. Avaliação dos pacotes candidatos, baseando-se na qualidade do produto, suporte,

direcionamento e reputação dos fornecedores;

6. Pedir opinião aos usuários dos softwares candidatos.

Na tomada de decisão para aquisição do software que será utilizado seguimos as seguintes condições: data que será entregue o produto, custo de aquisição e custo de suporte para o software. É muito importante para os gerentes não tomar decisões apenas visando o preço do produto, mas se ele vai atender por completo os interesses

da empresa que vai adquirir.