Exercícios resolvidos: modelos de processo e fundamentos do ciclo de vida

Explicação

1. Use os verbos como pistas

Antes de procurar o nome de cada atividade, destaque o que a equipe está tentando conseguir:

• em A, “definiram” indica que a equipe ainda está esclarecendo o que o software deve fazer;
• em B, “representou” e “construiu” mostram a passagem das regras para uma solução executável;
• em C, “comparou” e “avaliassem” colocam a solução diante do comportamento esperado e dos usuários;
• em D, “nova regra” e “alterou” mostram que algo existente precisa mudar.

Agora fica mais fácil aplicar a bússola: definir aponta para especificação, conceber e construir aponta para projeto e implementação, comparar e avaliar aponta para validação e responder a uma mudança aponta para evolução. A classificação considera a finalidade principal. Uma ação real pode ajudar em mais de uma finalidade.

2. Faça o teste do resultado observável

Para encontrar um produto, pergunte: “o que poderia ficar salvo, ser mostrado a outra pessoa ou passar por uma revisão depois desta ação?”. Procure um substantivo, não apenas outro verbo.

• Depois de A, podem ficar as regras de prioridade registradas e acordadas.
• Depois de B, podem ficar o modelo da solução e a versão executável.
• Depois de C, podem ficar os resultados das verificações e a avaliação dos operadores.
• Depois de D, podem ficar o registro da mudança e uma nova versão candidata à avaliação.

A conversa faz parte do trabalho. A regra registrada é um produto desse trabalho. Essa diferença evita chamar qualquer ação de produto.

3. Pense em filme, mapa e evidência

O processo seria o filme do trabalho real: conversas, decisões, tentativas, correções e retornos. O modelo de processo seria um mapa desse filme, com apenas as partes úteis para uma pergunta. O produto seria uma evidência deixada por uma atividade, como uma regra registrada, um modelo da solução ou uma versão executável.

O mapa nunca é o filme inteiro. Por isso, um modelo simples pode ser útil sem descrever tudo o que ocorreu.

4. Evite desenhar uma linha de trem

As quatro atividades fundamentais não são estações que a equipe visita uma única vez. Elas são finalidades que precisam aparecer ao longo do ciclo de vida. Se a validação revelar que uma regra foi mal entendida, a equipe pode voltar à especificação. Se o defeito estiver apenas na construção, o retorno pode ir para projeto e implementação. Uma nova regra entra pela evolução e pode exigir nova especificação, construção e validação.

5. Monte o desenho em camadas

Primeiro, coloque as quatro atividades fundamentais. Depois, mostre a chegada a um produto utilizável. Por último, acrescente a causa de cada retorno. Neste cenário, você pode escolher um resultado inadequado causado por uma regra que precisa ser revista. Essa escolha justifica o retorno da validação à especificação.

Antes de finalizar, confira se o desenho mostra:

• as quatro atividades fundamentais;
• a chegada a um produto utilizável;
• o motivo do retorno após a validação;
• a nova regra passando pela evolução e voltando à definição do que será construído.

Resposta esperada

1. Finalidades principais: A corresponde à especificação, B a projeto e implementação, C à validação e D à evolução.
2. Produtos observáveis: A gera regras acordadas. B gera um modelo da solução e uma versão executável. C gera resultados das verificações e a avaliação dos operadores. D gera o registro da mudança e uma nova versão candidata à avaliação.
3. Conceitos: o processo é o trabalho real da equipe. O modelo de processo é uma representação simplificada desse trabalho. O produto é um resultado observável gerado por uma atividade.
4. Ciclo de vida: ele conecta definição, construção, avaliação e evolução. Não impõe uma sequência rígida porque as atividades podem se repetir, se sobrepor e retornar a partes anteriores.
5. Modelo:

flowchart TD
    A["Especificação"] --> B["Projeto e implementação"]
    B --> C["Validação"]
    C -->|"resultado adequado"| D["Produto utilizável"]
    C -->|"resultado inadequado: regra precisa ser revista"| A
    D -->|"nova regra"| E["Evolução"]
    E -->|"revisar requisitos diante da nova regra"| A

Explicação

1. Troque a lente, não o cenário

As mesmas ações podem ser observadas por duas perguntas. A primeira é: “de que maneira a equipe está trabalhando?”. Para encontrar a resposta, procure o verbo principal:

• A usa uma conversa, então é comunicação;
• B organiza responsáveis, sequência e riscos, então é planejamento;
• C cria uma representação, então é modelagem;
• D implementa e faz verificações técnicas, então é construção;
• E disponibiliza a versão e coleta uma avaliação, então é entrega.

Essa lente descreve a forma de conduzir o trabalho. Ela ainda não informa qual finalidade fundamental cada ação atende.

2. Pergunte o que a ação tenta alcançar

Agora use a segunda lente: “qual resultado principal a equipe busca?”.

• Em A, a conversa serve para definir uma regra. A finalidade é especificação.
• Em B, a finalidade principal é evolução porque a ação organiza o trabalho necessário para realizar uma mudança em um produto existente. Essa evolução pode exigir uma nova especificação quando a equipe precisa definir quais comportamentos, regras ou restrições serão alterados. Porém, o enunciado de B não descreve diretamente essa definição do comportamento. Ele apenas situa o trabalho em torno de uma mudança. Por isso, a classificação principal continua sendo evolução, embora o processo mais amplo possa retornar à especificação.
• Em C, a equipe representa a solução que produzirá recomendações. A finalidade principal é projeto e implementação.
• Em D, implementar e testar tecnicamente ajuda a construir uma solução que funcione. Por isso, a finalidade principal também é projeto e implementação. O teste técnico não prova sozinho que o produto atende à necessidade dos operadores.
• Em E, os operadores avaliam as recomendações. Essa comparação com a necessidade de uso aponta para validação.

O nome da atividade metodológica não determina a finalidade. O contexto completa a classificação.

3. Faça o teste da correspondência fixa

Se cada atividade metodológica correspondesse sempre a uma única finalidade, comunicação serviria apenas para especificar. Isso falha rapidamente: a equipe também conversa para avaliar uma versão ou entender uma mudança. Logo, as duas classificações funcionam como lentes diferentes, não como duas colunas de tradução.

4. Reutilize a mesma ferramenta em momentos diferentes

Em A, conversar com os operadores ajuda a descobrir as prioridades e apoia a especificação. Depois do uso, uma conversa sobre a utilidade das recomendações apoia a validação. A ferramenta é a mesma, mas a pergunta e o resultado buscado mudam.

Resposta esperada

1. Atividades metodológicas: A é comunicação, B é planejamento, C é modelagem, D é construção e E é entrega.
2. Finalidades fundamentais: A atende principalmente à especificação. B atende à evolução. C e D atendem a projeto e implementação. E atende à validação.
3. Relação entre as perspectivas: não há correspondência um a um. As atividades metodológicas mostram como a equipe trabalha. As atividades fundamentais mostram o resultado buscado. Uma mesma atividade metodológica pode apoiar finalidades diferentes.
4. Comunicação em duas finalidades: uma conversa para definir as prioridades apoia a especificação. Uma conversa para avaliar as recomendações da versão apoia a validação.

Explicação

1. Organize a ficha como uma pequena linha do tempo

Comece pelo centro, com o que acontece durante a análise. O verbo “analisar” nomeia a atividade. Em seguida, pergunte quem executa essa ação. O enunciado informa que a própria Central Aurora faz a análise, então esse componente assume o papel neste recorte do processo.

Agora olhe para a entrada da atividade. Antes de começar, a solicitação já precisa conter os quatro dados obrigatórios e o estado da energia precisa estar disponível. Essa é a pré-condição.

Por fim, olhe para a saída. A análise produz uma recomendação, que é o produto. Para considerar o trabalho concluído, resultado, motivo e o responsável informado na solicitação precisam estar registrados e ligados a ela. Esse estado final é a pós-condição. Só depois dessa separação vale preencher a ficha completa.

2. Aplique dois testes rápidos

Para testar uma pré-condição, complete a frase: “antes de começar, já é verdade que…”. “Antes de começar, já é verdade que conferir os dados” não funciona, pois “conferir” ainda é uma ação. “Antes de começar, os dados obrigatórios estão presentes” descreve um estado verificável.

Para testar uma pós-condição, pergunte: “outra pessoa consegue verificar objetivamente se isso aconteceu?”. “Está tudo certo” não diz o que deve ser observado. Já o registro do resultado, do motivo e do responsável informado pode ser conferido.

3. Passe a solicitação pelo filtro da regra

Faça a decisão em três passos:

1. O estado da energia é crítico.
2. Nesse estado, somente uma prioridade crítica permite energia adicional.
3. O laboratório possui prioridade comum, então não passa pelo filtro.

O resultado é a recomendação de rejeitar. O produto não fica completo apenas com a palavra “rejeitar”. Ele também precisa registrar o motivo, identificar o responsável informado na solicitação e permanecer ligado à solicitação analisada.

4. Use o teste do verbo e do resultado

“Analisar solicitação de energia” começa com um verbo e descreve o trabalho. “Recomendação registrada” nomeia algo que existe depois do trabalho e pode ser consultado. Portanto, o primeiro trecho é a atividade e o segundo é o produto.

Resposta esperada

1. Ficha da atividade:

Atividade: analisar solicitação de energia
Papel: Central Aurora
Pré-condição: a solicitação contém módulo, motivo, prioridade e responsável, e o estado da energia está disponível
Produto: recomendação registrada de liberar ou rejeitar a solicitação
Pós-condição: resultado, motivo e o responsável informado na solicitação estão registrados e ligados a ela

2. Condições: “conferir os dados” é uma tarefa, não um estado anterior. “Está tudo certo” não apresenta um estado verificável. A pré-condição deve informar que os dados e o estado da energia estão disponíveis. A pós-condição deve informar que resultado, motivo e o responsável informado na solicitação estão registrados e ligados a ela.
3. Simulação: o produto é a recomendação de rejeitar a solicitação. O motivo registrado informa que a energia está crítica e a prioridade do laboratório é comum. O registro também identifica o responsável informado na solicitação.
4. Atividade e produto: analisar a solicitação é o trabalho. A recomendação registrada é a saída observável desse trabalho.

Explicação

1. Mude o zoom da câmera

A Representação A usa uma visão aberta. Ela responde bem à pergunta “o que acontece antes e depois?”, pois mostra a sequência principal. Para encontrar omissões, tente fazer outras perguntas ao fluxo. “Quem decide?” e “qual estado permite começar?” ficam sem resposta. Papéis e condições são, portanto, duas omissões relevantes.

A Representação B usa uma visão aproximada de uma única atividade. Ela responde “quem analisa?”, “o que precisa existir antes?” e “qual resultado deve existir depois?”. Ao afastar a câmera, porém, surgem novas dúvidas. A ficha não mostra o fluxo completo nem os caminhos de exceção. Essas são duas omissões relevantes.

O exercício pede duas informações ausentes em cada caso. Existem outras, como duração e paralelismo, mas listar tudo não melhora a decisão. O importante é ligar cada omissão a uma pergunta que o modelo não consegue responder.

2. Procure a responsabilidade exata

A pergunta não é apenas “existe algum papel no modelo?”. Ela é “existe um papel ligado à ação de aprovar exceção?”. Nenhuma das duas representações responde a essa pergunta. A Representação B é apenas mais fácil de complementar porque já organiza informações por papel, mas o papel existente informa somente quem analisa a solicitação.

3. Não invente o caminho que falta

A pré-condição exige que a prioridade esteja informada. Ela funciona como uma porta de entrada: a análise só deveria começar quando os dados obrigatórios existem. Porém, a ficha não diz o que fazer quando a porta está fechada. O sistema poderia pedir uma correção, rejeitar a solicitação ou encaminhar o caso para outra pessoa. Como nenhum desses caminhos foi definido, não existe base para escolher um deles.

Essa é uma regra importante ao ler modelos: perceber uma ausência é diferente de preencher a ausência por conta própria.

4. Faça um remendo pequeno e direcionado

Não é necessário transformar o fluxo em um painel cheio de detalhes. Para tratar a prioridade ausente, basta acrescentar ao fluxo uma decisão depois do recebimento: se a prioridade não estiver informada, a solicitação volta para correção antes da análise. Para tratar a exceção, basta criar uma ficha curta separada, como esta:

Atividade: aprovar exceção
Papel: autoridade institucional designada pela colônia
Produto: decisão de aprovação ou rejeição registrada

A primeira alteração resolve um desvio do fluxo. A segunda resolve uma dúvida de responsabilidade. Cada representação continua fazendo um trabalho específico.

5. Compare ganho e custo

Um modelo simples oferece leitura rápida e visão geral. O risco é esconder um critério necessário, como ocorreu com a prioridade ausente. Um modelo detalhado deixa condições, produtos e papéis visíveis. O custo é exigir mais tempo para leitura e atualização.

Uma representação parcial não está automaticamente errada. Ela se torna insuficiente quando omite justamente a informação necessária para a decisão que deveria apoiar.

Resposta esperada

1. Representação A: mostra a ordem das atividades. Deixa de fora, entre outras informações, responsáveis e estados verificáveis. Representação B: mostra os detalhes da análise, incluindo papel, pré-condição, produto e pós-condição. Deixa de fora o fluxo completo e as exceções.
2. Aprovação de exceção: nenhuma representação responde quem aprova a exceção. A Representação B é mais fácil de complementar porque trabalha com papéis, mas identifica somente quem analisa a solicitação.
3. Prioridade ausente: não é possível decidir entre rejeitar a solicitação e pedir a informação que falta. A ficha exige que a prioridade exista antes da análise, mas nenhuma representação define como tratar a ausência.
4. Alteração mínima: acrescentar ao fluxo uma decisão que devolva para correção a solicitação sem prioridade. Em uma ficha separada, registrar a atividade “aprovar exceção”, o papel “autoridade institucional designada pela colônia” e o produto “decisão registrada”. Não é necessário colocar tudo no mesmo desenho.
5. Níveis de detalhe: o modelo simples facilita a comunicação, mas pode esconder critérios e responsabilidades. O modelo detalhado torna esses elementos visíveis, mas exige mais esforço de criação e manutenção.

Explicação

1. Compare um aspecto por vez

Evite responder apenas que um processo será “simples” e o outro será “rigoroso”. A tabela pede quatro diferenças observáveis.

No Projeto A, o nível de detalhe pode se limitar ao necessário para a versão atual. Os quatro estudantes podem acumular papéis. Registros curtos das decisões e avaliações são suficientes, e a validação pode acompanhar os ciclos do protótipo.

No Projeto B, as regras e os critérios precisam de mais detalhe. Desenvolvimento, avaliação e liberação precisam de responsáveis visíveis. A equipe deve registrar mudanças, resultados e aprovações, e a validação precisa terminar antes da liberação.

2. Regule os controles usando produto, equipe e organização

No produto, pergunte qual dano uma decisão errada pode causar. No Projeto A, os dados são fictícios. No Projeto B, uma recomendação pode afetar módulos críticos.

Na equipe, pergunte quantas pessoas precisam se coordenar. Quatro estudantes conseguem combinar papéis. Uma equipe institucional precisa deixar algumas responsabilidades explícitas.

Na organização, pergunte quais evidências precisam permanecer disponíveis. O Projeto A precisa aprender com avaliações frequentes. O Projeto B também precisa provar quem aprovou a mudança e quais resultados foram examinados.

Não basta afirmar que o Projeto B “precisa de mais formalidade”. Cada controle deve resolver um problema concreto:

• regras registradas permitem verificar qual comportamento era esperado;
• responsabilidades explícitas mostram quem decidiu e quem executou;
• resultados de validação registrados sustentam a decisão de liberar;
• mudanças registradas ajudam a entender por que uma nova versão existe.

No Projeto A, registros curtos podem cumprir essas funções porque o risco e a quantidade de pessoas são menores. O formato muda. A finalidade do registro permanece.

3. Separe o que pode encolher do que não pode desaparecer

O número de papéis, o detalhe dos registros e a forma da validação podem ser ajustados. Já as quatro perguntas fundamentais não podem sumir: o que construir, como construir, como conferir e como tratar mudanças. Os dois projetos também precisam deixar claro quem responde pelo trabalho e qual resultado foi produzido.

4. Teste os dois exageros

Para avaliar uma adaptação, compare o esforço do controle com o risco que ele reduz.

Levar ao sistema oficial o mesmo nível reduzido de detalhe, registros e aprovações do protótipo economizaria esforço, mas apagaria justamente as evidências necessárias para liberar ou investigar uma versão crítica. O risco permaneceria alto e pouco visível.

Levar todos os controles do sistema oficial para o protótipo aumentaria coordenação, registros e aprovações sem reduzir um risco equivalente. A equipe gastaria parte das seis semanas sustentando controles que o cenário não exige.

5. Complete somente o que ainda precisa ser descoberto

Não é necessário representar todo o processo em um único desenho. A atividade, a pré-condição e a regra já foram fornecidas. Restam três perguntas.

Quem responde pela decisão? O responsável institucional pela liberação. O que a atividade produz? Uma decisão de liberar ou não liberar. O que deve ser verdadeiro depois? A situação da versão deve corresponder à decisão, e a decisão, o responsável e o resultado da validação devem estar registrados.

Observe que o resultado da validação pode indicar rejeição. Nesse caso, a regra impede a liberação. A atividade ainda produz uma decisão registrada, mas a versão permanece sem liberação.

Resposta esperada

1. Adaptações:

2. Justificativa: o sistema oficial apresenta maior risco, a equipe institucional coordena mais responsabilidades e a organização precisa verificar aprovações e evidências. Por isso, o Projeto B exige mais controle.
3. Elementos preservados: os dois projetos precisam de especificação, projeto e implementação, validação e evolução. Também precisam indicar quem responde pelo trabalho e quais resultados foram produzidos, com níveis de detalhe adequados ao contexto.
4. Problemas das propostas: a Proposta A é insuficiente para o sistema oficial porque pode ocultar responsáveis e evidências necessárias para impedir ou investigar uma liberação inadequada. A Proposta B é excessiva para o protótipo porque aumenta o esforço e pode atrasar os ciclos curtos sem reduzir um risco equivalente.
5. Ficha da decisão de liberação:

Atividade: decidir sobre a liberação da nova versão
Papel: responsável institucional pela liberação
Pré-condição: existe uma versão candidata e o resultado da validação está registrado
Produto: decisão de liberar ou não liberar a versão
Pós-condição: a versão foi liberada ou permaneceu sem liberação de acordo com a decisão, e a decisão, o responsável e o resultado da validação estão registrados
Regra de liberação: liberar somente quando a validação foi aceita e o responsável institucional aprovou a liberação