ProcessosDesenvSoft_01

Prévia do material em texto

1 
Sistemas de Informação Automatizados 
Sistemas Batch 
 
Sistemas On-Line 
 
Sistemas em Tempo Real 
 
Sistemas de Apoio à Decisão 
 
Sistemas Baseados no Conhecimento 
 
2 
O que é uma metodologia ? 
3 
O que é uma metodologia ? 
Consiste em uma definição de etapas e modelos 
padronizados, que orientam e ordenam o trabalho 
do analista de sistemas ao longo do processo de 
desenvolvimento de sistemas. 
 
Uma boa metodologia deve definir o processo de 
desenvolvimento, possuir modelos para representar 
abstrações e diretivas para orientação do trabalho. 
4 
Benefícios de Utilização de Metodologias 
Dá transparência ao desenvolvimento; 
 
Provê condições de gerenciamento; 
 
Permite uniformidade de abordagem; 
 
Permite mobilidade de pessoal técnico; 
 
Facilita o controle de qualidade; 
 
Facilita maior aderência aos requisitos; 
5 
Uma metodologia de desenvolvimento de 
software possui de uma maneira geral os 
seguintes ingredientes: 
Fases, tarefas e passos do desenvolvimento; 
 
Técnicas; 
 
Ferramentas (diagramas e softwares utilizados); 
 
Produtos; 
 
Pontos e mecanismos de controle; 
 
Métricas (esquemas de mensuração); 
 
Responsabilidades; 
 
Integração com ferramentas CASE. 
6 
Ciclo de vida de Projetos de Software 
 
Modelo em Cascata (Waterfall) - Ciclo de Vida 
 Clássico - tradicional e com retroalimentação; 
Modelo Iterativo; 
Modelo Incremental; 
Modelo Espiral; 
Prototipação; 
Técnicas de Quarta Geração. 
7 
CONTEXTO 
 Anos: 70/80 
 Antes: Não era usado nenhum processo 
de desenvolvimento. 
 Programadores baseavam-se nas próprias 
experiências. 
Não havia forma definida e estruturada 
Não haviam testes e os erros eram 
corrigidos após sistema implantado. 
8 
 Modelo Balburdia 
 2 fases: Implementação & Correção 
 Modelo Codifica-remenda 
 Similar ao balburdia 
 Surge a idéia de necessidades após implantação, pois 
os sistemas tornavam-se maiores. 
MODELOS INICIAIS 
9 
 1º. Modelo em Engenharia de Software 
 Linear  cada atividade tem que ser concluída 
antes de iniciar a próxima. 
 Util: pequenos projetos 
 Importância: base para outros modelos. 
 Característica: usada até hoje. 
MODELO CASCATA 
10 
Estudo de Viabilidade 
Análise 
Projeto 
Implementação 
Geração do Teste de 
Aceite 
 Garantia da Qualidade 
Descrição de 
Procedimento 
Conversão de Banco de 
Dados 
Instalação 
1ª fase 
9ª fase 
Estudo de Viabilidade 
Análise 
Projeto 
Implementação 
Geração do Teste de 
Aceite 
 Garantia da Qualidade 
Descrição de 
Procedimento 
Conversão de Banco de 
Dados 
Instalação 
1ª fase 
9ª fase 
Modelo em Cascata (apresentado por YOURDON) 
11 
MODELO CASCATA 
Requisitos 
Testes 
Desenho 
Implementação 
Análise 
Manutenção Implantação 
12 
MODELO CASCATA 
Requisitos 
Testes 
Desenho 
Implementação 
Análise 
 D O C U M E N T A Ç Ã O 
13 
 Vantagem 
 Permite pontos de controle bem definidos  
facilita gestão do projeto 
 Requer documentação todas as fases. 
 Em tese  só avança se cliente Valida fase atual  
Participação do usuário 
 Simples de implementar e gerir. 
MODELO CASCATA 
14 
 Todos os requisitos devem ser descobertos no início -
- > não prevê alteração nos requisitos 
 Projeto raramente seguem fluxo seqüencial  
iterações (vários ciclos) são necessárias. 
 Não prevê manutenção. 
 Baixa visibilidade ao usuário só vê os resultados ao 
final 
 Dificulta visão de reutilização. 
 Se ocorrer atraso , todo o processo é afetado; 
 Só gestor tem visão do todo. 
MODELO CASCATA - DESVANTAGENS 
15 
 Variante “cascata tradicional” que permite a 
realimentação, ou seja, correções que surgirem 
durante outras fases do processo. 
 Modelo que permite a revisão de fases anteriores e a 
superposição entre as fases. 
 Porem o custo dessa revisão pode ser alto, 
dependendo da fase atual e do quanto se precisa 
retroceder 
CASCATA C/RETROALIMENTAÇÃO 
16 
CASCATA C/RETROALIMENTAÇÃO 
Requisitos 
Testes 
Desenho 
Implementação 
Análise 
Manutenção Implantação 
17 
Vantagem 
Possibilita a correção de erros nas 
fase(s) anterior(es), durante o 
processo de desenvolvimento. 
Prevê manutenção 
CASCATA C/RETROALIMENTAÇÃO 
18 
19 
 Seleção de uma parte do projeto 
 Identifica, especifica, implementa, testa e implanta 
a iteração 
 Se atender as especificações, passa-se a próxima 
iteração. 
PROCESSO ITERATIVO 
20 
PROCESSO ITERATIVO 
21 
 Modelo que se baseia na idéia de aumento do 
âmbito do sistema 
 Ou seja, na criação de novas versões para o modelo 
proposto. 
PROCESSO INCREMENTAL 
22 
PROCESSO INCREMENTAL 
23 
 Processo de desenvolvimento de software que 
define: 
 um subconjunto de requisitos e 
 utiliza o modelo em cascata para sua realização. 
 Cada porção do ciclo segue o projeto de arquitetura 
inicial como guia, mas com uma abordagem bem 
menor. 
 Uma vez satisfeitos os requisitos e os objetivos da 
iteração forem completos, o desenvolvimento segue 
para a próxima iteração. 
MODELO ITERATIVO E INCREMENTAL 
24 
MODELO ITERATIVO E INCREMENTAL 
25 
 O Modelo espiral se assemelha com a propotipação, 
mas inclui um fator: a análise de risco. 
 Funciona de forma iterativa, incremental, mas com 
uma etapa onde pode ser tomada a decisão de se 
interromper ou não o processo. 
MODELO: ESPIRAL 
26 
Planejamento 
 
 
 
 
 
 
 
 
Engenharia 
Análise dos 
riscos 
 
 
 
 
 
 
 
 
Avaliação do 
cliente 
Coleta inicial dos 
requisitos e 
planejamento do 
projeto 
Planejamento 
baseado nos 
comentários do 
cliente 
Avaliação do 
cliente 
Decisão de 
prosseguir/não 
prosseguir 
Na direção de 
um sistema 
concluído 
Protótipo de 
software inicial 
Sistema 
construído pela 
engenharia 
Análise dos 
riscos baseada 
na reação do 
cliente 
Espiral 
27 
 Cada volta da espiral representa uma fase do 
processo: 
 Definição dos objetivos - Especificação dos objetivos 
específicos da fase; 
 Análise dos riscos - Identificação e solução dos principais 
riscos 
 Desenvolvimento e validação; 
 Planejamento - O projeto é revisto e são definidos os 
planos para a próxima “volta da espiral”. 
 
MODELO: ESPIRAL 
28 
 Não há fases fixas como especificação e desenho - as 
voltas na espiral são determinadas pelo que é requerido. 
 Riscos são explicitamente avaliados e resolvidos no 
processo 
 Engloba as melhores características do ciclo de vida 
Clássico e da Prototipação, adicionando um novo 
elemento: a ANÁLISE DOS RISCOS. 
 Usa a Prototipação, em qualquer etapa da evolução do 
produto, como mecanismo de redução de riscos. 
MODELO: ESPIRAL 
29 
 Criação de um modelo para ser analisado e 
desenvolvido a partir do protótipo 
 O Analista coletará informações para um mini 
projeto, concentrando-se nas entradas e saídas do 
software. 
 Após a criação e aceitação do protótipo, o produto 
final será desenvolvido. 
 O protótipo serve como mecanismo para 
identificar os requisitos 
MODELO: PROTOTIPAÇÃO 
30 
 Tipos de protótipo: 
 em papel ou sistema: retratam a interface e interação 
 em sistema, implementando algumas funções 
 Quando usar? 
 O cliente definiu um conjunto de objetivos geraispara 
o software, mas não identificou requisitos de entrada, 
processamento e saída com detalhes 
 O desenvolvedor não tem certeza da eficiência de um 
algoritmo ou forma da interação. 
MODELO: PROTOTIPAÇÃO 
31 
MODELO: PROTOTIPAÇÃO 
32 
 1- OBTENÇÃO DOS REQUISITOS 
 O desenvolvedor e o cliente definem os objetivos gerais do 
software, identificam quais requisitos são conhecidos e as 
áreas que necessitam de definições adicionais. 
 2- PROJETO RÁPIDO 
 É a representação dos aspectos do software que são visíveis 
ao usuário (entrada e formatos de saída). 
 3- CONSTRUÇÃO PROTÓTIPO 
 É a implementação do projeto rápido. Serve como o 
“primeiro sistema” - recomendado que não seja usado 
como produto final. 
MODELO: PROTOTIPAÇÃO 
33 
 4- AVALIAÇÃO DO PROTÓTIPO 
 Cliente e desenvolvedor avaliam o protótipo. 
 5- REFINAMENTO DOS REQUISITOS: 
 Com base na avaliação, refinam o produto 
 Ocorre neste ponto um processo de iteração que pode 
conduzir à atividade 1 até que as necessidades do cliente 
sejam satisfeitas e o desenvolvedor compreenda o que 
precisa ser feito. 
 6- CONSTRUÇÃO PRODUTO: 
 A versão de produção deve ser construída considerando os 
critérios de qualidade. 
 Protótipo deve ser descartado 
MODELO: PROTOTIPAÇÃO 
Obtenção dos 
Requisitos 
Estratégia de 
“projeto” 
Implementação usando 
4GL 
Testes 
 
Técnicas de Quarta Geração 
34 
MANUTENÇÃO 
 Fase que tem: 
 Início: quando o sistema é instalado no 
ambiente do usuário, para uso. 
 Fim: quando o sistema torna-se obsoleto e é 
substituído. 
 Motivos da obsolescência: 
 Tecnologia ultrapassada 
 Custo de manutenção supera benefícios 
35 
 Suporte ao uso do sistema 
 Manuais, Help desk, visitas, treinamento 
 Desenvolvimento 
 Correção de erros (início)  ausência ou má qualidade 
dos testes 
 Melhorias nas funções existentes 
 Implementação de novas funções 
ATIVIDADES DA MANUTENÇÃO 
36 
ATIVIDADES DA MANUTENÇÃO 
 Melhorias nas funções existentes 
 Comum: efeito dominó  arquitetura inadequada 
 Soluções 
 Separação estática: identificar foco 
 Refatoração: modificação da estrutura do 
software, sem alterar o comportamento. 
37 
 Tipo de Aplicação 
 Rotatividade e disponibilidade-Pessoal 
 Duração da vida útil 
 Ambiente que se modifica 
 Características do hardware 
 Qualidade do projeto, do código, da documentação e dos 
testes 
AFETAM O CUSTO DA MANUTENÇÃO 
38 
AFETAM O TEMPO DA MANUTENÇÃO 
 O tempo da manutenção define o tempo de vida. 
 Atentar para o custo. 
 Elementos altamente coesos 
 Elementos com baixo acoplamento 
 Documentação completa e atualizada 
39 
 Cuidado com as novas versões 
 Causam instabilidade no ambiente 
 Ideal: 
 menos intervenção possível 
 acumular demandas que justifiquem a 
intervenção 
 tratar as demandas como um projeto 
 Dificuldade: controle das versões. 
MANUTENÇÃO COMO PROJETO 
40 
 Documento de demandas dos usuários 
 Data, Pedido, Tipo 
 Tipo 
 emergencial (imediato) 
 melhoria e nova função (analisar) 
COMO ACUMULAR DEMANDAS 
41 
 Manual do usuário 
 Linguagem clara e adequado ao perfil 
 Mostrar como o usuário usa as funcionalidades 
 Manual do Sistema 
 Introdução (visão de uso) 
 Funcionalidades 
 Pré-requisitos para funcionar 
DOCUMENTAÇÃO PARA SUPORTE 
42 
 Manual do Sistema 
 Referência 
 Facilidades do uso do sistema 
 Erros que podem ocorrer e como agir 
 Instalação 
 como instalar o sistema, plataformas de operação, 
pré-requisitos necessários. 
 
DOCUMENTAÇÃO PARA SUPORTE 
43 
 Possibilitar que a equipe entenda o que foi pensado e 
as soluções dadas. 
 Possibilitar que as alterações e novas funções 
possam ser documentadas. 
 Tipo de documentação: textual e modelos 
(diagramas). 
 Ferramenta CASE ajuda a manter a documentação 
VIVA e atualizada. 
DOCUMENTAÇÃO PARA MANUTENÇÃO 
44 
 Documentação do software 
 Descreve as partes do código fonte, requisitos necessários, 
arquitetura do sistema. 
 Bastante útil para o desenvolvedor no processo de 
melhoria ou correção do produto. 
 
DOCUMENTAÇÃO PARA MANUTENÇÃO 
45 
 Cronogramas 
 Acompanhar o andamento 
 Relatórios 
 Documentar acompanhamento de recursos 
 Documentos técnicos 
 Descrever as estratégias, problemas, limitações e idéias; 
 As decisões o que motivou as decisões 
DOCUMENTAÇÃO DO PROCESSO 
46