Engenharia de Software

Aula 02
Processos de Software
Prof. Esp. Bruno Guaringue Trindade
Processos de Software
Objetivos:

❑Compreender os conceitos e modelos de processos de software;

❑Apresentar modelos de processo de software e quando eles podem ser usados;
❑Conhecer atividades fundamentais do processo de engenharia de requisitos de software,
desenvolvimento de software, testes e evolução;
❑Entender por que os processos devem ser organizados de maneira a lidar com as mudanças de
requisitos e projeto de software;
❑Compreender como o Rational Unified Process (RUP) integra boas práticas de engenharia de
software para criar processos de software adaptáveis.
 Processos de Software
Um processo de software é um conjunto de atividades relacionadas que levam à produção de um
produto de software, sendo um novo projeto ou continuação de um software existente (manutenção,
expansão, etc).
Um Modelo Prescritivo de Processo de Software é um conjunto de elementos que inclui ações de
engenharia de software, produtos de trabalho e mecanismos que garantam a qualidade e controle de
modificações em cada projeto necessárias para o desenvolvimento de um sistema de software
(PRESSMAN, 2010)
Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades
fundamentais da Engenharia de Software:
1. Especificação de Software;
2. Projeto e implementação de software;
3. Validação de software;
4. Evolução de Software.
Processos de Software
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. Em processos ágeis, o planejamento é gradativo, ou seja, pode ser feito ao longo
do processo, sendo assim, o processo pode ser alterado de modo mais fácil para atender
necessidades de mudanças vindas do cliente.
Conforme Boehm e Turner (2003), cada abordagem é apropriada para diferentes tipos de
software. Geralmente, é necessário encontrar um equilíbrio entre os processos dirigidos a planos
e os processos ágeis.

Em determinados contextos, não existirá um processo ideal, portanto, muitas organizações

desenvolvem os próprios processos de desenvolvimento de software.
 Modelos de Processos de Software
Modelos de processos de software não são descrições definitivas do processo de software. Pelo
contrário, são abstrações que podem ser usadas para explicar diferentes abordagens de
desenvolvimento de software. Você pode vê-los como frameworks de processos que podem ser
ampliados e adaptados para criar processos de engenharia de software mais específicos.
Um Modelo Prescritivo de Processo de Software é um conjunto de elementos que inclui ações de
engenharia de software, produtos de trabalho e mecanismos que garantam a qualidade e controle de
modificações em cada projeto necessárias para o desenvolvimento de um sistema de software
(PRESSMAN, 2010)
Alguns dos principais modelos de processos de software:

1. Modelo em cascata;
2. Desenvolvimento incremental;
3. Engenharia de software orientada a reuso.
Modelo em Cascata
O primeiro modelo de processo de desenvolvimento de software a ser publicado foi derivado de
processos mais gerais de engenharia de sistemas (ROYCE, 1970). O modelo em cascata é um
exemplo de um processo dirigido a planos – em princípio , você deve projetar todas as atividades
do processo antes de começar a trabalhar nelas.
Principais estágios do modelo cascata:
1. Análise e definição de requisitos;
2. Projeto de sistema de software;
3. Implementação e teste unitário;
4. Integração e teste do sistema;
5. Operação e manutenção.
Modelo em Cascata
Modelo em Cascata
Análise e Definição de Requisitos: as funções, as restrições e os objetivos do sistema
são estabelecidos por meio de consulta aos usuários do sistema. Em seguida, são
definidos em detalhes e servem como uma especificação do sistema.

Projeto de Sistemas e Software: o processo de projeto de sistemas agrupa os requisitos

em sistemas de hardware e software. Envolve a identificação e a descrição das
abstrações fundamentais do sistema de software e suas relações.

Implementação e Teste Unitário: Durante este estágio, o projeto do software é

compreendido como um conjunto de programas ou unidades de programa. O teste de
unidade envolve verificar se cada uma das unidades atendem à sua especificação
Modelo em Cascata
Integração e Teste de sistemas: as unidades de programa ou programas individuais são
integrados e testados como um sistema completo a fim de garantir que os requisitos de
software foram atendidos. Depois do teste, o software é entregue ao cliente.

Operação e manutenção: O sistema é instalado e colocado em operação. Envolve

corrigir erros que não foram descobertos em estágios anteriores, melhorando a
implementação e descobrindo novos requisitos
Modelo em Cascata
Problemas:

1. Processo inflexível;
2. Dificuldade em absorver mudanças nos requisitos e demandas
por mudanças.

Portanto, o modelo em cascata é recomendado para projetos de

software em que os requisitos sejam totalmente conhecidos desde o
início e seja pouco provável que mudem radicalmente ao longo do
projeto.
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. Atividades de especificação, desenvolvimento e
validação são intercaladas, e não separadas, como rápido feedback entre todas as atividades.
Desenvolvimento Incremental
O desenvolvimento incremental tem três vantagens importantes quando comparado ao modelo
em cascata:
1. O custo de acomodar as mudanças de requisitos do cliente é reduzido. A quantidade de
análise e documentação que precisa ser refeita é muito menor do que o necessário no
modelo em cascata.
2. É mais fácil obter feedback dos clientes sobre o desenvolvimento do que foi feito. Os clientes
fazem comentários sobre as demonstração 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
todas as funcionalidades não forem incluídas. Entrega de módulos.
 Desenvolvimento Incremental
Outras vantagens:
1. Redução dos riscos envolvendo custos a um único incremento.
2. Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa
fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos
pressão do que numa fase final de projeto.
3. Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores
trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.
4. Reconhecimento de uma realidade frequentemente ignorada: as necessidades dos usuários e os
requisitos correspondentes não podem ser totalmente definidos no início do processo.
5. Este modelo de operação facilita a adaptação a mudanças de requisitos.
Desenvolvimento Incremental
Do ponto de vista do gerenciamento, a abordagem incremental tem dois problemas:

1. O processo não é visível, ou sua compreensão é mais complexa. 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 de novos incrementos. Incorporar
futuras mudanças do software pode ser feito até um limite viável, depois irá tornar-se cada
vez mais difícil e oneroso.
Desenvolvimento Incremental
Conclui-se que:
Sistemas de grande porte necessitam de um framework ou arquitetura estável, e as
responsabilidades das diferentes equipes do sistemas precisa ser claramente definidas. Portanto,
deve ser planejado com antecedência, e não desenvolvido de forma incremental.

Recomendação de utilização:
Softwares voltados para negócios, como plataformas de e-commerce.
Engenharia de Software orientada
a reúso
Na maioria dos projetos de software, há algum reúso de código. Isso acontece muitas vezes
informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou códigos
semelhantes ao que é exigido. No entanto, no século XXI, processos de desenvolvimento de
software com foco no reúso de software passarem a ser formalmente e amplamente utilizados.
Estágios principais da engenharia de software orientada a reúso:
1. Análise de componentes;
2. Modificação de requisitos;
3. Projeto do sistema com reúso;
4. Desenvolvimento e Integração.
Engenharia de Software orientada
a reúso
Análise de componentes: Dada a especificação de requisitos, é feita uma busca por componentes
para implementar essa especificação. Em geral, não há correspondência exata, e os
componentes que podem ser usados apenas fornecem algumas funcionalidade necessária.
Modificação de requisito: 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 refletis os componentes disponíveis.
Projeto do sistema com reúso: Durante esse estágio, o framework do sistema é projetado ou algo
existente é utilizado. Os projetistas tem em mente os componentes que serão usados e
organizam o projeto para realizar o reúso.
Desenvolvimento e integração: Softwares que não podem ser adquiridos através do reúso são
desenvolvidos ou os componentes reutilizados são integrados para criar um novo sistema.
Engenharia de Software orientada
a reúso
Existem três tipos de componente 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 JSF.
3. Sistemas de softwares stand-alone configurados para uso em um ambiente particular.
Engenharia de Software orientada
a reúso
Vantagens:
Confiança aumentada;
Risco de processo reduzido;
Uso eficiente de especialistas;
Conformidade com padrões;
Desenvolvimento acelerado.
Problemas:
Custos de manutenção aumentados
◦ Código do componente indisponível
Falta de apoio de ferramenta
◦ Muitas ferramentas CASE não apoiam o reuso
Síndrome do não-inventado-aqui
◦ Preferência em reescrever o componente
Criação e manutenção de uma biblioteca
de componentes
◦ Imaturidade na organização de uma biblioteca
de componentes
Dúvidas
Bibliografia
[1] SOMMERVILLE, I. Engenharia de software. 9. ed. Pearson (Nacionais) 2011.
[2] PRESSMAN, R. S. Engenharia de Software . McGraw-Hill, 2006.
[3] PAULA, W. Engenharia de Software: Fundamentos, Métodos e Padrões. 2 ed. Rio de Janeiro:
LTC, 2003.