Fases do Ciclo de Vida

O que é isto

Software não aparece pronto. Alguém precisa decidir o que construir, construir, conferir se o resultado serve, e depois alterar o sistema quando o mundo muda. Um processo de software é o conjunto de atividades relacionadas que levam à produção e à manutenção de um sistema. O ciclo de vida de desenvolvimento de software nomeia as fases em que esse trabalho costuma ser recortado no tempo: planejamento, requisitos, projeto, implementação, teste, implantação, manutenção.

As fases recortam o trabalho no tempo. Por baixo delas, Sommerville agrupa o mesmo trabalho em quatro atividades: especificação, desenvolvimento, validação e evolução. Elas aparecem em qualquer modelo de processo. O que muda é o empacotamento: uma passagem longa, várias voltas curtas, ou fases de negócio com iterações.

Esta página é o mapa. Cascata, iterativo e ágil instanciam o mapa; isso fica nas páginas de cada modelo.

Quatro atividades, um porquê

As quatro atividades:

1. Especificação — entender e definir quais serviços o sistema deve oferecer e quais restrições valem na operação e no desenvolvimento.
2. Desenvolvimento — projetar e construir o software que realiza esses serviços.
3. Validação — checar se o sistema faz o que o cliente precisa (o produto certo) e se foi construído de acordo com o que se combinou.
4. Evolução — alterar o sistema depois da primeira entrega: correção, adaptação ao ambiente, novas necessidades.

São quatro atividades. O nome da fase muda de empresa para empresa (análise, iniciação, descoberta). A atividade não muda. Se o texto fala em entender serviços e restrições, é especificação, mesmo que o nome oficial da fase diga outra coisa.

Cada atividade responde a uma pergunta que a anterior não fecha:

• Sem especificação, o desenvolvimento adivinha o problema.
• Sem desenvolvimento, a especificação é papel.
• Sem validação, ninguém sabe se o papel e o código coincidem com o uso.
• Sem evolução, o sistema útil de hoje vira o sistema errado de amanhã. A maior parte do custo de um software que permanece em uso acontece depois da primeira entrega.

As atividades se repetem. Num processo em cascata, cada uma ocupa um bloco longo. Num processo iterativo, um pedaço de cada uma acontece em todo ciclo. O mapa continua o mesmo.

Elas também se sobrepõem. Revisar o texto de requisitos antes de codificar já é validação, só que cedo. Uma mudança pedida no meio da construção reabre um pedaço de especificação. Evoluir um sistema em uso passa de novo pelas quatro: reespecificar o trecho que muda, redesenvolver, revalidar, entregar. As caixas do diagrama não são estanques; o que permanece é a pergunta de cada atividade.

Dois pares se confundem.

Especificação fecha o quê e as amarras. Serviço é o que o usuário consegue fazer (marcar consulta, registrar venda). Restrição é o que amarra operação ou processo: tempo de resposta, navegadores aceitos, linguagem exigida, lei de privacidade. Desenvolvimento fecha o como e o constrói: arquitetura, módulos, código.

Um documento que já descreve classes e interfaces saiu da especificação e entrou no desenvolvimento. "Funcionar no Chrome e no Safari" ainda é restrição de operação, logo especificação. A escolha da biblioteca fica no desenvolvimento. "Desenvolver na linguagem X" é restrição sobre o processo; também é especificação, distinta do ato de programar.

Validação pergunta se esta entrega está certa. Evolução altera um sistema já em uso. Corrigir um defeito encontrado no aceite ainda é validação (ou retrabalho de desenvolvimento). Trocar o layout do cupom fiscal um ano depois, porque a lei mudou, é evolução.

Especificar serviços e restrições em profundidade fica em Engenharia de Requisitos.

Fases nomeadas do ciclo

Uma organização clássica do ciclo, e o encaixe nas quatro atividades:

O planejamento não substitui a especificação. Viabilidade responde "vale a pena?" — mercado, prazo, custo, risco de não entregar. Requisitos respondem "o que o sistema fará, e sob quais restrições?". Dizer que o prazo é de seis meses é uma restrição de projeto; ainda não descreveu um serviço. Sem o segundo passo, o planejamento só autorizou um esforço sem alvo.

Projeto e implementação são as duas metades do desenvolvimento. No projeto, decide-se a arquitetura (quais módulos, quais interfaces, onde ficam os dados) e o detalhe o bastante para construir. Na implementação, esse desenho vira código integrado. Pular o projeto e ir direto à codificação encobre a metade do desenvolvimento que decide o como.

Teste é a fase em que a validação fica visível: o sistema montado é confrontado com o que se pediu. Revisões da especificação também validam, só que mais cedo — conferir o acordo antes de construir. Técnicas e tipos de teste pertencem à verificação e validação; aqui basta saber que essa conferência é a atividade de validação.

Implantação é a fronteira: o produto sai do laboratório e entra no uso (instalação, dados, treino). A partir daí, mudança é evolução — inclusive a "pequena" alteração de relatório que o usuário pede na segunda semana. Manutenção é o nome clássico dessa fase; a atividade, no mapa de Sommerville, é evolução.

O nome da fase varia (codificação no lugar de implementação, análise no lugar de requisitos). Reconheça a atividade por trás do rótulo.

Exemplo

Uma clínica pede um sistema de agendamento.

• "O paciente marca horário pela web; o sistema precisa funcionar nos navegadores mais usados; a consulta não pode cair em feriado." — especificação: um serviço (marcar) e duas restrições (navegador, calendário), ainda sem tela desenhada.
• Desenhar a agenda, o cadastro e o lembrete, e escrever o código. — desenvolvimento: o como e o construir.
• Um médico tenta marcar duas consultas no mesmo horário e o sistema recusa; um paciente marca pelo celular. — validação: esta entrega se comporta como combinado e como o uso exige.
• Seis meses depois, a clínica passa a atender em dois consultórios e o sistema precisa de duas agendas. — evolução: o produto já estava em uso; o mundo mudou.

Qual atividade é esta

Três trechos sobre o mesmo produto — um caixa de farmácia. O objetivo é nomear a atividade. O nome da fase no organograma pode enganar.

Contraste: espiral e RUP

O ciclo de vida não escolhe sozinho o ritmo. O modelo de processo decide se as quatro atividades correm uma vez, em sequência, ou em voltas.

Na cascata, uma passagem longa: especificar tudo, depois desenvolver, depois validar, depois evoluir. Cabe quando o quê é estável.

O desenvolvimento iterativo e incremental está em Desenvolvimento Iterativo e Incremental.

Na espiral (Boehm), cada volta é guiada por risco. Antes de construir o pedaço seguinte, a equipe nomeia o risco maior — tecnologia desconhecida, requisito incerto, prazo — trata dele (protótipo, estudo, piloto) e só então desenvolve e planeja a volta seguinte. As quatro atividades continuam lá; o que a espiral acrescenta é a ordem: tratar o que pode comprometer o projeto antes de ampliar o produto. Sem o passo de risco, a volta reduz-se a um incremento sem a lógica da espiral. Um portal de notas em que ninguém nunca integrou o serviço da Receita trata a integração na primeira volta e deixa o visual da página inicial para depois.

No RUP (Rational Unified Process) o recorte visível são quatro fases de negócio — concepção, elaboração, construção, transição — cada uma com uma ou mais iterações. As disciplinas (requisitos, análise, implementação, teste) atravessam as fases com intensidade diferente, não em blocos exclusivos:

• concepção — "vale o investimento?" (muita especificação, pouco código);
• elaboração — risco de arquitetura (especificação ainda forte, um pouco de desenvolvimento);
• construção — incrementos utilizáveis (muito desenvolvimento e validação);
• transição — produto em operação (validação de aceite e abertura da evolução).

Por ter iterações dentro de cada fase, o RUP difere da cascata linear, mesmo com nomes parecidos.

Espiral e RUP são duas formas de organizar as mesmas quatro atividades: um pelo risco, outro por fases de negócio com iterações. Modelos ágeis ficam em Desenvolvimento Ágil. O recorte interno de cada volta da espiral — setores, passos e o diagrama polar — vem a seguir.

Quatro setores de cada volta

Cada volta (loop) da espiral de Boehm tem quatro setores, nesta ordem:

1. Definição de objetivos — o que esta volta precisa decidir ou entregar, com alternativas e restrições da fatia.
2. Avaliação e redução dos riscos — nomear as incertezas e tratá-las, em geral com protótipo, estudo ou piloto.
3. Desenvolvimento e validação — só então construir e conferir a fatia desta volta.
4. Planejamento da volta seguinte — o que entra no próximo loop, dados os riscos que ainda restam.

A ordem é o procedimento. Sem objetivos, a volta não sabe o que atacar. Sem reduzir risco, o desenvolvimento amplia uma incerteza aberta. Sem o plano, a espiral para.

Esses setores não são as quatro atividades de Sommerville (especificação, desenvolvimento, validação, evolução): aquelas atravessam o processo inteiro; estes quatro organizam uma volta. Também não são as fases da cascata. Começar por requisitos, por identificação de riscos ou por planejamento inverte a ordem: objetivos abrem a volta; o plano da volta seguinte fecha.

O motor da espiral é tratar o que pode comprometer o projeto antes de gastar o desenvolvimento da fatia. Cada setor ocupa um quadrante do giro; o desenho disso fica no diagrama polar, mais abaixo.

Quatro passos do ciclo

O mesmo loop se descreve também como um ciclo de quatro passos: a mecânica de como a volta caminha, com ênfase nas alternativas e nas estratégias de risco.

1. Identificar os objetivos daquela volta.
2. Avaliar as alternativas à luz desses objetivos e dos riscos (incertezas e restrições do desenvolvimento).
3. Desenvolver estratégias que resolvam os riscos — simulação, prototipagem, estudo.
4. Planejar o próximo passo; a continuidade do processo fica determinada pelos riscos restantes.

Os passos 2 e 3 desdobram o setor de risco. O terceiro passo ainda é estratégia (simular, prototipar), não o desenvolvimento completo da fatia: construir e validar o produto da volta vem quando a estratégia já baixou o risco o bastante. O quarto passo não segue um calendário de cascata: decide se há próxima volta e o que ela ataca, só pelo que ainda não foi desarmado.

Sem avaliar alternativas, o protótipo ataca um caminho só. Sem amarrar o plano seguinte aos riscos restantes, a próxima volta deixa de ser guiada pelo que ainda pode comprometer o projeto.

Diagrama polar da espiral

Os quatro passos — e os quatro setores — ocupam os quadrantes de um mesmo giro. O modelo é evolutivo: cada volta acrescenta uma fatia, o produto amadurece, e o estado do projeto desenha-se como uma espiral no plano. Dois eixos:

• o raio (dimensão radial) é o custo acumulado dos vários passos do desenvolvimento — esforço, tempo, dinheiro gastos até ali;
• o ângulo (dimensão angular) é o progresso do projeto — quanto da volta, e das voltas, já se percorreu.

Cada quadrante avança cerca de um quarto de volta no ângulo; o raio no fim daquele passo já inclui o custo daquele setor. Uma volta completa é um giro; o raio no fim é maior que no começo, porque o custo só acumula. Uma volta cara (protótipo pesado) afasta a curva do centro. Uma volta barata (estudo curto) avança o ângulo com pouco crescimento do raio.

As coordenadas são polares: a distância ao centro reflete o custo acumulado; o ângulo, o progresso do projeto.

O desenho torna visível a troca. Tratar risco cedo cresce o raio no setor de avaliação para não pagar um raio ainda maior quando a fatia errada já estiver no produto.