Modelos de Desenvolvimento de Software: Incremental, Reuso e Espiral - Fundamentos da Engenharia de Software

FUNDAMENTOS DE ENGENHARIA DE SOFTWARE Prof Douglas Lopes Farias DESENVOLVIMENTO INCREMENTAL É baseado na ideia de desenvolver uma implementação inicial do software entregar aos clientes e receber feedbacks para melhorias até chegar ao sistema final adequado No modelo espiral diversas versões do sistema são criadas até que todas as necessidades tenham sido atendidas As atividades de especificação desenvolvimento e validação são intercaladas e não separadas com opinião dos clientes entre elas SOMMERVILLE 2011 DESENVOLVIMENTO INCREMENTAL Atividade simultâneas Descrição do esboço Especificação Desenvolvimento Validação Versão inicial Versões intermediárias Versão final MODELO ORIENTADO A REÚSO É normal que em qualquer desenvolvimento do software mesmo que informalmente ocorra reuso Enquanto o sistema esta sendo desenvolvido o programador observa semelhança com algo já existente e incorpore ao projeto com as devidas alterações Esse reuso informal ocorre independentemente do processo de desenvolvimento usado SOMMERVILLE 2011 MODELO ORIENTADO A REÚSO Especificação de requisitos Análise de componentes Alterações nos requisitos Projeto de sistema com reuso Desenvolvimento e integração Validação de sistema MODELO ORIENTADO A REÚSO 1 Análise de Componentes os requisitos são levantados e a partir deles é feita uma busca nos componentes de alguma funcionalidade em comum para implementar essa especificação 2 Modificação de Requisitos os requisitos são analisados usando informações sobre os componentes selecionados Em seguida eles são modificados para refletir os componentes disponíveis 3 Projeto do sistema com reuso o framework do sistema é projetado ou algo existente é reusado Alguns softwares novos podem ser necessários se componentes reusáveis não estiverem disponíveis 4 Desenvolvimento e integração softwares que não podem ser adquiridos externamente são desenvolvidos e os componentes são integrados para compor o novo sistema MODELO ESPIRAL O modelo espiral foi proposto por Boehm em 1998 ao contrário do modelo cascata o espiral não é uma sequência de atividades com retornos de umas para outras MODELO ESPIRAL Essas voltas são divididas em quatro setores que são explicados a seguir conforme Sommerville 2011 1 Definição de objetivos os objetivos específicos são definidos restrições ao processo e ao produto são identificadas os riscos do projeto são levantados e um plano de gerenciamento é elaborado 2 Avaliação e redução de riscos para cada risco identificado uma análise detalhada é feita e as mediadas para a redução desse risco são tomadas resolvendoos por meio de atividade de coleta de informações como analise mais detalhada prototipação e simulação 3 Desenvolvimento e validação um plano para desenvolvimento do sistema é selecionado depois de avaliado os riscos existente 4 Planejamento o projeto é revisado e uma decisão é tomada a respeito da continuidade do modelo com mais uma volta da espiral caso se decida pela continuidade planos são elaborados para as próximas fases do projeto MODELO ESPIRAL Determinar objetivos alternativas e restrições Avaliar alternativas identificar resolver riscos Análise de riscos Análise de riscos Análise de riscos Protótipo obrigatório Protótipo 3 Protótipo 2 Protótipo 1 REVISÃO Simulações modelos benchmarks Plano de requisitos Plano de ciclo de vida Conceito de operação Requisitos de SW Projeto de produto Projeto detalhado Código Plano de desenvolvimento Validação de requisitos Teste unitário Plano de integração e testes Projeto VV Teste de integração Teste de aceitação Operação Desenvolver e verificar próximo nível do produto Planejar próxima fase Processo Unificado Pressman No início dos anos 90 três amigos Ivar Jacobson James Rambaugh e Grady Booch começaram a trabalhar em torno de um método unificado O resultado foi a UML será estudada no Capítulo 5 MÉTODOS ÁGEIS Os conceitos existentes atualmente sobre métodos ágeis nasceram em meados dos anos 90 motivados pela adversidade aos chamados métodos pesados de desenvolvimento de software caracterizado por extensa documentação e demasiado formalismo sendo normalmente o modelo cascata Em 2001 um encontro realizado por 17 especialistas que já trabalhavam com os métodos leves marcou definitivamente o surgimento e propagação de paradigmas de desenvolvimento de software ágil O objetivo do encontro era trocar ideias do que estavam fazendo e discutir maneiras de melhorar o desempenho de seus projetos SBROCCO e MACEDO 2012 Durante a reunião eles perceberam que apesar de cada um usar uma prática diferente todos concordaram que havia um conjunto de princípios básicos que todos seguiam em projetos bem sucedidos Por isso decidiram redigir um documento intitulado Manifesto Ágil assinado por todos os presentes SBROCCO MACEDO 2012 eXtreme Programming XP É considerada uma metodologia ágil porque se adéqua bem à pequenas ou medias equipe de desenvolvimento de software em que os projetos são conduzidos com requisitos que não foram bem definidos e que mudam rapidamente Algumas características marcantes segundo Sbrocco e Macedo 2012 e Sommerville 2011 são Feedback constante Abordagem incremental com pequenos e frequentes releases do sistema Encoraja a comunicação entre as pessoas envolvidas com o engajamento contínuo do cliente com a equipe de desenvolvimento A manutenção da simplicidade é feita por meio da refatoração constante que melhora a qualidade do código e por meio de projetos simples eXtreme Programming XP Selecionar estórias do usuário para este release Dividir estórias em tarefas Planejar release Desenvolver integrar testar software Liberar software Avaliar sistema SCRUM Foi influenciada por pratica da indústria japonesa principalmente da manufatura implementada pela Honda e Toyota A terminologia SCRUM foi adotada por influência de uma formação do jogo de rugby em que o jogo é reiniciado por algum incidente ou quando a bola sai de campo SCRUM Características Product backlog Sprint backlog Daily scrum meeting 24 hours 24 weeks Potentially shippable product increment Ciclo Scrum SCRUM NÃO INICIADO INICIADO PRONTO O OBJETIVO DO SPRINT RELEASE BETA DEPOSITO BURNDOWN ITENS NÃO PLANEJADOS DEPOIS FERRAMENTA MIGRAÇÃO LOGIN BACKOFFICE USER ADMIN BACKOFFICE Implementar migração 8d Spec de GUI 2d Spike como Tapestry 3d 2d 05d Design 3D 2d Implam GUI 1d Enviar com J Regras 1d Design GUI CSS 1d Escrever teste que falha 3d Escrever teste que falha 2d Suporta a venha 3d Escrever whitepaper 4d SAQUE Escrever teste que falha 125d Saclencar requisitos 2d Implm GUI 6d Escrever teste que falha 3d Escrever teste que falha uningá Ensino a Distância EAD wwwuningabr A Melhor Formação