Baixe o app para aproveitar ainda mais
Prévia do material em texto
Modelos de Ciclo de Vida de Software ANÁLISE E PROJETO DE SISTEMAS 1 Retomando: Por que apenas codificar não é suficiente? 2 3 A engenharia de software representa uma abordagem sistemática que visa o desenvolvimento efetivo e eficiente de software guiado por restrições claras, usando técnicas e ferramentas e seguindo um processo. Portanto… a Engenharia de Software é necessária! Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Fases da Engenharia de Software 5 Engenharia de Requisitos Análise e Projeto Implementação Verificação e ValidaçãoManutenção É o processo de definir as necessidades dos stakeholders que necessitam ser atendidas pelo software Engenharia de Requisitos 6 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Engenharia de Requisitos 7 Por que esta fase é tão importante? Basicamente pelo custo da correção Custo&rela+vo¶&corrigir&erros:&Quando& introduzidos&vs.&quando&corrigidos& 100# 2.5# 5# 10# 25# .5#'#1# Requisitos# Design# Codificação# Teste#Unitário# Aceite# Manutenção# Estágio# Boehm&1988& Taxa&média&do&custo&14:1& Grady&1989& A Regra 1-10-100 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Engenharia de Requisitos 8 Gerenciamento+ Especificação,(3)+ Análise,(2)+ Elicitação+(1)+ Validação,,(4)+ É o processo no qual os requisitos são analisados para produzir uma descrição da estrutura interna e da organização do sistema, servindo como base para sua construção. Análise e Projeto 9 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Análise e Projeto 10 Projeto Arquitetural Especificação Abstrata Projeto de Interface Projeto de Componentes Estrutura de Dados Projeto de Algoritmos Atividades de Análise e Projeto Alto nível de abstração Baixo nível de abstração Estrutura do Sistema Especificação do Software Especificação da Interface Especificação de Compon. Especif. da Estr. de Dados Especificação de Algoritmos É o processo de realizar o modelo gerado pela análise e projeto e efetivamente criando o sistema software. Implementação 11 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Implementação •Há Quatro Princípios que afetam a forma que o software é construído: • Redução da complexidade: visa construir software que é fácil de compreender e usar • Antecipação da diversidade: a construção do software pode mudar muito ao longo do tempo, isto significa, ele vai evoluir de maneira inesperada. Neste caso, devemos antecipar algumas dessas mudanças • Estruturação da validação: ou projeto para testabilidade, devemos desenvolver software que seja fácil para testar • Obedeça padrões externos e internos: o software deve obedecer padrões corporativos e industriais de desenvolvimento. 12 É o processo de avaliar se o software atende a sua especificação e a sua razão de existir. Verificação e Validação 13 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Verificação e Validação Validação: estamos construindo o sistema certo? Verificação: estamos construindo certo o sistema? 14 Unidade Integração Sistema É o processo de manter o software útil enquanto ele evolui ao longo de seu ciclo de vida. Manutenção 15 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Manutenção •Quando o software está em operação, muita coisa pode acontecer: mudanças de ambiente, novas necessidades dos usuários, correção de bugs, etc. •Basicamente temos três tipos de manutenções: • Manutenções Corretivas: eliminar falhas encontradas em produção. • Manutenções Evolutivas: visam agregar novas funcionalidades e melhorias no sistema • Manutenções Adaptativas: adaptar o software a nova realidade ou novo ambiente externo, normalmente imposto (leis, regras, etc.). • Sempre que aplicar uma manutenção, deve-se realizar teste de regressão para verificar se ela não introduziu nenhuma nova falha. 16 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Questões Quais são as tradicionais fases do desenvolvimento de software? [ ] Engenharia de Requisitos, Análise e Projeto, Abstração, Implementação, Verificação e Validação [ ] Análise e Projeto, Otimização, Implementação, Verificação e Validação, Manutenção [ ] Engenharia de Requisitos, Análise e Projeto, Implementação, Verificação e Validação, Manutenção 17 Modelo definido de tudo que deve acontecer desde o início até o final de um processo de desenvolvimento de software Modelo de Processo de Desenvolvimento 18 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelo de Processo de Desenvolvimento •O objetivo é determinar a ordem em que cada atividade é executada •além do critério de transição 19 X Y Z X Y ? •Basicamente o modelo deve dizer : (1) o que nós devemos fazer e (2) quanto tempo nós devemos continuar executando cada atividade. O pai de todos os modelos 20 Cascata Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelo Cascata (ou Tradicional) •Características: • Planificação cuidadosa e ordem linear de atividades: fases sucessivas onde os resultados de uma fase tornam-se entradas da próxima; qualquer ordenamento diferente resulta num produto inferior. • Verificação no fim de cada fase para certificar-se que seus resultados intermediários são consistentes com a entrada e com requisitos do sistema. • Requisitos do usuário são “congelados” antes do início do projeto. 21 O projeto evolui de sua concepção até sua operação. Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelo Cascata (ou Tradicional) • Os erros são encontrados cedo no processo. • Esta abordagem é adequada quando: • Existe um conjunto de requisitos do usuário estáveis e de alta qualidade; • O sistema completo deve estar disponível de um única vez. • Vantagens: • Torna o processo de desenvolvimento estruturado. • Só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. • Minimiza o impacto da compreensão adquirida no decorrer do projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema não sejam aproveitadas. 22 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelo Cascata (ou Tradicional) 23 • Desvantagens: • O processo não é flexível • Não é fácil identificar todos os requisitos no início do projeto • Não é recomendado para projetos em que requisitos mudam, desenvolvedores não conhecem a tecnologia. • Dificuldade de assimilar e reagir a mudanças (de requisitos, qualidade , etc.) depois de iniciado. • Por que é um problema? Qualquer erro ou mal-entendido, se não for detectado no início do processo, pode ser desastroso. É difícil para o cliente especificar os requisitos explicitamente no início do projeto. • É excessivamente sincronizado. • Por que é um problema? Os projetos raramente seguem o fluxo sequencial que o modelo propõe. A iteração é sempre necessária e está presente, criando problemas na aplicação do modelo. • Se ocorrer um atraso, todo o processo é afetado. • A maioria dos programas só fica disponível quando o cronograma já está bastante adiantado. Um modelo incremental orientado a riscos 24 Espiral Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas 25 Modelo incremental organizado em 4 fases: 1. Determinar objetivos/requisitos 2. Identificar e resolver riscos 3. Desenvolver e testar 4. Planejar a nova fase • Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. • 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 processo. Modelo Espiral Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelo Espiral • Vantagens: • Redução de riscos do projeto devido a extensa análise de riscos. • Funcionalidades podem ser adicionadas a cada ciclo do projeto devido a natureza iterativa do projeto • Software é produzido nas fases iniciais do ciclo de vida (e feedback antecipado) • Modelo evolutivo que possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do sistema. • Permite que o projetista e cliente possam entender e reagir aos riscos em cada etapa evolutiva. 26 • Desvantagens: • Avaliação dos riscos exige muita experiência. • Este tipo de modelo não tem sido muito usado na indústria. • Ele é relativamente complexo comparado a outros modelos (e pode ser caro de implementar) Um modelo no qual nem todos os requisitos precisam ser entendidos… 27 Prototipação Evolutiva Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Prototipação Evolutiva •O sistema é continuamente refeito e reconstruído, portanto ideal quando nem todos os requisitos estão compreendidos •O desenvolvimento se dá das partes do sistema que os desenvolvedores compreendem, ao invés de desenvolver todo o sistema. • O sistema é entregue para o usuário, avaliado e depois segue para a nova iteração, na qual o protótipo é melhorado ou incrementado. 28 Conceito Inicial Projeto e Implementação Inicial do Protótipo Refinar o protótipo até ser aceitável Completar e lançar o protótipo Coleta'e' Refinamento'dos' Requisitos' Projeto' Rápido' Construção'do' Protó9po'Avaliação'do' Protó9po'pelo' Cliente' Refinamento' do'Protó9po' Engenharia'do' Produto' Início' Fim' Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Prototipação Evolutiva • Vantagens: • Feedback imediato • Prova de conceito. • Visibilidade antecipada do produto. • Encoraja participação dos usuários. • Exercício para identificar inconsistências de análise e projeto. • Redução do esforço no desenvolvimento. • Refina potenciais riscos de projeto. 29 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Prototipação Evolutiva 30 • Desvantagens: • É muito difícil de planejar quantos ciclos de desenvolvimento vai levar • Atividade de análise simplificada. • Confusão do usuário entre protótipo e o sistema real (performance, validação, etc). • Tempo e custo excessivo para desenvolvimento. • Falta de visibilidade do processo. • Dificuldade em manter a integridade entre protótipo e o software desenvolvido durante sua manutenção. Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas • Tipos/Classificações de Prototipação • Vertical: funcionalidade em profundidade; • Horizontal: amplitude de funções superficiais. • Evolucionário: evoluir até chegar a um produto; • Descartável: entender requisitos. 31 Prototipação Evolutiva Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Exercício •Faça um mock-up para um sistema de reserva de salas. •O Usuário deve poder indicar qual sala deseja utilizar em determinada data e também a descrição e o horário de início e término da atividade. •Sugestões de ferramentas: • http://pencil.evolus.vn/en-US/Home.aspx • http://builds.balsamiq.com/b/mockups-web-demo/ • http://mockupbuilder.com/ 32 Um modelo iterativo organizado em quatro grandes fases… 33 Processo Unificado (RUP) Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Processo Unificado (RUP) 34 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Processo Unificado (RUP) •Framework que fornece: atividades, papéis e artefatos necessários para o desenvolvimento de software. •Suas principais características são: • Desenvolvimento iterativo e incremental; • Orientado a objetos • Foco na criação de uma arquitetura robusta; • Análise de riscos; • Utilização de casos de uso para o desenvolvimento. 35 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Processo Unificado (RUP) •Processo dividido em quatro diferentes fases: • Concepção: estabelece o caso de negócio para o sistema e delimita o escopo do projeto. • Elaboração: envolve a análise do domínio do problema e a especificação da arquitetura do sistema. • Construção: envolve a elaboração do software a partir de arquitetura em um produto completo para utilização pelos usuários. • Transição: viabiliza que o software possa ser utilizado pelos usuários. 36 É um grupo de processos de desenvolvimento altamente iterativo e incremental 37 Metodologias Ágeis Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Metodologias Ágeis 38 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Metodologias Ágeis •As metodologias ágeis (ou leves) são processos de desenvolvimento de software, em geral, empregados por organizações que dão ênfase à colaboração baseada numa abordagem flexível. • Ideais para projetos nos quais os requisitos mudam constantemente, em decorrência do mercado, da organização, do projeto e do conhecimento. •São exemplos de métodos ágeis: • Programação eXtrema (XP) • Scrum • Crystal 39 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Metodologias Ágeis 40 http://www.manifestoagil.com.br/ http://www.manifestoagil.com.br/ Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas eXtreme Programming - XP •Características: • Feedback constante. • Abordagem incremental. • Comunicação entre as pessoas. 41 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Scrum • Indicado para equipes pequenas (aproximadamente 7 pessoas) e projetos com requisitos pouco estáveis ou desconhecidos. •Compreende iterações curtas com entregas para o cliente. •Diretrizes e práticas do SCRUM: 42 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Modelos de Ciclo de Vida de Software •Aspectos comuns a todos modelos: • Todos começam com (ou visam) uma compreensão melhor dos requisitos do sistema a ser desenvolvido. • Todos visam aumento da qualidade dos resultados parciais e finais. • Todos visam melhoria da gerência do processo de desenvolvimento (alguns, o controle do processo; outros, o acompanhamento do processo). 43 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Escolhendo o melhor modelo para um projeto 44 Modelo Adequado Modelo Errado Mas como escolher o melhor modelo? Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Escolhendo o melhor modelo para um projeto 45 Compreensão dos Requisitos Agenda e Recursos Riscos Interação com Clientes Conhecimento Técnico Duração do Projeto Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Questões •Qual dos seguintes modelos é o mais adequado para um sistema de controle de uma aeronave? [ ] Cascata [ ] Espiral [ ] Prototipação Evolucionária •Qual dos seguintes modelos é o mais adequado para um sistema virtual de aprendizagem? [ ] Cascata [ ] Espiral [ ] Prototipação Evolucionária 46 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Documentos para o Desenvolviment •Templates da IEEE: • 1058-1998 - IEEE Standard for Software Project Management Plans • 1016-2009 - IEEE Standard for Information Technology-- Systems Design--Software Design Descriptions • 1012-2012 - IEEE Standard for System and Software Verification and Validation • 830-1998 - IEEE Recommended Practice for Software Requirements Specifications •OpenUP • http://epf.eclipse.org/wikis/openuppt/ 47 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=741937 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5167255http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6204026 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=720574 http://epf.eclipse.org/wikis/openuppt/ Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Exercícios •Sugira um modelo genérico de processo de desenvolvimento de software mais apropriado para gerenciar o desenvolvimento dos seguintes sistemas: • Um sistema para controlar um antibloqueador de freios em um automóvel. • Um sistema de realidade virtual para apoiar a manutenção de software. • Um sistema de contabilidade de uma universidade que substitui um sistema existente. • Um sistema interativo que permite aos passageiros encontrar o horário dos trens por meio de terminais instalados nas estações. 48 Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Erros Clássicos - PESSOAS 49 HERÓI A ideia de que uma pessoa pode fazer tudo sozinha! AMBIENTE DE TRABALHO Um bom ambiente de trabalho faz aumentar a produtividade. GESTÃO DE PESSOAS Uma liderança pobre pode conduzir um projeto ao fracasso. Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Erros Clássicos - PROCESSOS 50 PROBLEMAS DE AGENDA Superestimar a habilidade das pessoas PROBLEMAS DE PLANEJAMENTO Falta ou abandono do planejamento pode levar a falha no projeto. Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Erros Clássicos - PRODUTO 51 GOLD PLATING REQUIREMENTS Entregar mais requisitos que o cliente pede. FEATURE CREEP Adicionar mais e mais funcionalidades que aquelas inicialmente solicitadas. PESQUISA != DESENVOLVIMENTO Ao usar novas tecnologias, técnicas,então o projeto é mais pesquisa que desenvolvimento Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Erros Clássicos - TECNOLOGIA 52 SÍNDROME DA BALA DE PRATA Se acredita que uma única tecnologia pode resolver todos problemas TROCA DE FERRAMENTAS Nem sempre mudar de ferramentas/ tecnologias é positivo. SEM VERSIONAMENTO Gerenciar manualmente documentos é um erro muito comum! Prof. Rodrigo Noll - Análise e Desenvolvimento de Sistemas - IFRS/Canoas Questão •Que tipo de erro está associado com adicionar uma pessoa em uma fase mais adiantada de um projeto? [ ] Pessoas [ ] Produto [ ] Tecnologia [ ] Não é um erro 53
Compartilhar