Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e recursos, tendo em vista a produção de determinado produto. Envolve um conjunto de técnicas e de ferramentas 2
características de um processo Prescreve todas as actividades principais Utiliza recursos, sujeitos a restrições (e.g. calendarização) Produz produtos intermédios e finais Pode ser composto por subprocessos organizados hierarquicamente Cada actividade tem definidos critérios de entrada e de saída As actividades organizam-se sequencialmente, do ponto de vista temporal Tem um conjunto de linhas orientadoras que explicam os objectivos de cada actividade Pode haver restrições para cada actividade, cada recurso e cada produto 3 ciclo de vida do software Quando um processo envolve a construção de um produto de software, diz-se que o processo é o ciclo de vida do software Definição e análise de requisitos Desenho do sistema Desenho do programa Escrita dos programas Testes modulares, de integração e do sistema Entrega do sistema Manutenção 4
importância do processo Impõe consistencia e estrutura às actividades de desenvolvimento Facilita a compreensão, o controlo e a verificação das actividades Permite registar experiencias que poderão ser usadas em futuros processo 5 modelo de processos Cria uma forma de entendimento comum das actividades, recursos e restrições ao processo Ajuda a equipa a encontrar inconsistencias, redundancias, omissões no processo em geral e nas suas partes em particular Define os objectivos do desenvolvimento (detectar faltas cedo, obter programas de elevada qualidade, respeitar o orçamento) Deve ser escolhido pela equipa o modelo que melhor se adapta aos seus objecivos 6
Modelos de processos de Software Modelo em Cascata (Waterfall) Modelo em V Modelo de prototipagem Especificação operacional Desenvolvimento faseado: iterativo e incremental Modelo em espiral Métodos ágeis 7 Modelo em cascata Foi um dos primeiros modelos propostos (Winston Royce, 1970) As etapas surgem sequencialmente a cada etapa é associada a construção de produtos intermédios, sendo necessário terminar uma etapa antes de iniciar a seguinte 8
Modelo em cascata 9 Modelo em cascata Simples e fácil de explicar aos clientes Visão de alto nível do processo de desenvolvimento Existem marcos e produtos intermédios associados a cada etapa, facilitando a gestão do projecto Funciona bem quando se percebe bem o problema ou quando os requisitos são definitivos 10
Modelo em cascata Ignora a iteração muitas vezes presente no desenvolvimento de aplicações não descreve como é que cada actividade transforma o produto intermédio recebido no produto intermédio produzido 11 prototipagem no modelo em cascata Um protótipo é um produto parcialmente desenvolvido O desenho do protótipo ajuda a equipa de desenvolvimento a encontrar estratégias de desenho alternativas o protótipo da interface com o utilizador ajuda o utilizador a perceber como ficará o sistema A prototipagem é útil para a verificação e validação em diferentes etapas do processo 12
prototipagem no modelo em cascata 13 Modelo em v Variante do modelo em cascata Utiliza testes de módulos para verificar o desenho Utiliza testes de integração para verificar a arquitectura do sistema Utiliza teste de aceitação para validar os requisitos Caso surjam problemas na verificação e na validação, o lado esquerdo do V pode ser executado novamente para serem feitas as respectivas alterações 14
Modelo em v 15 modelo de prototipagem A prototipagem é a base do modelo Reduz riscos de incerteza no desenvolvimento 16
modelo de especificação operacional Os requisitos podem ser examinados e as suas implicações avaliadas ainda na fase inicial do processo A funcionalidade e o desenho fundem-se 17 modelo de desenvolvimento faseado Ciclo de desenvolvimento curto O sistema é entregue em partes clientes vão vendo algumas funcionalidades, enquanto a equipa vai desenvolvendo o resto Há dois sistemas a funcionar em paralelo sistema de produção (versão n): está a ser usado pelo cliente sistema de desenvolvimento (versão n+1): a versão seguinte que está a ser preparada 18
modelo de desenvolvimento faseado 19 modelo de desenvolvimento faseado Desenvolvimento Incremental: começa com subsistema pequeno e funcional, depois acrescenta novas funcionalidades a cada versão Desenvolvimento Iterativo: começa com o sistema completo que vai sofrendo alterações de funcionalidades em cada versão 20
modelo de desenvolvimento faseado Vantagens O treino e a familiarização dos utilizadores pode decorrer cedo, mesmo que faltem algumas funções Clientes/utilizadores ficam motivados desde cedo para novas funcionalidades Versões frequentes permitem corrigir problemas inesperados rapidamente e globalmente A equipa de desenvolvimento pode focar diferentes áreas de conhecimento nas diferentes versões 21 modelo em espiral Boehm, 1988 Combina as actividades do processo com a gestão do risco para minimizar e controlar o risco O modelo apresenta-se como uma espiral onde cada iteração é representada por um circuito à volta de quatro fases: Planificação Determinação de objectivos, alternativas e restrições Avaliação de alternativas e riscos Desenvolvimento e teste 22
modelo em espiral 23 métodos ágeis Apostam na produção rápida de software flexível e de qualidade Manifesto Ágil (princípios alternativos) Valorização das pessoas e interacções em relação aos processos e às ferramentas É preferível gastar tempo a programar do que a preparar documentação Enfatisa a colaboração com o cliente e não o contrato Concentra-se em responder às alterações pedidas e não em criar um plano e segui-lo 24
métodos ágeis (exemplos) Extreme programming (XP): desenvolve software com requisitos incompletos e em constante mudança. Efectua acompanhamento constante e pequenos ajustes durante todo o processo de desenvolvimento Crystal: diversas abordagens baseadas no princípio da unicidade de um projecto (políticas e convenções próprias) Scrum: iterações de 30 dias. Várias equipas autónomas e organizadas. Coordenação feita com breves reuniões diárias 25 métodos ágeis: Extreme Programming Princípios da XP Comunicação: contínua entre clientes e equipas de desenvolvimento Simplicidade: escolhe desenho mais simples Coragem: entrega de novas funcionalidades cedo e com frequencia retroalimentação: revisita rapidamente as actividades durante o processo de desenvolvimento 26
Extreme Programming (práticas) Jogo do planeamento (cliente define o valor) Pequenas versões Metáfora Desenho simples Testes de aceitação Programação aos pares Posse colectiva Integração contínua (pequenos incrementos) Ritmo sustentável (40 h/ semana) Padrões de codificação Refactoring 27 demasiado extremo As práticas de XP são interdependentes Quando uma se altera as outras ficam vulneráveis Os requisitos têm que passar por testes de software não é para isso que o cliente paga Refactoring É difícil alterar continuamente a progamação sem degradar a arquitectura inicial 28
resumo O processo de desenvolvimento envolve actividades, recursos e produtos Há modelos de processos com diferentes perspectivas: organizacional, funcional, comportamental, etc Um modelo de processo é útil para a execução, colaboração e coordenação do trabalho em equipa 29