Diretrizes:  Plano de Desenvolvimento de Software

Plano de Desenvolvimento de Software

É um conjunto de atividades e de tarefas divididas por seqüências de tempo, com recursos atribuídos, contendo dependências de tarefas, para o projeto.

Tópicos

• Determinação do Tempo de uma Iteração
• Determinação do Número de Iterações
• Relação entre a Tradicional Seqüência de Revisão em Cascata e a Abordagem Iterativa
• Organização do Projeto

Determinação do Tempo de Cada Iteração

Uma iteração é definida como um mini-projeto completo, que passa por todas as principais disciplinas e resulta, na maioria dos casos, em um sistema executável, porém incompleto: um release. Embora o ciclo (edição, compilação, teste, depuração) pareça uma iteração, o significado aqui não é esse. Os builds diários ou semanais, que integram e testam gradativamente cada vez mais elementos do sistema, também podem parecer uma iteração, mas são apenas parte dela, conforme o uso do termo neste contexto.

A iteração inicia com planejamento e requisitos e termina com um release interno ou externo.

A rapidez da iteração depende, principalmente, do tamanho da organização do desenvolvimento.

Por exemplo:

• Cinco pessoas podem fazer um planejamento na segunda-feira de manhã, almoçar juntas todos os dias para monitorar o andamento do planejamento, realocar tarefas, iniciar o build na quinta-feira e concluir a iteração na sexta-feira à noite.
• Mas esse procedimento será muito difícil de ser executado por vinte pessoas. Mais tempo será gasto distribuindo o trabalho, sincronizando os subgrupos, integrando todos os elementos etc. Uma iteração poderá demorar três ou quatro semanas.
• Com quarenta pessoas, leva-se uma semana para "que o influxo nervoso vá da cabeça até as extremidades do corpo". Há níveis intermediários de gerenciamento, mas as noções básicas comuns do objetivo necessitarão de uma documentação mais formal. Três meses, geralmente, é um tempo de iteração razoável.

Outros fatores exercem influência: o grau de familiarização da organização com a abordagem iterativa, incluindo uma organização experiente e estável, o nível de automação usado pela equipe para gerenciar códigos (por exemplo, CM distribuído), para distribuir informações (por exemplo, web interna),para automatizar testes etc.

Preste atenção também porque há uma sobrecarga fixa em uma iteração, em relação a planejamento, sincronização, análise dos resultados e assim por diante.

Portanto, por um lado, convencido dos enormes benefícios da abordagem iterativa, você pode ficar tentado a iterar constantemente, porém os limites humanos de sua organização diminuirão sua vontade.

Alguns dados empíricos:

• As iterações que duram mais de seis meses provavelmente precisarão de marcos intermediários para manter o projeto sob controle. Considere a redução do escopo da iteração para diminuir o tempo da iteração e garantir um enfoque mais nítido.
• As iterações que duram mais de doze meses são por si só arriscadas já que a iteração ultrapassa o ciclo de fundos anual. Um projeto que aparentemente não produziu nada nos últimos doze meses corre o risco de perder seus fundos.
• As iterações que duram menos de um mês requerem uma elaboração cuidadosa do escopo. Em geral, as iterações de curta duração são mais adequadas à fase de Construção, caracterizada pela inclusão de poucas funções novas e inovações. Essas breves iterações poderão gerar pouca ou nenhuma análise ou design formal, podendo simplesmente estar aprimorando gradativamente a funcionalidade já bem compreendida.
• As iterações não precisam ter necessariamente o mesmo tempo: o tempo varia de acordo com os objetivos. Em geral, as iterações de elaboração serão mais demoradas do que as de construção. Em uma fase, as iterações têm geralmente o mesmo tempo (facilitando o planejamento).

Quando tiver idéia do número de iterações no esboço de plano, você precisará definir o conteúdo de cada iteração. Recomenda-se inclusive dar um nome ou um título para qualificar o produto no fim de cada iteração, o que ajudará as pessoas a obter um melhor enfoque.

Exemplo Iterações para um Comutador Telefônico Privado

• Iteração 1: chamada local.
• Iteração 2: acrescentar chamadas externas e gerenciamento de assinantes.
• Iteração 3: acrescentar correio de voz e chamadas de conferência.

Determinação do Número de Iterações

Um projeto bem simples pode ter apenas uma iteração por fase:

• Uma iteração na fase de iniciação produzindo, talvez, um protótipo de prova de conceito ou um modelo de interface de usuário ou nenhuma iteração, no caso, por exemplo, de um ciclo de evolução.
• Uma iteração na fase de elaboração para produzir um protótipo de arquitetura.
• Uma iteração na fase de construção para a criação do produto (até o release "beta").
• Uma iteração na transição para conclusão do produto (release de todo o produto).

Para obter um projeto mais substancial, a norma a ser seguida no ciclo de desenvolvimento inicial deve ser:

• Uma iteração na fase de iniciação (possivelmente com a produção de um protótipo).
• Duas iterações na fase de elaboração; uma para um protótipo de arquitetura e a outra para a baseline de arquitetura.
• Duas iterações na fase de construção para expor um sistema parcial e amadurecê-lo.
• Uma iteração na fase de transição para passar da capacidade operacional inicial para o release de todo o produto.

No caso de um grande projeto, com várias questões desconhecidas, novas tecnologias etc., é possível que haja um caso para:

• uma iteração adicional na fase de iniciação, para permitir mais tempo para a produção de um protótipo.
• uma iteração adicional na fase de elaboração, para permitir a exploração de diferentes tecnologias.
• uma iteração adicional na fase de construção devido ao tamanho total do produto.
• uma iteração adicional na fase de transição para permitir comentários sobre a operação.

Portanto, durante um ciclo de desenvolvimento haverá:

• Baixo: 3 iterações [0,1,1,1]
• Típico: 6 [1, 2, 2, 1]
• Alto: 9 [1, 3, 3, 2]
• Muito Alto: 10 [2, 3, 3, 2]

Em geral, planeje de três a dez iterações. Contudo, observe que os limites superior e inferior indicam circunstâncias fora do comum. Conseqüentemente, a maioria dos desenvolvimentos usará de seis a oito iterações.

São possíveis diversas variações, dependendo dos riscos, do tamanho e da complexidade:

• Se o produto for destinado a um domínio totalmente novo, será necessário acrescentar algumas iterações na fase de iniciação para consolidar os conceitos, apresentar diversos modelos para uma seção cruzada de clientes ou usuários finais ou para obter uma resposta segura a uma solicitação de proposta.
• Se uma nova arquitetura tiver que ser desenvolvida ou se houver uma grande quantidade de modelagens de casos de uso, ou muitos riscos desafiadores, planeje duas ou três iterações na fase de elaboração.
• Se o produto for grande, complexo e desenvolvido durante um longo período de tempo, planeje três ou mais iterações na fase de construção.
• Planeje várias iterações na fase de transição se, para agilizar a comercialização, você tiver que liberar o produto com um conjunto menor de funções ou se achar que talvez precisará fazer várias pequenas adaptações na base de usuários finais após um período de uso.

Relação entre a Tradicional Seqüência de Revisão em Cascata e a Abordagem Iterativa

A seqüência de revisão padrão de um projeto de ciclo de vida em cascata passa por uma única grande revisão após a conclusão dos artefatos importantes. Por exemplo:

• Revisão de Requisitos do Sistema (SRR), realizada após a conclusão da especificação do sistema;
• Revisão da Especificação de Software (SSR), realizada após a conclusão da especificação dos requisitos de software;
• Revisão Preliminar de Design (PDR), realizada após a conclusão das seções de design de arquitetura da descrição de design do software;
• Revisão Crítica de Design (CDR), realizada após a conclusão das seções detalhadas de design da descrição de design do software.

No Rational Unified Process (RUP), partes dos artefatos equivalentes são revistos assim que são concluídos em cada iteração, mas os marcos principais (e, portanto, as revisões) estão de acordo com a conclusão das fases: iniciação, elaboração, construção e transição. Um Gerente de Projeto que deseje adotar o RUP talvez tenha que encontrar uma maneira de reconciliar esse conflito aparente por causa das obrigações contratuais. O ideal seria que ele convencesse o cliente de que a abordagem baseada em fases e iterações, na verdade, permite uma visibilidade real maior do andamento do projeto, além de reduzir riscos, tornando desnecessária uma SRR, uma SSR etc. Entretanto, isso nem sempre é possível, e o Gerente de Projeto precisa programar essas revisões nos pontos apropriados. No RUP, é possível localizar os pontos em que esses importantes artefatos (na verdade, seus equivalentes no RUP) estão basicamente completos, embora isso nem sempre esteja perfeitamente de acordo com as fases ou as iterações.

Isso é feito aqui considerando que o esforço relativo que será gasto em requisitos, design e assuntos do gênero será aproximadamente o mesmo no RUP que no ciclo de vida em cascata (ideal), mas que o esforço será distribuído de modo diferente. O resultado é este:

• a SRR (que lida principalmente com a Visão) pode ser programada no fim da fase de iniciação;
• a SRR (que lida principalmente com a Especificação de Requisitos de Software) é realizada em aproximadamente 1/3 do caminho para a fase de elaboração;
• a PDR (que lida principalmente com o Documento de Arquitetura de Software) é realizada no fim da fase de elaboração;
• a CDR (que lida principalmente com o Modelo de Design) é realizada em aproximadamente 1/3 do caminho para a fase de construção.

Para obter eficiência, o Gerente de Projeto e o cliente deverão trocar idéias e tentar combinar essas revisões com as revisões prescritas do RUP. Isso é claramente possível para a SRR e a PDR, que podem ser combinadas com a Revisão dos Marcos de Ciclo de Vida de Objetivos e com a Revisão dos Marcos de Ciclo de Vida de Arquitetura, respectivamente. Isso, porém, não é tão óbvio no caso da SSR e da CDR. Entretanto, considerando que praticamente todos os projetos terão, no mínimo, duas iterações na elaboração e, pelo menos, duas na construção, recomenda-se que a SSR seja combinada com a Revisão de Aceitação de Iteração para a primeira iteração na fase de elaboração e que a CDR seja combinada com a Revisão de Aceitação da Iteração para a primeira iteração na construção. Nos dois casos, será possível ter uma boa visibilidade dos artefatos experimentados, com tempo suficiente para correção, embora a abordagem iterativa deva ser capaz de lidar com isso como rotina habitual.

Organização do Projeto

Assim como o processo de software é influenciado pelas características do projeto, a organização do projeto também sofre essa influência. A estrutura padrão, aqui apresentada (consulte a figura abaixo), precisa ser adaptada para refletir os efeitos de alguns fatores, como os que aparecem listados:

• Contexto dos Negócios
• Tamanho do Esforço para Desenvolvimento do Software
• Grau de Inovação
• Tipo de Aplicativo
• Processo de Desenvolvimento Atual
• Fatores Organizacionais
• Complexidade Técnica e Gerencial

Esses fatores serão descritos detalhadamente em Diretrizes: Discriminadores do Processo. Nesta seção, examinaremos seu efeito na escolha da estrutura do projeto. A figura a seguir apresenta uma organização de projeto padrão, que mostra como as responsabilidades são atribuídas à estrutura de equipe.

Figura que mostra a Organização Padrão do Projeto. Observe que não há valor em termos de maturidade ou autoridade na classificação dos papéis.

Essa figura é um ponto de início que orienta como as responsabilidades e os papéis no nível do projeto devem ser mapeados em uma estrutura de equipes. A figura também serve para destacar que os papéis (mostrados nas caixas amarelas) não representam indivíduos, mas "chapéus" que um indivíduo (ou uma equipe) pode usar durante o projeto. É por esse motivo que alguns papéis (o de Gerente de Projeto, por exemplo) aparecem mais de uma vez. Isso indica que, em algum momento, a função de Gerente de Projeto, conforme definido no RUP, poderá aparecer em mais de uma equipe. Por exemplo, em um grande projeto, a tarefa de preparação de um relatório de status em uma Estrutura de Divisão de Trabalho pode ser delegada a um indivíduo da Equipe de Administração. Entretanto, essa é uma responsabilidade que o RUP atribui ao papel denominado Gerente de Projeto.

Em um pequeno projeto, é provável que um indivíduo indicado como Gerente de Projeto execute todas as atividades do papel denominado Gerente de Projeto. Nesse caso, a Equipe de Administração funde-se na Equipe de Gerenciamento de Software. A seleção da estrutura da equipe será influenciada pela natureza e pelo tamanho do projeto, mas deve ser conciliada com algumas regras de grande senso comum:

• pequenas equipes geralmente são mais produtivas; entretanto, em um grande projeto, deve haver um equilíbrio em relação à freqüência de interação entre as equipes;
• hierarquias complexas devem ser evitadas;
• a faixa de controle de qualquer gerente ou chefe de equipe deve ser limitado a mais sete ou menos dois;
• a estrutura da equipe de desenvolvimento de software deve ser orientada pela arquitetura do software (e não vice-versa); uma arquitetura apropriada, de alta coesão e pouco acoplamento entre os subsistemas, permitirá que as equipes trabalhem paralelamente, de forma mais eficaz;
• é ideal que os testes, exceto o teste unitário, sejam realizados por uma equipe diferente da equipe de desenvolvimento. Observe, porém, que isso pode não ser econômico em um projeto muito pequeno;
• a estrutura deve permitir que sejam atribuídas autoridades e responsabilidades claramente definidas a todas as equipes e indivíduos. Isso é particularmente importante quando a hierarquia ultrapassa três níveis. Os gerentes e os chefes de equipe, no meio dessas estruturas, precisam entender quais são suas funções para equilibrar as atividades técnicas e gerenciais.
• a estrutura deve suportar as capacidades, as experiências e as motivações da equipe: por exemplo, se uma única equipe tiver como papel fazer análise, design e implementação, sem qualquer entrega intermediária, ela precisará de todas as competências necessárias. Analistas experientes não são necessariamente bons implementadores;
• as estruturas de equipe não devem ser rígidas: os indivíduos migrarão entre as equipes durante toda a vida útil do projeto, e as responsabilidades das equipes mudarão conforme a ênfase do projeto e de acordo com sua fase.

Os fundamentos da organização padrão serão descritos detalhadamente em [ROY98]. Em particular, as responsabilidades de implantação designadas para a equipe de avaliação de software reconhece que, entre todas as equipes em um projeto de desenvolvimento, a equipe de avaliação de software tem a maior exposição ao software tal como o usuário final irá vê-lo.

Durante a vida útil de um projeto, a organização se desenvolverá a fim de suportar a estrutura de divisão de trabalho capturada no plano de projeto. Isso é mostrado na figura abaixo, contida no [ROY98].

Essa evolução enfatiza um conjunto diferente de atividades em cada fase:

• equipe de Iniciação: uma organização que se concentra no planejamento, com suporte suficiente das outras equipes para garantir um consenso dos planos de todas as perspectivas;
• equipe de Elaboração: uma organização que se concentra na arquitetura; as forças incentivadoras do projeto estão associadas à equipe de arquitetura de software e com suporte das equipes de desenvolvimento de software e de avaliação de software, quando necessário, para atingir uma baseline de arquitetura estável;
• equipe de Construção: uma organização equilibrada em que a maior parte das atividades está associada às equipes de desenvolvimento de software e de avaliação de software;
• equipe de Transição: uma organização que se concentra no cliente e que usa os comentários sobre uso para orientar as atividades de implantação.

A migração entre as equipes durante essa evolução permitirá manter o conhecimento e a capacidade dentro do projeto. Por exemplo, quando a elaboração estiver concluída, alguns membros da equipe de arquitetura poderão ser transferidos para as equipes de desenvolvimento, podendo atuar como chefes de equipe ou transmitindo a 'visão' de arquitetura para o desenvolvimento. Por último, quase no final da fase de construção, o foco será na equipe de avaliação, e o pessoal passa da equipe de desenvolvimento para a equipe de avaliação. Nesse estágio, também é importante evitar a perda da integridade arquitetural, que se encontra no auge da construção, e evitar que a influência da equipe de arquitetura não se perca como 'centro de gravidade' à medida que o projeto for evoluindo. A migração de alguns membros da equipe de arquitetura para a equipe de avaliação é uma maneira de evitar isso.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process