Capítulo 2 - Processo de Software

Tópicos Abordados:

● Modelos de Processo de Software

● Atividades do Processo
● Lidando com Mudanças
● The Rational Unified Process (RUP) (Um exemplo de processo de software moderno)

O Processo de Software

Um processo de software é um conjunto de atividades relacionadas que levam à produção de

um produto de software.

Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades
fundamentais para a engenharia de software:
1. Especificação de software. A funcionalidade do software e as restrições a seu
funcionamento devem ser definidas.
2. Projeto e implementação de software. O software deve ser produzido para atender às
especificações.
3. Validação de software. O software deve ser validado para garantir que atenda às demandas
do cliente.
4. Evolução de software. O software deve evoluir para atender às necessidades de mudança
dos clientes.

Um modelo de processo de software é uma representação abstrata de um processo. Ele

representa uma descrição de um processo de uma perspectiva particular.

Descrições de Processos de Software

Ao descrever e discutir os processos, costumamos falar sobre suas atividades, como a

especificação de um modelo de dados, o projeto de interface de usuário etc., bem como a
organização dessas atividades. No entanto, assim como as atividades, as descrições do
processo também podem incluir:

1. Produtos, que são os resultados de uma das atividades do processo.

2. Papéis, que refletem as responsabilidades das pessoas envolvidas no processo.
3. Pré e pós-condições, que são declarações verdadeiras antes e depois de uma atividade do
processo ou da produção de um produto.

Plan-driven e Agile Processes (Processos Dirigidos a Planos e Processos Ágeis)

Os processos de software, às vezes, são categorizados como dirigidos a planos ou processos

ágeis.
Processos dirigidos a planos são aqueles em que todas as atividades são planejadas com
antecedência, e o progresso é avaliado por comparação com o planejamento inicial.
Em processos ágeis, que são discutidos no Capítulo 3, o planejamento é gradativo, e é mais fácil
alterar o processo de maneira a refletir as necessidades de mudança dos clientes.
Geralmente, é necessário encontrar um equilíbrio entre os processos dirigidos a planos e os
processos ágeis.
Embora não exista um processo ‘ideal’ de software, há espaço, em muitas organizações, para
melhorias no processo de software.
1- Modelos de Processo de Software

Como já foi discutido, um modelo de processo de software é uma representação simplificada de

um processo de software.

Os modelos de processo que abordados aqui são:

● O modelo em cascata: Modelo orientado a planos. Fases separadas e distintas de
especificação e desenvolvimento.
● Desenvolvimento incremental: Especificação, desenvolvimento e validação são
intercalados. Pode ser orientado a planos ou ágil.
● Engenharia de software orientada a reúso: O sistema é montado a partir de
componentes existentes. Pode ser orientado a planos ou ágil.

Esses modelos não são mutuamente exclusivos e muitas vezes são usados em conjunto,
especialmente para o desenvolvimento de sistemas de grande porte.

1.1 O Modelo em Cascata

Os principais estágios do modelo em cascata refletem diretamente as atividades fundamentais

do desenvolvimento:
1. Análise e definição de requisitos. Os serviços, restrições e metas do sistema são
estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e
funcionam como uma especificação do sistema.
2. Projeto de sistema e software. O processo de projeto de sistemas aloca os requisitos tanto
para sistemas de hardware como para sistemas de software, por meio da definição de uma
arquitetura geral do sistema. O projeto de software envolve identificação e descrição das
abstrações fundamentais do sistema de software e seus relacionamentos.
3. Implementação e teste unitário. Durante esse estágio, o projeto do software é desenvolvido
como um conjunto de programas ou unidades de programa. O teste unitário envolve a
verificação de que cada unidade atenda a sua especificação.
4. Integração e teste de sistema. As unidades individuais do programa ou programas são
integradas e testadas como um sistema completo para assegurar que os requisitos do software
tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente.
5. Operação e manutenção. Normalmente (embora não necessariamente), essa é a fase mais
longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a
correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhora
da implementação das unidades do sistema e ampliação de seus serviços em resposta às
descobertas de novos requisitos.
A principal desvantagem do modelo em cascata é a dificuldade de acomodar a mudança depois
que o processo está em andamento. Em princípio, uma fase deve ser concluída antes de passar
para a próxima fase.

Problemas do Modelo Cascata

Seu maior problema é a divisão inflexível do projeto em estágios distintos. Os compromissos

devem ser assumidos em um estágio inicial do processo, o que dificulta que atendam às
mudanças de requisitos dos clientes.
O modelo em cascata é usado principalmente para grandes projetos de engenharia de sistemas
onde um sistema é desenvolvido em vários locais. Nessas circunstâncias, a natureza orientada a
planos do modelo em cascata ajuda a coordenar o trabalho.

1.2 Desenvolvimento Incremental

O desenvolvimento incremental é baseado na ideia de desenvolver uma implementação inicial,

expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que
um sistema adequado seja desenvolvido.

O desenvolvimento incremental tem três vantagens importantes quando comparado ao modelo

em cascata:
1. O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A quantidade de
análise e documentação a ser refeita é muito menor do que o necessário no modelo em cascata.
2. É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes
podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado.
3. É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se
toda a funcionalidade não for incluída. Os clientes podem usar e obter ganhos a partir do
software inicial antes do que é possível com um processo em cascata.

Problemas do Desenvolvimento Incremental

Do ponto de vista do gerenciamento, a abordagem incremental tem dois problemas:

1. O processo não é visível. Os gerentes precisam de entregas regulares para mensurar o
progresso. Se os sistemas são desenvolvidos com rapidez, não é economicamente viável
produzir documentos que reflitam cada uma das versões do sistema.
2. A estrutura do sistema tende a se degradar com a adição dos novos incrementos. A menos
que tempo e dinheiro sejam dispendidos em refatoração para melhoria do software, as
constantes mudanças tendem a corromper sua estrutura. Incorporar futuras mudanças do
software torna-se cada vez mais difícil e oneroso.
1.3 Engenharia de Software Orientada a Reúso

Com base na reutilização sistemática onde os sistemas são integrados a partir de componentes
existentes ou sistemas COTS (Commercial-off-the-shelf). (sistemas de prateleira)

Estágios do processo:
1. Análise de componentes. Dada a especificação de requisitos, é feita uma busca por
componentes para implementar essa especificação.
2. Modificação de requisitos. Durante esse estágio, os requisitos são analisados usando-se
informações sobre os componentes que foram descobertos. Em seguida, estes serão
modificados para refletir os componentes disponíveis.
3. Projeto do sistema com reuso. Durante esse estágio, o framework do sistema é projetado
ou algo existente é reusado.
4. Desenvolvimento e integração. Softwares que não podem ser adquiridos externamente são
desenvolvidos, e os componentes e sistemas COTS são integrados para criar o novo sistema.

A reutilização é agora a abordagem padrão para construir muitos tipos de sistemas de negócios.
Reutilização abordada com mais profundidade no Capítulo 16.

Tipos de Componentes de Software

Existem três tipos de componentes de software que podem ser usados em um processo
orientado a reúso:
1. Web services desenvolvidos de acordo com os padrões de serviço e que estão disponíveis
para invocação remota.
2. Coleções de objetos que são desenvolvidas como um pacote a ser integrado com um
framework de componentes, como .NET ou J2EE.
3. Sistemas de software stand-alone configurados para uso em um ambiente particular.

2 - Atividades do Processo

Processos reais de software são intercalados com sequências de atividades técnicas, de

colaboração e de gerência, com o intuito de especificar, projetar, implementar e testar um
sistema de software. Os desenvolvedores de software usam uma variedade de diferentes
ferramentas de software em seu trabalho.
As quatro atividades básicas do processo — especificação, desenvolvimento, validação e
evolução — são organizadas de forma diferente conforme o processo de desenvolvimento. No
modelo em cascata são organizadas em sequência, enquanto que no desenvolvimento
incremental são intercaladas.
2.1 Especificação de Software

Especificação de software ou engenharia de requisitos é o processo de compreensão e definição

dos serviços requisitados do sistema e identificação de restrições relativas à operação e ao
desenvolvimento do sistema.

Existem quatro atividades principais do processo de engenharia de requisitos:

1. Estudo de viabilidade. É feita uma estimativa acerca da possibilidade de se satisfazerem as
necessidades do usuário identificado usando-se tecnologias atuais de software e hardware.
2. Elicitação e análise de requisitos. Esse é o processo de derivação dos requisitos do
sistema por meio da observação dos sistemas existentes, além de discussões com os potenciais
usuários e compradores, análise de tarefas, entre outras etapas.
3. Especificação de requisitos. É a atividade de traduzir as informações obtidas durante a
atividade de análise em um documento que define um conjunto de requisitos.
4. A validação de requisitos. Essa atividade verifica os requisitos quanto à realismo,
consistência e completude.

2.2 Projeto e Implementação de Software

O estágio de implementação do desenvolvimento de software é o processo de conversão de

uma especificação do sistema em um sistema executável.

● Projeto de software: Projetar uma estrutura de software que realize a especificação;

● Implementação: Traduz essa estrutura em um programa executável;

Atividades de projeto

As atividades de projeto e implementação estão intimamente relacionadas e podem ser

intercaladas.

1. Projeto de arquitetura, no qual você pode identificar a estrutura geral do sistema, os

componentes principais (algumas vezes, chamados subsistemas ou módulos), seus
relacionamentos e como eles são distribuídos.
2. Projeto de interface, no qual você define as interfaces entre os componentes do sistema.
3. Projeto de componente, no qual você toma cada componente do sistema e projeta seu
funcionamento.
4. Projeto de banco de dados, no qual você projeta as estruturas de dados do sistema e como
elas devem ser representadas em um banco de dados.
A Figura 2.5 mostra quatro atividades que podem ser parte do processo de projeto de sistemas
de informação:
2.3 Validação de Software

- Validação de software ou verificação e validação (V & V), tem a intenção de mostrar que
um software se adequa a suas especificações ao mesmo tempo que satisfaz as
especificações do cliente do sistema. Envolve verificação e revisão de processos e testes
de sistema.
- O teste do sistema envolve a execução do sistema com casos de teste que são
derivados da especificação dos dados reais a serem processados ​pelo sistema.
- O teste é a atividade de V & V mais comumente usada.

Estágios do processo

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

1. Testes de componentes. Os componentes individuais são testados independentemente; Os

componentes podem ser funções ou objetos ou agrupamentos coerentes dessas entidades.
2. Testes de sistema. Teste do sistema como um todo. O teste de propriedades emergentes é
particularmente importante.
3. Teste de aceitação. Testes com dados do cliente para verificar se o sistema atende às
necessidades do cliente.
Fases de Testes de um Processo de Software Dirigido a Planos

A Figura 2.7 ilustra como os planos de teste são o elo entre as atividades de teste e de
desenvolvimento. Esse modelo é, às vezes, chamado modelo V de desenvolvimento.

2.4 Evolução do Software

A flexibilidade dos sistemas de software é uma das principais razões pelas quais os softwares
vêm sendo, cada vez mais, incorporados em sistemas grandes e complexos.
À medida que os requisitos mudam por meio de circunstâncias de negócios em constante
mudança, o software que suporta os negócios também deve evoluir e mudar.
Embora tenha havido uma demarcação entre desenvolvimento e evolução (manutenção), isso é
cada vez mais irrelevante, pois cada vez menos sistemas são completamente novos.
Em vez de dois processos separados, é mais realista pensar na engenharia de software como
um processo evolutivo, no qual o software é constantemente alterado durante seu período de
vida em resposta às mudanças de requisitos e às necessidades do cliente.

2.5 Pontos Importantes: (REVISÃO)

● Processos de software são as atividades envolvidas na produção de um sistema de

software. Os modelos de processo de software são representações abstratas desses
processos.
● Os modelos gerais de processos descrevem a organização dos processos de software.
Exemplos desses modelos gerais incluem o modelo "cascata", desenvolvimento
incremental e desenvolvimento orientado para a reutilização.
● A engenharia de requisitos é o processo de desenvolvimento de uma especificação de
software.
● Os processos de projeto e implementação estão preocupados em transformar uma
especificação de requisitos em um sistema de software executável.
● A validação de software é o processo de verificar se o sistema está em conformidade
com sua especificação e atende às reais necessidades dos usuários do sistema.
● A evolução do software ocorre quando você altera os sistemas de software existentes
para atender a novos requisitos. O software deve evoluir para permanecer útil.
3 - Lidando com Mudanças

A mudança é inevitável em todos os grandes projetos de software. Mudanças nos negócios

levam a requisitos de sistema novos e alterados. Novas tecnologias abrem novas possibilidades
para melhorar as implementações. Mudar de plataforma requer mudanças de aplicativo. A
mudança leva ao retrabalho, de modo que os custos da mudança incluem tanto o retrabalho (por
exemplo, reanálise de requisitos) quanto os custos de implementação de novas funcionalidades.

Existem duas abordagens que podem ser adotadas para a redução de custos de retrabalho:
1. Prevenção de mudanças, em que o processo de software inclui atividades capazes de
antecipar as mudanças possíveis antes que seja necessário qualquer retrabalho. Por exemplo,
um protótipo de sistema pode ser desenvolvido para mostrar algumas características-chave do
sistema para os clientes.
2. Tolerância a mudanças, em que o processo foi projetado para que as mudanças possam ser
acomodadas a um custo relativamente baixo. Isso normalmente envolve alguma forma de
desenvolvimento incremental. As alterações propostas podem ser aplicadas em incrementos que
ainda não foram desenvolvidos. Se isso for impossível, então apenas um incremento (uma
pequena parte do sistema) deve ser alterado para incorporar as mudanças.

O autor discute outras duas maneiras de lidar com mudanças e mudanças nos requisitos
do sistema. São elas:

1. Prototipação de sistema: Um protótipo é uma versão inicial de um sistema de software,

usado para demonstrar conceitos, experimentar opções de projeto e descobrir mais sobre o
problema e suas possíveis soluções.

Um protótipo de software pode ser usado:

- No processo de engenharia de requisitos para ajudar na elicitação e validação de
requisitos;
- Nos projetos de sistema para explorar opções e desenvolver um projeto de interface do
usuário;
- No processo de teste para executar testes consecutivos.

Benefícios da Prototipação

● Melhor usabilidade do sistema.

● Uma correspondência mais próxima às necessidades reais dos usuários.
● Qualidade de projeto melhorada.
● Manutenibilidade melhorada.
● Esforço de desenvolvimento reduzido.

Processo de desenvolvimento de protótipo

Desenvolvimento de Protótipo

Pode ser baseado em linguagens ou ferramentas de prototipagem rápida. Pode envolver:

- Deixar de fora algumas funcionalidades.
- O protótipo deve focar em áreas do produto que não são bem compreendidas;
- A verificação e a recuperação de erros podem não estar incluídas no protótipo;
- Concentre-se em requisitos funcionais em vez de não funcionais, como confiabilidade e
segurança.

Protótipos Descartáveis

Os protótipos devem ser descartados após o desenvolvimento, pois não são uma boa base para
um sistema de produção:
- Pode ser impossível ajustar o sistema para atender a requisitos não funcionais;
- Os protótipos normalmente não são documentados;
- A estrutura do protótipo geralmente é degradada por meio de mudanças rápidas;
- O protótipo provavelmente não atenderá aos padrões normais de qualidade
organizacional

2. Entrega Incremental

- Em vez de entregar o sistema como uma única entrega, o desenvolvimento e a entrega

são divididos em incrementos com cada incremento entregando parte da funcionalidade
necessária.
- Os requisitos do usuário são priorizados e os requisitos de prioridade mais alta são
incluídos em incrementos iniciais.
- Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são
congelados, embora os requisitos para incrementos posteriores possam continuar a
evoluir.

Desenvolvimento e entrega incremental

● Desenvolvimento incremental:
- Desenvolva o sistema em incrementos e avalie cada incremento antes de
prosseguir para o desenvolvimento do próximo incremento;
- Abordagem normal utilizada em métodos ágeis;
- Avaliação feita por proxy de usuário/cliente.

● Entrega incremental:
- Implante um incremento para uso pelos usuários finais;
- Avaliação mais realista sobre o uso prático do software;
- Difícil de implementar para sistemas de substituição, pois os incrementos têm
menos funcionalidade do que o sistema que está sendo substituído.
Vantagens de entrega incremental

- Os clientes não precisam esperar até todo o sistema ficar pronto para obter lucro.
- Os incrementos iniciais atuam como um protótipo para ajudar a elicitar requisitos para
incrementos posteriores.
- Menor risco de falha geral do projeto.
- Os serviços de sistema de prioridade mais alta tendem a receber mais testes.

Problemas de entrega incremental

- A maioria dos sistemas requer um conjunto de recursos básicos que são usados ​por
diferentes partes do sistema.
- Como os requisitos não são definidos em detalhes até que um incremento seja
implementado, pode ser difícil identificar recursos comuns que são necessários para
todos os incrementos.
- A essência dos processos iterativos é que a especificação é desenvolvida em conjunto
com o software.
- No entanto, isso entra em conflito com o modelo de aquisição de muitas organizações,
onde a especificação completa do sistema faz parte do contrato de desenvolvimento do
sistema.

3. Modelo Espiral de Boehm

Um framework de processo de software dirigido a riscos (o modelo em espiral) foi proposto por
Boehm (1988).

- O processo é representado como uma espiral e não como uma sequência de atividades
com retrocesso.
- Cada loop na espiral representa uma fase do processo.
- Nenhuma fase fixa, como especificação ou design - os loops na espiral são escolhidos
dependendo do que é necessário.
- Os riscos são explicitamente avaliados e resolvidos ao longo do processo.
Setores do Modelo em Espiral

● Definição do objetivo: Os objetivos específicos para a fase são identificados.

● Avaliação e redução de riscos: Os riscos são avaliados e as atividades são
implementadas para reduzir os principais riscos.
● Desenvolvimento e validação: É escolhido um modelo de desenvolvimento para o
sistema que pode ser qualquer um dos modelos genéricos.
● Planejamento: O projeto é revisado e a próxima fase da espiral é planejada.

Uso do Modelo em Espiral

- O modelo espiral tem sido muito influente em ajudar as pessoas a pensar sobre iteração
em processos de software e introduzir a abordagem orientada a riscos para o
desenvolvimento.
- Na prática, no entanto, o modelo raramente é usado como publicado para o
desenvolvimento prático de software.

4 - Rational Unified Process (RUP) (Processo Racional Unificado)

Um processo genérico moderno derivado do trabalho na UML e processos associados.

Reúne aspectos dos 3 modelos genéricos de processo discutidos anteriormente.

Normalmente descrito a partir de 3 perspectivas:

- Uma perspectiva dinâmica que mostra fases ao longo do tempo;
- Uma perspectiva estática que mostra as atividades do processo;
- Uma perspectiva prática que sugere boas práticas.

Fases do RUP

● Concepção: Estabelecer o caso de negócios para o sistema.

● Elaboração: Desenvolver uma compreensão do domínio do problema e da arquitetura
do sistema.
● Construção: Projeto, programação e testes de sistemas.
● Transição: Implante o sistema em seu ambiente operacional.

Iteração do RUP

● Iteração em fase: Cada fase é iterativa com resultados desenvolvidos de forma

incremental.
● Iteração entre fases: Conforme mostrado pelo loop no modelo RUP, todo o conjunto de
fases pode ser executado de forma incremental.
 Workflows estáticos no Rational Unified Process

Boas Práticas RUP

● Desenvolver software de forma iterativa: Planeje incrementos com base nas

prioridades do cliente e entregue primeiro os incrementos de prioridade mais alta.
● Gerenciar requisitos: Documente explicitamente os requisitos do cliente e acompanhe
as mudanças nesses requisitos.
● Use arquiteturas baseadas em componentes: Organize a arquitetura do sistema como
um conjunto de componentes reutilizáveis
● Software de modelagem visual: Use modelos gráficos UML para apresentar
visualizações estáticas e dinâmicas do software.
● Verifique a qualidade do software: Certifique-se de que o software atenda aos padrões
de qualidade organizacional.
● Controlar alterações no software: Gerencie mudanças de software usando um sistema
de gerenciamento de mudanças e ferramentas de gerenciamento de configuração.
.
4.1 Pontos Importantes: (REVISÃO)

● Os processos devem incluir atividades para lidar com a mudança. Isso pode envolver
uma fase de prototipagem que ajuda a evitar decisões ruins sobre requisitos e design.
● Os processos podem ser estruturados para desenvolvimento e entrega iterativo, de modo
que as mudanças possam ser feitas sem interromper o sistema como um todo.
● O Rational Unified Process é um modelo de processo genérico moderno que é
organizado em fases (início, elaboração, construção e transição), mas separa as
atividades (requisitos, análise e projeto, etc.) dessas fases.