Engenharia de Software

Transcrição

1 Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra 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

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

3 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

4 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

5 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

6 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

7 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

8 Modelo em v 15 modelo de prototipagem A prototipagem é a base do modelo Reduz riscos de incerteza no desenvolvimento 16

9 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

10 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

11 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

12 modelo em espiral 23 métodos ágeis Agilidade ligeireza desembaraço vivacidade 24

13 métodos ágeis Apostam na produção rápida e eficiênte de software flexível e de qualidade, sem burocracia e de forma competitiva Contrastam com o formalismo de gestão de projectos e produção de extensa documentação associada aos processos anteriores Seguem abordagem iterativa e incremental, procurando minimizar os riscos do desenvolvimento cada iteração é um mini-projecto 25 Manifesto para o desenvolvimento ágil de software ( Principais valores Pessoas e interacções, em vez de processos e ferramentas. A motivação, a qualidade de vida, o ritmo de trabalho e as relações inter-pessoais são prioritários Software que trabalha, em vez de gastar tempo a preparar documentação de um sistema cujo desenvolvimento nunca chega ao fim Colaboração com o cliente e não a negociação do contrato. Estabelecer uma relação de confiança e de colaboração é preferível do que perder tempo a negociar cláusulas e a desgastar a relação Responder à mudança, e não seguir um plano 26

14 Manifesto para o desenvolvimento ágil de software ( Principais princípios Prioridade em satisfazer o cliente, através de entregas antecipadas e contínuas de software com valor Alterações dos requisitos são bem-vindas, mesmo no fim do desenvolvimento (vantagem competitiva) Trabalhar em equipa é sempre necessário Motivar e confiar Comunicar cara-a-cara Software a funcionar é a principal medida de progresso 27 Manifesto para o desenvolvimento ágil de software ( Promover desenvolvimento sustentável em que os participantes mantenham um ritmo constante e saudável de trabalho Excelência técnica e desenho de qualidade Simplicidade é essencial Equipa auto-organizada que trabalha em conjunto em todo o projecto Reflectir em equipa para afinar e ajustar o comportamento 28

15 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 Scrum: entrega incremental (iterações de 30 dias). Várias equipas autónomas e organizadas. Coordenação feita com breves reuniões diárias 29 métodos ágeis: Extreme Programming Valores 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 frequência. Persistência e capacidade de resolver problemas não triviais Feedback: revisita rapidamente as actividades durante o processo de desenvolvimento Respeito: respeito e sentido de responsabilidade 30

16 métodos ágeis: Extreme Programming Princípios da XP feedback rápido simplicidade mudanças incrementais abraçar a mudança 31 Extreme Programming (práticas) Jogo do planeamento (cliente define o valor e equipa estima o esforço) Pequenas versões Metáfora (história simples explicativa do sistema) Desenho simples e pragmático Desenvolvimento conduzido por testes (programa-se testes unitários ainda antes do código, cuja execução garante a correcção do sistema) 32

17 Extreme Programming (práticas) Refactorização Programação aos pares (um escreve e o outro verifica e pensa) Propriedade colectiva do código (é de todos) Integração contínua do código (pequenos incrementos) Ritmo de trabalho sustentável (40 h/semana) Padrões de codificação Incluir o cliente no projecto (representante do cliente a tempo integral) 33 34

18 Extreme Programming (equipa) programador (papel central, atribui tarefas e participa na calendarização) cliente (define as prioridades e a calendarização testador (tester) - apoia o cliente gestor (das pessoas da equipa) monitorizador (tracker) treinador (coach) - responsável pela aplicação da XP consultor (participa pontualmente) 35 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 Refactorização É difícil alterar continuamente a progamação sem degradar a arquitectura inicial 36

19 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 37