Processo de Desenvolvimento de Software Unidade V ...luizleao.com/Docencia/FAP/PDS/PDS_UND_05.pdf · Processo de Desenvolvimento de Software O desenvolvimento ágil de ... Processo

Processo de Desenvolvimento de

Software

Unidade V – Modelagem de PDS

Luiz Leão – [email protected]

http://www.luizleao.com

mailto:[email protected]

http://www.luizleao.com/


Processo de Desenvolvimento de Software

Conteúdo Programático desta aula


Modelo Cascata (Waterfall) ou TOP DOWN.

Modelo Iterativo.

Metodologia Ágil.



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



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



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.



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




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




Princípios

Comunicação

Coragem

Feedback

Respeito

Simplicidade



Comunicação



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



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



Respeito

Membros de uma equipe só irão se preocupar em comunicar-se

melhor, por exemplo, se houver respeito uns com os outros



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






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)



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.



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.



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.



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.



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.



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.



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.



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



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.

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.



Variação entre os modelos

Como o processo de desenvolvimento de software se

distribui/concentra no tempo dentro de um projeto?



Cada modelo tem suas vantagens e desvantagens

Cabe aos gerentes e analistas escolherem a

melhor abordagem para o projeto a ser

desenvolvido

Documents

Processo de Desenvolvimento de Software Unidade V ...luizleao.com/Docencia/FAP/PDS/PDS_UND_05.pdf · Processo de Desenvolvimento de Software O desenvolvimento ágil de ... Processo