A engenharia de software estabelece princípios para desenvolver software de forma eficiente e de qualidade, utilizando métodos, ferramentas e processos adequados a cada projeto. Existem vários paradigmas como cascata, incremental, RAD e orientado a objetos que se adaptam melhor a diferentes situações considerando fatores como prazo, complexidade e riscos. A escolha do modelo ideal deve levar em conta a

1. ENGENHARIA DE
SOFTWARE
RESUMO DA AULA ANTERIOR

2. Definicao de Engenharia de
software
estabelecimento e uso de sólidos
princípios de engenharia para:
Minimizar custos de desenvolvimento
de software;
Software confiável;
Software eficientemente;
Organizacao;
Produtividade; e
Software de qualidade

3. Etapas da Eng. Software
Métodos
Como fazer
Ferramentas
Apoio automatizado –CASE Tools
Procedimentos
Definem a sequência em que os
métodos são aplicados.

4. Ciclo de Vida clássico da ES
Definição de
Requisitos
Análise
Desenho
Implementação
Teste
Manutenção

5. Processo de Desenvolvimento
Definição (O quê?)- Analise e
Planeamento:
o que será desenvolvido
Desenvolvimento (Como?)- Desenho,
Codificacao e Teste:
como será desenvolvido
Manutenção (Mudanças?)- Correcao,
adaptacao e perfeicao:
que mudanças ocorrerão depois

6. PARADIGMAS DA
ENG. DE SOFTWARE
Definição, Caracterização,
Vantagens e Desvantagens.

7. Paradigmas de Eng. de Software
Incremental
RAD
Iterativo
Formal
Estruturado Modelos de Ciclo de
Lógico Vida de Software
Espiral
Evolutivo
OO
Combinação de Paradigmas
Técnicas de Quarta Geração

8. Paradigmas de Eng. de Software:
Escolha da Estrategia de deve
considerar:
Natureza do projecto;
Tipo da aplicação;
Métodos e ferramentas que serão
usados;
Métodos de controle;
Prazo de entrega;
Produtos que serão entregues.

9. Incremental
Requisitos Projecto
Requisitos
em da
superficiais
incrementos arquitetura
Desenvolv. Validação Integração Validação
incremento incremento incremento do
Sistema
sistema
completo
Sistema incompleto

10. Incremental
Desenvolvimento através de incrementos
sucessivas do âmbito do sistema;
O sistema é alargado progressivamente;
Ao invés de entregar o sistema completo,
divide-se o sistema em partes de tal forma
a cada entrega corresponder a alguma
funcionalidade do sistema;
Requisitos do usuário são priorizados e
quanto maior a prioridade, mais cedo tal
funcionalidade deve ser entregue;
Uma vez que o desenvolvimento de um
incremento seja iniciado, esses requisitos
são fixados enquanto que os posteriores
são deixados serem modificados;

11. Incremental - Vantagens
Esta abordagem é útil para
Problemas complexos;
Recursos humanos insuficientes;
Datas de entrega inflexíveis.

12. Incremental - Vantagens
Solicitações dos clientes são
entregues a cada incremento.
Assim, as funcionalidades são
entregues o mais cedo possível
Incrementos iniciais servem de
protótipo para obter requisitos para
incrementos posteriores
Diminuição do risco de falha de todo
o projeto
Serviços de maior prioridade tendem
a receber maior ênfase em testes

13. Rapid Application
Development (RAD)
É um modelo de processo de
desenvolvimento de software
iterativo e incremental;
O ciclo de desenvolvimento é
curto (entre 60 e 90 dias).

14. Rapid Application
Development (RAD)
Equipa 1 Equipa 2 Equipa 3
Modelado
Modelado
Modelado Modelado
Modelado Modelado
Da gestão
Da gestão
Da gestão
Da gestão Da gestão
Da gestão
Modelado
Modelado
Modelado Modelado
Modelado Dos dados
Dos dados
Modelado
Dos dados
Dos dados
Dos dados
Dos dados Modelado
Modelado
Dos
Dos
Modelado
Modelado processos
Modelado
Modelado
processos
Dos
Dos
Dos
Dos processos
processos Geração de
Geração de
processos
processos Aplicações
Aplicações
Geração de
Geração de
Geração de
Geração de Aplicações
Aplicações Testes e
Testes e
Aplicações
Aplicações entrega
entrega
Testes e
Testes e
Testes e
Testes e entrega
entrega
entrega
entrega

15. RAD - Vantagens
Permite o desenvolvimento rápido e/ou a
prototipagem de aplicações;
Enfatiza um ciclo de desenvolvimento
extremamente curto (entre 60 e 90 dias);
Cada função principal pode ser direcionada
para uma equipe RAD separada e então
integrada a formar um todo;
Criação e reutilização de componentes;
Visibilidade mais cedo (protótipos)
Maior flexibilidade (desenvolvedores podem
experimentar praticamente a vontade)
Grande redução de codificação manual
(wizards...);
Envolvimento maior do usuário;
Provável custo reduzido (tempo é dinheiro e
também devido ao reuso);

16. RAD - Desvantagens
Se uma aplicação não puder ser
modularizada de modo que cada função
principal seja completada em menos de 3
meses, não é aconselhável o uso do RAD;
Para projectos grandes (mas escaláveis) o
RAD exige recursos humanos suficientes
para criar o número correcto de equipes,
isso implica em um alto custo com a
equipe;
O envolvimento com o usuário tem que ser
activo;
Comprometimento da equipe do projecto;

17. RAD - Desvantagens
O RAD não é aconselhável quando os
riscos técnicos são altos e não é indicada
quando se está testando novas
tecnologias;
Menos eficientes;
Perda de precisão científica (falta de
métodos formais);
Funções reduzidas (reuso, "timeboxing");
Problemas legais;
Requisitos podem não se encaixar
(conflitos entre desenvolvedores e clientes)
Sucessos anteriores são difíceis de se
reproduzir.

18. O RAD é apropriado quando
A aplicação é do tipo "standalone";
A performance não é o mais
importante;
A distribuição do produto é pequena;
O escopo do projecto é restrito;
O sistema pode ser dividido em
vários módulos independentes;
A tecnologia necessária tem mais de
um ano de existência.

19. O RAD deve ser evitado
quando
A aplicação precisa interagir com outros programas;
Performance é essencial;
O desenvolvimento não pode tirar vantagem de
ferramentas de alto nível;
A distribuição do produto será em grande escala;
Para se construir sistemas operacionais
(confiabilidade exigida alta demais)
Jogos de computador (performance exigida muito
alta)
Riscos tecnológicos muito altos devido a tecnologia
ter sido recém lançada;
O sistema não pode ser modularizado.

20. Iterativo
Aplicação do modelo cascata
iterativamente;
As iterações iniciais atacam os
maiores riscos;

21. Iterativo
Os requisitos do sistema SEMPRE
mudam durante o desenvolvimento
Iteração pode ser aplicado a
qualquer um dos processos de
desenvolvimento
Duas abordagens são destacadas:
Desenvolvimento incremental
Desenvolvimento em espiral.

22. Iterativo
Desenvolvimento iterativo antecipa a
redução de riscos;
Testes e integração são realizados
desde o início, de forma contínua;
Riscos críticos são resolvidos antes
que grandes investimentos sejam
realizados;
Permite feedback dos usuários desde
cedo;
Pequenos objectivos, foco em curto-
prazo;
Progresso é medido de forma mais
concreta;
Implementações parciais podem ser
implantadas;

23. Formal
Definição de Especificação
requisitos formal
Transformação
formal
Integração e
testes

24. Formal
Métodos formais
Especificação matemática
Exacta e rigorosa
Detecta e corrige requisitos
incompletos, ambíguos e
inconsistentes

25. Formal
Desvantagens
Necessita de profissionais altamente
qualificados para aplicar a técnica
Alguns aspectos ainda são difíceis de
especificar (GUI)
Vantagens
Garantia de segurança e confiabilidade
Aplicações
Sistemas críticos e complexos

26. Cascata
Várias actividades executadas de forma
sistemática e sequencial

27. Cascata
Um dos mais antigos, e ainda um dos mais
usados!
Várias actividades executadas deforma
sistemática e sequencial;
Fixa pontos específicos para a entrega de
artefactos;
É simples e fácil de aplicar, facilitando o
planeamento;
Na prática, existe uma interacção entre as
atividades e cada atividade pode levar a
modificações nas anteriores;
Pressupõe que os requisitos ficarão
estáveis;
Atrasa a redução de riscos.

28. Cascata - Vantagens
Padroniza os métodos para análise,
projecto, codificação, testes e
manutenção.
Etapas semelhantes às etapas
genéricas aplicáveis a todos os
paradigmas;
Orientado a documentação;
Manutenção é mais simples.

29. Cascata - Desvantagens
Projectos reais raramente seguem o fluxo
sequencial que esse modelo propõe.
Sempre ocorre alguma interacção e/ou
superposição;
Dificilmente os clientes são capazes de
relacionar todos os requisitos de uma só
vez no início do projecto;
Maioria dos programas só estará
disponível quando o cronograma já está
bastante adiantado;
Dificuldades para se introduzir alterações
quando o processo está avançado;
Dificuldade para lidar com as mudanças
nos requisitos do sistema
Não gere riscos

30. Espiral

31. Espiral
Análise de riscos como ferramenta;
Essencial para o planeamento e
gestão do projecto;
Dificuldades para fechar o contrato;
Complexo e requer experiência na
avaliação de riscos!

32. Espiral - Vantagens
Modelo evolutivo possibilita uma
maior integração entre as fases e
facilita a depuração e a manutenção
do sistema.
Permite que o projectista e cliente
possa entender e reagir aos riscos
em cada etapa evolutiva.
Fácil de decidir o quando testar

33. Espiral - Desvantagens
Avaliação dos riscos exige muita
experiência;
O modelo é relativamente novo e
não tem sido amplamente utilizado;
Bem aplicado somente a sistemas
de larga escala;
Sistemas devem ser produtos
internos da empresa.

34. 4ª Geração
Ferramentas de 4ª Geração
Suporte automatizado à
especificação de requisitos.
A ferramenta gera codigo-fonte,
na base da especificação do
desenvolvedor;

35. Combinação de Paradigmas
Os paradigmas para a
Engenharia de Software
alcancam melhores resultados
quando combinadas. Exemplo:
Espiral resulta da combinacao
entre a Prototipacao e cascata
numa abordagem revolucionaria.

36. Evolutivo
Atividades
concorrentes
Versão
Especificação
inicial
Descrição Versões
Desenvolvimento intermediárias
superficial
Versão
Validação
final

37. Evolutivo
Desenvolvimento exploratório
(Protótipo evolucionário)
Construa, avalie e evolua para produto
Trabalhar com os clientes até se obter o
produto final a partir de uma especificação
bem-definida e completa do sistema.
Protótipo descartável
Construa, use e descarte
Obter requisitos do cliente. Inicia-se com
uma especificação incompleta e simples do
sistema

38. Estruturado

39. Orientado a Objectos
Métodos OO são voltados
principalmente para sistemas
complexos, que devem ser divididos
para a distribuição dos trabalhos
pela equipe;
A abordagem OO se baseia em um
desenvolvimento onde fases
teoricamente já completadas são
revistas continuamente, e alteradas
se preciso;
Iterativo e incremental.

40. Orientado a Objectos
paralelo
(reutilização de componentes)
Análise de Riscos
Identificar classes candidatas
Engenharia buscar classes na biblioteca
e Construção
extrair classes, se existem
desenvolver novas classes,
se não existem
adicionar novas classes
recursivo
à biblioteca
(modelo evolutivo)
construir n-ésima
iteração do sistema
Baseado em componentes
Unified Development Process
Utiliza UML

41. Selecção do Modelo
Projectos pequenos: ciclo
clássico
Limites severos de tempo: RAD
Data entrega muito próxima:
modelo incremental.
Sistemas Complexos com
muitas mudanças de Requisitos:
Orientadas a Objectos;

42. BIBLIOGRAFIA
Gerry Coleman and Renaat Verbruggen. A quality
software process for rapid application development,
Software Quality Journal 7, pp. 107-122, 1998.
Software Engineering. I.Sommerville;
Engenharia de Software, Roger S. Pressman, 3.ª
Edição.
A Discipline for Software Engineering.
W.S.Humphrey;
http://pt.wikipedia.org/wiki/Engenharia_de_software,
de 9/Fev/2007

43. TPC
1. Faca um estudo comparativo dos seguintes
paradigmas:
a. Evolutivo e Espiral;
b. Incremental e Iterativo;
c. Estruturada e OO;
2. Para cada uma das situacoes que modelo usaria
para desenvolvimento de Software:
a. Tempo reduzido (60 dias);
b. Sistema complexo, com muitos riscos;
c. Sistema com uma dimensão muito reduzida;
d. Sistema critico com alta precisão de
processamento (logico ou matemático);
e. Implementação de um jogo de entretenimento;
3. Para o desenvolvimento de um software para
gestao de registos academicos da UST, que com
binacao de modelos usaria? Justifique a sua
escolha.