Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com

Transcrição

1 Processo de Desenvolvimento de Software Luiz Leão

2 Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

3 Introdução Há um bom tempo busca-se um processo ou metodologia que seja previsível e repetível, e que melhore a produtividade e a qualidade do desenvolvimento de software Vários modelos foram idealizados com o intuito de organizar o processo, podendo assim alcançar a máxima eficiência pretendida, com o menor custo relacionado.

4 Modelo Cascata (Waterfall) O ciclo de vida em Cascata (Clássico ou Linear) possui uma tendência maior para a progressão sequencial apesar de pode haver retroalimentação. Problemas: Projetos reais raramente seguem o fluxo; Presume possibilidade de declarar previamente todos os requisitos; A implantação fica distante da fase inicial; Aplicabilidade: Modelo apropriado quando se tem requisitos bem definidos

5 Modelo Cascata (Waterfall)

6 Modelo em Fonte Baseado no modelo de cascata Porém, observe que a sequência sempre contêm ciclos Reflete o fato de que algumas fases não podem iniciar antes de outras E que algumas fases são intercaladas

7 Modelo em Espiral Sugerido por Boehmen em 1988 Representação em espiral, não como sequência de tarefas Não tem número fixo de fases Os riscos são tratados explicitamente

8 Modelo em Espiral

9 Modelo em Espiral O modelo espiral pode ser adaptado para ser aplicado ao longo de todo o ciclo de vida de uma aplicação, desde o desenvolvimento de conceitos até a sua manutenção [PRESSMAN, 2011]

10 Modelo Iterativo / Incremental A cada iteração: O software é incrementado em termos de artefatos de software A definição desses artefatos e suas iterações seguem a necessidade do Cliente/Usuário As primeiras devem abordar os artefatos de maior relevância para o produto.

11 Modelo Iterativo / Incremental

12 Metodologias Ágeis O desenvolvimento ágil de software defende alguns pontos de vista em detrimentos de outros: Manifesto Ágil: Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano.

13 Metodologias Ágeis - Feedback Processos ágeis usam feedback, ao invés do planejamento como seu mecanismo de controle primário O feedback é orientado por testes e releases periódicos do software envolvido

14 Metodologias Ágeis - Exemplos Scrum extreme Programming (XP) Etc.

15 SCRUM Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Os projetos são divididos em ciclos (mensais, semanais, etc.) chamados de Sprints. O Sprint representa um Time Box (intervalo de tempo) dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que no caso do Scrum, são as Sprints.

16 SCRUM (Cont.) As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

17 SCRUM Alguns termos serão comumente vistos ao utilizar essa metodologia: Produt Backlog Sprint Planning Meeting Sprint Backlog Daily Scrum Release Burndown Sprint Review Sprint Retrospective

18 SCRUM Product Backlog É uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, a lista cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

19 SCRUM Sprint Planning Meeting É uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo a equipe, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

20 SCRUM Sprint Backlog É uma lista de tarefas que a equipe se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

21 SCRUM Daily Scrum A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. É composta pelo Scrum Master e a equipe de desenvolvimento.

22 SCRUM Release Burndown Em um projeto Scrum, a equipe monitora seu progresso em relação ao projeto, atualizando um gráfico chamado Release Burndown ao final de cada Sprint (iteração). O eixo horizontal de um Release Burndown Chart mostra os Sprints; O eixo vertical mostra a quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe: Pontos de função, dias de trabalho e assim por diante.

23 SCRUM Release Burndown

24 SCRUM Sprint Review Meeting É feito ao final de cada Sprint. Durante esta reunião, a equipe mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. Os participantes do Sprint Review tipicamente incluem o Product Owner, a equipe, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

25 SCRUM Sprint Retrospective Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. Pode servir também para iniciar o planejamento da nova Sprint. Conta com a participação do Scrum Master e com a equipe de desenvolvimento.

26 SCRUM

27 extreme Programming (XP) É uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

28 extreme Programming (XP) Princípios Comunicação Coragem Feedback Respeito Simplicidade

29 Comunicação

30 Coragem Única constância nos projetos de software é a mudança A confiança nas ferramentas e nas metodologias adotadas ajudam em tomadas de decisões corajosas, para o bem do projeto

31 Feedback Projetos de software requerem alto investimento por parte do cliente É preciso que o cliente tenha conhecimento do status do seu investimento, a cada instante Para isso, a comunicação e o respeito devem esta presente na relação Equipe x Cliente

32 Respeito Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se houver respeito uns com os outros

33 Simplicidade Pesquisa sobre as funcionalidades desenvolvidas para um software Muito esforço é, geralmente, empregado na produção do software, sem que haja agregação de valor no produto final

34 extreme Programming (XP)

35 extreme Programming (XP) Práticas Organizacionais: Jogo de Planejamento Pequenas Versões (Releases) Teste de Aceitação Time Coeso Equipe: Propriedade Coletiva Padronização de Código Ritmo Sustentável Integração Contínua Metáforas Pares: Programação em Par Refatoração Projeto Simples Desenvolvimento Orientado a Teste (TDD)

36 Jogo de Planejamento É a reunião feita no início da iteração, entre desenvolvedores e cliente, cuja finalidade é identificar as prioridades do projeto para que os desenvolvedores estimem o esforço das tarefas. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado a cada ciclo, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada ciclo, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

37 Pequenas Versões (Releases) A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

38 Teste de Aceitação São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. Descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história está completa (aceita).

39 Time Coeso Deve ser formado pelo cliente, desenvolvedores e por profissionais que contribuam para o desenvolvimento do projeto, como consultores, por exemplo. A equipe de desenvolvimento é formada por pessoas engajadas e de perfis multidisciplinares, com o objetivo de termos um vasto conjunto de habilidades necessárias para o projeto. Um projeto bem sucedido precisa levar em conta a opinião de diversas partes, bem como incorporar diferentes pontos de vista.

40 Propriedade Coletiva O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

41 Padronização de Código A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. IDEs e Frameworks contribuem de forma significativa para implantar essa prática.

42 Ritmo Sustentável Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

43 Integração Contínua Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

44 Metáforas Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

45 Programação em Par É a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

46 Refatoração É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refatorar (ou refabricar) melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte

47 Projeto Simples Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP.

48 Desenvolvimento Orientado a Teste (TDD) Testing Driven Development Primeiro crie os testes unitários (Unit Tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

49 Variação entre os modelos Como o processo de desenvolvimento de software se distribui/concentra no tempo dentro de um projeto?

50 Cada modelo tem suas vantagens e desvantagens Cabe aos gerentes e analistas escolherem a melhor abordagem para o projeto a ser desenvolvido