[ATPS] Etapa1

ATPS 1ª ETAPA

O

Ronaldo C. Cavalcanti RA: 0901395323

Bruno Luiz RA: 0919440340

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

A FDD é, classicamente, descrita por cinco processos:

• Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
• Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
• Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.
• Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
• Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário

É 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 Antigo e bem conhecido processo é o Modelo em cascata, onde os desenvolvedores (a grosso modo) seguem estes passos em ordem. Eles estabelecem os requisitos, os analisam, projetam uma abordagem para solução, arquitetam um esboço do software, implementam o código, testam (inicialmente os testes unitários e então os testes de sistema), implantam e mantêm. Depois que cada passo é terminado, o processo segue para o próximo passo, tal como construtores que não revisam as fundações de uma casa depois que as paredes foram erguidas. Se as iterações não são incluídas no planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo, nos requisitos), então o processo inteiro da engenharia de software deve ser executado até o fim, resultando em funcionalidades de software desnecessárias ou sem uso.Para isso tem que se fazer o implemento dos requisitos anteriormente analisados pelo programador.

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

O que é Scrum?

Scrum é uma metodologia ágil para gerência de projetos. Ela é baseada em ciclos de 30 dias chamados Sprints, onde se trabalha para alcançar objetivos bem definidos. Estes objetivos são representados no Product Backlog, uma lista de coisas para fazer que é constantemente atualizada e repriorizada.

Quais são os papéis?

• Equipe: responsável por entregar soluções, geralmente é formada por um grupo pequeno (entre 5 e 9 pessoas) e que trabalha de forma auto-gerenciada;
• Product Owner: responsável pela visão de negócios do projeto, é ele quem define e prioriza o Product Backlog. Geralmente é o papel desempenhado pelo cliente;
• Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência.
• Como funciona?

• Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.
• Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser entregues são agora tratados no Sprint Backlog. As tarefas agora são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas.
• Reuniões Diárias: o Scrum Master se reune diariamente com a Equipe num mesmo horário, para que se reporte:
• O que foi feito ontem?
• O que se pretende fazer hoje?
• Quais são os impedimentos que estão atrapalhando a execução das tarefas?
• Revisões: no final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint.

Processo

	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
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. Alteração das Prioridades. Funcionalidade que agregam valor.	Sensação de informalidade; Prazo. Falta planejamento de escopo
Cascata	Minimiza o tempo de planejamento. Funciona bem para equipes tecnicamente mais fracas.	Inflexível. Apenas a fase final produz um deliverable que não é um documento. Torna-se difícil voltar atrás para corrigir erros.