1. Engenharia de Software

2. Tópicos – Engenharia de Software
 O que é?
 Camadas
 Perguntas que devem ser respondidas
 Fases genéricas da Engenharia de Software
 Modelos de Processos de Engenharia de Software
 Modelos de Processos de Desenvolvimento de Software
 RUP - (Rational Unified Process)

3. O que é Engenharia de Software?
É um conceito que está baseado em camadas:
 Qualidade: Toda engenharia deve se fundamentar no
comprometimento com a qualidade;
 Processo: É a base da engenharia de software. É o
processo que “cola” as ferramentas e os métodos;
 Métodos: Fornecem a definição do “como fazer” o
desenvolvimento de software;
 Ferramentas: Realizam o suporte automatizado ou
semi-automatizado para os processos e métodos
(exemplo: ferramentas CASE);

4. Camadas de Engenharia de Software
Ferramentas
Métodos
Processos
Foco em Qualidade

5. Perguntas que devem ser respondidas
1) Qual é o problema a ser resolvido?
2) Quais características do software a ser gerado resolvem o
problema?
3) Como o software (a solução) serão concebidos?
4) Como o software será construído?
5) Qual a abordagem que será utilizada para cobrir erros
feitos no projeto e construção do software?
6) Como o software será mantido a longo prazo, quando
correções, adaptações e melhorias forem requeridas por
usuários do software?

6. Fases Genéricas da Engenharia de
Software

7. Modelos de Processos de Engenharia de
Software
 Para resolver problemas reais, o engenheiro de software
deve aplicar uma estratégia de desenvolvimento que
contemple as camadas de processos, métodos e
ferramentas;
 Esta estratégia é o modelo de processo ou paradigma
de engenharia de software;
 É escolhido baseado na natureza do projeto e aplicação,
nos métodos e ferramentas a serem utilizados e nos
controles e entregas requeridos;
 Os modelos definem ordem para uma atividade
inerentemente caótica;

8. Modelos de Processos de Desenvolvimento
de Software
 Modelo Linear Seqüencial
 Modelo de Prototipação
 Modelos Evolucionários
- Incremental
- Espiral
 RUP – Rational Unified Process
 Atividades de suporte : independentes do modelo de
processo
- Garantia de Qualidade de Software
- Gerenciamento da Configuração do Software
- Mensuração de Software

9. Modelo Linear Seqüencial
 Também chamado de “ciclo de vida clássico” e “modelo
cascata”;
 Sugere uma abordagem seqüencial para o
desenvolvimento de software;
Engenharia do Sistema /
Informação
Projeto
Análise Codificaçã Testes
(Design)
o

10. Modelo Linear Seqüencial
 Engenharia do sistema/informação: O software é parte de um
sistema maior. Por isso, o trabalho inicial com a definição dos
elementos do sistema e do software, é realizada uma análise do
projeto superficial;
 Análise: Intensificação do levantamento de requisitos, agora focado
no software. Define domínio de informação, funcionalidade,
comportamento, performance e interface;
 Projeto ( design ): Traduz os requerimentos para uma
representação técnica;
 Codificação: É a tradução do projeto em uma linguagem de
programação. Se o projeto for detalhado, a codificação é um processo
mecânico;
 Teste: Teste do programa codificado. Pode ser da lógica interna do
software ou focado nas funcionalidades externas;
 Suporte: Corrige e adapta o software gerado. Reaplica as fases
precedentes no programa existente.

11. Modelo Linear Seqüencial
É o mais antigo paradigma de engenharia de software;
Problemas do modelo linear seqüencial:
 Projetos reais raramente seguem a ordem seqüencial proposta
e mudanças nesta seqüência podem causar confusão na
equipe de projeto;
 É difícil para os usuários definir todos os requisitos
explicitamente. O modelo seqüencial requer esta definição e é
difícil acomodar incertezas nos requisitos;
 O cliente deve ter paciência. Uma versão “visível” do programa
estará disponível somente no fim do projeto. Erros percebidos
somente nesta fase podem ser tornar um desastre;

12. Modelo de Prototipação
Permite que o cliente “perceba” o software que está
sendo gerado antes da finalização;
Atividades do modelo:
 Definição de requisitos;
 Projeto “Rápido”: foca em representar os aspectos do
software que serão visíveis ao usuário. É a construção de um
protótipo;
 Avaliação do Protótipo: o usuário avalia o protótipo e
refina os requisitos;
 Natureza iterativa: as atividades se repetem até que o
software fique pronto;

13. Modelo de Prototipação

14. Modelo de Prototipação
Problemas:
 O cliente vê o que parece ser uma versão que funciona
do software. Apesar das grandes mudanças que devem
ser feitas para que o protótipo se torne um software
completo e com qualidade, o cliente pode querer fazer
“remendos” no protótipo para iniciar o uso;
 Práticas não desejáveis de codificação podem ser
utilizadas para construção do protótipo e depois
“esquecidas”, tornando-se a solução definitiva;
 “Software nunca está pronto”...

15. Modelos Evolucionários
 A natureza evolucionária do software não é considerada
explicitamente nem no modelo linear seqüencial, nem no
modelo de prototipação;
 Os modelos evolucionários são iterativos, ou seja, são
caracterizados de maneira que permitem aos
engenheiros de software, construções com versões
cada vez mais completas do software;
Veremos dois tipos de modelos evolucionários:
- Incremental
- Espiral

16. Modelo Incremental
 O modelo incremental combina elementos do modelo linear
seqüencial (aplicado repetidamente) com a filosofia iterativa
da prototipação;
 Cada seqüência linear produz um “incremento” entregável
(deliverable) do software;
Exemplo de um processador de texto:
– Primeiro entregar funções básicas de manipulação de
arquivo;
– Depois, entregar funcionalidades de edição e
produção de documentos mais avançadas;
– No terceiro incremento, entregar verificação de grafia
e gramática;
– ...

17. Modelo Incremental
 A cada incremento, o usuário pode utilizar o produto
gerado ou fazer uma revisão detalhada;
 O próximo incremento deve implementar as solicitações
do usuário, mais as novas funcionalidades planejadas;
 O processo é repetido até que o produto completo é
entregue;

18. Modelo Incremental
 O modelo incremental, como o de prototipação, é iterativo. Mas
diferentemente do de prototipação, ele foca em entregar um produto
operacional em cada incremento;

19. Modelo Espiral
 É um modelo que acopla a natureza iterativa da
prototipação com os aspectos sistemáticos e
controlados do modelo linear seqüencial;
 O software é desenvolvido em uma série de “releases”
incrementais: nas primeiras iterações podem apenas ser
um modelo em papel ou um protótipo; nas últimas,
versões cada vez mais completas do software são
produzidas;

20. Modelo Espiral
O modelo espiral é dividido em um número de atividades,
chamadas regiões de tarefas. Tipicamente, existem de 3 a 6
regiões;

21. Modelo Espiral
 Comunicação com cliente: tarefas requeridas para estabelecer
comunicação efetiva entre desenvolvedor e cliente;
 Planejamento: tarefas requeridas para definir recursos, tempos de
tarefas e outras atividades de planejamento;
 Análise de Risco: tarefas requeridas para avaliar riscos técnicos e
de gerenciamento;
 Engenharia: tarefas requeridas para construir um ou mais
representações da aplicação;
 Construção e Entrega: tarefas requeridas para construir, testar,
instalar, e prover suporte ao usuário;
 Avaliação do cliente: tarefas requeridas para obter feedback do
cliente baseado na avaliação das representações do software criadas
durante o estágio de engenharia;

22. Modelo Espiral
 Cada região possui um conjunto de tarefas, que são adaptadas
às características do projeto a ser iniciado. Para pequenos
projetos, poucas tarefas. Para grandes projetos, mais tarefas
para garantir nível maior de formalidade;
 Quando o processo inicia, a equipe de desenvolvimento se
move na espiral em sentido horário, iniciando no centro:
- O primeiro circuito resulta no desenvolvimento da
especificação;
- O subseqüente, pode ser usado para desenvolvimento do
protótipo;
- Cada passagem na região de Planejamento resulta em ajustes
no plano de projeto (inclusive o número de iterações necessárias
para finalizar o projeto);

23. Modelo Espiral
 Não termina quando o software é entregue: pode ser adaptado a todo o
ciclo de vida do software;
 “Eixos de Entrada de Projeto”: cada cubo localizado no eixo pode ser
utilizado para representar o ponto de início de diferentes tipos de
projetos;

24. Modelo Espiral
 Projeto de Desenvolvimento de Conceito: inicia no centro da espiral e
continua na espiral até que esteja completo (área mais escura);
 Se o conceito será desenvolvido na forma de um produto, o processo
continua através do próximo cubo (ponto de entrada de desenvolvimento
de novo produto). O novo produto evolui na espiral na área em cinza
médio;
 Em essência, se a espiral for vista dessa forma, ela continua até que o
software é retirado de uso;
Problemas:
- Pode ser difícil convencer os clientes de que a abordagem evolucionária
é controlável;
- O modelo não é usado na mesma extensão que o linear e o de
prototipação, e, por isso, não foi “testado” o suficiente;

25. RUP - (Rational Unified Process)
 As demandas atuais para softwares poderosos e complexos
não têm sido atendidas pela forma como softwares são
desenvolvidos. Hoje em dia, muitas pessoas desenvolvem
software usando modelos de 25 anos atrás;
 A comunidade de software precisava de um processo que:
- Provesse um guia para a ordem das atividades da equipe do
projeto;
- Direcionasse as tarefas dos desenvolvedores e da equipe como
um todo;
- Especificasse quais os artefatos que devem ser desenvolvidos;
- Oferecesse critérios para monitoramento e medida dos produtos
atividades de um projeto;

26. RUP - (Rational Unified Process)
 O RUP é um modelo de processo de desenvolvimento
de software (dessa forma, ele descreve um conjunto de
atividades para transformar os requisitos do usuários em
um software);
 É baseado em componentes: o sistema de software
sendo desenvolvido é feito de componentes de software
interconectados via interfaces bem definidas;
 Utiliza a UML (Unified Modeling Language)

27. Características Fundamentais
 Direcionado a Caso de Uso: o processo de
desenvolvimento segue um fluxo (procede) através de
uma série de workflows que derivam dos casos de uso;
 Centrado em Arquitetura: o processo do RUP ajuda
o arquiteto a focar nos objetivos corretos, como
entendimento, resiliência a mudanças futuras e reuso.
Casos de uso e arquitetura se completam e devem
evoluir em paralelo;
 Iterativo e incremental: divide o trabalho de
engenharia do software em “mini-projetos” ou iterações.
Cada iteração resulta em um incremento no produto;

28. Iterações
 Em cada iteração, os desenvolvedores identificam e
especificam casos de uso relevantes, criam um projeto
usando a arquitetura escolhida como um guia,
implementam o projeto em componentes e verificam se os
componentes satisfazem o caso de uso;
 Se a iteração atinge seu objetivo, prossegue-se para a
próxima iteração. Quando não, os desenvolvedores
revisam suas decisões e tentam nova abordagem;

29. Benefícios das Iterações
 A iteração controlada reduz o custo do risco às despesas
de um único incremento, e não do produto pronto;
 A iteração controlada reduz o risco de não colocar o
produto no mercado no tempo esperado, ou seja, os riscos
são descobertos antes;
 Acelera o tempo de desenvolvimento porque trabalha com
tarefas mais curtas e focadas;
 Reconhece uma realidade geralmente ignorada:
necessidades dos usuários e requerimentos não podem
ser definidos logo no início. São tipicamente refinados em
iterações sucessivas.

30. O Produto de Software do RUP
Segundo o RUP, um produto de software deve ter:
 Um modelo de casos de uso com todos os casos de uso e seus
relacionamentos com usuários;
 Um modelo de análise que tem dois propósitos: refinar os casos de
uso em mais detalhes e fazer uma alocação inicial do comportamento do
sistema em uma série de objetos que provêem o comportamento;
 Um modelo de projeto ( design ) que define: a) a estrutura estática
do sistema como subsistemas, classes e interfaces; e b) os casos de
usos realizados como colaborações entre os subsistemas, classes e
interfaces;
 Um modelo de implementação , que inclui componentes
(representando código fonte), e mapeando as classes para os
componentes;
 Um modelo de implantação (deployment), que define os nós físicos
dos computadores e os mapeamentos dos componentes para estes nós;
 Um modelo de testes , que descreve os casos de teste e verifica os
casos de uso;
 E uma representação da arquitetura ;

31. O Produto de Software do RUP

32. O Ciclo de Vida do RUP
 O processo unificado repete uma série de ciclos que
formam a vida de um sistema. Cada ciclo é concluído
com uma release (entrega) aos clientes;
 Cada ciclo consiste de 4 fases: inception (iniciação),
elaboration (elaboração), construction (construção),
transition (transição) e cada fase é dividida em
iterações;

33. O Ciclo de Vida do RUP

34. Fases e Iterações do RUP
 Uma fase termina com um marco (milestone), que é
definido pela disponibilidade de certos artefatos
(modelos ou documentos) em um determinado estado;
 Dentro de cada fase, são realizadas iterações. Uma
iteração é equivalente a um “mini-projeto”;

35. Fases
 Iniciação: o foco é chegar a um acordo com os stakeholders quanto
à visão do sistema e aos objetivos e estimativas das demais fases do
ciclo/projeto;
 Elaboração: esta fase é um processo de engenharia, onde o foco
está em especificar uma arquitetura robusta e confiável para o sistema
e fazer o planejamento para o restante do ciclo/projeto;
 Construção: a fase de construção basicamente consiste num
processo de manufatura, onde o foco está na construção do
sistema e no gerenciamento dos recursos e otimização de
tempo, custos e qualidade;
 Transição: o objetivo desta fase é transferir o produto para a
comunidade de usuários. Pode ser apenas uma release do
produto, e não o produto final.

36. Fases

37. As Disciplinas do RUP
 Os processos são procedimentos compostos de
atividades logicamente seqüenciadas e têm objetivos
específicos em relação ao projeto;
 O RUP possui 6 processos de engenharia e 3 processos
de suporte, também chamados de disciplinas;

38. As Disciplinas do RUP
 Engenharia:
– Modelagem de Negócio : foca no entendimento do negócio
ser automatizado pelo software;
– Requisitos: foca no entendimento dos requisitos do software;
– Análise e Design : análise dos requisitos e projeto (design) do
software;
– Implementação: codificação dos componentes;
– Teste: avaliação do sistema em relação aos requisitos;
– Implantação: entrega do software;
 Suporte:
– Gerenciamento de Projeto ;
– Gerenciamento de Configurações e Mudanças ;
– Ambiente: preparação do ambiente para desenvolvimento do
projeto;

39. As Disciplinas do RUP
 Quando o projeto amadurece, a ênfase em certas
atividades das disciplinas aumenta ou diminui;
 As atividades podem ser executadas qualquer tempo
durante o ciclo de vida do projeto;

40. As Disciplinas do RUP

41. As Disciplinas do RUP