2. Modelos de Desenvolvimento de Software Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2005/06 EST, Setúbal Ciclo de Vida do Software Um sistema de software é desenvolvido gradualmente até ser entregue ao cliente e até depois disso Ter um processo definido é essencial O ciclo de vida é um conjunto de passos que o software deve cumprir desde a ideia da concepção até à conclusão. Paradigma estruturado: Fase de requisitos. Fase da especificação. Fase do desenho. Fase da implementação. Fase da integração. Fase da manutenção. Conclusão. Patrícia Macedo@2005 EST Setubal Engenharia de Software 2 1
Custos de cada fase Patrícia Macedo@2005 EST Setubal Engenharia de Software 3 Modelos de ciclos de vida de software: Modelo Sequenciais Waterfall (Cascata) Modelo de Protipos Rapid Prototyping (Construção de Protótipos) Modelos Evolucionários Incremental (Incremental) Synchronize & stabilize (Sincronizar e estabilizar) Spiral (Espiral) Patrícia Macedo@2005 EST Setubal Engenharia de Software 4 2
Construir & Modificar Nenhumas especificações Nenhum tipo de desenho Principais problemas: Difícil de aplicar em problemas complexos Tempo de desenvolvimento do código elevado Utilizadores descontentes com a qualidade do software Dificuldades acrescidas para se adicionar funcionalidades e/ou eliminar erros (bugs) Patrícia Macedo@2005 EST Setubal Engenharia de Software 5 Modelo Cascata Requisitos Alteração dos Requisitos Especificação Desenvolvimento Manutenção Implementação Entrega ao cliente Patrícia Macedo@2005 EST Setubal Engenharia de Software 6 Conclusão 3
Modelo Cascata Fases do ciclo de vida: Análise de requisitos Especificação Implementação e teste dos módulos e teste do sistema Entrega e manutenção No fim de cada fase é obrigatório um teste para verificar se os objectivos foram alcançados Cada fase é visitada sequencialmente Iterações dentro de uma fase são possíveis até que o teste ao sistema seja satisfatório Patrícia Macedo@2005 EST Setubal Engenharia de Software 7 Modelo Cascata: Análise de Requisitos e Especificação O que éo problema Primeira fase no desenvolvimento de um projecto de desenvolvimento de software em larga escala, após um estudo de viabilidade que define os custos e benefícios do sistema de software É necessário compreender bem as necessidades do cliente e documentá-las de forma clara em termos facilmente perceptíveis para o utilizador Poderão ser desenvolvidos aqui manuais de utilização e planos de teste do sistema Patrícia Macedo@2005 EST Setubal Engenharia de Software 8 4
Modelo Cascata: Como resolver o problema Após a documentação dos requisitos ter sido produzida, é necessário desenhar o software 2 sub-fases: (i) Arquitectural (ii) Detalhe da estrutura geral de módulos e respectiva relação (e.g. definição da estrutura modular) Detalhes de cada um dos módulos (e.g. definição das interfaces de cada módulo) Patrícia Macedo@2005 EST Setubal Engenharia de Software 9 Modelo Cascata: Implementação Esta é a fase em que se produz efectivamente o código que será entregue ao cliente na forma de um sistema de software funcional Os módulos desenvolvidos nesta fase são individualmente testados antes de serem entregues à fase seguinte (integração) A produção de código pode ser sujeita a normas que definem a estrutura do programa: Comentários Convenções para os nomes das variáveis e das funções Estilo de programação Patrícia Macedo@2005 EST Setubal Engenharia de Software 10 5
Modelo Cascata: Todos os módulos anteriormente desenvolvidos e testados individualmente são, nesta fase, integrados e testados como um sistema completo Várias metodologias: progressiva de cada módulo e teste subsequente de todos os módulos e teste ( big-bang testing Disponibilização de uma versão alpha para ser testada no mundo real Patrícia Macedo@2005 EST Setubal Engenharia de Software 11 Modelo Cascata: Manutenção Tendo o sistema passado todos os testes, é entregue ao cliente e entra na fase de manutenção Todas as modificações efectuadas no sistema após a entrega são consideradas como fazendo parte da manutenção Normalmente é constituída por duas fases: Beta : Serve normalmente para efectuar uma experiência controlada para detectar erros e obter opiniões sobre o software Distribuição aos utilizadores Patrícia Macedo@2005 EST Setubal Engenharia de Software 12 6
Modelo Cascata: Vantagens Disciplina na produção de software através da criação de documentos: Nenhuma fase é concluída até que os documentos e/ou código seja verificado/testado Progressão linear e objectiva O teste é uma parte inerente a todo o processo: Continuamente e no fim de todas as fases de produção Patrícia Macedo@2005 EST Setubal Engenharia de Software 13 Modelo Cascata: Desvantagens O processo pode ser decomposto em fases adicionais e pode não ser inteiramente sequencial Difícil de aplicar em alguns tipos de problemas, e.g. o utilizador pode não conhecer os requisitos da aplicação O cliente apenas pode ver o produto depois de ser implementado Leva a produtos que não vão ao encontro das necessidades dos utilizadores Grandes mudanças nos requisitos são problemáticas Funciona melhor quando os requisitos são estáveis e o problema é conhecido Patrícia Macedo@2005 EST Setubal Engenharia de Software 14 7
Construção de Protótipos Protótipo Alteração dos Requisitos Especificação Desenvolvimento Manutenção Implementação Entrega ao cliente Patrícia Macedo@2005 EST Setubal Engenharia de Software 15 Conclusão Construção de Protótipos A construção de protótipos substitui a fase de requisitos: Permite que os utilizadores possam ver e usar as soluções propostas Desenvolver a especificação a partir do protótipo: Continuar com as restantes fases do modelo cascata O protótipo deve ser construído e alterado rapidamente: Não perder muito tempo melhorando o código/estrutura Colocá-lo à frente do utilizador ASAP Ferramentas de desenvolvimento de interfaces do utilizador e outras facilitam a tarefa Patrícia Macedo@2005 EST Setubal Engenharia de Software 16 8
Construção de Protótipos Vantagens: Processo linear Permite uma maior liberdade devido á natureza do protótipo Desvantagens: Perda de tempo na construção/alteração do protótipo Tornar os protótipos em produto final é problemático => degenera no modelo construir e arranjar Funciona melhor quando os requisitos não são conhecidos Patrícia Macedo@2005 EST Setubal Engenharia de Software 17 Modelo Incremental Requisitos Especificação Para cada implementação: Desenvolvimento Manutenção detalhado Implementação Teste Entrega ao cliente Patrícia Macedo@2005 EST Setubal Engenharia de Software 18 Conclusão 9
Modelo Incremental Entrega ao cliente de versões incrementais do mesmo projecto Cada implementação ( build ) consiste em: Uma unidade de software Toda a documentação do projecto (e.g. requisitos, especificações, planos de teste, manual do utilizador) Estratégia principal: Entregar algo ao utilizador Medir o valor acrescido Ajustar a especificação e os objectivos a partir dos problemas/pedidos do utilizador Patrícia Macedo@2005 EST Setubal Engenharia de Software 19 Modelo Incremental Divisão do projecto em builds Cada adiciona novas funções Teste do produto como um todo Vantagens: Produto operacional em poucas semanas Mais fácil de gerir Retorno de capital mais rápido Desvantagens: Necessita de uma arquitectura flexível Perda de tempo na entrega e/ou construção de builds Patrícia Macedo@2005 EST Setubal Engenharia de Software 20 10
Especificações Sincronizar & Estabilizar (Microsoft) Implementação, Entregar ao cliente (versão 1) Especificações Implementação, Entregar ao cliente (versão 2) Especificações Implementação, Entregar ao cliente (versão 3)... Especificações Implementação, Entregar ao cliente (versão n) Patrícia Macedo@2005 EST Setubal Engenharia de Software 21 Sincronizar & Estabilizar Análise de requisitos Intrevistar potenciais utilizadores Construir especificações gerais do projecto Dividir cada projecto em 3 ou 4 builds Cada adiciona novas funcionalidades Cada build é construído por pequenas e diferentes equipas Ao fim de cada dia sincroniza (test & debug) Ao fim de cada build estabiliza (fix & freeze) Patrícia Macedo@2005 EST Setubal Engenharia de Software 22 11
Modelo em Espiral Verify Verify Verify Verify Risk analysis Risk analysis Rapid prototype Specification Risk analysis Design Implementation Risk analysis Patrícia Macedo@2005 EST Setubal Engenharia de Software 23 Modelo em Espiral Modelo cíclico Quatro fases: Protótipo, especificação, desenho e implementação O raio da espiral representa o custo acumulado O ângulo representa o progresso Ideia chave: Minimizar o risco Antes de cada fase: Observar as alternativas Análise de risco Depois de cada fase: Avaliação Planeamento da próxima fase Patrícia Macedo@2005 EST Setubal Engenharia de Software 24 12
Modelo em Espiral Gestão de riscos, em cada ciclo da espiral: Identificar potenciais riscos Planear o próximo passo baseando-se nessa análise Refinar a especificação e a arquitectura nas áreas com elevado risco Tenta identificar potenciais problemas Não apenas nas fases iniciais Quais são as partes arriscadas do sistema Baseia-se na experiência do programador Experiência é um factor crítico O modelo falha se os riscos não forem bem avaliados Apenas válido para grandes projectos Patrícia Macedo@2005 EST Setubal Engenharia de Software 25 Alguns riscos 1. Falta de pessoal 2. Planeamento e orçamento irrealista 3. Desenvolver as funções de software erradas 4. Desenvolver a interface errada 5. Os requisitos mudam continuamente 6. Falhas em componentes externos 7. Falhas em tarefas calculadas externamente 8. Desempenho em temporeal inadequado Patrícia Macedo@2005 EST Setubal Engenharia de Software 26 13