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.