Definições e ciclo de vida

“A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software”.

“É a aplicação sistemática de conhecimentos científicos na criação e construção de soluções com um bom custo benefício para resolução de problemas práticos da sociedade”.

Abrange um conjunto de três elementos fundamentais:

Métodos,

Ferramentas e

Procedimentos

Métodos: proporcionam os detalhes de como fazer para construir o software.

Planejamento e estimativa de projeto

Análise de requisitos de software e de sistemas

Projeto da estrutura de dados

Codificação

Teste

Manutenção

Ferramentas: dão suporte automatizado aos métodos.

existem atualmente ferramentas para sustentar cada um dos métodos

quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE -Computer Aided Software Engineering

Procedimentos: constituem o elo de ligação entre os métodos e as ferramentas;

sequência em que os métodos serão aplicados

produtos que se exige que sejam entregues

controles que ajudam assegurar a qualidade e coordenar as alterações

marcos de referência que possibilitam administrar o progresso do software.

O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido:

1. DEFINIÇÃO,

2. DESENVOLVIMENTO e

3. MANUTENÇÃO.

Software é:

(1) Instruções (programas) de computador que, quando executadas, produzem a função e o desempenho desejados; +

(2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informação; +

(3) documentos que descrevem a operação e o uso dos programas.

Roger Pressman

Um conjunto de instruções que quando executadas produzem a função e o desempenho desejados, estruturas de dados que permitam que as informações relativas aos problema a resolver sejam manipulados adequadamente e a documentação necessária para uma melhor operação e entendimento.

Não consiste apenas em um programa de computador, mas também todos os dados de documentação e configuração selecionados

Conjunto de programas

Arquivos de configuração

Documentação do sistema

Documentação para o usuário

Site contendo informações e atualizações do sistema

O Software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico:

Custos são concentrados no trabalho de engenharia.

Projetos não podem ser geridos como projetos de manufatura.

“Fábrica de Software!”

Software não desgasta!

Software não é sensível aos problemas ambientais que fazem com que o hardware se desgaste.

Ver curvas de falha, páginas 14 e 15 do Pressman.

Toda falha indica erro de projeto ou implementação: manutenção do SW é mais complicada que a do HW.

A maioria dos softwares é feita sob medida e não montada a partir de componentes existentes.

!= Hardware.

Situação esta mudando:

Orientação a objetos.

Reusabilidade é o “Santo Graal”(diminui custos e melhora projetos).

1. Revisões

2. Documentação

3. Controle de

Mudanças

CCCooonnnssstttrrruuuçççãããooo

1. Entender

2. Modificar

3. Revalidar

Manutenção “mudanças”

OOOpppeeerrraaaçççãããooo

SSSOOOFFFTTTWWWAAARRREEE

PPPRRROOODDDUUUTTTOOO

AAAtttiiivvviiidddaaadddeeesss dddeee AAApppoooiiiooo

1. Análise de

Sistema

2. Planejamento

do Projeto

3. Análise de

Requisitos

Definição“o que” Desenvolvimento

“como”

1. Projeto de

Software

2. Codificação

3. Teste

Alguns ciclos de vida mais conhecidos são: Ciclo de Vida Clássico (Cascata)

Prototipação

Modelo Espiral

Desenvolvimento Iterativo

Evolutivo

natureza do projeto e da aplicação

métodos e ferramentas a serem usados ou disponíveis

controles e produtos que precisam ser entregues

prazos e recursos disponíveis

modelo mais antigo e o mais amplamente usado da engenharia de software

modelado em função do ciclo da engenharia convencional

requer uma abordagem sistemática, sequencial ao desenvolvimento de software

Engenharia de

SistemasAnálise de

Requisitos Projeto

Codificação

Testes

Manutenção

Definição: “o que” será desenvolvido.

Análise do sistema : define o papel de cada elemento num sistema baseado em computador, atribuindo, em última análise, o papel que o software desempenhará.

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 as tarefas e a programação de trabalho, definidas.

18

Definição: “o que” será desenvolvido.

Análise de requisitos : o escopo definido para o software proporciona uma direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho se inicie.

19

Desenvolvimento: “como” será desenvolvido.

Projeto de software : traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura, o procedimento algorítmico e as características de interfaces.

Codificação : as representações do projeto devem ser convertidas numa linguagem artificial que resulte em instruções que possam ser executadas pelo computador. A etapa de codificação realiza essa conversão.

Realização de testes do software : logo que é implementado numa forma executável por máquina, o software deve ser testado para que se possa descobrir defeitos de função, lógica e implementação.

20

Manutenção: “mudanças” que estão associadas à:

CORRECÃO DE ERROS,

ADAPTAÇÕES e AMPLIAÇÕES.

EVOLUTIVAS

Três tipos de mudanças são encontradas durante a fase de manutenção:

21

Correção: mesmo com as melhores atividades de garantia da qualidade, é possível que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos.

Adaptação: com o passar de tempo, o ambiente original para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa resulta em modificações no software a fim de acomodar mudanças em seu ambiente.

Melhoramento funcional: à medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios, estendendo o software para além de suas exigências funcionais originais.

22

Atividades de proteção : complementam as fases e passos descritos na visão genérica da Engenharia de Software.

Revisões : são feitas 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 sistema e o software estejam disponíveis para uso posterior.

Controle das mudanças : é instituído de forma que elas possam ser aprovadas e acompanhadas.

23

projetos reais raramente seguem o fluxo seqüencial que o modelo propõe

logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural

o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.

idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software.

apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.

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 definiçõ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)

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

Construção Protótipo: implementação do projeto rápido

Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

Refinamento dos

Requisitos: cliente e

desenvolvedor refinam os

requisitos do software a ser

desenvolvido.

Ocorre neste ponto umprocesso de iteração que

pode conduzir a 1a. atividade até que as

necessidades do cliente sejam satisfeitas e o

desenvolvedor compreenda o que precisa ser feito.

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

Construção Produto: 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.

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 (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.

Exercício de prototipação

Grupo de até 4 alunos

Construir um protótipo para um dos temas a seguir:

Software de locação

Locação de filmes por um determinado cliente

Devolução dos filmes locados

Efetuar pagamento dos filmes locados utilizando cartão crédito

Emitir relação de filmes locados no mês, agrupadas por gênero do filmes. Indicador subtotais de locações (quantidade e valor financeiro arrecadado) por filme e por gênero.

Software de controle acadêmico

Emissão das disciplinas cursadas pelo aluno com suas respectivas notas, carga horária, frequências e situação (aprovado ou reprovado)

Matrícula on-line do aluno

Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente

A chave é definir-se as regras do jogo logo no começo

O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos

Por quê ?

O primeiro design muito provavelmente será deficiente com respeito aos requisitos principais do projeto

nem todos os requisitos são claramente identificáveis a princípio, e aqueles que são podem as vezes ser ambíguos ou simplesmente inconsistentes

requisitos podem mudar ou ficar obsoletos

clientes podem mudar de opinião

mercado competitivo pode exigir mudanças

A descoberta tardia de defeitos no design resultarão em aumentos de custos ou cancelamento do projeto

O tempo e o dinheiro gastos na correção de um design defeituoso não são recuperáveis !

O modelo espiral acopla a natureza iterativa da prototipação com os aspectos controlados e sistemáticosdo modelo cascata

O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa

Existem tipicamente de 3 a 6 regiões de tarefa

36

Adiciona um novo elemento: a Análise de Risco

Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos

Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

O modelo é relativamente novo e não tem sido amplamente usado

O paradigma do modelo espiral para a engenharia de software é a abordagem mais realística para o desenvolvimento de sistemas e de software de grande escala

37

38

Planejamento

Análise de Riscos

Engenharia

Construção e Liberação

Avaliação do Cliente

Comunicação com

Cliente

Especificação

de Requisitos

Análise

Design

Implementação

Teste

Tempo

Ris

co

Aplicação da Cascata Iterativamente ao Sistema

Primeiras iterações carregam os maiores riscos

Cada iteração gera uma versão executável com algum incrementoao sistema

Cada iteração inclui integração e testes

R

A

D

I

T tempo

R

A

D

I

T

R

A

D

I

T

R

A

D

I

T

I1 I2 I3 I4

Tempo

Ris

co

CascataIterativo

Iteração Iteração Iteração Iteração Iteração Iteração Iteração Iteração

SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley, 2007.

PRESSMAN, R. S. Engenharia de Software: Uma abordagem Profissional. 7ª ed. Porto Alegre: AMGH, 2011.