Aula02abr EngSoft

(1)

Disciplina de

Engenharia de Software

Modelos de Processo de

Desenvolvimento de

software

(2)

“Uma estratégia de desenvolvimento que englobe processos, métodos e ferramentas,

e as fases de desenvolvimento”

Elementos da ES - Etapas

Paradigmas de Engenharia de Software

Modelos de Processos de Desenvolvimento de Software Ciclo de Vida de Software

(3)

Engenharia de Software 3



Um ciclo de vida de software (CVS) pode ser

visto como o período e tempo que se inicia com um conceito para um produto de software e acaba sempre que o software deixa de estar disponível para utilização;



Um modelo de Ciclo de Vida de Software

representa as atividades, suas entradas e saídas (documentos, tabelas, medições) e suas interações durante o ciclo de vida.

Modelos de Processos de

(4)



A elaboração de modelos para os processos de desenvolvimento de software atingiu um estágio maduro, baseado em

 conhecimento; e

 experiência de uma grande escala de projetos desenvolvidos;



Um modelo de processos estabelece um

framework (arquitetura, estrutura) para as principais atividades, entradas, saídas e restrições do projeto.

Modelos de Processos de

(5)



Existem vários modelos, porém alguns são

amplamente discutidos:

 Modelo Clássico (Cascata)

 Modelo Incremental;  Modelo de Prototipação;  Modelo Espiral; e  Modelo Evolucionário.

Modelos de Processos de

Desenvolvimento de Software

(6)

Modelo Clássico (Cascata)



Definido por Royce, em 1970;



Desde 1979 considerado padrão para IEEE;



Modelo mais antigo e o mais amplamente usado

da engenharia de software;



Modelado em função do ciclo da engenharia

convencional;



Em seu formato original descrevia uma

abordagem sistemática e seqüencial para o desenvolvimento de software;

(7)

Engenharia de Software 7 Requisitos do Sistema Análise Projeto Codificação Teste Manutenção

(8)

Modelo Clássico (Cascata)



Preocupa-se com o que conhecemos por

Engenharia Progressiva de Produtos de Software  Isto significa iniciar com um modelo conceitual de alto

nível para um sistema;

 Após a descrição da construção conceitual ter sido concluída, passa-se para as fases de projeto, implementação, ....



Uma das principais vantagens deste modelo é

permitir a gerência do baseline

 identifica um conjunto fixo de documentos produzidos como resultado de cada fase do ciclo e vida.

(9)

(10)



Requisitos do Sistema (Engenharia de Sistemas)

 Planejamento do sistema – Qual é o problema, as deficiências atuais ??

 Chamado de Levantamento dos Requisitos para o sistema;

 Coleta e especificação de todos os requisitos necessários para o desenvolvimento do sistema em questão;

 Intensa comunicação entre usuário e analista;

 Importância para técnicas adequadas de coleta de dados;

(11)

(12)



Análise do Sistema – “O que fazer”

 Também chamada de Projeto Lógico;

 Intensificação da coleta de requisitos;

 Interpretação das necessidades do cliente para modelos formais de representação do sistema;

 Os requisitos iniciais são detalhados (refinados);

 Os requisitos são documentados;

 MÉTODOS: Análise Estruturada, Análise Orientada a Objetos...

 PRODUTO: Especificação dos Requisitos.

(13)

(14)



Projeto do Sistema – “Como fazer”

 Também chamado de Projeto Físico

 Concentra-se em alguns aspectos importantes, tais como:

• Estrutura de dados do sistema (SGBD, sistema de arquivos,...);

• Interfaces do Sistema (layout, padrões, menus, botões);

• Projetar módulos do sistema;

 O projeto também é documentado, tornando-se parte da configuração do sistema

(15)

(16)



Codificação

 Interpretação das formalizações vistas na etapa de projeto para uma determinada linguagem de programação;

 Codificação de todos os módulos, interfaces, estruturas de dados, integrando todas as partes do sistema;

 Também chamada de Projeto de Implantação;

(17)

(18)



Testes

 Concentra-se:

• nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas; e

• nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza os resultados esperados.

• também chamada de Projeto de Implantação;

• produz um documento denominado Especificação e Resultado de Testes.

(19)

(20)



Manutenção

 Provavelmente o software sofrerá mudanças depois que for entregue ao cliente;

 Manutenções podem existir em decorrência de:

• erros encontrados;

• necessidade de adaptação a fim de acomodar mudanças no ambiente externo; ou

• exigência do cliente em relação a acréscimo de informações.

(21)



Manutenção - Tipos

 Manutenção Corretiva: diagnóstico e correção de erros;

 Manutenção Adaptativa: adaptação do software para acomodar mudanças externas;

 Manutenção Perfectiva: exigência do cliente para acréscimos funcionais e de desempenho;

 Manutenção Preventiva: ocorre quando o software é modificado para melhorar a confiabilidade ou para oferecer uma base melhor para futuras ampliações (técnicas de engenharia reversa e reengenharia).

(22)



Os projetos reais raramente seguem um fluxo seqüencial, proposta do ciclo de vida em cascata;



O início do projeto é cheio de incertezas em

relação as especificações do cliente, o que é natural, porém, o ciclo em cascata exige a declaração de todos os requisitos logo no início do projeto;



Apresentação tardia do primeiro esboço do

sistema, podendo causar insatisfação ao cliente.

(23)



Problemas parciais:

 Falta de iteratividade no processo de desenvolvimento;

 Execução das atividades de testes apenas no final do processo.



Congelamento dos requisitos e modelos de análise

do sistema.



Para resolver as deficiências do Modelo Clássico

foram apresentados os modelos evolucionários e de prototipação.

(24)



Problemas parciais:

 Falta de iteratividade no processo de desenvolvimento;

 Execução das atividades de testes apenas no final do processo.



Congelamento dos requisitos e modelos de análise

do sistema.



Para resolver as deficiências do Modelo Clássico

foram apresentados os modelos evolucionários e

Modelo Clássico - Problemas

Embora o Modelo Clássico

tenha problemas,ele é significativamente melhor do que uma abordagem casual de desenvolvimento

(25)



O Modelo clássico trouxe contribuições

importantes para o processo de desenvolvimento de software:



imposição de disciplina, planejamento e

gerenciamento;



a implementação do produto somente após os

objetivos terem sido completamente

entendidos.

(26)

Prototipação



A prototipação não é realmente considerada um

modelo de ciclo de vida, e sim uma técnica para produzir e desenvolver, de forma rápida partes do sistema que possam ser utilizadas pelo usuário para avaliação do sistema;



Processo que possibilita ao desenvolvedor criar

modelos (protótipos) do software que está desenvolvendo;



Permite uma maior interação

cliente-desenvolvedor, servindo como mecanismo para identificar os requisitos de software

(27)

Prototipação



O modelo pode assumir três formas:

 Um protótipo em papel ou sistema, apresentando apenas a interação usuário-sistema (prototipagem descartável);

 Um protótipo que implementa algumas funções exigidas pelo sistema;

 Um protótipo que executa superficialmente todas as funções desejadas pelo sistema, sendo que sofrerá sucessivos refinamentos (prototipagem evolucionária).

(28)

fim início construção produto refinamento protótipo avaliação protótipo pelo cliente construção protótipo projeto rápido obtenção dos requisitos

Prototipação - Etapas

(29)

Prototipação - Etapas



Obtenção dos Requisitos

 Desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de informações adicionais.



Projeto Rápido

 Representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída).

(30)

Prototipação - Etapas



Construção do Protótipo

 Implementação do projeto rápido;

 Primeira visão do sistema (recomendável sua exclusão futuramente);



Avaliação do Protótipo

 O cliente avalia o protótipo.



Refinamento do Protótipo

 Após a avaliação, cliente e desenvolvedor refinam os requisitos iniciais para o software a ser desenvolvido;

(31)

Prototipação - Etapas



Construção do Software

 Identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

(32)

Prototipação - Problemas



Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo.

 não aceita bem a idéia que a versão final do software vai ser

construída e “força” a utilização do protótipo como produto final



Desenvolvedor freqüentemente faz uma implementação comprometida com o objetivo de produzir rapidamente um protótipo.

 depois de um tempo ele familiariza-se com essas escolhas, e

(33)

Prototipação - Problemas



A prototipação é uma técnica eficiente, desde que já no início seja definida sua funcionalidade;



Soluciona o problema da espera no Modelo em Cascata



Não é preciso esperar até o final do ciclo de desenvolvimento para se obter uma versão operacional do

software;



Ambos, cliente e desenvolvedor, devem concordar que o protótipo seja construído para servir como um mecanismo de levantamento de requisitos e não solução final.

(34)

Modelo Incremental



Combina elementos do Modelo em Cascata

(Clássico) com a filosofia iterativa da

prototipação;



o objetivo é trabalhar junto do usuário para

descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido.

(35)

(36)



A versão inicial é freqüentemente o núcleo do produto (a parte mais importante);



A evolução acontece quando novas características

são adicionadas à medida que são sugeridas pelo usuário;



Este modelo é importante quando é difícil

estabelecer a priori uma especificação detalhada dos requisitos;



Mais apropriado para sistemas pequenos.

(37)

Ciclo de Vida em Espiral



Proposto por Boehm, em 1986, com o objetivo de

integrar os diversos modelos existentes na época, eliminando suas dificuldades e explorando seus pontos fortes;



Assume que o processo de desenvolvimento

ocorre em ciclos, cada um contendo fases de avaliação e planejamento onde a opção de abordagem para a próxima fase é determinada;

(38)

Ciclo de Vida em Espiral



É um modelo cíclico e não linear que visa

aproveitar as qualidades dos ciclo de vida clássico e de prototipação, com a inclusão de um novo elemento: a Análise de Riscos;



Permite definir a utilização dos outros tipos

conforme o resultado apresentado pela análise de riscos.



Por exemplo, se o nível de incerteza for grande, pode-se usar protótipos para uma melhor avaliação da situação, tanto pelo analista quanto pelo usuário.

(39)

Simulações, modelos, benchmarks Análise de Risco 1 Protótipo 1 Protótipo 2 Protótipo 3 Protótipo operacional Análise de Risco 2 Análise de Risco 3 Análise de Risco 4 Avaliação das alternativas e identificação/resolução e Análise dos riscos Planejamento

(Determinação dos objetivos, alternativas

e restrições)

Plano de requisitos plano de ciclo de vida

Plano de Desenvolvimento Plano de teste e integração Conceito de operação Requisitos de Software Validação dos requisitos Projeto do produto de software Validação e verificação do projeto Projeto detalhado Código Teste de unidade Teste de Integração Teste de Sistema

Implementação Desenvolvimento e_{verificação do} próximo nível do produto Avaliação do Cliente e Plano da próxima fase Custos Requisitos iniciais e planejamento do projeto Revisão Engenharia

(40)

Ciclo de Vida em Espiral

decisão de continuar ou não

na direção de um sistema concluído

avaliação do

cliente engenharia

análise dos riscos planejamento

(41)

Ciclo de Vida em Espiral - Fases



Planejamento: determinação dos objetivos,

alternativas e restrições;



Análise dos Riscos: avaliação das alternativas e

identificação/resolução do potencial de riscos;



Engenharia: desenvolvimento do produto no

nível seguinte



Avaliação do Cliente: avaliação do produto e

(42)

Ciclo de Vida em Espiral



Permite o uso da prototipação em qualquer etapa

do ciclo de vida;



Utiliza os conceitos de seqüência de atividades

como no ciclo de vida clássico, porém, com maior iteração;



É, atualmente, a abordagem mais realística para o

(43)

Visão Genérica da ES- Pressman



Independente do paradigma de engenharia de

software escolhido, o processo de desenvolvimento abrange três fases genéricas:

 Definição;

 Desenvolvimento; e

(44)

Visão Genérica da ES- Pressman

DEFINIÇÃO

•Definição dos Requisitos do

software •Planejamento do Projeto de desenvolvimento do software •Análise _{DESENVOLVIMENTO} •Projeto do Software •Implementação •Implantação MANUTENÇÃO •Correção •Adaptação •Expansão

(45)

Visão Genérica da ES - Definição

FASE DE DEFINIÇÃO: “o quê” será desenvolvido



Planejamento do Projeto de Software: assim que o

escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados, e tarefas e programação de trabalho são definidas.



Especificação e Análise dos Requisitos: definição

detalhada do domínio da informação e da função do software

(46)

Visão Genérica da ES - Desenvolvimento

FASE DE DESENVOLVIMENTO: “como” o software vai ser desenvolvido



Projeto de Software: traduz os requisitos do software num conjunto de

representações (algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface;



Codificação: as representações do projeto devem ser convertidas numa

linguagem artificial (a linguagem pode ser uma linguagem de programação convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador



Realização de Testes do Software: logo que o software é implementado

numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação

(47)

FASE DE MANUTENÇÃO: concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para uso operacional



Correção: mesmo com as melhores atividades de garantia de qualidade

de software, é provável que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos.



Adaptação: com o passar do tempo, o ambiente original (por exemplo a

CPU, o sistema operacional e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o

software para acomodar mudanças em seu ambiente.



Melhoramento Funcional: a medida que o software é usado, o usuário

reconhecerá funções adicionais que oferecerão benefícios.

(48)



ATIVIDADES DE PROTEÇÃO - as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção:

 Revisões: efetuadas para garantir que a qualidade seja

mantida à medida que cada etapa é concluída.

 Documentação: é desenvolvida e controlada para

garantir que informações completas sobre o software estejam disponíveis para uso posterior.

 Controle das Mudanças: é instituído de forma que as

mudanças possam ser aprovadas e acompanhadas.

(49)

Visão Genérica - Rezende

CONCEPÇÃO PROJETO LÓGICO PROJETO FÍSICO IMPLEMEN- TAÇÃO IMPLANTA- ÇÃO OPERAÇÃO

(50)

Visão Genérica - Rezende



Concepção

 analisar vantagens de construir um novo sistema; ou

 modificar o sistema existente.



Projeto Lógico

 especificação detalhada do sistema a ser desenvolvido.

 análise do Sistema Atual e Projeto do Novo Sistema;



Projeto Físico

 equipamento utilizado; e

(51)



Implementação

 revisão das especificações dos programas;

 desenvolvimento da lógica dos programas;

 codificação dos programas;

 construção dos arquivos ( banco de dados);

 teste dos programas; e

 elaboração de manuais de operação.

(52)



Implantação

 deve ser realizado planejamento detalhado;

 lida-se com dados e resultados reais;

 teste do sistema junto ao usuário

• definição do pessoal que será envolvido;

• cálculo dos tempos de execução;

• avaliação da interação dos programas com as rotinas manuais;

• avaliação dos resultados gerais do sistema e confronto com com o que havia sido previsto.

(53)

Visão Genérica - Rezende



Implantação (cont.)

 treinamento

• divulgar sistema para as pessoas que vão operá-lo; e

• planejar teste do sistema.  procedimentos operacionais

• corrigir possíveis falhas detectadas no teste;

• aprovação do sistema; e

(54)

Visão Genérica - Rezende



Implantação (cont.)

 conversão do sistema

• ponto central da implantação;

• passagem do antigo para o novo sistema (testado e aceito):

– mudança direta; – paralelo;

– piloto; – parcial.

(55)

Visão Genérica - Rezende



Operação

 Produção

• uso do sistema; e

• manter sistema funcionando.  Manutenção

• mudanças introduzidas no sistema:

• alterações internas e externas;

• correção de erros encontrados no sistema;

• melhorar o desempenho; e

(56)



Segundo o padrão IEEE 1074-1995, há três

processos principais durante a fase de

desenvolvimento de software:

 Requisitos: decidir o que o sistema deve fazer, suas

atividades, riscos e plano de testes;

 Projeto: determinar como um sistema efetua os

cálculos, sua estrutura e suas funções específicas;

 Implementação: produzir código-fonte, documentação e testes; validar e verificar.

(57)

Envolvidos na ES



Usuário

 Pessoa ou grupo de pessoas para quem o sistema é construído.



Analista de Sistemas (Projetista de Software)

 trazer à luz detalhes do sistema;

 habilidade com pessoas; e

(58)

Envolvidos na ES



Programador  produzir programas; e  testar programas.



Operador  execução de programas;  operação de equipamentos;  entrada de dados;  emissão de relatórios; e

(59)

Importância da ES

Projeto Lógico Projeto Físico Implementação Implantação Teste Manutenção Desenvolvimento com sistemática Desenvolvimento sem sistemática Implementação Implantação Manutenção