Toposia - Engenharia de Software

Introdução3.1

Neste capítulo, vamos mergulhar no conceito fundamental de processo de software. Se você já tentou desenvolver um programa complexo sem um plano claro, provavelmente percebeu que a codificação, por si só, é apenas a ponta do iceberg. Para que um software seja robusto, gerenciável, economicamente viável e atenda às reais necessidades do cliente, precisamos de muito mais do que apenas linhas de código: precisamos de um processo estruturado.

Podemos definir um processo de software como um conjunto coerente de atividades necessárias para transformar uma necessidade abstrata em um produto de software funcional. Pense nele como o roteiro mestre que guia a sua equipe desde a ideia inicial até a entrega final e a manutenção contínua do sistema. Embora existam milhares de processos diferentes na indústria (adaptados para empresas gigantescas, agências governamentais ou startups ágeis), todos eles compartilham quatro atividades fundamentais que formam a espinha dorsal da engenharia de software:

Especificação de software: O momento onde definimos rigorosamente o que o sistema deve fazer e, tão importante quanto, quais são suas restrições de operação e desenvolvimento.
Projeto e implementação: A fase criativa e técnica onde o sistema é arquitetado, organizado em módulos e efetivamente construído.
Validação de software: A etapa crítica onde garantimos que o software faz o que o cliente pediu (validação) e que foi construído corretamente (verificação).
Evolução de software: A realidade inevitável de que o software precisa mudar ao longo do tempo para acompanhar as novas demandas do mercado e do mundo real.

É importante ressaltar que, na prática, essas quatro atividades não são tarefas simples ou isoladas. Elas são processos complexos em si mesmas, compostas por diversas subatividades (como validação de requisitos, projeto de arquitetura e testes unitários). Além disso, elas coexistem com atividades de apoio essenciais, como a documentação do sistema e o gerenciamento de configuração de software.

Para descrever um processo de software de forma completa, não basta listar o que é feito (as atividades). Precisamos entender a estrutura ao redor delas. Assim, uma descrição robusta de processo geralmente inclui:

Produtos (Artefatos): São os resultados tangíveis de uma atividade. Por exemplo, o resultado da atividade de projeto de arquitetura pode ser um modelo visual da arquitetura de software.
Papéis: Definem quem faz o quê, refletindo as responsabilidades das pessoas envolvidas (ex: gerente de projeto, gerente de configuração, programador).
Pré e pós-condições: São declarações que precisam ser verdadeiras antes e depois de uma atividade.
- Exemplo: Antes de iniciar o projeto de arquitetura, uma pré-condição pode ser que "todos os requisitos foram aprovados pelo cliente". Após a conclusão, uma pós-condição seria que "os modelos UML da arquitetura foram revisados".

Ao longo desta leitura, você verá que, embora esses componentes sejam universais, a forma como os organizamos e encadeamos pode variar drasticamente. Alguns processos são dirigidos a planos (onde todas as atividades, produtos e pré-condições são planejados e documentados com antecedência), enquanto outros são ágeis (onde o planejamento é incremental, iterativo e adaptativo). É crucial que você entenda que não existe um "jeito certo" universal, mas existe o jeito mais adequado para o contexto específico do seu projeto e da sua equipe.

Modelos de Processo de Software3.2

Um modelo de processo de software é, essencialmente, uma representação simplificada ou uma abstração de um processo real. Pense neles como frameworks conceituais que você pode estender e adaptar para criar o processo específico de trabalho da sua organização. Vamos analisar três paradigmas gerais que influenciam a maioria dos métodos modernos de desenvolvimento.

É crucial entender que esses modelos não são mutuamente exclusivos. Na prática, eles são frequentemente usados em conjunto, especialmente no desenvolvimento de sistemas de grande porte, onde faz sentido combinar as melhores características do modelo em cascata (previsibilidade) e dos modelos de desenvolvimento incremental (flexibilidade).

Por exemplo, considere a arquitetura e os subsistemas:

Arquitetura e Requisitos Estáveis: Você precisa de informações sólidas sobre os requisitos essenciais para projetar uma arquitetura de software que suporte o sistema. Essa base não pode ser desenvolvida de forma puramente incremental; aqui, uma abordagem mais rígida (como o modelo em cascata) é necessária para partes bem compreendidas.
Interfaces e Incertezas: Por outro lado, subsistemas difíceis de especificar antecipadamente, como a interface com o usuário (onde o feedback visual é vital), devem sempre ser desenvolvidos através de uma abordagem incremental.

Com essa flexibilidade em mente, sabendo que subsistemas diferentes podem exigir abordagens diferentes, vamos analisar três paradigmas gerais que influenciam a maioria dos métodos modernos de desenvolvimento.

O Modelo em Cascata (Waterfall)3.2.1

O primeiro modelo de processo de desenvolvimento de software a ser publicado foi derivado da engenharia de sistemas (ROYCE, 1970) e é conhecido como modelo em cascata ou ciclo de vida de software. Ele é um exemplo clássico de um processo dirigido a planos, onde se deve planejar e programar todas as atividades antes de iniciá-las. A principal característica desse modelo é o encadeamento sequencial das fases, onde cada estágio alimenta o próximo, conforme ilustrado na figura abaixo:

Os principais estágios deste modelo refletem diretamente as atividades fundamentais do desenvolvimento:

Análise e definição de requisitos: Os serviços, restrições e metas são estabelecidos com os usuários e definidos como uma especificação detalhada.
Projeto de sistema e software: Aloca-se os requisitos para hardware e software, definindo a arquitetura e descrevendo as abstrações fundamentais do sistema.
Implementação e teste unitário: O projeto é desenvolvido em unidades de programa, verificando se cada uma atende à sua especificação.
Integração e teste de sistema: As unidades são integradas e testadas como um sistema completo para assegurar o cumprimento dos requisitos antes da entrega.
Operação e manutenção: Fase geralmente mais longa, onde o sistema é usado, erros são corrigidos e novos requisitos são implementados.

Embora o modelo sugira que um estágio só comece após a aprovação documental do anterior, na prática, essas fases se sobrepõem e trocam informações constantemente. No entanto, devido aos custos de alterar documentos e iterar, é comum "congelar" especificações prematuramente para avançar, o que pode levar a sistemas que não atendem bem ao usuário se os requisitos mudarem. Por sua inflexibilidade, o modelo em cascata é mais adequado para projetos onde os requisitos são bem compreendidos e estáveis, sendo ainda muito utilizado por facilitar o monitoramento gerencial através da documentação produzida em cada fase.

Uma variação importante deste modelo é o desenvolvimento formal de sistemas, onde se cria um modelo matemático da especificação que é refinado em código executável através de transformações que preservam a consistência. Essa abordagem, vista em métodos como o método B, é ideal para sistemas críticos de segurança e proteção, pois permite demonstrar matematicamente que o programa corresponde à especificação. Contudo, devido à necessidade de conhecimentos especializados e alto custo, ela geralmente não oferece um bom custo-benefício para a maioria dos sistemas que não possuem requisitos críticos de segurança.

Desenvolvimento Incremental3.2.2

O desenvolvimento incremental baseia-se na ideia de criar uma implementação inicial, expô-la aos comentários dos usuários e evoluí-la através de várias versões até que um sistema adequado seja finalizado. Diferente do modelo em cascata, aqui as atividades de especificação, desenvolvimento e validação são intercaladas e ocorrem simultaneamente, permitindo um rápido feedback entre elas, conforme ilustrado na figura abaixo:

Essa abordagem é fundamental para as metodologias ágeis e reflete a maneira natural como os seres humanos resolvem problemas: avançando passo a passo e corrigindo o curso conforme necessário, em vez de planejar uma solução completa antecipadamente. Isso a torna superior ao modelo em cascata para sistemas de negócios e e-commerce. Ao priorizar as funcionalidades mais importantes ou urgentes nos primeiros incrementos, o cliente pode avaliar o sistema cedo; caso haja problemas, apenas o incremento atual precisa ser alterado, tornando as mudanças durante o desenvolvimento mais baratas e fáceis do que as correções tardias de um processo linear.

Em comparação ao modelo em cascata, o desenvolvimento incremental oferece três grandes vantagens: reduz o custo de acomodar mudanças nos requisitos (menos retrabalho de documentação), facilita o feedback do cliente (que pode avaliar software funcionando em vez de documentos abstratos) e permite a entrega rápida de software útil, gerando valor antes mesmo da conclusão total. Essa abordagem pode ser gerenciada de forma dirigida a planos (com incrementos definidos previamente) ou de forma ágil (onde os incrementos futuros dependem do progresso e das prioridades do cliente), sendo esta última a mais comum atualmente para sistemas aplicativos.

No entanto, do ponto de vista gerencial, o modelo apresenta desafios. O processo é menos visível, pois não é economicamente viável produzir documentação detalhada para cada versão rápida, dificultando a mensuração do progresso. Além disso, a estrutura do sistema tende a degradar com as constantes adições, exigindo investimento contínuo em refatoração para evitar que futuras mudanças se tornem onerosas. Esses problemas são críticos em sistemas grandes e complexos (sistemas de vida longa), onde uma arquitetura estável deve ser planejada antecipadamente para coordenar múltiplas equipes, e não desenvolvida incrementalmente. Por fim, é importante notar que desenvolvimento incremental é diferente de entrega incremental: você pode desenvolver em etapas para obter feedback sem necessariamente implantar cada versão no ambiente operacional do cliente, o que evita a interrupção frequente dos processos de negócios normais.

Engenharia de Software Orientada a Reúso3.2.3

Na maioria dos projetos, o reúso de código acontece de maneira informal, mas atualmente, processos formalizados com foco no reúso tornaram-se amplamente utilizados. Essas abordagens dependem de uma base de componentes existentes (que podem variar desde Web services e coleções de objetos para frameworks como .NET ou J2EE, até sistemas completos do tipo COTS) e de um framework de integração. Um modelo geral desse processo é apresentado na Figura 2.3 abaixo, onde, diferentemente dos modelos tradicionais, os estágios intermediários são adaptados para capitalizar sobre o que já existe:

Apesar das etapas iniciais serem bem parecidas com os métodos anteriores, o processo segue quatro etapas distintas após a especificação inicial do sistema:

Análise de componentes: Busca-se componentes que atendam à especificação, muitas vezes encontrando correspondências parciais.
Modificação de requisitos: Os requisitos são alterados para se adequarem aos componentes disponíveis, podendo reiniciar a busca se necessário.
Projeto do sistema com reúso: O framework é projetado ou escolhido considerando os componentes selecionados, criando novos softwares apenas se não houver opção de reúso.
Desenvolvimento e integração: Integra-se os componentes (incluindo sistemas COTS) e desenvolve-se o código faltante.

A principal vantagem dessa abordagem é a redução de custos, riscos e do tempo de entrega, uma vez que há menos software a ser desenvolvido do zero. No entanto, isso traz desvantagens inerentes: inevitavelmente ocorrem compromissos nos requisitos, o que pode resultar em um sistema que não atende perfeitamente às necessidades reais do usuário, além da perda de controle sobre a evolução do sistema, já que as atualizações dos componentes reutilizados ficam a cargo de terceiros e não da organização que os utiliza.

Atividades do Processo3.3

Agora que entendemos os "formatos" (os modelos), precisamos olhar mais de perto para o "conteúdo": as atividades técnicas reais que ocorrem dentro desses processos, independentemente do modelo escolhido.

Especificação de Software3.3.1

A especificação de software, ou engenharia de requisitos, é o processo crítico de compreender e definir os serviços que o sistema deve prestar e as restrições sob as quais deve operar. Como erros nesta fase geram problemas inevitáveis no projeto e implementação, o objetivo é produzir um documento de requisitos acordado que satisfaça os stakeholders. Esses requisitos são apresentados em dois níveis de detalhe: declarações de alto nível para usuários finais e clientes, e especificações detalhadas para os desenvolvedores do sistema. O fluxo desse processo é ilustrado na figura abaixo:

O processo engloba quatro atividades principais: o estudo de viabilidade, uma análise rápida e econômica para decidir se o projeto é tecnicamente possível e financeiramente rentável; a elicitação e análise, que deriva os requisitos através de observação, discussões e modelos de sistema; a especificação, que traduz a análise em um documento formal contendo requisitos de usuário (abstratos) e de sistema (detalhados); e a validação, que checa a completude, consistência e realismo dos requisitos para corrigir erros. Embora apresentadas sequencialmente, na prática essas atividades são intercaladas e contínuas, especialmente em métodos ágeis, onde os requisitos são desenvolvidos incrementalmente com a participação ativa do usuário na equipe.

Projeto e Implementação de Software3.3.2

O estágio de implementação é o processo de conversão de uma especificação em um sistema executável, envolvendo atividades de projeto e programação que, em abordagens incrementais, também refinam a própria especificação. O projeto de software descreve a estrutura, dados, interfaces e algoritmos do sistema, desenvolvendo-se de forma iterativa à medida que detalhes e formalidade são adicionados. Conforme ilustrado na figura abaixo, esse processo depende de entradas essenciais como informações da plataforma (sistema operacional, banco de dados), especificações de requisitos e descrições de dados. Embora o modelo sugira um fluxo sequencial, na realidade as atividades são intercaladas, com feedback constante entre os estágios.

Para sistemas de informação, o processo de projeto geralmente engloba quatro atividades fundamentais: (1) Projeto de arquitetura, que define a estrutura global e os relacionamentos entre os principais subsistemas; (2) Projeto de interface, que estabelece especificações inequívocas permitindo que componentes sejam desenvolvidos independentemente sem conhecimento de suas implementações internas; (3) Projeto de componente, que detalha o funcionamento específico de cada parte, podendo variar de declarações simples a modelos detalhados para geração automática; e (4) Projeto de banco de dados, que estrutura a representação dos dados do sistema.

As saídas desse processo variam drasticamente conforme a metodologia: sistemas críticos exigem documentação detalhada, abordagens dirigidas a modelos (MDD) focam em diagramas capazes de gerar código, e métodos ágeis muitas vezes consideram o próprio código como a documentação de projeto. A programação em si é uma atividade pessoal sem um processo universal, onde cada desenvolvedor adota sua própria estratégia (como focar primeiro nos dados ou nas funcionalidades mais difíceis). Durante essa fase, os programadores realizam testes para revelar falhas e executam o debugging, o processo de localizar e corrigir esses defeitos através da formulação e teste de hipóteses sobre o comportamento do software.

Validação de Software3.3.3

A validação de software, ou genericamente verificação e validação (V&V), tem o objetivo de demonstrar que o software atende tanto às suas especificações técnicas (verificação) quanto às necessidades reais do cliente (validação). Embora inclua processos de inspeção e revisão em várias fases, a principal técnica utilizada é o teste de programa, que consome a maior parte dos custos desta etapa. Como sistemas complexos não devem ser testados como uma unidade monolítica, o processo é dividido em estágios iterativos onde defeitos são descobertos, corrigidos e retestados, conforme ilustrado abaixo:

Os estágios fundamentais do processo de teste são:

Testes de desenvolvimento: Realizados pelos próprios desenvolvedores de forma independente em cada componente (funções ou classes), frequentemente utilizando ferramentas de automação como JUnit.
Testes de sistema: Os componentes são integrados para formar o sistema completo (ou subsistemas em projetos maiores). O foco aqui é encontrar erros de interface, interações inesperadas e validar requisitos funcionais e não funcionais.
Testes de aceitação: O estágio final antes do uso operacional, onde o sistema é testado com dados reais fornecidos pelo cliente, e não dados simulados. Isso pode revelar erros na definição dos requisitos e problemas de desempenho que não apareceram nos testes anteriores.

A execução desses testes varia conforme a metodologia. Em abordagens incrementais e ágeis (como XP), os testes são intercalados com o desenvolvimento, muitas vezes escritos antes mesmo do código, garantindo feedback rápido. Já em processos dirigidos a planos, comuns em sistemas críticos, os testes são guiados por planos pré-formulados que ligam as fases de especificação e projeto às fases de teste correspondentes. Esse relacionamento é frequentemente representado pelo "Modelo V":

Por fim, a validação de entrega assume formas diferentes dependendo do destino do software. Para sistemas sob encomenda, realiza-se o teste alfa, que continua até que desenvolvedor e cliente concordem que os requisitos foram atendidos. Para produtos de mercado, utiliza-se o teste beta, onde o software é liberado para um grupo de usuários potenciais que relatam problemas e bugs não antecipados em uso real, permitindo ajustes antes da venda geral.

Evolução de Software3.3.4

A flexibilidade inerente ao software é o principal motivo de sua incorporação em sistemas grandes e complexos. Ao contrário do hardware, onde alterações de projeto se tornam proibitivamente caras após a decisão de fabricação, o software permite mudanças a qualquer momento durante ou após o desenvolvimento. Mesmo modificações significativas no código são consideravelmente mais baratas do que as correspondentes alterações físicas no hardware. Historicamente, estabeleceu-se uma distinção entre o "desenvolvimento" (visto como uma atividade criativa de concepção inicial) e a "manutenção" (vista como uma tarefa maçante de correção). No entanto, essa visão é enganosa, pois os custos de manutenção frequentemente superam os custos de criação original.

Atualmente, a separação rígida entre desenvolvimento e manutenção tornou-se irrelevante, uma vez que poucos sistemas são construídos inteiramente do zero. É mais realista e eficaz encarar a engenharia de software como um processo evolutivo contínuo, onde a linha entre criar e manter deixa de existir. O software deve ser visualizado como um organismo vivo que é constantemente alterado durante todo o seu ciclo de vida para responder às mudanças de requisitos e novas necessidades do cliente, conforme ilustrado na figura abaixo:

Lidando com Mudanças3.4

A mudança é uma realidade inevitável em grandes projetos de software, impulsionada por alterações nos requisitos, pressões de negócio e novas tecnologias. Independentemente do modelo de processo adotado, é essencial que ele acomode essas modificações, pois a mudança gera "retrabalho", a necessidade de refazer análises, projetos e testes, o que inevitavelmente eleva os custos de desenvolvimento. Para mitigar esses custos, existem duas abordagens principais: a prevenção de mudanças, que busca antecipar alterações (por exemplo, através de protótipos que refinam requisitos antes de gastos elevados), e a tolerância a mudanças, que projeta o processo para acomodar alterações a baixo custo, permitindo, por exemplo, que modificações sejam aplicadas em incrementos ainda não desenvolvidos.

Duas técnicas específicas instrumentalizam essas abordagens. A prototipação de sistema foca na prevenção, desenvolvendo rapidamente uma versão para validar necessidades e decisões de projeto, permitindo que usuários refinem requisitos antes da entrega final e reduzindo propostas de alteração tardias. Já a entrega incremental suporta tanto a prevenção quanto a tolerância: ao entregar partes do sistema para experimentação, evita-se o compromisso prematuro com requisitos totais e permite-se que mudanças sejam incorporadas em incrementos futuros com baixo impacto financeiro. Vale mencionar também a refatoração, que melhora a estrutura do código para suportar mudanças contínuas (tema aprofundado em métodos ágeis).

Prototipação3.4.1

Um protótipo é uma versão inicial de um sistema utilizada para demonstrar conceitos, experimentar opções de projeto e descobrir mais sobre o problema antes da construção final. O desenvolvimento rápido e iterativo dessa versão é essencial para controlar custos e permitir que os stakeholders validem os requisitos no início do processo. Na engenharia de requisitos, o protótipo auxilia na elicitação e validação, revelando erros e omissões que descrições textuais não conseguem captar, especialmente quando funcionalidades interagem. No projeto de sistema, ele é vital para verificar a viabilidade técnica (como desempenho de banco de dados) e, fundamentalmente, para o design de interfaces de usuário, onde diagramas estáticos são insuficientes para expressar a dinâmica de uso.

O processo de desenvolvimento de protótipos deve ter objetivos explícitos desde o início, seja validar requisitos ou testar uma interface, para garantir que gerentes e usuários compreendam seu propósito. Para reduzir custos e acelerar a entrega, é comum relaxar requisitos não funcionais, como desempenho, robustez e tratamento de erros, focando apenas no que é necessário para a avaliação. O fluxo desse processo é ilustrado abaixo:

A fase final envolve a avaliação, onde usuários são treinados para testar o sistema. Contudo, há riscos: o comportamento do usuário no protótipo pode diferir do uso real devido a problemas de desempenho da versão de teste. Um perigo ainda maior ocorre quando gerentes pressionam para transformar um protótipo descartável (frequentemente sem documentação, com estrutura degradada e qualidade relaxada) no sistema final. Para evitar esses custos e riscos de código, pode-se recorrer a protótipos de baixa fidelidade, como maquetes em papel ou a técnica "Mágico de Oz", que simulam a interação sem a necessidade de software executável.

Entrega Incremental3.4.2

A entrega incremental é uma abordagem onde incrementos desenvolvidos são entregues e implantados para uso real em um ambiente operacional, diferindo da simples prototipação. O processo começa com os clientes identificando e priorizando os serviços desejados; os de maior prioridade são detalhados e desenvolvidos primeiro. Uma vez iniciado o desenvolvimento de um incremento, seus requisitos são congelados, embora a análise para incrementos futuros continue. Conforme cada parte é concluída, ela é integrada e entregue, permitindo que o cliente utilize as funcionalidades mais críticas imediatamente e forneça feedback baseado na experiência real para guiar as próximas fases. O fluxo desse processo é ilustrado abaixo:

Essa estratégia oferece vantagens significativas: ao contrário de protótipos descartáveis, o cliente ganha experiência com o sistema real sem necessidade de reaprendizado posterior, e o valor do negócio é entregue cedo. Além disso, como os incrementos de alta prioridade são os primeiros a serem entregues e permanecem em uso enquanto o resto é construído, eles recebem a maior carga de testes, reduzindo drasticamente a probabilidade de falhas nas partes mais importantes do sistema.

Entretanto, a entrega incremental apresenta desafios estruturais e gerenciais. Tecnicamente, é difícil identificar recursos básicos comuns (infraestrutura) necessários para todos os módulos quando não se tem uma especificação detalhada de todo o sistema no início. Operacionalmente, é difícil substituir sistemas legados, pois usuários relutam em trocar um sistema completo antigo por um novo ainda incompleto. Contratualmente, o modelo gera conflitos com departamentos de compras de grandes organizações e governos, que exigem especificações completas antes de assinar contratos, algo inexistente nessa abordagem até a fase final. Por essas razões, a entrega incremental não é ideal para sistemas muito grandes com equipes distribuídas, sistemas embutidos dependentes de hardware simultâneo ou sistemas críticos de segurança que exigem análise completa prévia; para estes, o uso de prototipagem iterativa prévia para definir requisitos fixos ainda é a melhor solução.

O Modelo Espiral de Boehm3.4.3

Proposto por Boehm (1988), o modelo em espiral é um framework de processo de software dirigido a riscos, onde o fluxo é representado não como uma sequência linear, mas como uma espiral em que cada volta corresponde a uma fase distinta do processo, partindo da viabilidade até o projeto detalhado. Diferentemente de outros modelos, este combina estratégias de prevenção e tolerância a mudanças ao assumir que as modificações são geralmente resultados de riscos de projeto, incorporando assim atividades explícitas de gerenciamento para mitigá-los. A estrutura desse modelo é ilustrada abaixo:

Cada ciclo da espiral é dividido em quatro setores fundamentais:

(1) Definição de objetivos, onde metas específicas, restrições e um plano de gerenciamento são elaborados juntamente com a identificação dos riscos;
(2) Avaliação e redução de riscos, fase analítica onde medidas como a criação de protótipos são tomadas para mitigar incertezas (como requisitos inadequados);
(3) Desenvolvimento e validação, onde o modelo de desenvolvimento é escolhido dinamicamente com base no risco dominante, por exemplo, usando métodos formais se o risco for segurança, ou o modelo em cascata se o risco for integração; e
(4) Planejamento, onde o projeto é revisado e decide-se se deve avançar para a próxima volta da espiral.

A grande inovação deste modelo é o reconhecimento explícito de que "risco" (algo que pode dar errado, como prazos, custos ou falhas técnicas) deve guiar o processo, resolvendo incertezas através de coleta de informações e simulação antes da construção efetiva.

Rational Unified Process (RUP)3.5

O Rational Unified Process (RUP) é um modelo de processo moderno e híbrido, derivado da UML, que combina elementos de modelos genéricos, boas práticas de especificação e suporte à prototipação e entrega incremental. Diferente dos modelos convencionais que apresentam uma visão única, o RUP é estruturado em três perspectivas: uma dinâmica (fases ao longo do tempo), uma estática (atividades ou workflows) e uma prática (melhores práticas recomendadas).

Sob a perspectiva dinâmica, o RUP divide o ciclo de vida em quatro fases distintas, que são orientadas aos objetivos de negócio e não apenas a tarefas técnicas. A iteração é suportada tanto dentro de cada fase quanto no ciclo completo (da transição de volta à concepção). As fases são:

Concepção: O foco é estabelecer o business case, identificar interações externas e avaliar se o projeto é viável e contribui para o negócio; caso contrário, é cancelado aqui.
Elaboração: Busca-se compreender o problema, estabelecer a arquitetura base, planejar o projeto e identificar/mitigar os maiores riscos. O resultado é um modelo de requisitos e arquitetura sólidos.
Construção: Envolve o projeto detalhado, programação e testes. As partes são desenvolvidas em paralelo e integradas, resultando em um software funcional e documentado.
Transição: A fase final transfere o sistema para o ambiente real do usuário. Diferente de outros modelos que ignoram essa etapa cara e complexa, o RUP a torna explícita para garantir o funcionamento operacional.

A grande inovação do RUP reside na separação entre essas fases e os workflows (perspectiva estática). Enquanto as fases são temporais, os workflows são atividades técnicas (como Modelagem de Negócios, Requisitos, Análise, Implementação, Teste e Implantação, além dos processos de apoio como Gerência de Configuração e Projeto) que ocorrem durante todo o projeto. Isso significa que não existe uma "fase de requisitos" isolada; o workflow de requisitos acontece em todas as fases, apenas com maior intensidade no início e menor no fim.

Por fim, a perspectiva prática do RUP prescreve seis boas práticas fundamentais para a engenharia de software moderna:

Desenvolver software iterativamente: Planejar incrementos baseados nas prioridades do cliente e riscos.
Gerenciar requisitos: Documentar explicitamente e controlar as mudanças e seus impactos.
Usar arquiteturas baseadas em componentes: Estruturar o sistema em módulos reutilizáveis.
Modelar visualmente (UML): Utilizar diagramas gráficos para representar as visões estáticas e dinâmicas.
Verificar a qualidade: Garantir conformidade com padrões organizacionais continuamente.
Controlar mudanças: Utilizar sistemas de gerenciamento de configuração para lidar com a evolução do software.

Questões3.6

1. Justificando sua resposta com base no tipo de sistema a ser desenvolvido, sugira o modelo genérico de processo de software mais adequado para ser usado como base para a gerência do desenvolvimento dos sistemas a seguir:

Um sistema para controlar o antibloqueio de frenagem de um carro.
Um sistema de realidade virtual para dar apoio à manutenção de software.
Um sistema de contabilidade para uma universidade, que substitua um sistema já existente.
Um sistema interativo de planejamento de viagens que ajude os usuários a planejar viagens com menor impacto ambiental.

2. Explique por que o desenvolvimento incremental é o método mais eficaz para o desenvolvimento de sistemas de software de negócios. Por que esse modelo é menos adequado para a engenharia de sistemas de tempo real?

3. Considere o modelo de processo baseado em reúso. Explique por que, nesse processo, é essencial ter duas atividades distintas de engenharia de requisitos.

4. Sugira por que é importante, no processo de engenharia de requisitos, fazer uma distinção entre desenvolvimento dos requisitos do usuário e desenvolvimento de requisitos de sistema.

5. Descreva as principais atividades do processo de projeto de software e as saídas dessas atividades. Usando um diagrama (ou descrição visual), mostre as possíveis relações entre as saídas dessas atividades.

6. Explique por que, em sistemas complexos, as mudanças são inevitáveis. Exemplifique as atividades de processo de software que ajudam a prever as mudanças e fazer com que o software seja desenvolvido mais tolerante a mudanças (nesta resposta, desconsidere a prototipação e a entrega incremental).

7. Explique por que os sistemas desenvolvidos como protótipos normalmente não devem ser usados como sistemas de produção.

8. Explique por que o modelo em espiral de Boehm é um modelo adaptável, que apoia tanto as atividades de prevenção de mudanças quanto as de tolerância a mudanças. Na prática, esse modelo não tem sido amplamente usado. Sugira as possíveis razões para isso.

9. Quais são as vantagens de proporcionar visões estáticas e dinâmicas do processo de software, assim como no Rational Unified Process (RUP)?

10. Historicamente, a introdução de tecnologia provocou mudanças profundas no mercado de trabalho e, pelo menos temporariamente, deixou muitas pessoas desempregadas. Discuta se a introdução da automação extensiva em processos pode vir a ter as mesmas consequências para os engenheiros de software. Se sua resposta for não, justifique. Se você acha que sim, que vai reduzir as oportunidades de emprego, é ética a resistência passiva ou ativa, pelos engenheiros afetados, à introdução dessa tecnologia?

Próximos Passos3.7

No próximo tópico, mergulharemos no Desenvolvimento Ágil: Scrum e XP. Veremos como a necessidade de lidar com a rápida mudança nos requisitos de negócios impulsionou o surgimento de métodos que rompem com a rigidez dos modelos tradicionais. Exploraremos em detalhes o funcionamento de metodologias como Scrum e Extreme Programming (XP), entendendo como elas reconfiguram as atividades fundamentais de software para priorizar a entrega contínua de valor e a colaboração intensa.