SlideShare uma empresa Scribd logo
Processo do Software
 Grupo de atividades coerentes para
especificação, projeto, implementação
e teste de sistemas de software.
Objetivos
 Introduzir os processos de modelagem de
software
 Descrever alguns modelos de processos e quando
eles devem ser usados
 Descrever em linhas gerais o processo modelo
para os requisitos de engenharia, de
desenvolvimento de softare, seu teste e evolução
 Indroduzir a tecnologia CASE para o auxílio dos
processos de software
Tópicos cobertos
 Modelos do processo de software
 Iteração entre os processos
 Especificação de software
 Projeto e implementação de software
 Validação do software
 Evolução do software
 Processos automatizados de desenvolvimento
O processo do software
 Um conjunto estruturado de atividades necessárias para
desenvolver um sistema de software
• Especificação
• Projeto
• Validação
• Evolução
 Um modelo de processo de software é uma representação
abstrata do processo. Ela apresenta uma descrição do
processo de algumas perspectivas particulares
Modelos genéricos de processos de
software
 O modelo cascata (waterfall)
• Fases separadas e distintas de especificação e desenvolvimento
 Desenvolvimento evolucionário (ou prototipação)
• Especificação e desenvolvimento são intercalados
 Modelo de sistema formal
• Um modelo de sistema matemático é formalmente transformado
numa implementação
 Desenvolvimento baseado em reuso
• O sistema é construído a partir de componentes existentes
Waterfall model
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance
Modelo Cascata
Sistemático e seqüencial
Waterfall model phases
 Análise de requisitos e definições
 Projeto do sistema e do software
 Implementação e teste de unidades
 Integração e testes do sistema
 Manutenção e operação
 Uma deficiência do modelo cascata é a
dificuldade em acomodar mudanças depois que o
processo se inicia.
Análise e Engenharia de Sistemas
 Estabelecer os requisitos básicos para todos os
sistemas que envolvem o software, como
hardware, pessoas e bancos de dados.
 Envolve a coleta dos requisitos em nível do
sistema, com uma pequena quantidade de projeto
e análise de alto nível.
Analise de Requisitos de Sw
 Concentra a coleta de requisitos no sw.
 Leva à compreensão do domínio da informação, a
função, desempenho e interfaces exigidos.
 Os requisitos para o sistema e para o sw são
documentados e revistos com o cliente.
Projeto
 Estrutura de dados
 Arquitetura de sw
 Detalhes procedimentais
 Caracterização da interface
 É avaliado antes de começar a ser implementado
 Junto com as etapas anteriores torna-se parte da
documentação do sistema
Codificação
 Projeto traduzido para a linguagem do
computador.
 Se o projeto for executado detalhadamente, a
codificação pode ser executada mecanicamente?
Testes
 Concentra-se nos aspectos lógicos internos do sw.
 Garante que “todas as instruções” tenham sido
testadas.
 A entrada definida produz os resultados exigidos?
 Garbage in, garbage out?
Manutenção
 Sw embutido nem sempre tem esta parte.
 Erros encontrados.
 Mudanças no ambiente externo.
 Acréscimos funcionais.
 Desempenho
Problemas com a Cascata
 O mais antigo e amplamente usado.
 Projetos reais raramente seguem o fluxo seqüencial que ele
propõe. Ocorrem iterações que trazem problemas na
aplicação do paradigma.
 É difícil para o cliente declarar todas as exigências
explicitamente. É difícil acomodar as incertezas naturais
que existem no começo de muitos projetos.
 O cliente deve ter paciência. Uma versão do sw só estará
disponível em um ponto tardio do cronograma. Um erro
crasso, pode ser desastroso.
 Só é apropriado quando os requisitos são bem conhecidos.
Desenvolvimento evolucionário
 Desenvolvimento exploratório
• O objetivo é trabalhar com o cliente e desenvolver um sistema
final a partir das especificações iniciais. Deve iniciar com
requisitos bem compreendidos.
 Jogar fora a prototipação
• O objetivo é entender os requisitos do sistema. Deve iniciar com
requisitos pouco compreendidos.
Desenvolvimento evolucionário
Validation
Final
version
Development
Intermediate
versions
Specification
Initial
version
Outline
description
Concurrent
activities
Prototipação
Coleta e refinamento
dos requisitos
Avaliação do protótipo
pelo cliente
Início
Desenvolvimento evolucionário
 Problemas
• Falta de visibilidade sobre o processo.
• Sistema geralmente pouco estruturado.
• Habilidades especiais (ex. em linguagens para uma rápida
prototipação) são requeridas.
 Aplicabilidade
• Para sistemas interativos pequenos ou médios.
• Para partes de de grandes sistemas (ex. A interface com o
usuário).
• Para sistemas com pouco tempo de vida.
Modelo de desenvolvimento
formal
 Baseado na transformação de uma especificação
matemática através de diferentes representações
em um programa executável.
 As transformações preservam a corretude das
especificações, sendo fácil demonstrar que que o
programa segue estas últimas.
 Baseado na abordagem ‘Cleanroom’ para o
desenvolvimento de software.
Modelo de desenvolvimento
formal
Requirements
definition
Formal
specification
Formal
transformation
Integration and
system testing
Transformações formais
R2
Formal
specification
R3
Executable
program
P2 P3 P4
T1 T2 T3 T4
Proofs of transformation correctness
Formal transformations
R1
P1
Desenvolvimento formal
 Problemas
• São necessárias habilidades especiais e treinamento para aplicar
a técnica.
• Dificuldade para formalizar especificamente alguns aspectos do
sistema, como a interface com o usuário.
 Aplicabilidade
• Sistemas críticos, especialmente aqueles em que uma versão
segura deve ser feita antes do sistema entrar em operação.
Desenvolvimento orientado a
reutilização
 Baseado na sistemática do reuse, onde os
sistemas são integrados a partir de componentes
existentes ou sistemas COTS (Commercial-off-
the-shelf).
 Estágios do processo
• Análise dos componentes
• Modificação dos requisitos
• Projeto do sistema com reutilização
• Desenvolvimento e integração
 Esta abordagem está se tornando mais importante,
porém ainda há pouca experiência com ela.
Reuse-oriented development
Requirements
specification
Component
analysis
Development
and integration
System design
with reuse
Requirements
modification
System
validation
Processo de iteração
 Os requisitos do sistema sempre evoluem ao
longo do projeto, então o processo de iteração dos
estágios anteriores é retrabalhado e vira parte do
processo para grandes sistemas.
 Iteração pode ser aplicada a qualquer modelo
genérico de ciclo de vida.
 Duas abordagens semelhantes:
• Desenvolvimento incremental
• Desenvolvimento espiral
Desenvolvimento incremental
 Ao invés de entreagar o sistema uma única vez, o
desenvolvimento e a entrega são partidos em
incrementos, que fornecem parte das
funcionalidades requeridas.
 Os requisitos do usuários são dispostos
hierarquicamente, e os requisitos de prioridades
mais altas são incluídos nas primeiras entregas.
 Quando o desenvolvimento de um incremento é
iniciado, os requisitos são “congelados” de forma
que os requisitos para incrementos posteriores
possam continuar a evoluir.
Incremental development
Validate
increment
Develop system
increment
Design system
architecture
Integrate
increment
Validate
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
system
Vantagens do desenvolvimento
incremental
 Valor ao cliente tende a ser entregue a cada
incremento, então a funcionalidade dos sistema
tende a ser avaliada mais cedo.
 Os primeiros incrementos funcionam como um
protótipo para ajudar a esclarecer os requisitos
para os próximos incrementos.
 Baixo risco de o projeto falhar completamente.
 As tarefas de mais alta prioridade, tendem a
receber mais testes.
Extreme programming (XP)
 Nova abordagem de desenvolvimento baseada no
desenvolvimento e entrega de pequenos
incrementos de funcionalidade.
 Funciona com melhorias contínuas no código,
envolvimento do usuário no time de
desenvolvimento e programação em pares.
 Os testes aparecem antes da codificação.
Desenvolvimento em espiral
 O Processo é representado como um espiral ao invés de
uma sequência de atividades com voltas para trás.
 Cada volta no espiral representa uma fase no processo.
 Não há fases fixas como especificação ou projeto. As
voltas no espiral são escolhidas dependendo do que é
requisitado
 Os riscos são explicitamente avaliados e resolvidos
durante todo o processo
Spiral model of the software process
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integration
test
Acceptance
test
Service Develop, verify
next-level product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
Setores do modelo espiral
 Definição dos objetivos
• 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 organizadas para reduzir
os riscos chave.
 Desenvolvimento e validação
• Um modelo de desenvolvimento para o sistema é escolhido,
que pode ser qualquer um dos modelos genéricos.
 Planejamento
• O projeto é revisto e a próxima fase da espiral é planejada.

Mais conteúdo relacionado

Semelhante a ES4.ppt

FES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdfFES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdf
FChico2
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
Tiago Vizoto
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4
Elaine Cecília Gatto
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
CursoSENAC
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
Computação Depressão
 
Aula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdfAula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdf
FChico2
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
wilsonguns
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
Robson Silva Espig
 
Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)
AnthonnyDayvson
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
diha36
 
Modelos de Processo de Software
Modelos de Processo de SoftwareModelos de Processo de Software
Modelos de Processo de Software
Rogerio P C do Nascimento
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
Franklin Matos Correia
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
Manuel Menezes de Sequeira
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
Patrícia Melo
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individual
Adivaldo_badinho
 

Semelhante a ES4.ppt (20)

FES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdfFES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdf
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 
Aula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdfAula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdf
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Modelos de Processo de Software
Modelos de Processo de SoftwareModelos de Processo de Software
Modelos de Processo de Software
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individual
 

ES4.ppt

  • 1. Processo do Software  Grupo de atividades coerentes para especificação, projeto, implementação e teste de sistemas de software.
  • 2. Objetivos  Introduzir os processos de modelagem de software  Descrever alguns modelos de processos e quando eles devem ser usados  Descrever em linhas gerais o processo modelo para os requisitos de engenharia, de desenvolvimento de softare, seu teste e evolução  Indroduzir a tecnologia CASE para o auxílio dos processos de software
  • 3. Tópicos cobertos  Modelos do processo de software  Iteração entre os processos  Especificação de software  Projeto e implementação de software  Validação do software  Evolução do software  Processos automatizados de desenvolvimento
  • 4. O processo do software  Um conjunto estruturado de atividades necessárias para desenvolver um sistema de software • Especificação • Projeto • Validação • Evolução  Um modelo de processo de software é uma representação abstrata do processo. Ela apresenta uma descrição do processo de algumas perspectivas particulares
  • 5. Modelos genéricos de processos de software  O modelo cascata (waterfall) • Fases separadas e distintas de especificação e desenvolvimento  Desenvolvimento evolucionário (ou prototipação) • Especificação e desenvolvimento são intercalados  Modelo de sistema formal • Um modelo de sistema matemático é formalmente transformado numa implementação  Desenvolvimento baseado em reuso • O sistema é construído a partir de componentes existentes
  • 6. Waterfall model Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
  • 8. Waterfall model phases  Análise de requisitos e definições  Projeto do sistema e do software  Implementação e teste de unidades  Integração e testes do sistema  Manutenção e operação  Uma deficiência do modelo cascata é a dificuldade em acomodar mudanças depois que o processo se inicia.
  • 9. Análise e Engenharia de Sistemas  Estabelecer os requisitos básicos para todos os sistemas que envolvem o software, como hardware, pessoas e bancos de dados.  Envolve a coleta dos requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível.
  • 10. Analise de Requisitos de Sw  Concentra a coleta de requisitos no sw.  Leva à compreensão do domínio da informação, a função, desempenho e interfaces exigidos.  Os requisitos para o sistema e para o sw são documentados e revistos com o cliente.
  • 11. Projeto  Estrutura de dados  Arquitetura de sw  Detalhes procedimentais  Caracterização da interface  É avaliado antes de começar a ser implementado  Junto com as etapas anteriores torna-se parte da documentação do sistema
  • 12. Codificação  Projeto traduzido para a linguagem do computador.  Se o projeto for executado detalhadamente, a codificação pode ser executada mecanicamente?
  • 13. Testes  Concentra-se nos aspectos lógicos internos do sw.  Garante que “todas as instruções” tenham sido testadas.  A entrada definida produz os resultados exigidos?  Garbage in, garbage out?
  • 14. Manutenção  Sw embutido nem sempre tem esta parte.  Erros encontrados.  Mudanças no ambiente externo.  Acréscimos funcionais.  Desempenho
  • 15. Problemas com a Cascata  O mais antigo e amplamente usado.  Projetos reais raramente seguem o fluxo seqüencial que ele propõe. Ocorrem iterações que trazem problemas na aplicação do paradigma.  É difícil para o cliente declarar todas as exigências explicitamente. É difícil acomodar as incertezas naturais que existem no começo de muitos projetos.  O cliente deve ter paciência. Uma versão do sw só estará disponível em um ponto tardio do cronograma. Um erro crasso, pode ser desastroso.  Só é apropriado quando os requisitos são bem conhecidos.
  • 16. Desenvolvimento evolucionário  Desenvolvimento exploratório • O objetivo é trabalhar com o cliente e desenvolver um sistema final a partir das especificações iniciais. Deve iniciar com requisitos bem compreendidos.  Jogar fora a prototipação • O objetivo é entender os requisitos do sistema. Deve iniciar com requisitos pouco compreendidos.
  • 18. Prototipação Coleta e refinamento dos requisitos Avaliação do protótipo pelo cliente Início
  • 19. Desenvolvimento evolucionário  Problemas • Falta de visibilidade sobre o processo. • Sistema geralmente pouco estruturado. • Habilidades especiais (ex. em linguagens para uma rápida prototipação) são requeridas.  Aplicabilidade • Para sistemas interativos pequenos ou médios. • Para partes de de grandes sistemas (ex. A interface com o usuário). • Para sistemas com pouco tempo de vida.
  • 20. Modelo de desenvolvimento formal  Baseado na transformação de uma especificação matemática através de diferentes representações em um programa executável.  As transformações preservam a corretude das especificações, sendo fácil demonstrar que que o programa segue estas últimas.  Baseado na abordagem ‘Cleanroom’ para o desenvolvimento de software.
  • 22. Transformações formais R2 Formal specification R3 Executable program P2 P3 P4 T1 T2 T3 T4 Proofs of transformation correctness Formal transformations R1 P1
  • 23. Desenvolvimento formal  Problemas • São necessárias habilidades especiais e treinamento para aplicar a técnica. • Dificuldade para formalizar especificamente alguns aspectos do sistema, como a interface com o usuário.  Aplicabilidade • Sistemas críticos, especialmente aqueles em que uma versão segura deve ser feita antes do sistema entrar em operação.
  • 24. Desenvolvimento orientado a reutilização  Baseado na sistemática do reuse, onde os sistemas são integrados a partir de componentes existentes ou sistemas COTS (Commercial-off- the-shelf).  Estágios do processo • Análise dos componentes • Modificação dos requisitos • Projeto do sistema com reutilização • Desenvolvimento e integração  Esta abordagem está se tornando mais importante, porém ainda há pouca experiência com ela.
  • 26. Processo de iteração  Os requisitos do sistema sempre evoluem ao longo do projeto, então o processo de iteração dos estágios anteriores é retrabalhado e vira parte do processo para grandes sistemas.  Iteração pode ser aplicada a qualquer modelo genérico de ciclo de vida.  Duas abordagens semelhantes: • Desenvolvimento incremental • Desenvolvimento espiral
  • 27. Desenvolvimento incremental  Ao invés de entreagar o sistema uma única vez, o desenvolvimento e a entrega são partidos em incrementos, que fornecem parte das funcionalidades requeridas.  Os requisitos do usuários são dispostos hierarquicamente, e os requisitos de prioridades mais altas são incluídos nas primeiras entregas.  Quando o desenvolvimento de um incremento é iniciado, os requisitos são “congelados” de forma que os requisitos para incrementos posteriores possam continuar a evoluir.
  • 28. Incremental development Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
  • 29. Vantagens do desenvolvimento incremental  Valor ao cliente tende a ser entregue a cada incremento, então a funcionalidade dos sistema tende a ser avaliada mais cedo.  Os primeiros incrementos funcionam como um protótipo para ajudar a esclarecer os requisitos para os próximos incrementos.  Baixo risco de o projeto falhar completamente.  As tarefas de mais alta prioridade, tendem a receber mais testes.
  • 30. Extreme programming (XP)  Nova abordagem de desenvolvimento baseada no desenvolvimento e entrega de pequenos incrementos de funcionalidade.  Funciona com melhorias contínuas no código, envolvimento do usuário no time de desenvolvimento e programação em pares.  Os testes aparecem antes da codificação.
  • 31. Desenvolvimento em espiral  O Processo é representado como um espiral ao invés de uma sequência de atividades com voltas para trás.  Cada volta no espiral representa uma fase no processo.  Não há fases fixas como especificação ou projeto. As voltas no espiral são escolhidas dependendo do que é requisitado  Os riscos são explicitamente avaliados e resolvidos durante todo o processo
  • 32. Spiral model of the software process Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance test Service Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW
  • 33. Setores do modelo espiral  Definição dos objetivos • 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 organizadas para reduzir os riscos chave.  Desenvolvimento e validação • Um modelo de desenvolvimento para o sistema é escolhido, que pode ser qualquer um dos modelos genéricos.  Planejamento • O projeto é revisto e a próxima fase da espiral é planejada.