2 ciclo de vida classico3

Prévia do material em texto

CICLO DE VIDA CLÁSSICO
PROF. CRISTINA FILIPAKIS
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
ENGENHARIA DE SISTEMAS
• Primeira etapa do desenvolvimento de um sistema
• Pode ser realizada por um gerente ou analista de sistemas
• Nesta fase, as funcionalidades do sistema são identificadas 
• Começa-se com as metas e restrições do cliente e deriva-se uma ou mais 
soluções 
• Para a escolha da alternativa viável faz-se estudos de viabilidade (técnica, 
financeira, legal) 
ENGENHARIA DE SISTEMAS
• Exemplo de diversas soluções para estoque:
• Um operador é treinado e colocado na classificação, lê a caixa e a 
coloca no depósito adequado.
• Um leitor de código de barras e um controlador são colocados na 
classificação e no armazenamento da caixa.
• Um robô faz a alocação das caixas no depósito.
ENGENHARIA DE SISTEMAS
PERGUNTAS PERTINENTES AO 
DOMÍNIO:
• Quantos nº de identificação devem ser 
processados e qual o formato deles?
• Qual a velocidade da esteira?
• Qual a distância entre os depósitos?
• Existem caixas sem identificação?
• Algum depósito está cheio?
• Algum índice de falhas é permitido?
• Quais são as restrições de custo e prazo?
CONSIDERAÇÕES PARA ESCOLHA 
DA ALTERNATIVA MAIS VIÁVEL:
• O sistema pode ser construído dentro 
do prazo?
• Qual a solução mais lucrativa? Retorno 
x riscos
• Existem tecnologias para o 
desenvolvimento?
• Os componentes (hw, peças) estão 
disponíveis?
• Existe pessoal treinado?
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
ANÁLISE DE REQUISITOS
• Processo de descoberta, refinamento, modelagem e especificação dos 
requisitos
• O escopo do software é refinado
• A qualidade do sistema deve ser avaliada nesta fase
• Problemas: Interpretações errôneas ou ambíguas
ANÁLISE DE REQUISITOS
•Atividades de análise de requisitos:
• Reconhecimento detalhado do problema
• Definição da solução do problema
•Modelagem (diagramas) 
• Revisão
ANÁLISE DE REQUISITOS
•Habilidades do analista
• Compreender conceitos abstratos e reorganizá-los de forma 
lógica
• Absorver informações pertinentes de fontes conflitantes e 
confusas. (cliente/usuários)
• Entender o ambiente do usuário e cliente 
• Desenvolver boa comunicação verbal
ANÁLISE DE REQUISITOS
• Princípios da análise
• O domínio de um problema deve ser representado e compreendido
• O motivo da criação de cada requisito deve ser lembrado
• O problema pode/deve ser dividido em partes
• O processo de análise deve mover-se da informação essencial para um nível mais 
detalhado (dos modelos de alto nível para os de baixo nível)
• Os requisitos devem ser priorizados pelos usuários
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
PROJETO DE SOFTWARE
• Cada um dos artefatos da análise fornece subsídios para a criação de um modelo 
de projeto
• Os artefatos do projeto possuem um nível mais baixo de abstração
• O projeto deve representar todos os requisitos explícitos (requisitos funcionais) 
contidos na análise de requisitos e os requisitos implícitos (atributos e requisitos não-
funcionais) desejados pelo cliente e/ou necessários para o sistema
• O projeto deve ser legível pelos implementadores, testadores...
• O projeto deve ser uniforme e suportar mudanças
• Projeto é DIFERENTE de codificação!
PROJETO DE SOFTWARE
• Conceitos de projeto
• Coesão: relação entre os métodos de uma classe. É desejável a alta 
coesão!
• Acoplamento: ligação entre classes e módulos do sistema. É desejável um 
baixo acoplamento!
• Ocultamento de informações: proteção das informações do sistema. Ex: 
descritores - public, private, protect.
• Independência Funcional: em relação aos módulos, as partes precisam 
funcionar de maneira autossuficiente.
EXEMPLOS DE DIAGRAMAS UML
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE SEQUÊNCIA
DIAGRAMA DE CLASSES
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
TESTES DE SOFTWARE
• A atividade de testes é um elemento crítico da Qualidade de Software, pois 
representa uma última revisão dos artefatos produzidos no desenvolvimento 
do software
• Testar é o processo de verificação de documentos e diagramas e de 
execução do código COM a intenção de descobrir erros
• Um bom caso de teste é aquele que tem uma boa probabilidade de 
encontrar erros ainda não descobertos.
• A atividade de teste não pode mostrar simplesmente a ausência de erros
TESTES DE SOFTWARE
• Se os testes forem bem sucedidos:
• Serão descobertos erros OU os artefatos parecem estar corretos
• Se os erros graves forem encontrados regularmente, a qualidade 
do processo e/ou do produto é suspeita.
• Se os artefatos estiverem corretos, conforme os testes:
• a qualidade é aceitável OU os testes já não são mais eficientes
TESTES DE SOFTWARE
• Etapas:
• Planejamento
• Construção
• Implementação (no caso dos testes automatizados)
• Execução
• Análise dos resultados
TESTES DE SOFTWARE
• Testes progressivos: primeira execução de um caso de teste
• Testes regressivos: re-execução dos casos de testes
• Teste de verificação: testes executados na documentação e no código como 
documento
• Teste de validação: testes aplicados no código em execução
• Teste de unidade
• Teste de integração
• Teste de sistema
• Teste de aceite: alpha teste, beta teste e aceite formal
TESTE DO CAMINHO BÁSICO
• Calcula uma medida de 
complexidade para o programa 
testado, chamada Complexidade 
Ciclomática – CC
• Define o número de entradas, com 
seus respectivos valores, que deve 
ser executado para se testar todas 
as decisões lógicas do programa.
• Fórmulas para calcular a CC:
• CC = nº de regiões
• CC = nº ramos – nº nós + 2
• CC = nº nós predicativos + 1
• Passos do teste
• Numerar o programa
• Desenhar o grafo
• Calcular o CC
• Definir os caminhos básicos
• Definir os conjuntos de entradas
CICLO DE VIDA CLÁSSICO
Engenharia 
de Sistemas
Análise de 
Requisitos
Projeto de 
Software
Codificação
Testes
Manutenção
MANUTENÇÃO
• Tarefa executada após a entrega do sistema.
• Deve-se adotar uma política de manutenção.
• Pode envolver correções de erros, adaptação à novas plataformas, sistemas 
operacionais (SO), hardwares e usuários, adição de novas funcionalidades e 
melhoria de funcionalidades.
“Para adaptar, aperfeiçoar e corrigir deve-se modificar a 
documentação antes de alterar o código. O que foi 
modificado deve ser retestado”.
MANUTENÇÃO
• Tipos de Manutenção
• Corretiva: correção de erros já “descobertos” pelo cliente.
• Adaptativa: adaptação do sistema à uma nova realidade – novo 
hardware, SO, novos requisitos.
• Perfectiva: executada em softwares bem sucedidos quando há a 
necessidade de se alterar algum requisito visando melhoria de 
desempenho.
• Preventiva: software modificado para evitar a ocorrência de erros.
MANUTENÇÃO
MANUTENÇÃO NÃO -ESTRUTURADA
• Único elemento disponível é o 
código. 
• Penosa avaliação do código.
• Documentação do código ruim 
ou inexistente.
• Mudanças difíceis de serem 
avaliadas.
• Ausência de testes de regressão
MANUTENÇÃO ESTRUTURADA
• Documentaçãodo software 
completa.
• Avalia-se o impacto da 
modificação.
• Modelagem é modificada.
• Código é gerado.
• Executa-se teste de regressão.
• Software é liberado.
MANUTENÇÃO
• Engenharia Reversa
• Processo de analisar um 
programa num esforço de criar 
uma representação do 
programa em um nível de 
abstração mais alto do que o 
código fonte
• Reengenharia
• Utilização das informações 
recuperadas de um sistema 
para alterar ou reconstruir o 
sistema
Código
Engenharia 
Reversa
Documentação + 
código
Reengenharia
Sistema 
melhorado