Modelos de Ciclo de Vida (Cascata, Prototipação, Espiral, Incremental e RUP)

O que mais cai

Do que trata o tópico

Este tópico ensina como uma equipe organiza o trabalho de construir software do primeiro contato com o cliente até a manutenção do sistema em uso. O aluno aprende o que é um processo de software e um modelo de ciclo de vida, e depois estuda os modelos que a prova cobra: cascata, modelo em V, prototipação, espiral, incremental, desenvolvimento baseado em componentes, RUP, RAD e os modelos especializados. O tópico fecha com a norma ISO/IEC 12207, que descreve os processos do ciclo de vida do software sem impor um modelo.

Base de referência

• ISO/IEC/IEEE 12207:2017, Engenharia de sistemas e software, Processos do ciclo de vida do software (norma paga, explicada aqui com palavras próprias).
• ISO/IEC 12207:1995, primeira edição da mesma norma, citada para comparação, porque a prova ainda cobra a divisão dos processos dessa edição.

Conteúdo

Conceitos e outros modelos de desenvolvimento

Uma prefeitura contrata uma equipe para fazer o sistema de matrícula das escolas. Se cada programador começa a escrever código do jeito que acha melhor, ninguém sabe o que já está pronto, o que falta e quem testa o quê. A engenharia de software resolve esse problema com um processo de software, isto é, um conjunto organizado de atividades, ações e tarefas que levam à construção de um produto de software. O processo diz o que fazer, em que ordem e com que resultado em cada passo.

O ciclo de vida do software é o período que vai da ideia do sistema até a retirada dele de uso. O modelo de ciclo de vida, também chamado de modelo de processo, é uma representação simplificada de como as atividades se organizam ao longo desse período. O modelo não é o processo real de uma empresa: ele é um esquema genérico que a empresa adapta ao próprio projeto.

Atividades fundamentais

Os livros de engenharia de software descrevem as atividades presentes em qualquer processo, com nomes um pouco diferentes. Uma descrição usa quatro atividades fundamentais: especificação (definir o que o sistema faz), projeto e implementação (construir o sistema), validação (conferir se o sistema faz o que o cliente quer) e evolução (mudar o sistema quando a necessidade muda). Outra descrição usa cinco atividades metodológicas genéricas: comunicação, planejamento, modelagem, construção e entrega.

As cinco atividades metodológicas funcionam assim:

1. Comunicação: a equipe conversa com o cliente e com os usuários para entender os objetivos e levantar os requisitos.
2. Planejamento: a equipe define as tarefas, os riscos, os recursos, os produtos de trabalho e o cronograma.
3. Modelagem: a equipe cria modelos (diagramas, esboços) que ajudam a entender os requisitos e o projeto.
4. Construção: a equipe gera o código e faz os testes que revelam os erros.
5. Entrega: a equipe entrega o software ao cliente, que avalia o produto e dá o retorno.

Além delas existem as atividades de apoio, chamadas também de atividades guarda-chuva, porque cobrem o projeto inteiro e não uma fase só. Entre elas estão o controle e acompanhamento do projeto, a gestão de riscos, a garantia da qualidade, as revisões técnicas, a medição, o gerenciamento de configuração, o gerenciamento da reusabilidade e a produção dos artefatos, isto é, dos documentos, modelos e códigos que o processo gera.

Fluxo do processo

O fluxo do processo descreve como as atividades metodológicas se encadeiam no tempo. No fluxo linear, as cinco atividades acontecem uma vez, em sequência, e no fluxo iterativo, uma ou mais atividades se repetem antes de a equipe passar adiante. No fluxo evolucionário, as atividades se repetem em ciclos, e cada ciclo produz uma versão mais completa do software. No fluxo paralelo, duas ou mais atividades acontecem ao mesmo tempo, como a modelagem de uma parte enquanto a construção de outra já começou.

Modelos prescritivos e modelos ágeis

Os modelos prescritivos, também chamados de tradicionais ou dirigidos por plano, definem um conjunto de atividades, tarefas, marcos e produtos de trabalho e esperam que a equipe planeje o projeto antes de executá-lo. O cascata, o modelo em V, o incremental, o espiral e o RUP são prescritivos. Os métodos ágeis reduzem a documentação formal, entregam software em ciclos curtos e aceitam a mudança de requisito a qualquer momento. A diferença entre os dois grupos é de ênfase, e não de presença ou ausência de planejamento: o ágil também planeja, mas planeja em horizontes curtos.

Codifica e remenda

O modelo codifica e remenda (code and fix) é a ausência de modelo: o programador escreve, testa e corrige, sem requisito documentado e sem projeto. Ele serve para um programa pequeno e descartável, mas num sistema grande gera código difícil de manter.

RAD

O RAD (Rapid Application Development, desenvolvimento rápido de aplicação) é um modelo incremental que enfatiza um ciclo de desenvolvimento muito curto. Ele alcança a rapidez com o reúso de componentes, com ferramentas que geram código e com várias equipes trabalhando em paralelo, cada uma numa função do sistema. Os livros citam como referência um sistema completo em um período curto, de 60 a 90 dias, quando os requisitos são bem entendidos e o escopo é restrito.

O RAD exige pessoal suficiente para formar várias equipes, exige desenvolvedores e clientes comprometidos com o prazo curto e não serve quando o sistema não pode ser dividido em módulos, quando o desempenho é crítico ou quando o risco técnico é alto, como no uso de uma tecnologia nova.

Modelo de desenvolvimento concorrente

O modelo concorrente, também chamado de engenharia concorrente, representa cada atividade do processo como uma máquina de estados. Uma atividade pode estar em estados como inativa, em desenvolvimento, aguardando modificações, em revisão, em linha de base ou concluída. Um evento muda o estado: se o cliente pede uma mudança de requisito, a atividade de modelagem sai de concluída e vai para aguardando modificações, enquanto a construção continua em outra parte.

No modelo concorrente, todas as atividades existem ao mesmo tempo, cada uma num estado diferente, e a atividade não termina de vez: um evento pode reabri-la.

Métodos formais e sala limpa

O modelo de métodos formais usa notação matemática para especificar, desenvolver e verificar o software. Com a especificação em linguagem matemática, a equipe prova que o programa atende à especificação e elimina ambiguidade, incompletude e inconsistência antes do teste. A sala limpa (cleanroom) é uma variante que usa a verificação formal e o teste estatístico para evitar o defeito, em vez de achá-lo e corrigi-lo depois.

Os métodos formais custam caro, exigem pessoal com formação em matemática e não servem para conversar com o cliente, que não lê a notação. Por isso aparecem em sistemas críticos, como controle de tráfego aéreo e equipamento médico.

Desenvolvimento orientado a aspectos

O desenvolvimento de software orientado a aspectos trata dos interesses transversais (crosscutting concerns), isto é, das funções que se espalham por muitas partes do sistema, como segurança, registro de log, controle de transação e tratamento de erro. Em vez de repetir o código de log em cada classe, a equipe escreve um aspecto, que é um módulo separado com esse interesse, e o mecanismo da linguagem aplica o aspecto nos pontos indicados. O modelo resolve o espalhamento e o entrelaçamento de código.

Exemplo resolvido: classificar o modelo indicado para quatro situações.

1. Um tribunal precisa de um módulo de consulta de processos em 75 dias, com requisitos claros e componentes prontos da casa. O modelo indicado é o RAD: prazo curto, requisitos bem entendidos e reúso.
2. Uma empresa de equipamentos médicos faz o software de uma bomba de infusão. O modelo indicado é o de métodos formais, porque o defeito pode ferir o paciente.
3. Uma equipe repete o mesmo código de auditoria de acesso em 300 classes. O modelo indicado é o orientado a aspectos, porque a auditoria é um interesse transversal.
4. Numa equipe, o cliente pede uma mudança de requisito, e a modelagem volta ao estado aguardando modificações enquanto a construção de outra parte continua. O modelo que descreve essa situação é o concorrente, porque cada atividade tem o seu estado e um evento reabre a atividade concluída.

A diferença que a banca mais troca nesta parte é entre processo e modelo. O processo é o conjunto real de atividades que a equipe executa; o modelo é a representação abstrata desse processo. Outra troca frequente é entre atividade metodológica (comunicação, planejamento, modelagem, construção e entrega) e atividade de apoio (gestão de riscos, qualidade, configuração), que acompanha todas as outras.

O erro comum é achar que o RAD serve para qualquer sistema porque é rápido. O RAD depende de requisitos claros, de módulos independentes e de equipes suficientes, e falha no sistema de alto risco técnico ou de desempenho crítico.

Como a banca cobra: a banca troca o nome do modelo pela característica de outro (prazo curto do RAD atribuído a aspectos, estados do concorrente atribuídos ao espiral) e confunde atividade metodológica com atividade de apoio. Ela também cobra as condições em que o RAD não serve.

Modelo em cascata ou clássico

Uma empresa precisa trocar o sistema de folha de pagamento de um órgão, e as regras de cálculo estão escritas e não vão mudar durante o projeto. Nessa situação faz sentido levantar todos os requisitos primeiro, projetar tudo, programar tudo e só então testar e entregar. Esse é o modelo em cascata, também chamado de modelo clássico, sequencial linear ou ciclo de vida clássico, em que cada fase começa quando a anterior termina e o resultado de uma fase desce para a seguinte, como a água de uma cascata.

O modelo foi descrito por Winston Royce. O próprio Royce apontou o risco de seguir as fases sem retorno e defendeu a iteração entre fases vizinhas e a construção de uma versão preliminar, mas o modelo ficou conhecido na forma estritamente sequencial.

Fases

Uma descrição comum divide o cascata em cinco fases:

1. Definição de requisitos: a equipe consulta os usuários e define os serviços, as restrições e as metas do sistema. Sai daqui a especificação de requisitos.
2. Projeto de sistema e de software: a equipe define a arquitetura geral, divide os requisitos entre hardware e software e descreve as abstrações do software. Sai daqui o documento de projeto.
3. Implementação e teste de unidade: a equipe programa os módulos e testa cada unidade isoladamente. Saem daqui as unidades testadas.
4. Integração e teste de sistema: a equipe junta as unidades, testa o sistema completo e entrega o software ao cliente.
5. Operação e manutenção: o sistema entra em uso, e a equipe corrige os erros que não apareceram antes e ajusta o sistema a novas necessidades. Em geral, é a fase mais longa do ciclo de vida.

Outra descrição usa as cinco atividades metodológicas em sequência, de comunicação a entrega, com o mesmo sentido.

Características

O cascata é dirigido por documentos: ao fim de cada fase, um ou mais documentos são aprovados, e essa aprovação é o marco que libera a fase seguinte. Por isso o gerente enxerga bem o andamento do projeto, porque sabe quantos documentos já foram aprovados. O cliente, porém, só vê o sistema funcionando no fim, depois da integração.

Na forma pura, o cascata não volta atrás. Na prática, a maioria das descrições admite a retroalimentação, isto é, o retorno a uma fase anterior quando a fase atual acha um erro. Essa versão se chama cascata com retroalimentação (ou com realimentação), e ela continua sequencial: o retorno corrige a fase anterior, mas a ordem das fases não muda.

Vantagens e limites

As vantagens são a disciplina, a documentação completa e o controle fácil pelo gerente. O cascata é indicado quando os requisitos são bem entendidos e estáveis, quando o sistema é crítico e exige documentação formal e quando o software faz parte de um sistema maior, com hardware feito por outras equipes.

Os limites aparecem quando o requisito não está claro ou muda. Os livros apontam três problemas:

1. Projetos reais raramente seguem o fluxo sequencial, e uma mudança no meio do caminho causa confusão.
2. O cliente tem dificuldade de declarar todos os requisitos no começo, e o cascata exige isso.
3. O cliente precisa de paciência, porque a versão executável do programa só aparece no fim do projeto, e um erro grave descoberto nessa hora custa caro.

Há também o estado de bloqueio: uma parte da equipe fica parada esperando que outra termine a fase da qual depende. O custo de corrigir um erro de requisito cresce a cada fase em que ele passa sem ser visto, porque o erro desce para o projeto, para o código e para os testes.

O modelo em V

O modelo em V é uma variação do cascata que liga cada fase de desenvolvimento a uma fase de teste. O lado esquerdo do V desce pelas fases de especificação, do requisito ao projeto detalhado; a base do V é a codificação; o lado direito sobe pelos testes, do teste de unidade ao teste de aceitação. Cada teste do lado direito valida o produto da fase correspondente do lado esquerdo.

As ligações do V são estas:

1. O requisito do cliente é validado pelo teste de aceitação.
2. A especificação do sistema é validada pelo teste de sistema.
3. O projeto da arquitetura é validado pelo teste de integração.
4. O projeto dos componentes é validado pelo teste de unidade.

O V não muda a ordem do cascata. A diferença é que ele planeja o teste de cada nível na fase de especificação correspondente: o plano do teste de aceitação nasce junto com os requisitos. Por isso o V é associado à verificação e à validação.

Exemplo resolvido: decidir se o cascata serve em três projetos.

1. Um órgão refaz o cálculo de um tributo já existente, com regras escritas e estáveis, e o contrato exige documento aprovado em cada etapa. O cascata serve: requisito estável, controle por documento e escopo fechado.
2. Uma startup cria um aplicativo novo de serviços para o cidadão, e ninguém sabe ainda quais telas o público vai usar. O cascata não serve: o requisito é incerto e vai mudar, e o produto só apareceria no fim.
3. Uma equipe faz o software embarcado de um equipamento cujo hardware outra equipe constrói, com as interfaces fixadas em contrato. O cascata serve, ou a sua variação em V: o software faz parte de um sistema maior, e o requisito fica fixo junto com o hardware.

Na prática, a equipe da folha de pagamento aprova a especificação com o setor de pessoal, aprova o projeto, programa, integra e roda a folha em paralelo com o sistema antigo. Se o teste de sistema acha um erro de requisito, a equipe volta à especificação e desce de novo pelas fases.

A diferença para o incremental é que o cascata entrega o sistema inteiro de uma vez, no fim, e o incremental entrega partes que funcionam ao longo do projeto. A diferença para o espiral é que o cascata não tem análise de risco explícita em cada ciclo.

O erro comum é dizer que o cascata não tem nenhuma volta. A versão com retroalimentação permite voltar à fase anterior, e o próprio Royce já recomendava esse retorno; o que define o cascata é a sequência das fases, e não a proibição de corrigir.

Como a banca cobra: a banca apresenta o cascata como iterativo, como adequado a requisitos instáveis ou como modelo que mostra cedo o software ao cliente. Ela também cobra as ligações do modelo em V e o papel de Royce.

Prototipação

Um gestor de um hospital público pede um sistema de controle de leitos, mas não consegue dizer quais informações precisa ver na tela nem em que ordem. Ele diz que vai saber quando ver. A prototipação resolve esse problema: a equipe constrói depressa uma versão parcial do sistema, o protótipo, mostra ao gestor e usa a reação dele para descobrir os requisitos. O protótipo é um modelo do sistema que existe para responder a perguntas, e não para entrar em produção.

A prototipação serve quando o cliente define objetivos gerais, mas não define em detalhe as entradas, o processamento e as saídas, ou quando a equipe tem dúvida sobre um algoritmo, sobre o sistema operacional ou sobre a forma da interação com o usuário. Alguns livros tratam a prototipação como um modelo de processo próprio, dentro dos modelos evolucionários. Outros a tratam como uma técnica que cabe dentro de qualquer modelo, em especial na engenharia de requisitos e no projeto da interface.

Como funciona, passo a passo

O paradigma da prototipação segue um ciclo curto que se repete:

1. Comunicação: a equipe se reúne com o cliente e levanta os objetivos gerais e os requisitos já conhecidos. Sai daqui uma lista inicial de necessidades e de dúvidas.
2. Plano rápido: a equipe planeja uma iteração curta de prototipação.
3. Modelagem por projeto rápido: a equipe desenha só o que o usuário vai ver, como telas, formatos de saída e fluxo de navegação.
4. Construção do protótipo: a equipe monta o protótipo depressa, com ferramentas que aceleram a montagem.
5. Entrega e retorno: o cliente usa o protótipo e diz o que está certo, o que falta e o que muda. O retorno refina os requisitos, e o ciclo recomeça até que os requisitos fiquem claros.

Tipos de protótipo

O protótipo descartável (throwaway) serve só para entender o requisito. Depois que o cliente aprova a ideia, a equipe joga o protótipo fora e constrói o sistema real com a qualidade de produção. Ele é feito depressa, sem cuidar de desempenho nem de manutenção, e não pode virar o produto.

O protótipo evolutivo (evolucionário) é a primeira versão do próprio sistema. A equipe começa pelas partes mais bem entendidas, mostra ao cliente e acrescenta funções a cada ciclo, até o protótipo virar o produto final. Ele precisa ter qualidade de produção desde o começo, porque não será descartado.

Os protótipos também se classificam pela fidelidade e pela abrangência:

1. O protótipo de baixa fidelidade é feito em papel, em esboço ou em quadro, e testa a ideia e o fluxo das telas a custo quase zero.
2. O protótipo de alta fidelidade parece o sistema real, com telas navegáveis e aparência final, e testa a usabilidade em detalhe.
3. O protótipo horizontal mostra muitas funções, mas só na superfície (as telas sem a lógica por trás). Ele serve para validar a interface e o escopo.
4. O protótipo vertical implementa poucas funções em profundidade, da tela ao banco de dados. Ele serve para testar uma questão técnica, como o desempenho de um cálculo.

Vantagens e limites

A prototipação reduz o risco de construir o sistema errado, porque o usuário vê e mexe antes de o sistema existir, e revela cedo requisitos esquecidos e problemas de usabilidade.

Os livros apontam dois problemas principais. O primeiro está no cliente: ele vê uma versão que parece funcionar e pede alguns ajustes para colocá-la em uso, sem saber que o protótipo foi feito sem qualidade, sem pensar na manutenção e com atalhos técnicos. O segundo está no desenvolvedor: para fazer o protótipo depressa, ele usa um sistema operacional ou uma linguagem inadequados, ou um algoritmo ineficiente, e depois se acostuma com essas escolhas, que acabam ficando no sistema final.

Exemplo resolvido: escolher o tipo de protótipo em três situações.

1. A equipe quer saber se os servidores de um órgão entendem a ordem das telas de um pedido de férias. A escolha é um protótipo de baixa fidelidade, em papel, porque a pergunta é sobre o fluxo, e não sobre o código.
2. A equipe tem dúvida se o banco de dados responde em menos de dois segundos a uma consulta com milhões de registros. A escolha é um protótipo vertical, que vai da tela ao banco nessa única função.
3. O cliente quer um sistema que ele mesmo vai descobrir aos poucos, e a equipe planeja crescer o sistema a partir da primeira versão. A escolha é o protótipo evolutivo, com qualidade de produção desde o início.

Na prática, a equipe do hospital monta em dois dias um protótipo navegável do painel de leitos, com dados fictícios. O gestor percebe que precisa do tempo de espera do paciente na tela principal, e a equipe registra o requisito e descarta o protótipo.

A diferença para o incremental é que o primeiro incremento é um produto operacional, que o cliente já usa no trabalho, e o protótipo descartável não entra em uso. A diferença para o espiral é que o espiral pode usar protótipos em cada volta, mas o objetivo dele é reduzir risco, e o protótipo é só um dos meios.

O erro comum é tratar todo protótipo como descartável ou todo protótipo como base do sistema. O descartável é jogado fora; o evolutivo vira o produto e por isso exige qualidade desde o começo.

Como a banca cobra: a banca afirma que o protótipo descartável pode virar o produto final, troca horizontal por vertical e cobra os dois problemas da prototipação (o cliente que quer usar o protótipo e o desenvolvedor que mantém as escolhas ruins).

Modelos evolucionários (espiral, incremental e CBD)

O requisito de um sistema grande muda enquanto a equipe trabalha. Os modelos evolucionários respondem a isso com ciclos: cada ciclo produz uma versão mais completa do software, e o retorno do cliente orienta o ciclo seguinte. Esta parte estuda o incremental, o espiral e o desenvolvimento baseado em componentes (CBD, do inglês Component-Based Development).

A classificação muda de livro para livro: uma obra clássica põe o incremental num grupo próprio e o desenvolvimento baseado em componentes entre os modelos especializados, mas diz que este é evolucionário por natureza.

Iterativo e incremental

Antes dos modelos, convém separar dois termos que a banca troca. O desenvolvimento iterativo repete ciclos e refina o que já existe: a cada iteração, uma parte do sistema fica melhor. O desenvolvimento incremental entrega o sistema em partes, e cada parte nova acrescenta funções ao que já estava entregue. Um modelo pode ser iterativo e incremental ao mesmo tempo, como o RUP e os métodos ágeis.

Modelo incremental

O modelo incremental combina o fluxo linear com o fluxo paralelo. A equipe aplica sequências lineares (comunicação, planejamento, modelagem, construção e entrega) de forma escalonada no tempo, e cada sequência produz um incremento, isto é, uma parte do software que funciona e pode ser entregue ao cliente. O primeiro incremento costuma ser o núcleo do produto (core product): ele atende aos requisitos básicos, e os recursos complementares ficam para os incrementos seguintes.

O funcionamento segue estes passos:

1. A equipe levanta os requisitos gerais e os divide em incrementos, por prioridade do cliente.
2. A equipe desenvolve o primeiro incremento, o núcleo, e o entrega para uso.
3. O cliente usa o núcleo e avalia. A avaliação gera o plano do incremento seguinte.
4. A equipe desenvolve o segundo incremento, que soma funções ao núcleo, e o entrega.
5. O ciclo se repete até o produto ficar completo.

Um exemplo clássico é o editor de texto. O primeiro incremento traz o gerenciamento de arquivos e a edição básica; o segundo, uma edição mais sofisticada; o terceiro, a revisão ortográfica e gramatical; o quarto, a formatação avançada de página.

O incremental é útil quando não há pessoal para fazer o sistema inteiro no prazo, porque os primeiros incrementos podem ser feitos com menos gente. Ele também contorna risco técnico: a parte que depende de um hardware ainda não entregue fica para um incremento posterior.

As vantagens são a entrega cedo de valor, o retorno do cliente sobre o software real, o custo menor de acomodar mudança e o risco menor de fracasso total, porque as funções mais importantes chegam primeiro e são as mais testadas. Os limites são o processo menos visível para o gerente, que não mede o andamento por documentos, e a estrutura do sistema, que tende a se degradar quando cada incremento acrescenta código sem refatoração.

Exemplo resolvido: comparar a primeira entrega no cascata e no incremental.

1. Um sistema tem quatro módulos, e cada módulo leva 8 semanas de trabalho da equipe.
2. No cascata, o cliente recebe o sistema só no fim: 4 × 8 = 32 semanas.
3. No incremental, o primeiro incremento (o núcleo, com o módulo mais importante) é entregue na semana 8.
4. O cliente usa o núcleo a partir da semana 8 e dá o retorno, que ajusta os três incrementos seguintes. O sistema completo continua perto das 32 semanas, mas o primeiro valor chega 24 semanas antes.

Modelo espiral

O modelo espiral foi proposto por Barry Boehm e é um modelo evolucionário orientado a riscos. Ele junta a natureza iterativa da prototipação com os aspectos controlados e sistemáticos do cascata. O processo é desenhado como uma espiral: cada volta é uma fase do projeto, e em cada volta a equipe avalia os riscos antes de seguir.

Cada volta passa por quatro setores:

1. Definição de objetivos: a equipe define os objetivos daquela fase, as restrições e as alternativas, e faz um plano detalhado. Os riscos do projeto são identificados.
2. Avaliação e redução de riscos: para cada risco, a equipe faz uma análise e toma medidas para reduzi-lo. Se o risco é um requisito obscuro, a medida pode ser um protótipo.
3. Desenvolvimento e validação: a equipe escolhe o modelo de desenvolvimento para aquela volta, conforme o risco que sobrou, e constrói e valida o produto daquela fase.
4. Planejamento: a equipe revisa o projeto com o cliente e decide se continua para a próxima volta. Se continua, planeja a próxima fase.

Na espiral, a dimensão do raio representa o custo acumulado do projeto, e a dimensão angular representa o progresso em cada volta. As primeiras voltas podem produzir só a especificação ou um protótipo; as voltas seguintes produzem versões cada vez mais completas. Os marcos de ponto âncora registram os produtos e as condições obtidas a cada passagem.

O espiral é chamado de metamodelo, porque pode incorporar outros modelos em suas voltas. Se o risco da interface é alto, a volta usa prototipação; se os requisitos de uma parte são estáveis e o risco que resta é de integração, a volta pode usar o cascata.

As vantagens são o tratamento explícito do risco, a adequação a sistemas grandes e complexos e a flexibilidade para usar o modelo certo em cada volta. Os limites são a dificuldade de convencer o cliente de que a evolução é controlável, a dependência de pessoal com experiência em análise de risco e o custo alto para projetos pequenos.

Exemplo resolvido: ordenar os riscos de uma volta pela exposição ao risco. A exposição ao risco é o produto da probabilidade pela perda que o risco causa:

Nessa fórmula, ER é a exposição ao risco, P é a probabilidade de o risco acontecer (de 0 a 1) e C é o custo que o projeto sofre se o risco acontece.

1. Risco A, a tecnologia nova não aguentar a carga: P = 0,3 e C = R$ 200.000,00. ER = 0,3 × 200.000 = R$ 60.000,00.
2. Risco B, o órgão parceiro atrasar a integração: P = 0,1 e C = R$ 500.000,00. ER = 0,1 × 500.000 = R$ 50.000,00.
3. Risco C, um requisito da tela mudar: P = 0,5 e C = R$ 40.000,00. ER = 0,5 × 40.000 = R$ 20.000,00.
4. A ordem de tratamento é A, B e C. Na volta, a equipe ataca primeiro o risco A, por exemplo com um protótipo vertical que testa a carga.

Desenvolvimento baseado em componentes (CBD)

O desenvolvimento baseado em componentes constrói o sistema montando componentes de software já existentes, em vez de escrever tudo do zero. Os componentes podem ser comerciais de prateleira (COTS, do inglês commercial off-the-shelf), comprados de um fornecedor, ou desenvolvidos antes pela própria organização. O modelo é evolucionário e iterativo, como o espiral, e o foco é o reúso.

As etapas do modelo são estas:

1. A equipe pesquisa e avalia os componentes disponíveis para o domínio da aplicação.
2. A equipe considera as questões de integração dos componentes escolhidos.
3. A equipe projeta uma arquitetura de software que acomode os componentes.
4. A equipe integra os componentes à arquitetura.
5. A equipe faz testes abrangentes para garantir que o conjunto funciona.

O CBD reduz o tempo de desenvolvimento e o custo, porque o componente já existe e já foi testado. O preço é a perda de controle sobre a evolução do componente, que depende do fornecedor, e o ajuste dos requisitos ao que os componentes oferecem.

Na prática, um tribunal que precisa de um sistema de diárias usa um componente pronto de cálculo, um de autenticação já usado na casa e um comercial de relatórios, e programa só o que nenhum deles cobre.

A diferença que a banca mais cobra é entre o incremental e o espiral. O incremental entrega partes operacionais e é guiado pela prioridade do cliente; o espiral é guiado pelo risco e pode, nas primeiras voltas, produzir só especificação e protótipo.

O erro comum é dizer que o espiral entrega um produto operacional a cada volta. As primeiras voltas podem produzir só a especificação ou um protótipo, e quem entrega uma parte operacional em cada ciclo é o incremental.

Como a banca cobra: a banca troca o critério do espiral (risco) pelo do incremental (prioridade do cliente), afirma que o espiral serve bem a projetos pequenos e confunde iterativo com incremental. Ela também cobra os quatro setores de cada volta e a ideia de metamodelo.

RUP (Rational Unified Process) e Processo Unificado

Uma empresa grande desenvolve um sistema de arrecadação para um estado, com dezenas de profissionais, e precisa de um processo que diga quem faz cada coisa, que documentos saem de cada etapa e como o projeto avança em ciclos. O Processo Unificado (UP, do inglês Unified Process) foi criado por Ivar Jacobson, Grady Booch e James Rumbaugh, os mesmos autores da UML, para responder a essa necessidade. O RUP (Rational Unified Process) é a versão comercial e detalhada do Processo Unificado, criada pela Rational Software, empresa depois comprada pela IBM.

O RUP é um framework de processo, isto é, uma estrutura que a organização adapta a cada projeto: um projeto pequeno usa poucos artefatos, e um projeto grande usa muitos.

As três características

O Processo Unificado tem três características que a prova cobra sempre juntas:

1. É dirigido por casos de uso: os casos de uso, que descrevem como o usuário interage com o sistema, guiam a análise, o projeto, a implementação e o teste.
2. É centrado na arquitetura: a equipe define cedo uma arquitetura robusta e a valida antes de construir o grosso do sistema.
3. É iterativo e incremental: o projeto é dividido em iterações, e cada iteração produz um incremento do sistema que funciona.

As duas dimensões

O RUP se desenha em duas dimensões. A dimensão horizontal é a do tempo, dividida em fases e iterações, e mostra o aspecto dinâmico do processo. A dimensão vertical é a das disciplinas (também chamadas de fluxos de trabalho), que agrupam as atividades por assunto, e mostra o aspecto estático. O desenho que cruza as duas dimensões mostra o esforço de cada disciplina subindo e descendo ao longo das fases.

As quatro fases e os marcos

O RUP tem quatro fases, e cada fase termina num marco, isto é, num ponto de decisão em que os responsáveis avaliam se o projeto pode seguir:

1. Concepção (ou iniciação): a equipe define o escopo, o caso de negócio (a justificativa econômica do projeto), os riscos principais e os casos de uso essenciais. O marco é o dos objetivos do ciclo de vida.
2. Elaboração: a equipe analisa o domínio do problema, detalha a maior parte dos requisitos, trata os riscos maiores e estabelece a arquitetura executável, uma linha de base da arquitetura que já roda. O marco é o da arquitetura do ciclo de vida.
3. Construção: a equipe desenvolve e testa a maior parte do código, a partir da arquitetura validada. Em geral, é a fase mais longa. O marco é o da capacidade operacional inicial, quando o sistema já pode ser usado pelos primeiros usuários.
4. Transição: a equipe entrega o sistema à comunidade de usuários, com teste beta, treinamento, conversão de dados e correção dos últimos problemas. O marco é o do lançamento do produto.

Cada fase pode ter uma ou mais iterações, e cada iteração passa por várias disciplinas. A fase não é uma disciplina: na elaboração, por exemplo, a equipe também implementa e testa, porque a arquitetura executável precisa rodar.

Um livro clássico de engenharia de software descreve o Processo Unificado com cinco fases, e não quatro: concepção, elaboração, construção, transição e produção, em que o software é monitorado em uso e recebe suporte. A prova pode cobrar as duas descrições, e o enunciado diz qual delas usa; quando fala do RUP da Rational, as fases são quatro.

As nove disciplinas

O RUP tem nove disciplinas. As seis disciplinas de engenharia são:

1. Modelagem de negócios: entender a organização em que o sistema vai funcionar.
2. Requisitos: definir o que o sistema deve fazer, com casos de uso.
3. Análise e design (projeto): transformar os requisitos num projeto do sistema.
4. Implementação: programar e testar as unidades.
5. Teste: verificar o sistema e a integração das partes.
6. Implantação: entregar o sistema aos usuários.

As três disciplinas de suporte (de apoio) são: gerenciamento de configuração e mudança, gerenciamento de projeto e ambiente. A disciplina de ambiente cuida das ferramentas e do processo que a equipe usa.

Os elementos do processo

O RUP descreve o trabalho com quatro elementos básicos. O papel diz quem faz (analista de sistemas, arquiteto, testador), e a atividade diz como se faz, como unidade de trabalho de um papel. O artefato diz o que se produz (modelo de casos de uso, documento de arquitetura, código, plano de teste). A disciplina, ou fluxo de trabalho, diz quando as atividades acontecem e em que sequência.

As boas práticas

O RUP reúne seis boas práticas de desenvolvimento:

1. Desenvolver de forma iterativa.
2. Gerenciar os requisitos.
3. Usar arquiteturas baseadas em componentes.
4. Modelar visualmente o software, com a UML.
5. Verificar a qualidade de forma contínua.
6. Controlar as mudanças no software.

Para descrever a arquitetura, o RUP usa a visão 4+1, proposta por Philippe Kruchten. Ela tem quatro visões (lógica, de processo, de implementação e de implantação) e uma quinta visão, a de casos de uso (os cenários), que liga as outras quatro.

Exemplo resolvido: dizer em que fase do RUP está cada situação do sistema de arrecadação.

1. A equipe escreve o caso de negócio, estima o custo e lista os casos de uso essenciais. É a concepção.
2. A equipe constrói e testa o esqueleto do sistema, com as camadas e a integração com o banco, para provar que a arquitetura aguenta a carga. É a elaboração, porque o objetivo é a arquitetura executável.
3. A equipe programa os módulos de cálculo, de boletos e de relatórios sobre a arquitetura aprovada. É a construção.
4. A equipe faz o teste beta com três delegacias fiscais, treina os servidores e migra os dados do sistema antigo. É a transição.

Na prática, o gerente do projeto de arrecadação planeja duas iterações na elaboração, porque o risco da integração com o banco é alto. Se a arquitetura não aguenta a carga, ele a refaz antes do marco, e não na construção, onde a correção custaria mais.

A diferença para o cascata é que, no RUP, as disciplinas se repetem em todas as fases e o software executável aparece cedo; no cascata, cada fase é uma atividade só, e o executável aparece no fim.

O erro comum é confundir fase com disciplina, como dizer que a fase de elaboração é a fase de análise e design. As fases são do tempo (concepção, elaboração, construção e transição); as disciplinas são do assunto (requisitos, análise e design, implementação, teste) e acontecem em várias fases.

Como a banca cobra: a banca troca os marcos entre as fases, chama disciplina de fase e põe a modelagem de negócios entre as disciplinas de suporte. Ela também cobra as três características do Processo Unificado e a visão 4+1.

ISO/IEC 12207

Um órgão público contrata uma empresa para fazer um sistema e outra para mantê-lo. Para que as duas empresas e o órgão falem a mesma língua sobre aquisição, fornecimento, desenvolvimento, operação e manutenção, existe a ISO/IEC 12207, norma internacional que descreve os processos do ciclo de vida do software. Ela dá um vocabulário comum e uma estrutura de processos que o órgão pode exigir em contrato.

A norma não impõe um modelo de ciclo de vida nem um método de desenvolvimento. Ela diz quais processos existem, qual o propósito de cada um e que resultados ele produz, e cada organização escolhe o modelo (cascata, incremental, espiral, ágil) e encaixa os processos nele. Essa é a cobrança mais frequente: quem afirma que a norma obriga o cascata ou qualquer outro modelo erra.

Estrutura

A norma organiza o trabalho numa hierarquia: cada processo se divide em atividades, e cada atividade se divide em tarefas. Cada processo tem um propósito e uma lista de resultados esperados. A norma também prevê a adaptação (tailoring): a organização tira ou ajusta processos, atividades e tarefas que não se aplicam ao projeto, e registra a decisão.

A conformidade com a norma pode ser plena, quando a organização cumpre todos os requisitos dos processos declarados, ou adaptada, quando cumpre os requisitos conforme a adaptação que fez e justificou.

Edição de 1995

A primeira edição, de 1995, dividia os processos em três classes:

1. Processos fundamentais (ou primários): aquisição, fornecimento, desenvolvimento, operação e manutenção. São os processos que iniciam ou executam o desenvolvimento, a operação ou a manutenção do software.
2. Processos de apoio: documentação, gerência de configuração, garantia da qualidade, verificação, validação, revisão conjunta, auditoria e resolução de problemas. Eles apoiam outro processo e contribuem para a qualidade do projeto.
3. Processos organizacionais: gerência, infraestrutura, melhoria e treinamento. A organização usa esses processos para criar e manter a estrutura que sustenta os outros.

A edição de 1995 tinha ainda um processo de adaptação, num anexo, que orientava o ajuste da norma ao projeto. A diferença entre verificação e validação aparece aqui: a verificação confere se o produto foi feito do jeito certo, conforme a especificação; a validação confere se o produto certo foi feito, conforme o uso pretendido.

Edição de 2008

A edição de 2008 alinhou a norma à norma de processos do ciclo de vida de sistemas, a ISO/IEC 15288. Ela separou os processos em dois blocos: os processos de contexto de sistema (acordo, organizacionais habilitadores de projeto, de projeto e técnicos) e os processos específicos de software (implementação de software, apoio ao software e reúso de software).

Edição de 2017

A edição de 2017, ISO/IEC/IEEE 12207:2017, foi feita em conjunto com o IEEE e é alinhada à ISO/IEC/IEEE 15288:2015. Ela tem 30 processos em quatro grupos:

1. Processos de acordo (2): aquisição e fornecimento.
2. Processos organizacionais habilitadores de projeto (6): gestão do modelo de ciclo de vida, gestão de infraestrutura, gestão de portfólio, gestão de recursos humanos, gestão da qualidade e gestão do conhecimento.
3. Processos de gestão técnica (8): planejamento do projeto, avaliação e controle do projeto, gestão de decisões, gestão de riscos, gestão de configuração, gestão da informação, medição e garantia da qualidade.
4. Processos técnicos (14): análise do negócio ou da missão, definição de necessidades e requisitos das partes interessadas, definição de requisitos do sistema ou do software, definição da arquitetura, definição do projeto, análise do sistema, implementação, integração, verificação, transição, validação, operação, manutenção e descarte.

Exemplo resolvido: classificar processos pelas duas edições.

1. A gerência de configuração era um processo de apoio em 1995. Em 2017, a gestão de configuração está nos processos de gestão técnica.
2. A garantia da qualidade era processo de apoio em 1995. Em 2017, a garantia da qualidade está na gestão técnica, e a gestão da qualidade está nos processos organizacionais habilitadores de projeto.
3. A manutenção era processo fundamental em 1995. Em 2017, ela está nos processos técnicos.
4. A aquisição era processo fundamental em 1995. Em 2017, ela está nos processos de acordo, ao lado do fornecimento.

Na prática, o órgão usa o processo de aquisição para escolher o fornecedor e aceitar o produto, e a empresa contratada usa o processo de fornecimento para executar o contrato. O contrato pode exigir os processos da norma sem exigir um modelo de ciclo de vida.

A diferença para os modelos de ciclo de vida é que a norma lista processos e resultados, e o modelo organiza a ordem desses processos no tempo.

O erro comum é misturar as edições: dizer que a edição de 2017 tem as classes de processos fundamentais, de apoio e organizacionais. Essa divisão é de 1995; a edição de 2017 usa os grupos de acordo, organizacionais habilitadores de projeto, de gestão técnica e técnicos.

Como a banca cobra: a banca afirma que a norma impõe um modelo de ciclo de vida, troca processos entre as classes da edição de 1995 (verificação como fundamental, documentação como organizacional) e mistura os grupos da edição de 2017.

Engenharia de software baseada em componentes (ESBC)

Cada órgão de um estado escreve o próprio código de autenticação de usuário, de envio de e-mail e de geração de relatório em PDF. O mesmo trabalho se repete dezenas de vezes, com dezenas de defeitos diferentes. A engenharia de software baseada em componentes (ESBC, ou CBSE, do inglês Component-Based Software Engineering) resolve esse desperdício: ela define, implementa e compõe componentes independentes, com interfaces bem definidas, para montar sistemas a partir de peças reutilizáveis.

Um componente é uma unidade de software independente, que oferece serviços por meio de interfaces e pode ser composta com outros componentes. O componente é uma caixa-preta: o acesso acontece só pela interface.

Características do componente

Os livros apontam cinco características de um componente:

1. Padronizado: segue um modelo de componentes, que define as interfaces, os metadados, a documentação, a composição e a implantação.
2. Independente: pode ser composto e implantado sem depender de outros componentes específicos. Se precisa de um serviço externo, declara isso na interface que requer.
3. Passível de composição: toda interação externa acontece por interfaces públicas.
4. Implantável: funciona como entidade autônoma numa plataforma que implementa o modelo de componentes. Em geral, é um binário que não precisa ser compilado antes do uso.
5. Documentado: tem a documentação completa, para que o usuário decida se ele atende à necessidade.

Interfaces

O componente tem duas interfaces. A interface fornecida (provides) define os serviços que o componente oferece aos outros. A interface requerida (requires) define os serviços que o componente precisa receber de outros componentes para funcionar. A interface requerida não diz qual componente vai fornecer o serviço: ela só diz o que é preciso, e é isso que mantém o componente independente.

Modelo de componentes e middleware

Um modelo de componentes define os padrões de interface, de uso, de documentação e de implantação dos componentes. Os modelos conhecidos são o Enterprise JavaBeans (EJB), o modelo .NET e o CORBA. O middleware do modelo dá os serviços de plataforma, como comunicação e transação.

Processos da ESBC

A ESBC tem dois grandes processos:

1. Desenvolvimento para reúso: a equipe cria componentes que serão reutilizados em outros sistemas. O componente precisa ser genérico, bem documentado e livre de detalhes de uma aplicação só.
2. Desenvolvimento com reúso: a equipe constrói um sistema novo usando componentes que já existem.

O desenvolvimento com reúso segue estas etapas:

1. A equipe esboça os requisitos do sistema, sem detalhar demais, para deixar espaço para os componentes.
2. A equipe identifica os componentes candidatos.
3. A equipe modifica os requisitos de acordo com os componentes encontrados. É a etapa típica da ESBC: o requisito se ajusta ao componente, por acordo com o cliente.
4. A equipe faz o projeto da arquitetura.
5. A equipe identifica de novo os componentes candidatos, agora com a arquitetura definida.
6. A equipe compõe os componentes para criar o sistema.

Composição

A composição é o processo de juntar componentes para criar um sistema. Ela tem três tipos:

1. Sequencial: os componentes são executados em sequência, e a saída de um vira a entrada do outro, com um código de ligação entre eles.
2. Hierárquica: um componente chama diretamente os serviços de outro; a interface fornecida de um atende à interface requerida do outro.
3. Aditiva: as interfaces de dois componentes se juntam para formar um componente novo, cuja interface é a soma das duas.

Quando as interfaces não combinam, a equipe escreve um adaptador, um código de ligação que converte uma interface na outra. A incompatibilidade pode ser de parâmetros (tipos ou quantidade diferentes), de operação (nomes diferentes) ou de incompletude (uma interface oferece só parte do que a outra precisa).

Na prática, o tribunal de contas do estado monta o sistema de recebimento de prestação de contas com um componente de assinatura digital, um componente de autenticação e um componente de validação de planilha. O componente de validação espera os dados num formato diferente do que o componente de recebimento entrega, e a equipe escreve um adaptador entre os dois.

A diferença para a orientação a objetos é que o componente é uma unidade de implantação independente, acessada só pela interface, e pode ser escrito em qualquer linguagem compatível com o modelo; o objeto é uma unidade de código dentro de um programa e define um tipo. A diferença para o modelo de processo CBD é de escopo: o CBD é o modelo de ciclo de vida, e a ESBC é a disciplina inteira, com o componente, o modelo de componentes e os processos para reúso e com reúso.

O erro comum é achar que a ESBC mantém intocados os requisitos do cliente. A etapa de modificar os requisitos conforme os componentes é parte do processo, e o ganho de tempo e custo vem desse ajuste.

Como a banca cobra: a banca troca interface fornecida por requerida, nega a independência do componente e cobra as etapas do desenvolvimento com reúso, em especial a modificação dos requisitos.

Quadros e comparações

A tabela abaixo compara os modelos de ciclo de vida pelo que guia cada um e pelo momento em que o cliente vê o software.

A tabela abaixo mostra as fases do RUP, o foco e o marco de cada uma.

A tabela abaixo compara os protótipos descartável e evolutivo.

A tabela abaixo compara a divisão de processos nas edições de 1995 e de 2017 da ISO/IEC 12207.

Para decorar

Pegadinhas

Fontes e data

• [1] ISO/IEC/IEEE 12207:2017, Engenharia de sistemas e software, Processos do ciclo de vida do software (norma paga, explicada com palavras próprias).
• [2] ISO/IEC 12207:1995, Processos do ciclo de vida do software, citada para comparação.
• [3] Conhecimento consolidado de livro didático de engenharia de software sobre processo de software, cascata, modelo em V, prototipação, incremental, espiral, desenvolvimento baseado em componentes, RAD, modelo concorrente, métodos formais, desenvolvimento orientado a aspectos, Processo Unificado, RUP e engenharia de software baseada em componentes.

Texto conferido em 15/10/2026.