Construir Cronograma

A construção do cronograma é feita de acordo com os seguintes passos: 1. Se o projeto é de desenvolvimento

a. Considerar a duração das etapas conforme sugerido pela planilha de pontos de função (ver Figura 4.2).

b. Dividir o projeto em um plano de releases (com cada release tendo o tamanho máximo de três meses). A divisão em releases tem por objetivos:

1. Diminuir a ansiedade natural do cliente, permitindo que o mesmo receba parcialmente o software que está sendo construído;

2. Reduzir os riscos de mudanças constantes em requisitos, permitindo que o escopo do projeto vá sendo desdobrado gradativamente (atendendo as boas práticas dos modelos iterativos e incrementais); 3. Facilitar a interação com o cliente, no sentido de obter o software que

melhor se ajuste às suas necessidades. Isto é alcançado pelo fato dos releases materializarem o conceito abstrato que estava restrito aos requisitos, permitindo que se trabalhe de forma equivalente a uma construção de software baseada em prototipagem.

c. Cada release deve ser estimado usando a planilha de pontos de função, sendo anexadas ao SGC a planilha geral do projeto e as planilhas de cada release; d. Em cada release devem ser lançadas as transações funcionais e de dados que

forem ser criadas naquele release. As transações já contabilizadas em um determinado release não devem ser contabilizadas em releases posteriores; e. Se for necessário reduzir a duração do cronograma, deve ser avaliado quão

flexível é o conjunto de requisitos e priorizada a redução da duração das atividades do caminho crítico. O caminho crítico é o formado pelas atividades que são críticas ao cronograma do projeto, correspondendo ao caminho mais longo (que leva mais tempo) para a realização do projeto. Atividades críticas não podem atrasar, pois acarretam em atrasos globais ao projeto. Desta forma, o gerente de projeto deve desprender uma atenção particular para cada uma dessas atividades do caminho crítico de modo a minimizar o atraso no projeto. Se os requisitos podem ser cortados, o cronograma pode ser encurtado tanto quanto se queira, proporcionalmente à disposição que se tenha de cortar requisitos. Isto leva a fazer menos trabalho em menos tempo, o que é

Centro de Informática – UFPE Página 109 razoável. No entanto, se o conjunto de requisitos não é flexível, encurtar o cronograma depende de adicionar pessoas para fazer mais trabalho em menos tempo (paralelamente), o que só é razoável até um determinado ponto. Nas últimas décadas, vários pesquisadores investigaram os efeitos de compressão de um cronograma. A Figura 4.6 [McConnell-06] sumariza os resultados destas investigações.

Figura 4.6 – Efeitos de Comprimir ou Expandir um Cronograma Nominal [McConnell-06]

O eixo horizontal no gráfico representa a relação entre o cronograma nominal e o comprimido. Um valor de 0,9 no eixo indica um cronograma comprimido que levará 0,9 vezes o tempo que o cronograma nominal (isto é, 90% do nominal). O eixo vertical representa o esforço total requerido quando o cronograma é comprimido ou expandido comparado ao esforço requerido quando o cronograma nominal é usado. Um valor de 1,3 no eixo vertical indica que o cronograma comprimido requer 1,3 vezes o esforço que o cronograma nominal requereria. Concluímos assim que a compressão do cronograma nominal aumenta o esforço total. Se o cronograma nominal era de 10 meses com 5 desenvolvedores, você não pode simplesmente assumir que é possível fazer em 5 meses com 10 desenvolvedores (como diz um velho adágio, “nove mulheres não fazem um filho em um mês”).

Centro de Informática – UFPE Página 110 Cronogramas comprimidos requerem mais esforço por diversas razões:

1. Times maiores requerem mais coordenação e gerenciamento.

2. Times maiores introduzem mais vias de comunicação, o que introduz mais chances de falhas de comunicação, o que introduz mais erros, que por sua vez têm que ser corrigidos. O aumento de vias de comunicação pode ser visualizado na Figura 4.7.

Figura 4.7 – Vias de Comunicação de Acordo com Tamanho de Time de Projeto

3. Cronogramas reduzidos requerem que mais trabalho seja feito em paralelo. Quanto mais trabalho se sobrepõe, mais alta a chance que uma parte do trabalho se baseie em outra incompleta ou defeituosa, e que mudanças tardias venham a aumentar o total de retrabalho.

A conclusão que Barry Boehm [BOEHM-00] e Steve McConnel [McConnell-06] chegam é que existe uma zona do impossível, um ponto além do qual o cronograma de desenvolvimento simplesmente não pode ser encurtado. Mesmo que se trabalhe mais duro, mesmo que se trabalhe de forma mais inteligente, mesmo usando soluções criativas, ou aumentando o time. Simplesmente não pode ser feito. O consenso destes pesquisadores é que a compressão de um cronograma em mais de 25% do nominal não é possível.

1

Vias de comunicação com 2 pessoas

3

Vias de comunicação com 3 pessoas

6

Vias de comunicação com 4 pessoas

10

Vias de comunicação com 5 pessoas

Centro de Informática – UFPE Página 111 2. Montar cronograma de acordo com templates. Estão definidos templates de

acordo com o tipo de negócio, detalhando as atividades e entregáveis previstos (ver exemplo na Figura 4.8 [SGQP-07]):

1. Consultoria

i. Processo de Desenvolvimento ii. Gestão de TI

iii. Segurança, Performance e Redes

2. Desenvolvimento de SW – Projeto Fechado (ver Figura 4.8 [SGQP-07]) 3. Levantamento de Requisitos

4. Fábrica de Construção 5. Fábrica de Testes 6. Integração de Software 7. Implantação de Produtos

Id Nome da tarefa Duração Predecessoras

1 Template - Proj eto Nome 49 dias

2 Planej amento 3 dias

3 Elaboração do Plano de Projeto 3 dias 4 Iteração 1 - Nome Iteração 1 23 dias

5 Requisitos 3 dias

6 Levantamento e detalhamento de Requisitos 3 dias 3

7 Análise e Proj eto 3 dias

8 Elaboração do modelo de análise e projeto 3 dias 6 9 Implementação e Testes Unitários 15 dias

10 Implementação e Testes 15 dias8TI-3 dias 11 Documentação 4 dias 10II

12 Testes de Integração 14 dias

13 Elaboração do Projeto de Testes 4 dias 8;11 14 Execução dos Testes Integrados 3 dias 13;10

15 Release da Iteração 1 2 dias

16 Liberação da Release 1 2 dias 14 17 Iteração 2 - Nome Iteração 2 23 dias

18 Requisitos 3 dias 14II

19 Levantamento e detalhamento de Requisitos 3 dias

20 Análise e Proj eto 3 dias

21 Elaboração do modelo de análise e projeto 3 dias 19 22 Implementação e Testes Unitários 15 dias

23 Implementação e Testes 15 dias21TI-3 dias 24 Documentação 4 dias 23II

25 Testes de Integração 14 dias

26 Elaboração do Projeto de Testes 4 dias 21;24 27 Execução dos Testes Integrados 3 dias 23;26

28 Release da Iteração 2 2 dias

29 Liberação da Release 2 2 dias 27

30 Fechamento do Proj eto 5 dias 17

31 Transferência de Tecnologia 5 dias 32 Homologação da Versão Final 5 dias 31TT

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 Mês 2 Mês 3

Centro de Informática – UFPE Página 112