Adélia Barros ([email protected]) Introdução à Engenharia de Software Modelos de Processo

Adélia Barros([email protected])

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;


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


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;




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




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




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




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.




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;


Modelos Evolucionários◦ Incremental ( Exploratório );

◦ Modelo de Prototipação ( Descartáveis );

◦ Espiral ( Explorató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 ?

Documents

Adélia Barros ([email protected]) Introdução à Engenharia de Software Modelos de Processo