ES Aula 07

Prévia do material em texto

Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
1 
 
MODELO – ESPIRAL 
• Foi desenvolvido para abranger as melhores características tanto do ciclo de vida 
clássico (cascata) como da prototipação; 
• Acrescenta: Análise de Riscos 
• O modelo é dividido em 4 (quatro quadrantes) 
1. Planejamento 
2. Análise de Riscos 
3. Engenharia 
4. Avaliação do Cliente 
• É uma abordagem mais realística para o desenvolvimento de sistemas e de software 
em grande escala; 
• Usa uma abordagem evolucionária, o produto vai sendo desenvolvido e avaliado 
durante o processo; 
• A cada ciclo é feita a análise de riscos e, dependendo do resultado da análise pode-se 
optar por não desenvolver algo no produto ou mesmo interromper o 
desenvolvimento; 
• A prototipação é usada como mecanismo para redução de riscos; 
• O modelo espiral exige experiência na avaliação dos riscos; um grande risco não 
descoberto fatalmente irá gerar problemas; 
• O modelo ajuda a envolver o cliente na avaliação e apresentação de sugestões durante 
o projeto; o cliente envolve-se com o projeto e ajuda a minimizar os riscos no 
desenvolvimento. 
Durante o ciclo do projeto, são executadas atividades de cada quadrante: 
1. Planejamento: determinação dos objetivos, alternativas e restrições; 
2. Análise dos Riscos: análise de alternativas e identificação ou resolução dos riscos; 
• Decisão de continuar ou não 
3. Engenharia: elaborar a definição das entidades, construção de protótipos, produzir o 
software; 
4. Avaliação do Cliente: o cliente avalia o trabalho produzido; 
Volta ao passo 1 baseado na avaliação e sugestões do cliente. 
 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
2 
 
MODELO – INCREMENTAL 
 
• Combina o modelo Cascata de maneira interativa; 
• Ao final de cada incremento tem-se um produto operacional final, exemplo: 
• Incremento 1: Módulo – Estoque; 
• Incremento 2: Módulo – Compra; 
• Incremento 3: Módulo – Venda; 
• Incremento 4: Módulo – Faturamento; 
Tende a diminuir a ansiedade do cliente a cada incremento. 
 
MODELO – RAD Rapid Application Development 
 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
3 
 
 
• Semelhante ao modelo CASCATA; 
• Visa entregar o sistema completo de 60 a 90 dias; 
• Múltiplas equipes trabalham em paralelo na modelagem e construção; 
• Considera a existência de componentes reutilizáveis e geração de código; 
• Difícil de ser utilizado em domínios novos ou instáveis, ou seja, a equipe não tem 
afinidade com as regras de negócio ou as regras para o sistema solicitado não estão 
bem definidas. 
 
MODELO – RUP (Rational Unified Process) 
• Usa a abordagem da orientação a objetos em sua concepção; 
• É projetado e documentado utilizando a notação UML (Unified Modeling Language) 
para ilustrar os processos em ação; 
• Utiliza técnicas e práticas aprovadas comercialmente; 
• É um processo considerado pesado e preferencialmente aplicável a grandes equipes de 
desenvolvimento. 
 
MODELO - PRAXIS 
• Praxis 
• Baseado nos modelos RUP (principal referência), TSP e PSP 
• Tem enfoque educacional, com o objetivo de dar suporte ao treinamento em 
Engenharia de Software e à implantação de processos em organizações que 
desenvolvem, mantêm ou contratam software. 
 
MODELO - CLEANROOM 
• Cleanroom (Sala Limpa) 
• Baseado no projeto apurado das funções, que são analisadas pelo método de 
revisão-par com o objetivo de verificar se fazem realmente o que foram 
especificadas a fazer; 
• Remove a necessidade de depuração do programa, assegurando que os erros 
nunca começam introduzidos no sistema; 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
4 
 
• Difundida no desenvolvimento de grandes projetos corporativos. 
 
MODELO - ICONIX 
• Iconix 
• Processo de desenvolvimento de software baseado no RUP 
• Usa um número reduzido de artefatos e checkpoints; 
• Apresenta como uma metodologia prática, simples, intermediária entre a 
complexidade do RUP (Rational Unified Process) e a simplicidade do XP 
(Extreme Programming); 
• Poderosa para guiar a análise e projeto orientado a objetos; 
 
PSP – Personal Software Process 
O modelo PSP, um método que busca a melhoria da qualidade do trabalho do Engenheiro de 
Software, através da definição precisa e qualitativa de um processo pessoal. 
• O propósito é ajudar ao Engenheiro de Software a realizar um trabalho melhor; 
• É uma ferramenta que pode ser utilizada de muitas formas: 
• Administrar o trabalho; 
• Avaliar o próprio talento; 
• Construir habilidades; 
• Planejar; 
• Descobrir precisamente o próprio desempenho; 
• Medir a qualidade dos produtos. 
• É uma estrutura de formulários, diretrizes e procedimentos para o desenvolvimento 
de software; 
• Provê dados históricos; 
• Torna os elementos rotineiros mais previsíveis e eficientes. 
• O PSP é derivado do CMM; 
• Como no CMM, existem os níveis de maturidade dos processos; 
• São 5 (cinco) níveis de maturidade, onde o 1 é o nível inicial. 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
5 
 
• Níveis: 
1. Inicial – processo “ad hoc” ou caótico ocasionalmente; poucos processos estão 
definidos e o sucesso depende do esforço individual; 
2. Repetível – são estabelecidos processos básicos de administração de projetos 
para identificar custos, horários e funcionalidades. 
3. Definido – o processo de software, para a administração e para as atividades 
da Engenharia é documentado, unificado e integrado em um processo de 
software padrão. Todos os projetos usam uma versão aprovada do processo 
padrão para desenvolver e manter o software. 
4. Administrado – são coletadas medidas detalhadas do processo e qualidade do 
produto. O processo de software e os produtos são quantitativamente 
compreendidos e controlados. 
5. Aperfeiçoado – melhoria contínua do processo através de avaliação 
quantitativa do processo e da condução de ideias e tecnologias inovadoras. 
• Para o PSP os níveis de definições e as suas práticas foram refinados; a cada nível as 
(KPA – Key Process Area) possuem metas e exemplos práticos; 
• Alguns itens do CMM são excluídos por não estarem adequados ao nível individual 
(personal) 
 
O PSP suporta, em escala individual, 12 das 18 KPAs do modelo CMM; 
 
 
 
 
 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
6 
 
• Tem como objetivo principal criar uma equipe de projetos autodirigida (que se 
organiza por si mesma para produzir software de alta qualidade); 
• Também visa os seguintes objetivos: 
1. Mostrar aos gerentes como: treinar, motivar e ajudar suas equipes a manter 
alto desempenho; 
2. Acelerar o aperfeiçoamento dos processos de software; 
3. Fornecer orientação para melhorias a organizações; 
4. Facilitar o ensino de habilidades de trabalho em equipe de nível industrial. 
 
TSP – Team Software Process 
• O TSP define as seguintes atividades: 
1. Lançamento do Projeto 
2. Projeto de Alto Nível 
3. Implementação 
4. Integração e Testes 
5. Autópsia 
• As atividades capacitam a equipe a planejar, projetar e construir software de maneira 
disciplinada; 
• Também é possível medir quantitativamente o processo e o produto; 
• A autópsia representa o estágio para melhoria dos processos. 
• O processo faz uso de uma grande variedade de: 
1. Roteiros (scripts); 
2. Formulários; 
3. Padrões que servem para orientar os membros da equipe; 
• Os roteiros definem atividades de processos específicos (lançamento do projeto, 
projeto, implementação, etc) 
• A equipe deve se comprometer com oprocesso e passar por treinamento consistente. 
 
 
mailto:prof.rikaluz@gmail.com
Disciplina Engenharia de Software Turmas: ADS 
Prof. Rika Luz prof.rikaluz@gmail.com Aula 07 
 
7 
 
TSP – Pontos Fortes 
• Formação de uma equipe coesa, que busca um objetivo comum; 
• Suas práticas melhoram o gerenciamento do projeto; 
• Completamente alinhado com o CMM, funcionando como “catalisador” 
TSP – Pontos Fracos 
• Requer treinamento prévio em Personal Software Process (PSP) 
• Não possui modelos de documentos; 
• Não entra em detalhes sobre a execução das atividades. 
 
mailto:prof.rikaluz@gmail.com