View
104
Download
0
Category
Preview:
Citation preview
Adélia Barros(adelia_nassau@yahoo.com.br)
Introdução à Engenharia de Software
Modelos de Processo
Revisando...Processo de Software
O que é processo de software:◦ É um conjunto de todas as atividades necessárias para
definir, desenvolver, testar e manter um produto de software;
Objetivos de um processo de desenvolvimento:◦ Definir quais as atividades a serem executadas;◦ Quando, como e por quem as atividades serão
executadas;◦ Prover pontos de controle para verificar o andamento
do desenvolvimento;◦ Padronizar a forma de desenvolver software em uma
organização.
Revisando... Processo de Software Através de uma visão geral um processo de
software pode ser considerado assim (Uma Visão
Genérica: 3 Fases):◦ Definição - “o que”
Levantamento de Requisitos; Análise de Sistemas.
◦ Desenvolvimento - “como” Projeto; Geração do Código; Teste.
◦ Implantação e Manutenção
Modelo de Processo de Software
A escolha de um modelo ◦ determina as técnicas e os agentes envolvidos em
cada fase;
◦ depende do tipo de projeto.
Modelo de Processo de Software
Principais modelos ou processos:◦ Modelo clássico (ou em cascata);
◦ Modelos Evolucionários Modelo de Prototipação ( Descartáveis ); Incremental ( Exploratório ); Espiral ( Exploratório ).
Processo de Software – Modelo Cascata
Também conhecido como ciclo de vida clássico ou Modelo Cascata:◦ Modelo mais antigo e mais usado;
◦ Modelado em função do ciclo de engenharia convencional;
◦ Requer uma abordagem sistemática e seqüencial para o desenvolvimento de um software;
Processo de Software – Modelo Cascata
Engenharia de Engenharia de SistemasSistemas
Engenharia de Engenharia de SistemasSistemas
Análise de Análise de Requisitos Requisitos
Análise de Análise de Requisitos Requisitos
Projeto Projeto Projeto Projeto
Codificação Codificação Codificação Codificação
Testes Testes Testes Testes
ManutençãoManutenção ManutençãoManutenção
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
ANÁLISE E ENGENHARIA DE ANÁLISE E ENGENHARIA DE SISTEMASSISTEMAS
1. Envolve a coleta de requisitos de todos os elementos do sistema;
2. Essa visão de sistema é essencial quando o software faz interface com outros
elementos como HW, pessoas e BD;
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
ANÁLISE DE REQUISITOS DE ANÁLISE DE REQUISITOS DE SOFTWARESOFTWARE
1. processo de coleta dos requisitos é intensificado e concentrado especificamente no software
2. deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos
3. os requisitos (para o sistema e para o software) são documentados e revistos com o cliente
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
PROJETOPROJETO1. tradução dos requisitos do software para um
conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie
2. se concentra em 4 atributos do programa: Estrutura de Dados, Arquitetura de Software, Detalhes Procedimentais e Caracterização de Interfaces
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
CODIFICAÇÃOCODIFICAÇÃO1. tradução das
representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
TESTESTESTES Concentram-se:
1. nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas
2. nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.
Processo de Software – Modelo Cascata
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
MANUTENÇÃOMANUTENÇÃO1. o software deverá sofrer mudanças
depois que for entregue ao cliente
Modelo Cascata:vantagens
Os gerentes de projetos de software aceitaram o modelo entusiasticamente porque:◦ Oferece uma maneira de tornar o processo mais
visível.◦ Facilita o planejamento.◦ Fixa pontos específicos para a escrita de
relatórios.
Modelo Cascata:vantagens
Apropriado para projetos que possuem uma definição estável do produto e tecnologia bastante conhecida◦ Ex. porte de algum produto existente para uma nova
plataforma. Apropriado também para projetos com
requisitos estáveis e bem entendidos mas de realização complexa.
Minimiza sobrecarga de planejamento, uma vez que todo o planejamento é feito no início.
Modelo Cascata:Problemas
Projetos reais raramente seguem o fluxo de seqüencial proposto;
É difícil estabelecer todos os requisitos no começo do projeto na qual existe uma incerteza natural quanto a esses requisitos;
Uma versão do software só vai ficar pronto em um ponto tardio do desenvolvimento;◦ Assim se houver algum erro crasso não detectado
na análise ou projeto o resultado pode ser desastroso;
Há muitos estágios bloqueantes que permitem a ociosidade dos desenvolvedores em alguns momentos.
Modelo Cascata
Embora o Modelo Ciclo de Vida Embora o Modelo Ciclo de Vida
Clássico tenha fragilidades, ele é Clássico tenha fragilidades, ele é
significativamente melhor do que significativamente melhor do que
uma abordagem casual (ad-hoc) ao uma abordagem casual (ad-hoc) ao
desenvolvimento de softwaredesenvolvimento de software
Modelo ad-hoc
Desenvolvimento evolucionário
ValidationFinal
version
Development Intermediateversions
SpecificationInitial
version
Outlinedescription
Concurrentactivities
Idéia geral:◦ Desenvolvimento da primeira versão do sistema o mais
rápido possível; ◦ Modificações sucessivas até que o sistema seja considerado
adequado;◦ Após o desenvolvimento de cada uma das versões do
sistema ele é mostrado aos usuários para comentários.
Adequado para o desenvolvimento de sistemas onde é difícil ou impossível de se fazer uma especificação detalhada do sistema;
Desenvolvimento evolucionário
Modelos Evolucionários◦ Incremental ( Exploratório );
◦ Modelo de Prototipação ( Descartáveis );
◦ Espiral ( Exploratório ).
Desenvolvimento evolucionário
Modelo Incremental Os requisitos são primeiramente identificados e ,em seguida,
as demais atividades do desenvolvimento são repetidas (nova versão do software).
Exploração de Conceitos
Requisitos
Projeto Implementação Instalação Manutenção
Versão 1..n
Modelo Incremental
Surgiu para remediar a deficiência do modelo em cascata◦ Cascata parte do princípio irreal de que os
requisitos permanecem estáveis
Desenvolvimento Evolucionário: Prototipação descartável O objetivo é entender os objetivos do sistema.
◦Começa com requisitos vagamente entendidos.
A primeira fase prevê o desenvolvimento de um programa para o usuário experimentar. ◦No entanto, o objetivo aqui é estabelecer os
requisitos do sistema. ◦O software deve ser reimplementado na fase
seguinte.
Desenvolvimento Evolucionário: Prototipação descartável A construção de protótipos com os quais os
usuários possam brincar é uma idéia bastante atrativa:◦ Para sistemas grandes e complicados.◦ Quando não existe um sistema anterior ou um sistema manual
que ajude a especificar os requisitos. Os objetivos do protótipo devem estar bem claros
antes do início da codificação. Possíveis objetivos: ◦ Entender os requisitos dos usuários. ◦ Definir a interface com os usuários. ◦ Demonstrar a viabilidade do sistema para os gerentes.
Uma decisão importante a ser tomada é escolher o que será e o que não será parte do protótipo. ◦ Não é economicamente viável implementar todo o
sistema! ◦ Os objetivos do protótipo são o ponto de partida.
Desenvolvimento Evolucionário: Prototipação descartável
Prototipagem:o que incluir no protótipo? Algumas possibilidades:
◦ Implementar todas as funções do sistema mas com um número reduzido de detalhes.
◦ Implementar um subconjunto das funções, possivelmente com um número maior de detalhes.
◦ Desconsiderar requisitos associados a velocidade, espaço, confiabilidade, etc.
◦ A menos que o objetivo do protótipo seja definir a interface com o usuário, desconsiderar a parte de manipulação de erros.
Prototipação
fim
início
construção produto
Refinamento dos requisitos
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos requisitos
Prototipação:possíveis vantagens
Protótipos contribuem para melhorar a qualidade da especificação dos futuros programas, o que leva à diminuição dos gastos com manutenção.
O treinamento dos usuários pode ser feito antes do produto ficar pronto.
Partes do protótipo podem ser usadas no desenvolvimento do sistema final.
Prototipação:possíveis desvantagens Em geral o grande argumento contra a
construção de protótipos é o custo.◦ A construção do protótipo atrasa o início da
implementação do sistema final. Atrasos são um dos maiores problemas dos projetos de
software. Construir um protótipo pode não ser tão mais rápido
assim do que construir o sistema final.
Prototipação:possíveis desvantagens O cliente vê algo que parece ser uma versão do
software desejado e não entende porque o produto precisa ser reconstruído. ◦ A tendência é o cliente exigir que pequenos acertos sejam
feitos para que o protótipo se transforme no sistema final. ◦ Freqüentemente a gerência cede ...
Muitas das concessões feitas na implementação do protótipo visando a construção rápida podem vir a fazer parte do sistema final. ◦ Utilização de linguagens, ferramentas, algoritmos, etc. que
sejam inadequados e/ou ineficientes.
O Modelo Espiral Foi criado visando abranger as melhores
características do modelo clássico e da prototipagem.
Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. ◦ análise de riscos em intervalos regulares do processo
de desenvolvimento de software; ◦ planejamento; ◦ controle; ◦ tomada de decisão.
Fases do modelo espiral Planejamento: determinação dos objetivos,
alternativas e restrições; Análise de riscos: análise de alternativas e
identificação / resolução dos riscos; Engenharia: desenvolvimento do produto no
“nível seguinte”; Avaliação feita pelo cliente: avaliação dos
resultados da engenharia.
O Modelo Espiral
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
O Modelo Espiral Observações:
◦ A cada ciclo da espiral, versões progressivamente mais completas do software são construídas;
◦ Antes de cada ciclo, uma análise de riscos é feita;
◦ Ao fim de cada ciclo é feita uma avaliação se deve-se prosseguir para o próximo ciclo.
O Modelo Espiral:risco O que é risco? Difícil de se definir precisamente!
◦ Qualquer coisa que possa sair errado;◦ Conseqüência de informação inadequada;◦ O risco de uma atividade é a medida de incerteza do
resultado desta atividade;◦ O risco está associado com a quantidade de informação
disponível: quanto menos informação, maior o risco; Riscos são resolvidos por ações que descubram ou
gerem informações que reduzam o grau de incerteza.
Há quem defenda que a tarefa principal dos gerentes de projetos de software é a minimização dos riscos.
“Execução” padrão de uma volta na espiral
Objetivos Restrições Alternativas Riscos Resolução do risco Resultados Planos Compromisso
Ex: Melhoria da Qualidade Objetivos
◦ Melhoria significativa da qualidade do software Limitações
◦ No prazo de três anos◦ Sem grande investimento de capital◦ Sem mudanças radicais nos padrões da companhia
Alternativas ◦ Reuso de software certificado existente◦ Introduzir especificação e verificação formal◦ Investir em ferramentas de teste e validação
Riscos◦ Não ser possível alcançar uma melhoria de qualidade com custo
apropriado; ◦ Melhoria de qualidade poder aumentar o custo de forma
excessiva; ◦ Novos métodos podem causar a saída de funcionários.
Resolução de risco◦ Pesquisa na literatura existente;◦ Projeto piloto; ◦ Levantamento de componentes potencialmente reutilizáveis; ◦ Avaliação das ferramentas de suporte disponíveis;◦ Treinamento de funcionários e seminários de motivação.
Ex: Melhoria da Qualidade (cont)
Resultados◦ Dificuldade de quantificar melhorias; ◦ Pouca disponibilidade de ferramentas de suporte para os padrões de
desenvolvimento da empresa;◦ Disponibilidade de componentes para reuso, porém poucas
ferramentas para suporta reutilização.
Planejamento◦ Explorar em mais detalhes a opção de reuso;◦ Desenvolver protótipos de ferramentas de suporte de reuso;◦ Explorar o esquema de certificação de componentes.
Compromisso◦ Patrocinar uma fase de estudo com duração de 18- meses.
Ex: Melhoria da Qualidade (cont)
Vantagem do modelo espiral Introduz a análise de riscos; Foca atenção em eliminação precoce de
erros; Iterativo e incremental, a cada iteração,
versões mais completas do software são progressivamente construídas;
Acomoda mudanças nos requisitos; Diminui os riscos em projetos de grande
escala.
Problemas do modelo espiral
Gerenciamento mais complexo; Cliente deve estar disponível a cada ciclo; Nem todo cliente aceita a abordagem do
modelo; É difícil convencer gerentes de que todo este
processo é controlável; Requer experiência em avaliação de risco.
Pontos principais
A engenharia de software trata de teorias, métodos e ferramentas para o desenvolvimento, gerenciamento e evolução de produtos de software
Produtos de software incluem programas e documentação.
Atributos do produto: manutenabilidade, dependabilidade, eficiência e usabilidade
O processo de software consiste daquelas atividades envolvidas no desenvolvimento de software
Pontos principais O modelo cascata considera cada atividade do
processo uma fase distinta Desenvolvimento evolucionário considera as
atividades do processo concorrentemente O modelo espiral é baseado em riscos A visibilidade do processo envolve a criação de
produtos associados às atividades
Processo de Software – Conclusão
ENGENHARIA DE SOFTWAREENGENHARIA DE SOFTWARE
pode ser vista como uma abordagem de desenvolvimento de software elaborada
com disciplina e métodos bem definidos.
.....“a construção por múltiplas pessoas de um software de múltiplas versões” [Parnas 1987]
Introdução à Engenharia de Software
DÚVIDAS ?
Recommended