Desenvolvimento de Software

Um ciclo de vida de desenvolvimento 开发生命周期 é o conjunto de etapas desde a ideia até o software finalizado e mantido. Ele serve para planejar, gerenciar e controlar um projeto — construir o produto certo, no prazo, com boa qualidade.

Por que um ciclo de vida é necessário

A lista do avaliador para "o propósito de um ciclo de vida de desenvolvimento": ele divide um grande projeto em etapas que podem ser planejadas e gerenciadas; garante que os requisitos sejam encontrados e concordados antes de iniciar o projeto e a codificação; inclui testes e documentação em vez de deixá-los para o final; permite que a equipe acompanhe o progresso contra marcos e gerencie riscos; e oferece ao cliente pontos definidos para revisar o trabalho. Sem um, uma equipe codifica primeiro e descobre tarde demais que construiu a coisa errada.

Por que existem diferentes tipos

Nenhum único ciclo de vida se adapta a todo projeto, então existem vários ciclos de vida de desenvolvimento. A escolha depende do tamanho e complexidade, quão claros os requisitos 需求 são no início, quanto de mudança é esperado, o nível de risco, a equipe e o prazo.

Modelos comuns

• Cascata 瀑布模型 — uma sequência linear (Análise → Projeto → Codificação → Teste → Manutenção), cada etapa concluída antes da próxima. Claro e bem documentado; bom para requisitos estáveis, mas mau para lidar com mudanças no meio do projeto, e o cliente vê nada funcionando até o final.
• Modelo iterativo 迭代模型 — passadas repetidas, cada uma produzindo uma versão parcial que é revisada e refinada. Captura problemas mais cedo; bom quando requisitos são descobertos ao longo do tempo, mas mais difícil de estimar.
• Desenvolvimento Rápido de Aplicativos 快速应用开发 (RAD) — uso intenso de um protótipo 原型 e feedback do usuário. Entrega muito rápida da primeira versão; bom para requisitos mutáveis, mas depende da disponibilidade do usuário e se adequa a sistemas menores.
• Agile 敏捷 — iterações curtas ("sprints"), colaboração e testes constantes. Flexível e adaptativo, mas precisa de um cliente comprometido e uma equipe qualificada.

Princípios, benefícios e desvantagens — conforme listado no esquema de correção.

Exemplo resolvido. Uma empresa deve ser a primeira a lançar um site para um novo console de jogos, e o design mudará à medida que os recursos do console forem anunciados. Nomeie o ciclo de vida mais adequado e justifique.

RAD. Um protótipo do site pode ser construído e mostrado aos usuários em poucos dias, e refinado à medida que os requisitos mudam; o site é pequeno o suficiente para uma abordagem guiada por protótipos, e a velocidade de entrega é o requisito principal. Cascata fixaria os requisitos antes de qualquer página ser construída e entregaria nada até o final.

As etapas padrão

Cada etapa tem um propósito, uma saída e atividades típicas — uma pergunta "descreva a etapa ..." quer duas ou três dessas.

• análise — descobrir o que o programa deve fazer. Atividades: entrevistas, questionários e observação do sistema atual; um estudo de viabilidade; acordar a especificação de requisitos, contra a qual cada etapa posterior será verificada.
• projeto — decidir como ele fará. Saídas: o diagrama de estrutura (módulos e parâmetros), fluxogramas ou pseudocódigo para cada módulo, tabelas de identificadores e estruturas de dados, layouts de tela e arquivo, e o plano de teste escrito agora, a partir da especificação, antes de qualquer código existir.
• codificação (implementação 实现) — escrever o programa em uma linguagem de alto nível, módulo por módulo, seguindo o projeto; cada módulo é testado à medida que é escrito.
• teste — executar o programa contra o plano de teste (dados normais, anormais, extremos e de fronteira) e corrigir os erros encontrados; testes de integração, alfa, beta e aceitação seguem.
• manutenção 维护 — após o lançamento, corrigir falhas, adaptar o programa a novos hardware, software ou leis, e melhorá-lo (veja abaixo).

Exemplo resolvido. Complete o diagrama de cascata Análise → ? → ? → ? → Manutenção e descreva o que acontece na etapa de projeto.

As etapas faltantes são Projeto, Codificação, Teste. Na etapa de projeto, os requisitos são transformados em um plano para o programa: o problema é decomposto em módulos (um diagrama de estrutura), o algoritmo para cada módulo é escrito como pseudocódigo ou fluxograma, as estruturas de dados e identificadores são escolhidos, as telas e arquivos são dispostos, e o plano de teste é escrito a partir da especificação.

Diagrama de estrutura

Um diagrama de estrutura 结构图 mostra a decomposição hierárquica 分解 de um programa em módulos (subrotinas 子程序) e os parâmetros 参数 passados entre eles. Cada módulo é um retângulo; linhas ligam o chamador (acima) ao chamado (abaixo); pequenas setas mostram dados indo para baixo e resultados voltando para cima. O projeto pode então ser convertido em pseudocódigo 伪代码 equivalente.

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

É uma ferramenta de etapa de projeto, e você pode ler as assinaturas dos procedimentos nele.

Os símbolos que o avaliador pede. Uma caixa é um módulo; uma linha liga um chamador (acima) aos módulos que ele chama (abaixo), lida da esquerda para a direita na ordem em que são chamados. Uma pequena seta com um círculo aberto na cauda é um par de dados — um parâmetro passado para baixo dentro de um módulo ou um valor retornado para cima; uma seta com um círculo preenchido é um par de controlo, uma flag (geralmente BOOLEAN) que informa ao chamador o que aconteceu. Um losango numa ramificação significa seleção: apenas um dos módulos abaixo dele é chamado, dependendo de uma condição. Uma seta curva varrendo sobre as ligações significa iteração: os módulos sob ela são chamados repetidamente num ciclo.

Exemplo resolvido. Quatro módulos são definidos como PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN e PROCEDURE Report(Total : INTEGER, Count : INTEGER). Main chama ReadData, depois chama IsValid uma vez para cada valor lido, depois chama Report. Descreva o diagrama de estrutura.

Main no topo; ReadData, IsValid e Report numa fila abaixo dele, da esquerda para a direita na ordem de chamada. Na ligação ReadData, um par de dados ascendente Count (um parâmetro BYREF retorna). Na ligação IsValid, um par de dados descendente Value e um par de controlo ascendente (o resultado BOOLEAN), com uma seta de iteração curva sobre essa ligação porque é chamada para cada valor. Na ligação Report, dois pares de dados descendentes, Total e Count. Lendo no outro sentido, uma função é qualquer módulo que retorna um valor — seu cabeçalho precisa de RETURNS e do tipo retornado.

Diagrama de transição de estado

Um diagrama de transição de estado 状态转换图 mostra os estados 状态 que um sistema pode estar e os eventos que o movem entre eles — bom para máquinas de venda automática, semáforos, interfaces de usuário. Diagramas de transição de estado são usados para documentar o comportamento de um algoritmo ou sistema. Cada estado é um círculo; cada transição é uma seta rotulada com o evento.

   coin inserted               item selected
[Idle] --------------→ [Awaiting selection] ----------→ [Dispensing]

Torna fácil identificar transições ausentes ("e se uma segunda moeda for inserida enquanto aguarda seleção?").

Ler e desenhar um. Cada transição é rotulada entrada | saída (ou condição | ação): o que aconteceu, depois o que o sistema faz ao mudar de estado. Uma questão dá uma tabela de estado atual, entrada, saída, próximo estado e pede o diagrama, ou o inverso — cada linha da tabela corresponde exatamente a uma seta. Verifique se cada estado tem uma seta saindo dele para cada entrada que possa ocorrer, incluindo aquelas que deixam o estado inalterado (uma seta que volta para o mesmo estado).

Exemplo resolvido. Um controlador de bomba tem estados bomba desligada e bomba ligada. Em bomba desligada, a entrada nível baixo detectado produz a saída ativar bomba e move para bomba ligada; em bomba ligada, nível normal detectado produz desativar bomba e move para bomba desligada. Qualquer outra entrada deixa o estado inalterado. Desenhe a tabela.

As duas linhas "sem alteração" tornam-se setas de loop no diagrama; omiti-las resulta na perda de pontos por incompletude.

• erro de sintaxe 语法错误 — viola a gramática da linguagem (colchete faltando, palavra-chave grafada incorretamente). Capturado durante a tradução; o programa não executará até ser corrigido.
• erro de tempo de execução 运行时错误 — ocorre enquanto executa (divisão por zero, arquivo não encontrado, índice de array fora do intervalo). O programa falha ou levanta uma exceção; corrige adicionando verificações.
• erro lógico 逻辑错误 — o programa executa mas produz resultados errados (usar + para -, um erro de limite de ciclo, condições em ordem incorreta). O mais difícil de encontrar; o único sinal é a saída errada, então use testes cuidadosos e rastreamento.

Expor e evitar falhas. Falhas são expostas por testes contra um plano de testes, por uma execução seca ou tabela de rastreamento, por uma revisão com colegas, e pelo depurador da IDE (pontos de interrupção, passo a passo, observação de variáveis). São evitadas projetando antes de codificar (diagrama de estrutura, pseudocódigo), por código modular com identificadores e comentários significativos, por validação de toda entrada, por lidar com exceções em vez de deixar um erro de tempo de execução travar o programa, e pelas verificações de sintaxe dinâmica da IDE enquanto se digita.

Exemplo resolvido. Identifique o tipo de erro em cada caso e como ele se manifesta. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) é executado com y = "0". (b) A mesma linha é executada com x = "12a". (c) Um ciclo escrito como FOR i <- 1 TO 9 processa um array de dez elementos. (d) OUTPUT "Total: " Total está faltando uma vírgula.

(a) Erro de tempo de execução — divisão por zero; o programa falha quando esta linha é executada com esses dados. (b) Erro de tempo de execução — a string não pode ser convertida em número. (c) Erro lógico — o programa executa mas o décimo elemento nunca é processado, então o output está errado. (d) Erro de sintaxe — a instrução viola as regras da linguagem e é relatada pelo tradutor antes do programa rodar.

Exemplo resolvido. Corrija os erros neste pseudocódigo, que deve output a média de dez notas.

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

A divisão deve ser por 10, não 9 (erro lógico); a linha de output precisa de uma vírgula ou de um & entre a string e o valor (erro de sintaxe); e Average nunca foi declarado como REAL (erro de sintaxe ou tempo de execução, dependendo da linguagem). Diga qual linha e qual é a linha corrigida: Average <- Total / 10.

• execução seca 手工跟踪 — rastreie o código no papel, anotando o valor de cada variável numa tabela.
• revisão 走查 — uma revisão em equipe do código.
• teste branco 白盒测试 — projetado a partir da estrutura interna do código, cobrindo cada instrução, ramificação e ciclo.
• teste preto 黑盒测试 — projetado apenas a partir da especificação: forneça entradas, verifique saídas.
• teste de integração 集成测试 — combine módulos e teste as interfaces entre eles.
• teste alfa α测试 — pelos desenvolvedores/interno antes do lançamento; teste beta β测试 — por um grupo limitado de usuários reais em seu próprio ambiente.
• teste de aceitação 验收测试 — pelo cliente, para decidir se o produto serve ao propósito.
• stub 桩 — um espaço reservado para um módulo que ainda não existe, para que a estrutura possa ser testada de cima para baixo.

Qual método, quando. Um execução seca e uma revisão não precisam de computador — a execução seca é você, rastreando o algoritmo com uma tabela de rastreamento 跟踪表; a revisão é uma reunião em que o autor explica o código linha por linha e colegas buscam falhas, então também espalha conhecimento do código pela equipe e o verifica contra o projeto. Testes brancos são escritos por quem pode ver o código e visam exercitar cada caminho; testes pretos são escritos a partir da especificação e verificam apenas entradas contra saídas esperadas, então um usuário ou tester separado pode fazê-los. Teste de integração segue teste de módulo: módulos que passam sozinhos ainda podem falhar quando os dados passados entre eles têm tipo errado ou estão na ordem errada. Teste alfa é interno; teste beta entrega uma candidata a versão a uma amostra de usuários reais, que reportam falhas de uso real; teste de aceitação é o cliente verificando o produto final contra os requisitos antes de pagá-lo. Um stub permite que o teste de cima para baixo comece antes que todos os módulos existam.

Exemplo resolvido. Após o programa passar nos testes internos, foi entregue a um grupo de usuários para testar antes do lançamento. Nome este tipo de teste e diga o que acontece a seguir.

Teste beta — usuários reais em seu próprio ambiente, reportando falhas que os desenvolvedores não encontraram. As falhas são corrigidas, depois o cliente realiza teste de aceitação contra os requisitos e o programa é lançado; falhas encontradas em uso real são então tratadas por manutenção corretiva.

Exemplo resolvido. Cite três benefícios de testar um programa por revisão.

Erros são encontrados por pessoas que não escreveram o código e, portanto, o leem sem pressupostos; a lógica é verificada contra o projeto e a especificação, não apenas contra dados de teste; várias pessoas aprendem como o código funciona, o que ajuda na manutenção futura; e nenhum dado de teste ou computador funcional é necessário, então pode ser feito cedo.

Uma estratégia de teste 测试策略 é a abordagem de alto nível — quais tipos de teste, quem os faz, quando, e os critérios para prosseguir. Um plano de teste 测试计划 é a lista detalhada de testes — cada um com dados de entrada, saída esperada, e uma coluna para a saída real.

O que cada um contém. Uma estratégia de teste estabelece quais métodos de teste serão usados em qual etapa (teste de módulo pelo programador, depois integração, alpha, beta, aceitação), quem é responsável por cada um, quais dados de teste são necessários e os critérios para passar à próxima etapa. Um plano de teste lista os testes individuais: para cada um, o módulo ou recurso em teste, os dados de entrada, a razão pela escolha dos dados (normal, anormal, extremo, limite), o resultado esperado, um espaço para o resultado real e o que fazer se diferirem. O plano é escrito na etapa de projeto, com base nas especificações, para testar o que o programa deveria fazer em vez do que ele acidentalmente faz.

Escolhendo dados de teste

Para cada campo ou condição, inclua três tipos:

• dados normais 正常数据 — valores típicos dentro da faixa válida (para notas 0–100: 50, 75).
• dados anormais 异常数据 — valores que deveriam ser rejeitados (-10, 200, "abc").
• dados extremos 极端数据 — os maiores e menores valores ainda aceitos (0 e 100).
• dados de fronteira 边界数据 — valores nas bordas, onde erros off-by-one se escondem (cada extremo aceito e o valor rejeitado logo fora dele: 0/-1, 100/101).

Exemplo resolvido. Um campo aceita uma nota de exame de 0 a 100. Forneça dados de teste de cada tipo com seu resultado esperado. Normal: 50 - aceito, um valor típico dentro do intervalo. Anormal: -10, 200, "abc" - todos rejeitados, estando fora do intervalo ou do tipo de dados errado. Extremo: 0 e 100 - os maiores e menores valores que ainda são aceitos. Fronteira: os pares que cruzam cada borda - -1 rejeitado junto com 0 aceito, e 100 aceito junto com 101 rejeitado. Cada valor deve carregar seu resultado esperado, ou o plano de teste não prova nada. Extremo e fronteira são o par mais frequentemente confundido: um valor extremo fica dentro e é aceito, enquanto um teste de fronteira é sempre um par de cada lado da borda - que é exatamente onde os erros off-by-one se escondem.

Exemplo resolvido. Um componente passa se seu peso, medido até o gram mais próximo, estiver dentro de 3 g do alvo de 50 g, ou seja, de 47 g a 53 g inclusive. Elabore as linhas do plano de teste para a verificação.

Cada linha deve dizer por que o valor foi escolhido e o que deveria acontecer; uma lista nua de números não ganha pontos.

A maior parte do custo de vida de um programa está na manutenção. Três tipos:

• manutenção perfectiva 完善性维护 — melhorar desempenho ou recursos mesmo funcionando (uma consulta mais rápida, uma nova opção).
• manutenção adaptativa 适应性维护 — mantê-lo funcionando em um ambiente em mudança (um novo SO, uma nova API, uma mudança legal).
• manutenção corretiva 纠正性维护 — corrigir bugs encontrados em uso.

Um programa pode precisar dos três durante sua vida.

Por que cada um é necessário — as razões listadas no gabarito. Corretiva: um defeito é reportado por um usuário após o lançamento, ou uma saída incorreta é notada em circunstâncias específicas que os testes não cobriram. Adaptativa: o sistema operacional, hardware ou navegador é atualizado; uma lei ou regra corporativa muda (taxas de imposto, requisitos de proteção de dados); o programa precisa funcionar com um novo sistema externo ou formato de arquivo. Perfectiva: usuários pedem recursos extras ou uma interface melhor; o programa é feito mais rápido ou usa menos memória; o código é limpo para facilitar mudanças futuras.

Exemplo resolvido. (a) Um programa lançado exibe um valor errado sob certas circunstâncias. (b) O hardware que executa um programa é substituído. (c) Clientes pedem que o programa de fidelidade de uma cafetería envie uma mensagem no aniversário do cliente. Nomeie o tipo de manutenção em cada caso.

(a) Corretiva — um defeito no programa entregue está sendo corrigido. (b) Adaptativa — o programa é alterado para rodar em seu novo ambiente. (c) Perfectiva — um recurso é adicionado a um programa que já funciona.

Quando solicitado a adicionar um recurso ou corrigir um bug:

1. leia o código existente até entender o algoritmo e o fluxo de dados.
2. encontre onde a alteração vai — qual subrotina, quais linhas.
3. faça a alteração o menor possível — não reescreva código funcional.
4. atualize partes relacionadas — todo chamador de uma lista de parâmetros alterada, toda rotina usando uma estrutura de dados alterada.
5. teste o novo comportamento e o antigo (regression testing 回归测试 — verifique se não quebrou nada).
6. documente a alteração.

Comentários claros, nomes significativos, subrotinas decompostas e um diagrama estrutural tornam um programa muito mais fácil de alterar — é por isso que as ferramentas de projeto importam mesmo após o primeiro lançamento.

Analisando um programa que você não escreveu. Comece pela tabela de identificadores e pelos cabeçalhos dos módulos: eles dizem o que cada módulo recebe e retorna antes de ler uma linha de seu corpo. Depois, faça o rastro do algoritmo com uma tabela de traçado para uma pequena entrada, anotando de onde vem cada valor de saída. Somente então decida onde a melhoria vai — geralmente um novo módulo chamado pelo existente, para perturbar o mínimo possível o código funcional — e escreva a pseudocódigo para a alteração e os dados de teste que a comprovam.

Uma questão de definição é avaliada contra wording fixo. Aprenda estas exatamente, e dê apenas uma resposta.

• Compare modelos de desenvolvimento (cascata, iterativo, RAD) por princípio, benefício, desvantagem, e saiba as cinco etapas do ciclo de vida de desenvolvimento de programas e o que cada uma produz.
• Diferencie erros de sintaxe, lógica e tempo de execução pelo momento em que aparecem: na tradução, na saída, durante a execução.
• Escolha dados de teste de todos os tipos — normal, anormal, extremo e fronteira — e dê a cada valor sua razão e resultado esperado.
• Diferencie os tipos de manutenção (corretiva, adaptativa, perfectiva) pelo motivo da alteração.
• Em um diagrama estrutural, nomeie todos os símbolos: caixa, linha de chamada, acoplamento de dados, acoplamento de controle, diamante de seleção, seta de iteração. Ao ler cabeçalhos de módulo em um diagrama, lembre-se que uma função tem RETURNS.

Erros comuns

• Descrever uma etapa do ciclo de vida apenas pelo seu nome ("na etapa de projeto o programa é projetado"). Diga o que é produzido: diagrama estrutural, pseudocódigo, plano de teste.
• Chamar uma saída errada de "erro de tempo de execução". Se o programa roda até o final, é um erro lógico.
• Dar dados de fronteira apenas como os extremos. A questão pede os valores em ambos os lados da borda.
• Tratar testes alpha e beta como iguais. Alpha é interno pelos desenvolvedores; beta é por usuários reais externos.
• Confundir manutenção adaptativa e perfectiva. Adaptativa responde a uma mudança fora do programa; perfectiva melhora um programa que ninguém precisava alterar.
• Desenhar um diagrama estrutural com os módulos em qualquer ordem. Eles são lidos da esquerda para a direita na ordem em que são chamados, e cada parâmetro precisa de sua seta.