Blog

uUNIVERSlDADE TIRADENTES – UNIT ADAUTO CAVALCANTE ALISSON BUSS DAVYS DE UVEIRA SOUZA BARBOSA WILLIANY WILSON WILLIAN ALVES DA MOTA FEATURE DRIVEN DEVELOPMENT (DESENVOLVIMENTO GUIADO POR FUNCIONALIDADES) 1 orlo to view nut*ge Aracaju 2012 ADAUTO WI LIAN ALVES DA MOTA Trabalho apresentado à IJniversidade Tiradentes Como medida de Eficiência. IGOR OLIVEIRA projeto, codificação, teste e documentação. Um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores tecnicos e gerentes. Fowler). Martln É recomendada a produção de documentação que realmente erá útil. As metodologias ágeis sugiram devido aos problemas de atraso no desenvolvimento de software, ou seja, um software que demore muito para ser desenvolvido tende a ficar desatualizado de acordo com os planejamentos. Houve outro método como o “método estruturado” em 1 980, criado para resolver também este tlpo de problema, mas mesmo assim os problemas continuaram, foi a partir daí que surgiu a metodologia ágil nos anos 90 justamente com o propósito de suprir aos grandes e pesados projetos. Martin Fowler) A metodologia ágil tem várias vantagens, pois divide-se em processos: – Develop an Overall Model – é nada mais nada menos que criar um modelo ou estrutura do programa de acordo com os requisitos e funcionalidades descritas pelo cliente. 2- Build by Feature List – é criar uma lista detalhada de todas as funcio 10 descritas pelo cliente. funcionalidades. 3- plan and By Feature – planejar como devem ser desenvolvidas as features ou funcionalidades. – Design By Feature — é analisar de maneira detalhada um diagrama seqüencial que irá se seguir no desenvolvimento das 5- Build and Feature – é onde faz todas as alterações necessárias para ser possa. ‘el se desenvolver uma funcionalidade. Oeff DeLuca, Peter Coad ) 2- Metodologia Ágil Agilidade é uma proposta de desenvolver projetos com uma estrutura e organização “suficientes”. Muita estrutura e organização reduzem a criatividade e a flexibilidade de suportar mudanças, pouca estrutura e organização permeiam a ineficiência e resulta em esforços maiores que os necessários.

A diferença entre caos e agilidade pode ser verificada nos produtos resultantes. Considerando o mesmo cenário turbulento de negócios, nas equipes que convivem com o caos verificamos atrasos constantes, balxissima qualidade dos sistemas, problemas om estimativas e estouro de orçamento. Nas equipes que utilizam-se de métodos ágeis percebemos entregas parciais constantes, interação com clientes para revisão de estimativas e orçamento conjuntamente com antecedência salutar ao projeto e principalmente dois pontos fundamentais: compromisso com a satisfação do cliente e responsabilidade com o resultado financeiro do projeto.

Project Management, 2002) 2. 1 Um pouco sobre Scrum (Highsmith, Jim. Agile Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. um rocesso á il para construir software incrementalmente em am software. ? um processo ágil para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita frequência. No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box 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 são chamadas de Sprints no caso do Scrum. 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 Ownerprioriza 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 gacklog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inlcia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meetings Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint.

Assim reinicia-se o ciclo. Veja a ilustração abaixo: 3- Features (Funcionalidades) É uma característica ou funcionalldade do sistema que representa algum valor para o cliente. 3. 1- Estrutura das Feature: Feature: ;ação;;resultado;;objeto; Exemplos de Features * Calcular o desconto de uma venda; * Validar a senha de um usuário; * Imprimir a nota fiscal de uma venda; 4_ papéis Existem vários papéis desempenhados no FDD. Todos assumem algum tipo de papel, e um mesmo integrante pode desempenhar mais de um deles.

Eles estão divididos em três classes que são: papéis principais, secundários e adicionais. Dentre os papéis principais encontram-se: * Arquiteto Chefe É o componente com experiência em modelagem de objetos que tem a responsabilidade de guar os desenvolvedores. ‘k Programador Chefe O programador chefe é o responsável por uma equipe pequena e pela divisão e atribuição de trabalho entre os membros dela. Deve ser um programador experiente, pois é de sua esponsabilidade a escolha das features a implementar em cada iteração e as respectivas classes e métodos necessários.

Vai ser ele também que faz o relatório da atividade da equipe semanalmente e trata dos problemas técnicos e de recursos com os outros programadores chefe. * Experts em Domínio Responsável por prover todas as informações necessárias a respeito de área de dom[n e modelagem destes. juntamente com o Gerente de Desenvolvimento e os Programadores Chefe planeja a ordem que as funcionalidades serão implementadas. * Gerente de Desenvolvimento Assim como o Gerente de Projeto e os Programadores Chefe, ? incumbido de planejar a ordem em que as funcionalidades são implementadas, além das tarefas comuns a Gerentes de Desenvolvimento.

Dentre os papéis secundários encontram-se: Gestor de Atividade O gestor de atividade recebe os relatórios de atividade os vários programadores chefe e vai mantendo o gestor do projeto informado de toda a alteração que ocorra no mesmo. * Guru da Linguagem O guru da linguagem é um papel importante quando se trabalha com linguagem ou tecnologias novas. Faz-se necessário que este componente tenha um amplo domínio de diversas linguagens e tecnologlas mais recentes. ‘k Especialista da Área O especialista da área é alguém que conhece o assunto sobre o qual a aplicação atua.

Está envolvido na decisão do preço do programa e é ele que assegura que o sistema seja competente dentro da área, passando a quem desenvolve o programa os conhecimentos necessários. O especialista da área pode ser um cliente, um analista de negócio, um patrocinador ou um utilizador. ‘k Engenheiro de Buildes O engenheiro de buildes é o responsável por criar e manter o processo de build para as varias versões incluindo a documentação respectiva. PAGF 10 todos os casos de utilização exaustivamente e verificar se o istema é sólido, resistente a erros e se preenche os requisitos do cliente. Suporte O trabalho de suporte consiste em converter a informação para o formato necessário a um novo sistema e a novas releases do programa. * Documentador O documentador cria os manuais técnicos e de utilização indispensáveis para o usuário e suporte técnico. Processos da FDD Todos esses conceitos e práticas apresentadas nos parágrafos anteriores são usados dentro de um fluxo simples e conciso de cinco processos. Esses processos acontecem em duas fases iterativas: a primeira é chamada de Concepção e Planejamento e a segunda é chamada de Construção.

A Figura abaixo exibe uma visão geral de como essas fases se relacionam. para entender detalhadamente como essas fases se relacionam, é necessário conhecer quais processos estão contidos em cada uma. Veja na Figura acima, que a primeira etapa (Concepção e Planejamento) atua com o objetivo de proporcionar um entendimento inicial e abrangente do escopo, bem como, possibilitar um planejamento macro de entregas durante as iterações. Nessa etapa de planejamento acontecem os seguintes * Develop Overall Model (Desenvolver um Modelo Abrangente): esse processo o time dará início ao entendimento do escopo do produto que será desenvolvido. ara que isso aconteça, é possível utilizar o conceito de FBS, de forma que seja possível entender as primeiras Áreas de ne ócio e principais Atividades de negócio que o produto ém é possível utilizar a entendimento em alto grau de abstração do comportamento e integração das áreas e atividades do produto; * Build Features List (Construção da Lista de Funcionalidades): nesse processo o entendimento do escopo é ampliado através da descoberta das features de cada uma das áreas e atividades ais prioritárias.

Neste ponto, assim como explicado no tópico sobre FBS, começamos a ampliar o conteúdo da FBS através da identificação das funcionalidades do produto a ser implementado; * Plan by Feature (Planejar por Funcionalidade): munidos com a FBS de pelo menos uma pequena parte do produto, o time poderá planejar de que forma, como e quando (em qual iteração) serão implementados e entregues os requisitos.

Já na fase de Construção, o time poderá focar de maneira iterativa no desenvolvimento e entrega das funcionalidades da FBS. Esta fase possui dois processos, são eles: Design by Feature (Desenho por Funcionalidade): Aqu cada funcionalidade é modelada de acordo com a necessidade arquitetural do produto.

Nesse ponto o time poderá prototipar telas, esboçar ou especificar diagramas de classes, de sequência ou qualquer outra ferramenta de modelagem que o time precise para ampllar o aprendizado da funcionalidade em questão (usando ou não a técnica da UML em Cores); ‘k Build by Feature (Construção por Funcionalidade): como esse processo acontece na iteração de construção, é aqui que o código referente a cada funcionalidade do produto é realmente desenvolvido pelo time. Suporte a grandes projetos Conforme seu criador Jeff De Luca, o FDD foi originalmente proposto em um cenário onde havia um grande número de pessoas envolvidas no projeto, sendo este um projeto de grande porte. Devido a est grande número de pessoas envolvidas no projeto, sendo este um projeto de grande porte.

Devido a este fato, é evidente que o FDD por sua natureza possa ser utilizado para desenvolver projetos grandes e suportá-los de uma maneira satisfatória. podemos destacar certas características que facilitam sua implementação em projetos de grande magnitude, como por exemplo, o fato e todo o projeto ser dividido em pequenas partes que são as funcionalidades, onde um grupo de programadores é dividido em pequenas equipes, que desenvolverão as mesmas.

Por sua vez, estas funcionalidades são liberadas tão logo quanto são finalizadas, podendo ser prontamente testadas pelo usuário na forma de protótipos, ou seja, em um grande projeto, o cliente não terá de esperar até que o produto esteja totalmente pronto para poder utilizá-lo, fator imprescindível no caso do projeto demorar vários meses para sua versão final. – Integração entre processos No FDD temos cinco atividades principais para a construção do oftware, torna-se necessário o processo de integração entre as partes, desta forma havendo uma passagem segura de uma atividade a outra, e uma sólida base de declsão apoiando o fluxo entre as atividades. O FDD provê uma bela integração entre suas cinco atividades, cada fluxo de uma atividade a outra foi modelado adequadamente para permitir um ciclo de vida eficiente na construção do sofware. – Ferramentas de workflow De acordo com JeffDe Luca o criador do FDD, a primeira implementação foi criada no inicio de 1998 por Herman Veluwenkamp, e foi melhoradas graças aos requerimentos do róprio Jeff e dos feedbacks de seus usuários. Cecilia Kiew e Stephen Palmer são nomes que contribuíram significativame feedbacks de seus usuários. Cecilia Kiew e Stephen Palmer são nomes que contribu(ram significativamente para o projeto.

O Nebulon Tracking System desenvolvido por paul Szego, é atualmente o sistema oficial do FDD, este sistema foi desenvolvido utilizando a linguagem de programação Java. Ele possui uma variedade de ferramentas de automatização dos processos de FDD, além de planilhas e gráficos para facilitar a analise do andamento das atividades pelos gerentes. Uma outra ferramenta FDD que obteve destaque foi a criação da Sausage Interactive, uma empresa de desenvolvimento de websites.

De fato os desenvolvedores da Sausage receberam treinamento da Nebulon e passaram a utillzar o FDD para a desenvolvimento de sites, em seguida automatizaram sua tarefa construindo sua própria ferramenta. 8- Certificação Atualmente, você consegue uma certificação FDD Aware(consciente) através de qualquer uma das duas oficinas de formação FDD, bastando concluir com êxito uma das oficinas. Ao concluir as duas oficinas, você adquiri a certificação FDD Associate(associado) que é a base essencial.

Jeff De Luca informa em seu site que para adquirir certificações ao nível Practicing você deve entrar em contato no site através do fale conosco, lembro que estas certificações são individuais e que não há certificações para a organização. Para obter uma oficina credenciada Jeff De Luca recomenda visitar o site www. nebulon. com pois o mesmo consta informações mais atualizadas e consta inclusive oficinas públicas, o nebulon. com é uma empresa liderada por Jeff De Luca credenciada a prover treinamentos FDD com emissão de certlficados.