ATPS 1ª ETAPA




























Tiago Ap. Pessoa Ra: 0911345828

Wesley S.Dia RA: 0959532446
Evandro D. Oliveira Ra:0919435437
Marcio S. Oliveira RA: 0920349523







Trabalho apresentado para avaliação na disciplina de Engenharia de Software e análise de projeto de sistema, do curso de Ciência da Computação, período noturno, da Universidade Anhanguera de Campinas FAC III, ministrado pela professora Tânia Ramires.
















Opções de metodologias de processo









• FDD (Feature Driven Development )
• CASCATA
• SCRUM













Processo FDD


É uma metodologia ágil para gerenciamento e desenvolvimento de software

Vantagens

Recomendado para qualquer tipo de desenvolvimento.
Foco em características de valor para o cliente
FDD prioriza aquilo que o cliente prioriza
FDD possui requisito maus formais


Desvantagens

Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção


Funcionalidade

Pequena o suficiente para ser implementada no máximo
em 2 semanas
Oferece valor para o cliente
Às vezes pode ser o próprio caso de uso
Conceito muito próximo ao de um requisito funcional
Exemplos: Calcular o total de uma venda
Autorizar uma transação com cartão de um cliente












Processo CASCATA



O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.




Vantagens


O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas.

Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;

∙ Não suporta modificações nos requisitos;
∙Não prevê a manutenção;
∙Não permite a reutilização;
∙É excessivamente sincronizado;
∙Se ocorrer um atraso todo o processo é afetado;
∙ Faz aparecer o software muito tarde.


Desvantagens

O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.









Comparação com o modelo em cascata

O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.





Processo SCRUM

Na indústria de software, devido á alta complexidade e ao desenvolvimento, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, quando os processos definidos eram menos adequados para obter a alta produtividade e qualidade no produto final, verificou-se que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.
As empresas de software começaram a estudar essa metodologia, que propõe novos métodos em substituição aos métodos praticados tradicionalmente, pois o mercado de tecnologia da Informação está cada vez mais competitivo.
Os métodos ágeis, como uma alternativa aos processos tradicionais em decorrência da insatisfação dos profissionais de desenvolvimento de software, com a rigidez e resultados limitados obtidos através do uso de práticas tradicionais de gestão de projetos. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo.
• Interação entre indivíduos é mais importante que processos e ferramentas;
• Produto em funcionamento mais que documentação extensa;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
.


Ciclo do Processo do Scrum

No início de um projeto Scrum, mesmo que ainda se tenha uma visão superficial no principio, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. A partir dessa visão inicial, elabora-se uma lista enxuta dos principais itens; cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia ou infraestrutura. Esta lista é denominada Product Backlog.
Podemos traduzir Product Backlog como uma lista de prioridade de entrega que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar completa logo no começo, ela pode ganhar outros itens no decorrer do projeto, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto.


No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.
O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos, ou um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. Estas equipes recebem o nome de Scrum Teams. A preparação dos trabalhos é denominada Sprint Planning.
Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são Sprint Goal e Sprint.
O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. No início de cada iteração a equipe seleciona os itens do Product Backlog, de acordo com as suas prioridades e o prazo previamente combinado, este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico Sprint.
É importante que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela estará comprometida a finalizar tais tarefas. Os seus membros são quem deverão escolher com o que irão se comprometer e deverá mantê-la e organizá-la de tal forma a atender os objetivos. Nesse momento as tarefas maiores são subdivididas em partes menores.
Logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado com o total previsto anteriormente no Product Backlog. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente o número correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso.
Este método de liderança é exercido através de recorrentes tipos de reunião:
• Scrum Planning Meeting: É o início de uma Sprint, onde o Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento e a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe um Product Increment a ser entregue ao cliente ao final do Sprint.
Esta reunião é realizada com a presença do Product Owner, Scrum Master (líder facilitador do projeto), de todo Scrum Team (equipe), e quaisquer interessados, diretores ou representantes do cliente. Durante a reunião o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, e este faz as perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint Backlog.
A reunião Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. O Scrum Team reúne-se separadamente para discutir o que foi dito e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer.
• Daily Scrum Meeting: O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Scrum Daily Meeting é a resposta para promover a comunicação da equipe. É um encontro diário realizado pela equipe e o Scrum Master onde os membros discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia do rumo”.
São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente pela manhã, duram de 15 a 30 minutos, para responder a importantes perguntas:
• O que eu fiz desde a última Scrum Daily Meeting até agora?
• O que eu vou fazer hoje?
• O que pode me impedir?
As Daily Scrum Meeting não representam uma forma de cobrança vinda de um gerente de projetos, mas é uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que podem estar interferindo no bom andamento do Sprint.
• Criação do Product Increment: A finalização das funcionalidades definidas para um determinado Sprint marca a realização de um Product Increment. Os membros da equipe trabalham de maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint.
• Sprint Review: é uma reunião tipica de final de Sprint, neste momento a equipe exibe o Product Increment, potencialmente utilizável que foi construído, ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se torne adequado aos anseios do cliente. Os participantes desta reunião incluem tipicamente: o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos. O ideal é que a equipe tenha concluído todos os itens do Product Backlog alocados para o Sprint.


• Sprint Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Acontece apos a revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a equipe. Esta objetiva identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os problemas encontrados com o propósito de aperfeiçoá-los.

Nessa reunião é debatido o que funcionou na Sprint, o que precisa ser melhorado e quais ações devem ser tomadas para colocar as melhorias em prática. Geralmente o Sprint Retrospective tem de três a quatro horas de duração.

• Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado de acordo com os itens mais prioritários.
Os principais artefatos produzidos no processo do Scrum são o Product Backlog, Sprint Backlog, Burndown Chart e o TaskBoard.
O Burndown Chart é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo.
Com o Burndown Chart podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído.
Este dado estimativo pode ser comparado com o prazo que o Scrum Master definiu para que possamos saber se o projeto vai acabar ou não no prazo.
Este é um dos mais importantes trabalhos que o Scrum Master terá que fazer e o Burndown Chart é o indicador perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento.
O taskboard é um grande painel onde podem ser colocadas várias informações importantes para o acompanhamento do Sprint. O Sprint Backlog, ou seja, as atividades não iniciadas, as que estão em andamento e as concluídas ficam sempre visíveis e disponíveis para todos os interessados no projeto.
Algumas características das equipes de desenvolvimento são:





Processo





Ciclo de Trabalho













SCRUM FDD CASCATA

REUNIÃO P P P

DOCUMENTAÇÃO P P P

A.REQUISITOS P P P

MUDANÇAS / PLANEJAMENTO PP P PP


PRAZO E CUSTO
NP NP P













Vantagens Desvantagens
Cascata O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. Pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.

FDD Recomendado para qualquer tipo de desenvolvimento.
Foco em características de valor para o cliente
FDD prioriza aquilo que o cliente prioriza
FDD possui requisito maus formais Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção

Scrum Velocidade.
Motivação maior dos programadores.
Evita surpresas com os resultados.
Diminuição dos Bugs. Prioridade podem ser alteradas.
Funcionalidade que agregam valor, veem primeiro. Sensação de informalidade;
Prazo.
Falta planejamento de escopo