PROJETO EM SISTEMAS DE INFORMAÇÃO Unidade I-Metodologia de ...luizleao.com/Docencia/FAP/PROJETO_SI/PROJETO_SI_UND_01.pdf · O desenvolvimento ágil de software defende ... •eXtreme

Luiz Leão – [email protected]://www.luizleao.com

PROJETO EM SISTEMAS DE INFORMAÇÃO

Unidade I - Metodologia de desenvolvimento a ser adotada

mailto:[email protected]

http://www.luizleao.com/



Conteúdo Programático• Exposição das metodologias possíveis, conforme o tipo de

projeto;

• Fundamentação do aluno para conduzir as etapas do trabalho conforme a metodologia selecionada.



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.



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



Modelo Cascata (Waterfall)



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



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



Modelo em Espiral



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]



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.



Modelo Iterativo / Incremental



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.



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



Metodologias Ágeis - Exemplos• Scrum• eXtreme Programming (XP)• Etc.



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.



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 PlanningMeeting, 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.



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



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.



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 Ownerdescreve 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.



• É 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.

SCRUM – Sprint Backlog



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.



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.



SCRUM – Release Burndown



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.



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.



SCRUM



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.



eXtreme Programming (XP)• Princípios

– Comunicação

– Coragem

– Feedback

– Respeito

– Simplicidade



Comunicação• Embora existam inúmeras formas de se comunicar idéias,

algumas são mais eficazes que outras.

• Quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambiguidades.

• Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível.



Comunicação• Caso

contrario...



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



• 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.

Feedback



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

• Divergências individuais podem prejudicar seriamente o desenvolvimento do projeto.

Respeito



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

Fonte: Standish Group – The Chaos Report (2000)



eXtreme Programming (XP)



• 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)

eXtreme Programming (XP) – Práticas



• É 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.

Jogo de Planejamento



• 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 entrarem em produção.

Jogo de Planejamento



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.



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).



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.



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.



• 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.

Padronização de Código



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.



• 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.

Integração Contínua



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.



§ É 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.

Pair Programming



§ Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

Pair Programming



• É 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

Refatoração



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“, faça apenas isso.

• Sem se preocupar com um complexo sistema de autenticação, com controles de acesso.



Projeto Simples• 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.

• Código fácil deve ser identificado e substituído por código simples.



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.



• Como o processo de desenvolvimento de software se distribui/concentra no tempo dentro de um projeto?

Variação entre os modelos



Cada modelo tem suas vantagens e desvantagens

Cabe aos gerentes e analistas escolherem a melhor abordagem para o projeto a ser desenvolvido

Documents

PROJETO EM SISTEMAS DE INFORMAÇÃO Unidade I-Metodologia de ...luizleao.com/Docencia/FAP/PROJETO_SI/PROJETO_SI_UND_01.pdf · O desenvolvimento ágil de software defende ... •eXtreme