Modelos de Processo de Software Parte 4

1. Processo de Produção
de Software
Bacharelado em Engenharia de Software – Aula 18
Prof.ª M.ª Elaine Cecília Gatto

2. MODELOS DE PROCESSOS
DE PRODUÇÃO DE
SOFTWARE

3. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

4. Modelo Orientado a Ferramentas
• É um modelo específico de ferramentas CASE e
geradores de código aplicados com essas
ferramentas.
• É qualquer modelo baseado no uso intensivo de
ferramentas de prototipação e geração de código,
que permitam rápida produção de sistemas
executáveis a partir de especificações em alto
nível

5. Modelo Orientado a Ferramentas
• Modelo limitado pelas funcionalidades oferecidas
pelas ferramentas específicas
• Requisitos só são atendidos se a ferramenta de
produção permitir atender à funcionalidade
requerida
• Grande parte dos requisitos podem ser entregues
rapidamente se a ferramenta atender às
necessidades de produção
• Pode ser combinado a outros modelos

6. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

7. Modelos Concorrentes
• Também chamado de Engenharia Concorrente
• É mais adequado para projetos de Engenharia
de produto nos quais diferentes equipes de
engenharia estão envolvidas.
• Possibilita representar elementos
concorrentes e iterativos de qualquer um dos
modelos de processo descritos

8. Modelos Concorrentes
Um elemento
do modelo de
processo
concorrente

9. Modelos Concorrentes
• Uma atividade pode estar em qualquer um
dos estados observados em qualquer
momento determinado.
• Outras atividades podem ser representadas
de maneira análoga.
• Todas as atividades de Engenharia existem
simultaneamente, mas em estados diferentes.

10. Modelos Concorrentes
• Exemplo:
• Início do projeto
• Atividade de comunicação completou sua
primeira iteração e se encontra no estado
AGUARDANDO MODIFICAÇÕES

11. Modelos Concorrentes
• Exemplo:
• Atividade de Modelagem
• Estado INATIVO enquanto a comunicação inicial
era concluída
• Transita para o estado EM DESENVOLVIMENTO
• Se o cliente indicar mudanças, sai do EM
DESENVOLVIMENTO e vai para o estado de
AGUARDANDO MUDANÇAS

12. Modelos Concorrentes
• Define uma série de eventos que vão disparar
transições de um estado para outro para cada
uma das atividades, ações ou tarefas da
engenharia de software.
• Fornece uma “imagem” precisa do estado
atual de um projeto de software.

13. Modelos Concorrentes
• Não limita as atividades, ações e tarefas em
uma sequencia de eventos.
• Define uma rede de processos.
• Cada ação, tarefa e atividade existe
simultaneamente com outras ações, tarefas e
atividades

14. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

15. Modelo de Processo Incremental
• Contexto:
• Requisitos iniciais do software são razoavelmente
bem definidos
• O escopo geral do trabalho impede o uso de um
processo linear puro.
• Rápido fornecimento de determinado conjunto
funcional aos usuários
• Refinar e expandir funcionalidades em versões
posteriores

16. Modelo de Processo Incremental
• 1.ª Abordagem:
• Mais fácil desenvolver o software se os projetos
de grande porte são subdividos em
componentes menores que podem ser
desenvolvidos incremental e iterativamente.
• Modelo cascata: cada componente passava por
cada etapa iterativamente
• Modelo incremental: componentes são
desenvolvidos de forma sobreposta

17. Um Modelo Incremental de Múltiplos
Componentes
Requisito 1 Requisito 2 Requisito n
Design Design Design n
Código Código Código
Teste Teste Teste
Cesto de Integração
Teste de
Sistema
. . .
. . .
. . .
. . .

18. Modelo de Processo Incremental
• 2.ª Abordagem:
• Libera uma série de versões denominadas
incrementos.
• Oferece, progressivamente, maior
funcionalidade ao cliente à medida que cada
incremento é entregue.
• Combina os fluxos de processo linear e paralelo

19. Modelo de Processo Incremental
• Aplica sequencias lineares de forma
escalonada à medida que o tempo vai
avançando.
• Cada sequencia linear produz incrementos
entregáveis do software
• O primeiro incremento entregue é um
produto essencial: requisitos básicos (core)

20. Modelo de Processo Incremental
• Produto essencial é avaliado pelo cliente
• Um planejamento é desenvolvido para o próximo
incremento de acordo com o feedback do cliente
• Outros requisitos são incluídos no novo
incremento
• Esse processo é repetido após a liberação de cada
incremento até que seja gerado o produto
completo.

21. Um Modelo Incremental de Múltiplas
Versões
Requisitos Design Código Teste Pacote Versão 1
.
.
.
Requisitos Design Código Teste Pacote Versão n
Requisitos Design Código Teste Pacote Versão 2

22. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS

23. Modelos de Processo Especializado
• Incluem uma ou mais características dos
processos tradicionais
• São aplicados quando se opta por uma
abordagem de engenharia de software
especializada ou definida de forma restrita

24. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS

25. Desenvolvimento Baseado em
Componentes
• COTS:
• Commercial off-the-shelf OU Componentes de
Software Comercial de Prateleira
• São desenvolvidos para serem oferecidos como
produtos
• Disponibilizam funcionalidade almejada com
interfaces bem definidas
• Permitem que o componente seja integrado ao
software a ser desenvolvido

26. Desenvolvimento Baseado em
Componentes
• Incorpora características do modelo espiral
• É um modelo evolucionário
• Demanda abordagem iterativa
• Compreende aplicações de componentes de
software previamente empacotados.

27. Desenvolvimento Baseado em
Componentes
• Atividades de modelagem e construção:
iniciam com a identificação de componentes
candidatos.
• Componentes podem ser projetados como
módulos de software convencionais: classes
ou pacotes (orientação a objetos)

28. Desenvolvimento Baseado em
Componentes
• Etapas do modelo de desenvolvimento
baseado em componentes:
• Produtos baseados em componentes
disponíveis são pesquisados e avaliados
para o campo de aplicação em questão
• Itens de integração de componentes são
considerados.

29. Desenvolvimento Baseado em
Componentes
• Etapas do modelo de desenvolvimento
baseado em componentes:
• Arquitetura de software é projetada para
acomodar os componentes.
• Componentes são integrados à arquitetura.
• Testes completos são realizados para
garantir a funcionalidade adequada

30. Desenvolvimento Baseado em
Componentes
• Capacidade de reutilização de software
• Redução no tempo do ciclo de
desenvolvimento e custos do projeto

31. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS

32. O modelo de métodos formais
• Inclui um conjunto de atividades que conduzem à
especificação matemática formal do software
• Especifica, desenvolve e verifica um sistema
baseado em computador pela aplicação de uma
notação matemática rigorosa
• Muito utilizado para software com fato crítico de
segurança: aeronáutica, medicina, etc.

33. O modelo de métodos formais
• Oferece um mecanismo de eliminação de
muitos problemas que não são facilmente
resolvidos com modelos de engenharia de
software como ambiguidade, incompletude e
inconsistência
• Análise matemática pode ser aplicada para
descobrir e corrigir esses problemas

34. O modelo de métodos formais
• Desvantagens:
• Desenvolvimento de métodos formais
consome muito tempo e dinheiro
• Não existem muitas pessoas experientes ou
com formação nesta área – treinamento
• Para a comunicação com o cliente não é o
ideal

35. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS

36. Desenvolvimento de software orientado a
aspectos
• Preocupações transversais:
• Ocorre quando as preocupações transcendem
várias funções, recursos e informações do
sistema
• Requisitos de aspectos:
• Definem as preocupações transversais que tem
impacto em toda a arquitetura do software

37. Desenvolvimento de software orientado a
aspectos
• AOSD: Desenvolvimento de software orientado a
aspectos (Aspect-Oriented Software
Development)
• AOP: Programação orientada a aspectos (Aspect-
Oriented Programming)
• AOCE: Engenharia de Componentes orientada a
aspectos (Aspect-Oriented Component
Engineering)

38. Desenvolvimento de software orientado a
aspectos
• É um paradigma de engenharia de software
relativamente NOVO que oferece uma abordagem
METODOLÓGICA e de processos para:
• Definir, Especificar, Projetar e Construir
ASPECTOS
• Aspectos: mecanismos além das sub-rotinas e
herança para localizar a expressão de uma
preocupação cruzada

39. Desenvolvimento de software orientado a
aspectos
• Ainda não é um modelo de processo de
produção de software MADURO
• Pode adotar características do modelo
evolucionário e do concorrente

40. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS

41. Processo Unificado
• Processo de Software dirigido a casos de uso,
centrado na arquitetura, iterativo e
incremental
• É uma tentativa de aproveitar os melhores
recursos e características dos modelos
tradicionais

42. Processo Unificado
• Prioriza:
• Comunicação com o cliente
• Desenvolvimento de métodos racionais
para descrever a visão do cliente sobre um
sistema

43. Processo Unificado
• Enfatiza:
• Arquitetura de software
• Auxilia:
• Arquiteto de software a manter o foco nas
metas
• Sugere:
• Fluxo de processo iterativo e incremental

44. Processo Unificado
• Criadores:
• James Rumbaugh
• Grady Booch
• Ivar Jacobson
• Uniram forças para desenvolver um modelo único
de análise e projeto orientado a objetos
• Resultado: UML – Linguagem de Modelagem
Unificada (atual padrão industrial)

45. Processo Unificado
• RUP: Rational Unified Process – Processo
Unificado Racional (Rational Software
Corporation)
• Estrutura de processo baseado em três conceitos
principais:
• Dirigido por casos de uso
• Centrado na arquitetura
• Incremental e Iterativo

46. Processo Unificado

47. CONCEPÇÃO:
• Comunicação:
• Identificar as necessidades do negócio
• Proposta de uma arquitetura rudimentar
• Planejamento iterativo e incremental
• Definição dos Casos de Uso
• Funções, Recursos e Subsistemas

48. CONCEPÇÃO:
• Planejamento:
• Identificar recursos
• Avaliar os riscos principais
• Definir um cronograma
• Estabelecer uma base para as fases que
serão aplicadas no incremento

49. ELABORAÇÃO:
• Composta pelas atividades de planejamento e modelagem
• Refina e expande os casos de uso
• Amplia a representação arquitetural
• Verifica e demonstra a viabilidade da arquitetura
• Revisa o planejamento
• Assegura a adequação do escopo, riscos e datas de entregas

50. ELABORAÇÃO:
• Inclui cinco diferentes visões do software:
• Modelo de caso de uso
• Modelo de análise
• Modelo de projeto
• Modelo de implementação
• Modelo de disponibilização

51. CONSTRUÇÃO:
• O incremento é criado, codificado e testado nesta fase
• Entrada: modelo de arquitetura
• Operacionalização dos casos de uso
• Modelos de análise e de projeto devem ser concluídos
para refletir o incremento de software
• Testes são executados nos componentes
• Integração dos componentes

52. TRANSIÇÃO:
• Entrega e feedback
• Testes beta
• Detecção de defeitos e mudanças
• Material com informações de apoio: manuais, etc.
• Incremento de software é uma versão utilizável do sistema

53. PRODUÇÃO:
• Monitoramento do uso
contínuo do software
• Suporte operacional –
infraestrutura
• Relatórios de defeitos
• Solicitações de mudanças

54. Processo Unificado
• As cinco fases do processo unificado não ocorrem
sequencialmente, mas sim de forma escalonada e
concomitante
• Fluxo de trabalho:
• Análogo a conjunto de tarefas
• Identifica as tarefas exigidas para realizar uma
importante ação de engenharia
• Identifica os artefatos produzidos como
consequência da conclusão bem-sucedida das
tarefas

55. Processo Unificado
• Um fluxo de trabalho é distribuído ao longo
de todas as fases do processo unificado
• O processo é adaptado pela equipe conforme
suas necessidades
• Um fluxo de trabalho para um projeto não
necessariamente é aplicado a outro projeto

56. REFERÊNCIAS
1. TSUI, Frank; KARAM, Orlando. Fundamentos
da Engenharia de Software. Tradução e
Revisão Técnica de Edson Tanaka. 2.ª Edição.
Rio de Janeiro: LTC, 2013.
2. WAZLAWICK, Raul Sidnei. Engenharia de
Software: Conceitos e Práticas. 1.ª edição.
Rio de Janeiro: Elsevier, 2013.

57. REFERÊNCIAS
3. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de
Software: Uma Abordagem Profissional. Tradução:
João Eduardo Nóbrega Tortello. Revisão Técnica:
Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016.
4.FILHO, W. P. P. Engenharia de Software:
Fundamentos, Métodos e Padrões. 3.ª Edição.Rio
de Janeiro: LTC, 2015