Metodologias Ágeis - FDD - Douglas F Charao

Prévia do material em texto

Metodologias Ágeis: Feature Driven Development (FDD)
Douglas Friedrich Charão
Sistemas de Informação – Centro Universitário Franciscano (UFN) douglas.fcharao@ufn.edu.br 
Resumo. Este artigo tem como objetivo apresentar a metodologia de desenvolvimento ágil Feature Driven Development desde o contexto de sua criação, suas características, estrutura, aplicabilidade, seus benefícios e desvantagens e estudo de caso. 
Introdução 
É concreta a aceitação das metodologias de desenvolvimento ágil, há empresas que ainda se utilizam de metodologias legadas ou sequer utilizam metodologia, porém cada vez mais as metodologias ágeis ganham seu espaço no desenvolvimento de software.
Existem metodologias ágeis aplicadas em diversos ramos empresariais, e neste artigo iremos focar no Feature Driven Development (do acrônimo, Desenvolvimento Guiado por Funcionalidades) ou simplesmente, FDD.
Assim temos a apresentação na seguinte forma: na seção 2 é apresentada a metodologia FDD, bem como suas características, boas práticas e benefícios; no tópico 3 é descrita a estrutura da metodologia, composta por suas fases e processos; no tópico 4 é discutida a utilização do Scrum em conjunto ao FDD; por fim, no tópico 5, são expostas algumas ferramentas que podem ser utilizadas junto à metodologia. 
Metodologia FDD 
Segundo Prikladnucki, et al., (2014): Entre 1997-1999, em Cingapura, um importante banco internacional, o UOB (United Overseas Bank), precisava de uma completa reengenharia de sua plataforma de empréstimos para corporações, comércio e consumidores, abrangendo os mais diversos instrumentos. Era um projeto complexo e o maior desse tipo na região. Após quase dois anos de consultoria, 3.500 páginas de casos de uso documentados, mas com pouquíssimos softwares em execução, um dos membros da equipe, Jeff de Lucca, aceitou o desafio e convenceu a diretoria do banco a tentar mais uma vez, agora sob sua liderança e com uma pequena equipe de talentos de classe mundial para desenhar o sistema, treinar e ser mentores de outros. Ele já́ adotara um processo leve e altamente iterativo em outros projetos e estava disposto a experimentar novas estratégias.
O Desenvolvimento Guiado por Funcionalidade é uma metodologia para o processo de engenharia de software, que foi elaborada com foco na entrega frequente de software e na utilização de boas práticas durante o ciclo de seu desenvolvimento. Também foi uma das metodologias de desenvolvimento de software que serviram de base para se cunhar o termo metodologia ágil.
	Apesar de existirem atividades relacionadas ao gerenciamento de projetos, o FDD não é considerado apropriado para este objetivo, e por isto, é semelhante à metodologia XP. Devido a estas finalidades explicitas, o FDD é muitas vezes utilizado com o Scrum para o desenvolvimento de software, visto que o Scrum fornece um processo de trabalho, concentrando-se no gerenciamento do projeto como um todo.
	Carecido ao fato de a metodologia ser regida por funcionalidades (do inglês, feature), é necessário conhecer alguns pré-conceitos acerca desta questão. A feature deve ter uma granularidade que não ultrapasse o tamanho de uma iteração, ou seja, se foi definido que o projeto terá iterações de quatro semanas, não será possível possuir funcionalidades que precisem de mais tempo para serem desenvolvidas. Quando ocorre alguma situação deste tipo, uma feature deve ser decomposta em outras.
	Algumas características e benefícios concernentes a metodologia são:
1. Resultados úteis a cada duas semanas ou menos;
1. Blocos pequenos de funcionalidade valorizada pelo cliente, chamados de Features;
1. Planejamento detalhado e guia para medição;
1. Rastreabilidade e relatórios com precisão;
1. Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes, tudo em termos de negócio;
1. Fornece um conhecimento, no início do projeto, se o plano e a estimativa são sólidos;
1. Favorece fortemente o envolvimento de clientes ao processo de planejamento e desenvolvimento do software.
2.1. Papéis
Enquanto que o XP e Scrum não possuem papéis definidos relacionados ao desenvolvimento (por exemplo, programador ou gerente de projeto), o FDD possui três tipos de papéis:
1. Principais: gerente de projeto, arquiteto chefe, gerente de desenvolvimento, programador chefe, proprietário de classe e especialista de domínio;
1. Apoio: gerente de domínio, gerente de versão, especialista da linguagem, coordenador de construção e administrador de sistema;
1. Adicionais: testadores (testes), desenvolvedores e escritores técnicos.
2.2. Boas práticas
O FDD possui as chamadas melhores práticas que indicam boas práticas ao desenvolver com o FDD, são elas:
1. Modelagem Orientada a Objetos do Domínio;
1. Desenvolvimento por funcionalidade;
1. Classe proprietária, ou seja, a unidade é feita individualmente, evitando-se assim conflitos na equipe;
1. Equipes de recursos: são equipes pequenas, destinadas a desenvolver recursos necessários ao projeto, de forma secundária;
1. Uma inspeção é realizada constantemente para garantir a boa qualidade do código e do projeto;
1. Integração contínua para demonstrar constantemente as funcionalidades ao cliente;
1. Visibilidade de progressos e resultados. 
Estrutura e organização da metodologia 
Neste tópico, apresenta-se a estrutura da metodologia FDD, a qual possui apenas duas fases:
1. Concepção e planejamento: nesta fase, é desenvolvido um modelo abrangente, construída uma lista de funcionalidades e realizado o planejamento por funcionalidade.
1. Construção: nesta fase é realizado o detalhamento e construção por funcionalidade.
Figura 1. Organização da metodologia FDD
3.1. Processo 1: Desenvolver um Modelo Abrangente
É uma atividade inicial que abrange todo o projeto, realizada por membros do domínio do negócio e por desenvolvedores, sob a orientação de um modelador experiente.
	Realiza-se um estudo dirigido sobre o escopo do sistema e um detalhamento sobre o domínio do negócio para cada área a ser modelada. Após isso, pequenos grupos são formados por membros do domínio do negócio e desenvolvedores, que comporão seus próprios modelos que satisfaçam o domínio em questão. Os pequenos grupos apresentam seus modelos para serem revisados por parceiros e para discussão. Um dos modelos propostos, ou uma combinação dos modelos, é selecionada por consenso, tornando-se assim, o modelo para aquela área do domínio do negócio.
	O modelo de objetos é, então, iterativamente atualizado em seu conteúdo pelo processo quatro (Detalhar por Funcionalidade).	
	O resultado do processo é o modelo de objetos, composto por: diagramas de classes com foco na forma do modelo, métodos e atributos identificados são colocados nas classes, diagramas de sequência (se houver), comentários sobre o modelo para registrar o motivo pelo qual uma forma foi escolhida e/ou quais alternativas foram consideradas.
3.2. Processo 2: Construção da Lista de Funcionalidades
É uma atividade inicial que abrange todo o projeto, para identificar todas as funcionalidades que satisfaçam os requisitos.
	Uma equipe, geralmente composta apenas por programadores líderes do processo um, é formada para decompor funcionalmente o domínio em áreas, atividades de negócio dentro delas e passos dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades. 
	O resultado do processo é uma lista de funcionalidades, composta por: uma lista de áreas, para cada área deve haver uma lista de atividades de negócio, para cada passo de atividade deve haver uma funcionalidade.
3.3. Processo 3: Planejamento por Funcionalidade
É uma atividade inicial que abrange todo o projeto, para produzir o plano de desenvolvimento. 	
	O gerente do projeto/desenvolvimento e programadores líderes planejam a ordem na qual as funcionalidades serão implementadas, baseada nas dependências entre elas, na carga de trabalho da equipe e também na complexidade.
	O resultado do processo é o plano do desenvolvimento, consistindo em: atividades de negócio com datas de término, programadoreslíderes atribuídos a atividades de negócio, lista das classes e seus respectivos desenvolvedores proprietários.
3.4. Processo 4: Detalhamento por Funcionalidade
É uma atividade para cada funcionalidade, para produzir o pacote de projeto (design) para a funcionalidade.
	Um número de funcionalidades é agendado para desenvolvimento ao atribuí-las a um programador líder. Ele seleciona as funcionalidades para desenvolvimento a partir de sua “caixa de entrada” de funcionalidades atribuídas. Operacionalmente, com frequência acontece o caso de conjuntos de funcionalidades serem agendadas para desenvolvimento de uma vez pelo programador líder. Tal conjunto é chamado de Pacote de Trabalho do programador líder.
		O programador líder, então, forma uma equipe de funcionalidades, identificando os proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz diagramas de sequência para as funcionalidades atribuídas. O programador líder, então, refina o modelo de objetos, baseado no conteúdo do diagrama de sequência.
3.5. Processo 5: Construção por Funcionalidade
É uma atividade para cada funcionalidade, para produzir uma função com valor para o cliente. Começa com o pacote de projeto (design), de forma que os proprietários implementem os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção. Depois de inspecionado, o código é promovido à versão atual (build).
		O resultado do processo é: classes e/ou métodos que passaram na inspeção de código com sucesso, classes que foram promovidas à versão atual e o término de uma função com valor para o cliente.
Utilização do FDD em conjunto com o Scrum 
O Scrum e FDD são complementares em muitos aspectos, de forma que o primeiro pode ser utilizado para o gerenciamento do projeto e o segundo, para desenvolvimento do sistema. 
Figura 2. União das metodologias FDD e Scrum
Percebe-se na figura 2 a junção das principais características de cada metodologia. 
1. O resultado da fase de concepção e planejamento do FDD é o Product Backlog do Scrum.
1. O sprint, geralmente de 2 a 4 semanas, é realizado por meio da fase 2 do FDD, chamada de Construção.
A ideologia de gestão do projeto presente no Scrum é mantida por meio do planejamento do sprint, revisão do sprint e retrospectiva do sprint, além das reuniões diárias em pé. 
Ferramentas de aplicação 
A utilização do FDD em um projeto torna recomendável o uso de uma ferramenta que permita organizar todas as implementações que se deseja criar, sendo possível a inclusão e diferenciação de todas os componentes necessários para as novas funcionalidades.
Com o uso de uma ferramenta, é possível maximizar as vantagens do FDD, essencialmente, no sentido de evitar custos extras, como também de tempo gasto em criação de componentes desnecessários.
		Algumas das ferramentas disponíveis são: FDD Manager, MagicDraw, OptimalJ, Poseidon, Rose, Simply Objects, Together, Enterprise Architecht.
Estudo de caso 
O estudo de caso escolhido foi apresentado como trabalho final de graduação para obtenção de título de bacharel de Sistemas de Informação pelo autor Mauro Rodrigues Oviedo II.
6.1. Desenvolvimento de uma aplicação Android para avaliação dimensional corporal e requerimento energético em pacientes hospitalizados
O trabalho apresenta o desenvolvimento de um aplicativo, para a plataforma Android, com a finalidade de auxiliar o profissional nutricionista em suas rotinas administrativas. 
A metodologia escolhida para a elaboração do presente trabalho foi a Feature Driven Development. 
O aplicativo foi desenvolvido na linguagem de programação Java e para armazenamento de dados e autenticação de usuários foi utilizado respectivamente o Firebase Realtime Database e Firebase Authentication. 
Através do desenvolvimento deste aplicativo, pretende – se melhorar e agilizar as rotinas administrativas do profissional nutricionista.
6.1.1 Desenvolvimento de modelo abrangente
O modelo abrangente nada mais é do que o diagrama de domínio, que mostra a visão simplificada do todo.
Figura 3. Diagrama de Domínio
Representando a visão macro do sistema, contendo tópicos significativos para o funcionamento do sistema. O nutricionista registrará o paciente utilizando o sistema e realizará a avaliação nutricional que medirá a necessidade energética do paciente. 
6.1.2 Construção da lista de funcionalidades
Com base no modelo abrangente, é realizado a coleta dos requisitos funcionais e não funcionais necessários para a construção e cumprimento das necessidades do cliente.
Entende-se como funcionalidade tudo aquilo que é possível fazer utilizando o sistema. 
1. RF01 - Controle de Usuário: O sistema deverá gerenciar funções de cadastro, alteração e exclusão de usuário; 
1. RF02 - Controle de Paciente: O sistema deverá gerenciar funções de cadastro, alteração e exclusão de paciente; 
1. RF03 - Avaliação Nutricional: O sistema deverá realizar a avaliação nutricional do paciente através de cálculos e estimativas e gerar um resultado indicando a situação do paciente. 
Após os requisitos funcionais serão abordados os requisitos não funcionais. 
1. RNF01 – Utilizar a linguagem de programação Java; 
1. RNF02 – Salvar os dados em ambiente cloud. 
 As funcionalidades citadas estão sendo representadas pelo Diagrama de Caso de Uso na Figura 4. 
 
Figura 4. Diagrama de Caso de Uso
6.1.3 Planejamento por funcionalidade
Tendo em vista a lista de funcionalidades, é feito o planejamento das mesmas conforme mostra a tabela 1, organizando cada funcionalidade na ordem que foi desenvolvida, ordem esta que depende da complexidade de cada funcionalidade e seu tempo. Também foi desenvolvido o diagrama de caso de uso conforme mostra figura 4 e os seus respectivos descritivos conforme tabela 2 e 3, que é utilizado para descrever as principais funcionalidades do sistema, mostrando a interação destas com o usuário. 
Tabela 1. Planejamento por Funcionalidade 
	Ordem 
	Funcionalidade 
	Tempo 
	Complexidade 
	Relevância 
	01 
	RF01 - Controle de Usuário. 
	10 Dias 
	Baixa 
	Essencial 
	02 
	RF02 - Controle de Paciente. 
	15 Dias 
	Média 
	Essencial 
	03 
	RF03 - Avaliação Nutricional 
	20 Dias 
	Média 
	Essencial 
 	O descritivo de caso de uso, a seguir, descreve a funcionalidade Realizar Avaliação Nutricional. 
Tabela 2. Caso de Uso 01 – Realizar Avaliação Nutricional 
	Identificação 
	UC01 
	Caso de Uso 
	Realizar Avaliação Nutricional 
	Descrição 
	Possibilita ao nutricionista realizar a avaliação nutricional a fim de descobrir as necessidades energéticas do paciente. 
	Fluxo Principal [FP] 
	1. O usuário faz o login no sistema; 
1. O usuário coleta as dimensões corporais do paciente ou utiliza as dimensões corporais já cadastradas; 
1. O usuário seleciona qual o tipo de avaliação que deseja realizar; 
1. O sistema realiza os cálculos de acordo com o tipo selecionado; 
1. O sistema apresenta o resultado na tela; 
1. Fim do Caso de Uso. 
	Fluxo Alternativo [FA] 
	- 
O descritivo de caso de uso abaixo descreve o funcionamento da funcionalidade Gerenciar Paciente. 
Tabela 3. Caso de Uso 02 – Gerenciar Paciente 
	Identificação 
	UC02. 
	Caso de Uso 
	Gerenciar Paciente. 
	Descrição 
	Possibilita ao nutricionista realizar o cadastro, alteração e exclusão do paciente. 
	Fluxo 
Principal 
[FP] 
	1. O usuário faz o login no sistema. 
1. O usuário seleciona a opção desejada: Cadastrar [FA1], Alterar [FA2], Excluir [FA3]. 
1. Fim do caso de uso. 
	Fluxo de exceção [FE] 
	1. Paciente cadastrado 
a. O sistema verifica se o paciente já está cadastrado. Em caso positivo, retorna ao [FA1b]. 
	Fluxo 
Alternativo 
[FA] 
	1. Cadastrar 
0. O usuário seleciona a opção de cadastro de paciente; 
0. O usuário preenche o formulário de cadastro [FE1]; 
0. O sistema insere os dados do paciente no banco de dados; 
0. O sistema apresenta mensagem na tela; 
0. O sistema retorna ao [FP2]. 
1. Alterar 
1. O usuário selecionaa opção de alteração; 
1. O usuário escolhe o paciente; 
1. O usuário redefine os dados cadastrais do paciente; 
1. O sistema atualiza os dados do paciente no banco de dados; 
1. O sistema apresenta uma mensagem na tela; 
	
	f. O sistema retorna ao [FP2]. 
3. Exclusão 
1. O usuário faz login no sistema; 
1. O usuário seleciona a opção de exclusão; 
1. O usuário escolhe o paciente; 
1. O sistema move o paciente para a tabela de histórico no banco de dados; 
1. O sistema apresenta uma mensagem na tela; 
1. O sistema retorna ao [FP2]. 
6.1.4 Detalhamento por Funcionalidade
Após o planejamento das funcionalidades, é preciso realizar o detalhamento das mesmas, e para isso, foram criados o Diagrama de Classe, presente na Figura 5, e o Diagrama de Atividades na figura 6. Neste detalhamento não foi desenvolvido o Diagrama de Entidade-Relacionamento (DER). 
 
Figura 5. Diagrama de Classes. 
 
Figura 6. Diagrama de Atividades 
6.1.5 Construção por Funcionalidade
Nesta última etapa ocorreu então a implementação dos requisitos utilizando a linguagem de programação Java. 
Considerações finais 
Os processos ágeis têm evoluído ao longo dos anos em maturidade e número de adeptos, principalmente pela filosofia de resultados mais rápidos para o cliente, uma vez que este acompanha todo o processo de desenvolvimento.
	Utilizando somente a metodologia FDD em projetos de desenvolvimento de software, é possível perceber bons resultados, desde o encantamento do cliente até um ambiente saudável entre a equipe. No entanto, a característica mais marcante do FDD é flexibilidade na sua aplicação, podendo atuar em conjunto com outras metodologias, principalmente com o Scrum e desta forma, encaixando-se perfeitamente como metodologia de engenharia ágil de software.
		Muitos são os casos de sucesso da união do FDD e Scrum e por isto, conclui-se que sua utilização pode trazer um grande ganho para o projeto. 
 
Referências 
BARBOSA, Antônio; AZEVEDO, Bruno; PEREIRA, Bruno; SANTOS, Pedro. (2008) Metodologia Ágil: Feature Driven Development. Disponível em: 
<https://docplayer.com.br/1330073-Metodologia-agil-feature-driven-development.html>. Acesso em 01 de set. 2019.
GOMES, Fábio. “Introdução ao FDD - Feature Driven Development”. (2013) Disponível em:<http://www.devmedia.com.br/introducao-ao-fdd-feature-drivendevelopment/27971> Acesso em 01 de set. 2019.
OVIEDO II, Mauro Rodrigues. “Desenvolvimento de uma aplicação Android para avaliação dimensional corporal e requerimento energético em pacientes hospitalizados”. (2018) Santa Maria. 
PRIKLADNUCKI, R., Willi, R. e Milani, F., (2014), “Métodos Ágeis para Desenvolvimento de Software”. Porto Alegre: Editora Bookman. 
RAMSIN, Raman e R. Mahdavi-Hezave. (2015) “FDMD: Feature-Driven Methodology Development”. 2015 International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE), Barcelona, 2015, pp. 229-237. 
ROBASKI, José Ricardo. (2014) “FDD (Feature Driven Development)”. Disponível em: <https://medium.com/@jrobaski/fdd-feature-driven-development-7d08c5c24c8f>. Acesso em 01 de set. 2019.