MODELAGEM DO PROCESSO E
CICLO DE VIDA
Prof. Ms. Wiliam Carlos Galvão wiliamcgalvao@hotmail.com
Objetivos da Engenharia de
Software
Controle sobre o desenvolvimento de software
dentro de custos, prazos e níveis de
qualidade desejados
Produtividade no desenvolvimento, operação e
manutenção de software
Qualidade versus Produtividade
Permitir que profissionais tenham controle
sobre o desenvolvimento de software dentro
de custos, prazos e níveis de qualidade
desejados
Características da
Engenharia de Software
A Engenharia de Software se refere a
software
(sistemas)
desenvolvidos
por
grupos ao invés de indivíduos
usa princípios de engenharia ao invés de
arte, e
inclui tanto aspectos técnicos quanto não
Problemas relacionados ao Software
O avanço constante do hardware supera nossa capacidade de produzir software que explore esse potencial.
Nossa habilidade para construir novos produtos de software não acompanha a demanda, pela quantidade de passos a serem seguidos. 100 _ Desenvolvimento SW Manutenção SW Hardware 80 _ 60 _ 40 _ 20 _
Alguns problemas na construção de software
• A nível industrial, algumas questões que
caracterizaram as preocupações com o processo
de desenvolvimento de software foram:
– por que o software demora tanto para ser concluído?
– por que os custos de produção têm sido tão
elevados?
– por que não é possível detectar todos os erros antes
que o software seja entregue ao cliente?
– por que é tão difícil medir o progresso durante o
processo de desenvolvimento de software?
problema de comunicação entre
cliente e fornecedor
• a insatisfação do cliente com o sistema
"concluído"
ocorre
frequentemente,
devido, principalmente, ao fato de que
os projetos de desenvolvimento são
baseados em informações vagas sobre
as necessidades e desejos do cliente;
Falta de teste
• a qualidade do software é quase sempre
suspeita, problema resultante da pouca
atenção que foi dada, historicamente, às
técnicas de teste de software (até porque o
conceito de qualidade de software é algo
Programação sem controles
• a “cultura de programação” que ainda é
difundida e facilmente aceita por estudantes
e profissionais de Ciências da Computação;
Como reduzir ou resolver estes
problemas?
• Em primeiro lugar, é preciso estar ciente também de
que não existe uma abordagem mágica que seja a
melhor para a solução destes problemas
• É importante e desejável que estes métodos sejam
suportados por um conjunto de ferramentas que
permita automatizar o desenrolar destas etapas do
projeto
• É preciso uma definição clara de critérios de qualidade
e produtividade de software
• São estes aspectos que caracterizam a ENGENHARIA
O que é um software de
qualidade?
O software que satisfaz os requisitos solicitados pelo
usuário. Deve ser fácil de manter, ter boa performance,
ser confiável e fácil de usar
Alguns atributos de qualidade
Manutenibilidade
O software deve evoluir para atender os requisitos que
mudam
Eficiência
O software não deve desperdiçar os recursos do sistema
Usabilidade
O software deve ser fácil de usar pelos usuários para os quais
Qualidade de Software
(um exemplo para o Varejo)
Correto
A loja não pode deixar de cobrar por produtos
comprados pelo consumidor
Robusto e altamente disponível
A loja não pode parar de vender
Eficiente
O consumidor não pode esperar
A empresa quer investir pouco em recursos
Qualidade de Software
(um exemplo para o Varejo)
Amigável e fácil de usar
A empresa quer investir pouco em treinamento
Altamente extensível e adaptável
A empresa tem sempre novos requisitos (para ontem!)
A empresa quer o software customizado do seu jeito
(interface, teclado, idioma, moeda, etc.)
Reusável
Qualidade de Software
(um exemplo para o Varejo)
Aberto, compatível, de fácil integração com outros
sistemas
A empresa já tem controle de estoque, fidelização, etc.
Portável e independente de plataforma (hw e sw)
A empresa opta por uma determinada plataforma
Baixo custo de instalação e atualização
Importância da Engenharia de
Software
Qualidade
de
software
e
produtividade
garantem:
Disponibilidade de serviços essenciais
Segurança de pessoas
Competitividade das empresas
Produtores
Elementos e Atividades da
Engenharia de Software
Elementos
Modelos do ciclo de vida
do software
Linguagens
Métodos
Ferramentas
Processos
Atividades
Modelagem do negócio Elicitação de requisitos Análise e Projeto Implementação Testes Distribuição Planejamento Gerenciamento Gerência de Configuração e Mudanças ManutençãoAtividades e Artefatos da
Engenharia de Software
Artefatos Plano de Negócios Plano de Projeto Plano de Riscos Documento de Requisitos Mapeamentos A&P Documento de Caso de Uso Documento de Arquitetura Classes Documento de Testes Documento de Validação Manual do Sistema Atividades Modelagem do negócio Elicitação de requisitos Análise e Projeto Implementação Testes Distribuição Planejamento Gerenciamento Gerência de Configuração e Mudanças Manutenção
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
Processo
Conjunto de atividades
bem definidas
com responsáveis
com artefatos de entrada e saída
com dependências entre as mesmas e ordem de
execução
O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software.
Processo de Desenvolvimento de SW
É estudado dentro da área de Engenharia de Software e é considerado um dos principais mecanismos para obter software de qualidade e cumprir corretamente os contratos de desenvolvimento.
O Processo de desenvolvimento de software é uma das respostas técnicas adequadas para resolver a Crise do Software, termo utilizado nos anos 70, quando a Engenharia de Software era praticamente inexistente.
Processo de Desenvolvimento de SW
O termo expressava as dificuldades do desenvolvimento de software, frente ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados.
Na década de 70, a atividade “desenvolvimento de software” era executada de forma desorganizada, desestruturada e sem planejamento, gerando um produto final de má qualidade, pois não existia documentação ou era entregue fora do prazo ou o levantamento de tempo e esforço não correspondia à real necessidade.
Muitas vezes, esta atividade não satisfazia às necessidades do cliente, desperdiçando recursos da empresa e aumentando gastos, que não viriam a ser compensadores para o cliente, demandando tempo, esforço e dinheiro, daí o termo Crise do Software.
Processo de Desenvolvimento de SW
Além das linguagens, principalmente, foram desenvolvidas metodologias de desenvolvimento de software, onde passos eram detalhados para que o processo de desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária.
Com o tempo, as metodologias se tornaram mais complexas e distintas melhorando a qualidade do produto, independente do foco do sistema sempre haveria uma metodologia para manter a qualidade.
A partir deste cenário, com a necessidade de tornar o desenvolvimento de software um processo estruturado, planejado e padronizado, ele vem evoluindo para que erros que caracterizaram esta crise, como a má qualidade do que foi desenvolvido, não ocorram com projetos atuais.
Para isso linguagens para modelagem do sistema, como a UML, foram criadas.
Levantamento e Análise de Requisitos de SW
– A extração dos requisitos de um desejado produto de software é a primeira tarefa na sua criação.
– Embora o cliente provavelmente acredite conhecer o que software deve fazer, esta tarefa requer habilidade e experiência em Engenharia de Software.
Processo de Desenvolvimento de SW
Passos / Atividades
– Avaliar os problemas na situação atual
– Principal foco para o novo sistema: O QUE e não COMO: – qual o fluxo e o conteúdo de informação
– quais as funções do sistema
– quais dados o sistema produz e consome – qual o comportamento do sistema
– quais as características de interface com outros subsistemas – quais são as restrições do projeto
Definição (Especificação e Arquitetura do SW)
– A arquitetura de um sistema de software remete a uma representação abstrata de sua especificação.
– Arquitetura é concernente à garantia de que o sistema de software irá ao encontro dos requisitos do produto, como também assegura que futuros requisitos possam ser atendidos.
Processo de Desenvolvimento de SW
Passos / Atividades
Implementação ou Codificação
– A transformação de um projeto para um código, geralmente, é a parte mais evidente do trabalho da Engenharia de Software, mas não necessariamente a sua maior porção.
– Consiste na programação do que foi definido na especificação e representado na arquitetura do software.
Processo de Desenvolvimento de SW
Passos / Atividades
Testes
– Teste de partes do software, especialmente onde tenha sido codificado por mais de uma pessoa da equipe, trabalhando junto, é um papel importante da Engenharia de Software para garantir sua qualidade.
– O método de caixa preta (black Box), também chamado teste funcional, testa o sistema do ponto de vista do usuário, isto é, não considera a estrutura interna ou a forma de implementação do sistema, tendo como objetivo determinar se os requisitos foram total ou parcialmente satisfeitos.
– O método de caixa branca (white Box), por outro lado, procura exercitar todas as partes do código de um sistema.
Processo de Desenvolvimento de SW
Passos / Atividades
Documentação
– A documentação que recebe mais importância é a das interfaces externas, ou seja, da interação com o sistema.
– Uma importante tarefa (frequentemente desprezada) é a documentação do projeto interno do software para facilitar futuras manutenções e aprimoramentos.
Processo de Desenvolvimento de SW
Passos / Atividades
Suporte e Treinamento
– Uma grande parte dos projetos de SW falham porque o desenvolvedor não percebe que não importa quanto tempo a equipe gaste na criação do SW se ninguém usá-lo.
– As pessoas são resistentes à mudança e evitam aventurar-se em áreas pouco familiares.
– Então, como uma parte da fase de desenvolvimento, é muito importante o treinamento, que conduzirá para a próxima fase do software.
Processo de Desenvolvimento de SW
Passos / Atividades
Manutenção
– A manutenção e melhoria de SW lidam com a descoberta de novos problemas e requisitos.
– Pode tomar mais tempo que o gasto no desenvolvimento inicial do software.
– Requer um significativo esforço por parte de um Engenheiro de Software.
– A maior parte da manutenção é para ampliar os sistemas para novas funcionalidades, o que pode ser considerado um novo trabalho.
Processo de Desenvolvimento de SW
Passos / Atividades
Processo de software, ou processo de engenharia de software, é uma sequência coerente de práticas que tem por objetivo o desenvolvimento ou evolução de sistemas de
software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.
Visão geral da engenharia de
software
• De um modo geral, pode-se organizar o
processo de desenvolvimento de um software
a partir de três grandes fases:
– a fase de definição,
– a fase de desenvolvimento e
– a fase de manutenção
Ciclo de Vida do Sistema
O que é um modelo de ciclo de vida
de processo de software?
Uma representação abstrata e simplificada do
processo
de
desenvolvimento
software,
tipicamente
mostrando
as
principais
atividades e dados usados na produção e
manutenção de software
• Qual o propósito de estabelecer um Ciclo
de Vida para o Software?
– Definir que atividades devem ser executadas em
um projeto de desenvolvimento de sistemas
– Introduzir consistência entre vários projetos de
desenvolvimento de sistemas de uma mesma
organização
– Prover pontos de controle para prever,
gerenciar e controlar o desenvolvimento de
sistemas
Ciclo de Vida Clássico
Método sistemático e seqüencial, em que o resultado de uma fase se constitui na entrada da outra fase.
Foi modelado de acordo com o ciclo da engenharia convencional e abrange as seguintes fases:
- Levantamento de Requisitos - Análise de Requisitos - Projeto - Implementação - Testes - Manutenção
Ciclo de Vida Semi-Estruturado
Possui algumas características distintas das do Ciclo de Vida Clássico em relação à fase de Projeto, Implementação e Testes.
Na fase de Projeto, essa foi a primeira vez que se utilizou uma ferramenta de Projeto Estruturado. O principal conceito da fase de Projeto Estruturado é dado pelo conceito de modularização. Um módulo é uma parte do sistema que deve desempenhar uma função específica de maneira que:
– O funcionamento de um módulo deve estar oculto a outros módulos e deve ser dedicado à uma função específica;
– A interface de um módulo deve precisar somente das informações necessárias para que o módulo complete a tarefa.
– A abordagem Bottom-up das fases de Implementação e Testes foi substituída por uma abordagem Top-Down.
Ciclo de Vida Estruturado
O Ciclo de Vida Estruturado marca a utilização efetiva de ferramentas estruturadas de Análise e Projeto.
As ferramentas de Análise Estruturada como o DFD (Diagrama de Fluxo de Dados), dividem o sistema em processos, de forma que cada processo constitui uma função a ser desempenhada pelo sistema.
Ciclo de Vida Orientado a Objeto
Existem cinco fases no desenvolvimento de sistemas de software OO: - Análise de requisitos - Análise - Design (projeto) - Implementação (programação) - Testes
Ciclo de Vida do Projeto
• Define as fases que conectam o início ao fim do
projeto.
• Uma fase pode vir a constituir um projeto:
– Estudo de viabilidade
• A transição entre fases envolve transferência
técnica ou uma entrega.
– Normalmente uma fase só é iniciada quando a entrega
(produto tangível e verificável) da fase anterior estiver
completa, revisada e aprovada – mas a superposição
entre fases pode ocorrer.
Ciclo de Vida do Projeto
• O que definem?
– Que atividades técnicas devem ser executadas
em cada fase;
– Quando as entregas devem ser geradas e
como serão revisadas;
– Quem está envolvido em cada fase
– Como controlar e aprovar cada fase
Fases do Ciclo de Vida
• Deve haver uma revisão ao final das fases
para avaliar a entrega e o desempenho do
projeto:
– Avaliar se o projeto deve continuar na próxima
fase
Interação entre as Fases
•Fase de Projeto
•Fase de Codificação
•Processos de Iniciação •Processos de Execução •Processos de Planejamento •Processos de Controle •Processos de Encerramento •Processos de Iniciação •Processos de Execução •Processos de Planejamento •Processos de Controle •Processos de EncerramentoCaracterísticas do Ciclo de
Vida do Projeto
• Custos e quantidade de pessoas é baixo no início
do projeto, cresce no seu decorrer e volta a
diminuir no final;
• No início os riscos e incertezas são elevadas;
• A influência das partes interessadas é maior no
início do projeto;
Partes Interessadas
• Possuem influência no objetivo, resultados e
ciclo de vida do projeto .
• A influência pode ser positiva ou negativa,
dependendo do benefício ou perda decorrente
do projeto.
• Possuem responsabilidades e autoridade.
• As partes, ou o gerente, ignorar essas
responsabilidades, prejudica o projeto.
Marcos e Pontos de Controle
• Marco - produto final de uma fase.
• Ponto
de
controle
–
produtos
intermediários da fase ou de uma subfase.
• Pontos de controle visam garantir que o
marco será concluído no prazo e qualidade
esperada.
Ciclo de Vida – Projeto e Produto
• São conceitos diferentes
– Projeto – fases do início ao fim do projeto.
– Produto – fases do início ao fim do produto.
• Dificilmente coincidem.
• Em software o projeto normalmente está
associado ao desenvolvimento e não inclui a
operação e manutenção.
Critérios para seleção de um modelo de ciclo de vida
•Critérios relacionados aos usuários / equipe
•Experiência dos usuários no domínio da aplicação.
•Facilidade dos usuários em expressar requisitos.
•Experiência da equipe de desenvolvimento no domínio da aplicação.
•Experiência da equipe de desenvolvimento em engenharia de software.
•Critérios relacionados ao problema
•Grau de maturidade do domínio da aplicação.
•Complexidade do problema.
•Freqüência de mudanças nos requisitos.
•Grau de magnitude das mudanças nos requisitos.
•Grau de modularidade do problema.
•Critérios relacionados ao produto
• Tamanho da aplicação.
•Grau de complexidade da aplicação.
•Grau de importância dos requisitos de interface.
•Critérios relacionados aos recursos
•Disponibilidade de recursos humanos.
•Grau de acesso aos usuários.
•Critérios relacionados ao desenvolvimento
•Aplicável à necessidade de entrega de produtos intermediários.
•Grau dos riscos técnicos.
Modelos de Ciclo de Vida de Software
– Cascata ou Tradicional
– Incremental
– Evolutivo
– Prototipação
– Espiral
– RAD
– Orientado a Reuso
– ...
• Modelo em cascata
– É o modelo mais simples de desenvolvimento de
software
– Cada etapa (fase) realizada, resulta em uma saída
– Estas saídas, obtidas ao final de cada etapa, são
vistas como produtos intermediários e
apresentam-se, normalmente, na forma de documentos
(documento
de
especificação
de
requisitos,
documento de projeto do sistema, etc...).
– Outra característica importante deste modelo é que
as saídas de uma etapa são as entradas da
seguinte, o que significa que uma vez definidas,
elas não devem, em hipótese alguma ser
modificadas.
•Teste
•Engenharia
•de Sistemas
•Análise
•Projeto
•Codificação
•Manutenção
Cascata
• Ciclo de Vida Clássico
• Prevê um processo de desenvolvimento
com etapas sequenciais
• Base: engenharia convencional
• O resultado de cada fase envolve a
elaboração de um ou mais documentos
que são aprovados
Diretivas do modelo cascata
• Duas diretivas importantes que norteiam o
desenvolvimento segundo o modelo cascata,
são:
– todas as etapas definidas no modelo devem ser
realizadas, isto porque, em projetos de grande
complexidade, a realização formal destas vai
determinar o sucesso ou não do desenvolvimento;
a realização informal e implícita de algumas
destas etapas poderia ser feita apenas no caso de
projetos de pequeno porte;
– a ordenação das etapas na forma como foi
apresentada deve ser rigorosamente respeitada;
Fases do Modelo Cascata
Modelo Cascata (Modelo Queda d‟Água)
Engenharia de sistemas
objetivo é ter uma visão global do sistema como um todo (incluindo hardware, software,equipamentos e as pessoas envolvidas) como forma de definir precisamente o papel do software neste contexto.
Análise de requisitos
permite uma clara definição dos requisitos de software, sendo que o resultado será utilizado como referência para as etapas posteriores
Projeto
É um processo de várias etapas. Entre elas: estrutura de dados, arquitetura de software e caracterização da interface
Codificação
O Software deve ser traduzido numa forma legível por máquina (programação)
Teste e Integração
Assim que o código for gerado, inicia-se a fase de testes no programa
Operação e Manutenção
Com toda certeza, o software sofrerá mudanças depois que for entregue ao cliente: erros podem ser encontrados, o software pode precisar de adaptações, podem haver acréscimos funcionais ou de desempenho.
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
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?
Manutenção
• Sw embutido nem sempre tem esta parte.
• Erros encontrados.
• Mudanças no ambiente externo.
• Acréscimos funcionais.
Problemas com a Cascata
• O mais antigo e amplamente usado.
• Para grandes projetos o tempo que decorre desde a
especificação até sua implantação é grande
É difícil para o cliente declarar todas as exigências do software
explicitamente, como o modelo exige. Muitas vezes, nem
mesmo o cliente sabe o que quer ou do que precisa.
• 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.
Problemas com a Cascata
• O Ambiente Externo evolui e é diferente daquele que deu
origem a sua especificação
• Na prática os estágios se sobrepõem
• O processo de software envolve interações
Problemas com a Cascata
Projetos reais raramente seguem o fluxo sequencial proposto
pelo modelo. Por ex.: é possível que haja a necessidade de
retornar à fase de análise de requisitos, estando na fase de
projeto ou codificação
as primeiras versões operacionais do software são obtidas nas
etapas mais tardias do processo, o que na maioria das vezes
inquieta o cliente, uma vez que ele quer ter acesso rápido ao seu
produto.
O processo de desenvolvimento de
software na realidade
Prototipação
• é um modelo de processo de desenvolvimento que busca contornar algumas das limitações existentes no modelo Cascata.
• A idéia por trás deste modelo é eliminar a política de "congelamento" dos requisitos antes do projeto do sistema ou da codificação.
• é um modelo de desenvolvimento interessante para alguns sistemas de grande porte os quais representam um certo grau de dificuldade para exprimir rigorosamente os requisitos;
• através da construção de um protótipo do sistema, é possível demonstrar a viabilidade do sistema.
• é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial.
Prototipação
•Ouvir o
usuário
•Construir o
protótipo
•Usuário
testa o
protótipo
Prototipação
•Coleta e refinamento •dos requisitos •Avaliação do protótipo •pelo cliente •InícioFormas de protótipo
• Protótipo em papel ou modelo executável
– retrata
a
interface
homem
–
máquina,
capacitando o cliente a compreender a forma de
interação com o software
Formas de Protótipo
• Protótipo de trabalho
– Um protótipo funcional, que implementa um
subconjunto dos requisitos indicados
– Não é um sistema completo, e deixa a desejar
em alguns aspectos. Normalmente a interface
com o usuário não é implementada no protótipo.
Evolucionário
• Base
– Desenvolver uma implementação inicial
– Expor o resultado ao comentário do usuário
– Aprimoramento por meio de muitas versões
– Até que o sistema tenha sido totalmente
desenvolvido
• Dois tipos:
– Exploratório
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.
Evolucionário
• Exploratório
– Trabalhar com o cliente
– O desenvolvimento inicia com as partes do sistema que são compreendidas
– O sistema evolui com as novas características propostas pelo cliente
• Protótipos descartáveis
– O protótipo experimenta os requisitos não compreendidos – Neste caso o objetivo é a Especificação de Requisitos
Evolucionário
• Produz sistemas que atendem as necessidades imediatas
do cliente
• Problemas
– O processo não é visível
• Não se produzem documentos que reflitam as versões do sistema
– Frequentemente são mal estruturados
• Software sem estrutura
• Modificações cada vez mais custosas
– Ferramentas e técnicas especiais
• Possibilitam rápido desenvolvimento
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.
Formal
• Transformação formal
– Várias etapas
– Representação mais detalhada, matematicamente correta
• Adequada a sistemas críticos
– Permite verificação automática de consistência – Model checking
• utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições
– Prova de teoremas
• axiomas do comportamento do sistema são empregados para derivar uma prova de que o sistema vai se comportar de uma determinada forma
Formal
• Base: a transformação matemática formal de
uma especificação de sistema em um
programa executável
– A especificação de requisitos é redefinida com uma
linguagem formal
•Especificação de •Requisitos •Especificação •Formal •Transformação •Formal •TestesDesenvolvimento 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.
Orientado a Reuso
• Ampla base de componentes reusáveis
• Infra-estrutura de integração
• Etapas:
– De posse da Especificação de Requisitos,
buscam-se componentes para implementá-la
– Negociação – requisitos são modificados para que
se possa usar os componentes
Orientado a Reuso
•Projeto de Sistema com Reuso •Desenvolviment o e Integração •Modificação de Requisitos •Análise de Componentes •Especificação de Requisitos •Evolução do SistemaDesenvolvimento 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.
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
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.
Modelo Espiral
• O processo de desenvolvimento se move
sobre uma espiral evolucionária
– Melhores características do
• Ciclo de vida clássico
• Evolucionário – Prototipação
• Acrescenta Análise de Riscos
• As fases são executadas de forma iterativa
• As fases de análise e projeto não são
monolíticas e distintas
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
Modelo Espiral
• Planejamento
– objetivos, alternativas e restrições
• Análise de Riscos
– Análise de alternativas e identificação/resolução de riscos – Prototipação pode ser usada
– Simulações e outros modelos podem ser usados para definir melhor o problema
• Desenvolvimento e Validação
– Desenvolvimento do produto no “nível seguinte”
• Avaliação feita pelo Cliente
• Volta ao Planejamento
Iteração de processo
• Existe a necessidade de utilizar diferentes
abordagens para diferentes partes do sistema
• Partes do processo são repetidas enquanto os
requisitos evoluem
• Modelos Híbridos
– Apóiam a iteração do processo
– Desenvolvimento Espiral
Enfoque Incremental
• Uma variação do modelo cascata onde a partir
da fase de especificação de requisitos são
feitos incrementos sucessivos.
• Estratégia para minimizar riscos, obtendo-se
resultados de médio e curto prazo sem se
descuidar do objetivo final
Desenvolvimento Incremental
Em vez de entregar o sistema como um todo, o
desenvolvimento
e
a
entrega
são
divididos
em
incrementos, com cada incremento entregando parte da
funcionalidade requerida
Requisitos dos usuários são priorizados e os requisitos de
mais alta prioridade são incluídos nas iterações iniciais
Uma vez que o desenvolvimento de um incremento é
iniciado, os requisitos são "congelados". Embora os
requisitos possam continuar a evoluir para incrementos
posteriores
Enfoque Incremental
•Requisitos
•Design
•Codificação
•Testes
•Implantação
•Requisitos
•Design
•Codificação
•Testes
•Implantação
•Uma interação
•tempo
Modelos Iterativos
Requisitos de sistema SEMPRE evoluem
durante curso de um projeto. Assim a iteração
do
processo
sempre
faz
parte
do
desenvolvimento de grandes sistemas
Iterações podem ser aplicadas a quaisquer dos
modelos de de ciclo de vida
Duas abordagens (relacionadas)
Desenvolvimento espiral
Desenvolvimento Espiral
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
O processo é representado como uma espiral em vez de uma
sequência de atividades
Cada volta na espiral representa uma fase no processo
Não há fases fixas como especificação ou projeto - voltas na
espiral são escolhidas dependendo do que é requerido
Riscos são avaliados explicitamente e resolvidos ao longo do
Linguagem
Notação com sintaxe e semântica bem
definidas
com representação gráfica ou textual
Usada para descrever os artefatos gerados
durante o desenvolvimento de software
Método
Descrição sistemática de como deve-se realizar
uma determinada atividade ou tarefa
A descrição é normalmente feita através de
padrões e guias
Exemplos: Método para descoberta das classes
Metodologia
Pontos principais
Métodos são formas organizadas de produzir software.
Eles incluem sugestões para o processo a ser seguido, as
notações a serem usadas, regras que governam as
descrições do sistema que são produzidas e diretrizes de
projeto
Ferramentas CASE são sistemas de software que são
projetados para suportar as atividades rotineiras no
processo de software, como edição de diagramas de
projeto e verificação de consistência dos diagramas
Ferramenta CASE
Provê
suporte
computacional
a
um
determinado método ou linguagem
Ambiente de desenvolvimento: conjunto de
ferramentas integradas (CASE)
Nos dias atuais
Entretanto, a Crise do Software perdura até hoje, onde, mesmo com técnicas avançadas de desenvolvimento e padrões consolidados na área de criação de software, ainda existem características da época da Crise, como projetos atrasados, erros de estimativa de custos e de tempo, que tornam o processo, ainda que sistematizado, passível de muitos erros.
