Your SlideShare is downloading. ×
TCC FDD Jorge Bublitz
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TCC FDD Jorge Bublitz

1,685

Published on

Trabalho de Conclusão de Curso (Monografia) do Curso de Pós-Graduação em Engenharia de Sistemas

Trabalho de Conclusão de Curso (Monografia) do Curso de Pós-Graduação em Engenharia de Sistemas

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,685
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
94
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB CURSO DE ENGENHARIA DE SISTEMAS JORGE LUIS BUBLITZ DESENVOLVIMENTO ÁGIL DIRIGIDO A FUNCIONALIDADES CUIABÁ – MT 2009
  • 2. JORGE LUIS BUBLITZDESENVOLVIMENTO ÁGIL DIRIGIDO A FUNCIONALIDADES Trabalho de Conclusão de Curso de Pós- Graduação Latu Sensu em Engenharia de Sistemas apresentado a ESAB – Escola Superior Aberta do Brasil sob orientação da Profa. Me. Beatriz Christo Gobbi. CUIABÁ – MT 2009
  • 3. JORGE LUIS BUBLITZDESENVOLVIMENTO ÁGIL DIRIGIDO A FUNCIONALIDADES Aprovado em __ de __________ de 2009. _________________________________ _________________________________ _________________________________ CUIABÁ – MT 2009
  • 4. Dedico este trabalho a todas as pessoasque sempre me apoiaram e me apóiam.Minha esposa pelo esforço e paciênciadurante essa fase de estudos.Ao Prof. Me. Hélio Maluf, que despertouem mim o gosto pela Matemática e conse-quentemente pela Informática.
  • 5. AGRADECIMENTOSAgradeço a Deus por tudo.Aos meus pais pela oportunidade que mederam de estudar e pelo exemplo dado.Ao Adail Heptaman, amigo e mestre FDD.
  • 6. “Antes de partir para a guerra, é de sumaimportância atacar a estratégia inimiga” (Sun Tzu)
  • 7. RESUMOO estudo tem como objetivo verificar e comprovar se uma metodologia ágil dedesenvolvimento de software trás realmente agilidade ao processo de produção.Para tal foi realizada uma pesquisa através de estudo de caso: a equipedesenvolveu um software utilizando a metodologia de Desenvolvimento Dirigido aFuncionalidades, sendo este o primeiro projeto que se utilizou essa novametodologia. Até então utilizávamos a técnica de estimativa do prazo dedesenvolvimento por pontos de casos de uso e o desenvolvimento em cascata.Normalmente nossas estimativas de prazo de entrega não se cumpriam e era muitodifícil nos adaptar e responder às mudanças de requisitos que ocorriam durante odesenvolvimento. Verificou-se que alguns membros da equipe tinham dúvidas sobrecomo aplicar a metodologia, apesar de terem passado por um treinamento prévio,além de certa resistência à mudança de metodologia. Através de observações,anotamos a produtividade e o tempo de desenvolvimento e o comparamos com aestimativa da técnica anterior. Concluiu-se que a metodologia realmente cumpre oque propõe, pois mesmo com mudanças nos requisitos do software, o prazo final deentrega foi cumprido, bem como a capacidade da equipe de se adequar asmudanças.
  • 8. LISTA DE FIGURASFigura 1 - The Extreme Chaos Report (2001) ........................................................... 16Figura 2 - Modelo em Cascata .................................................................................. 17Figura 3 – As Fases e os Processos da FDD............................................................ 35Figura 4 - Desenvolver um Modelo Abrangente ........................................................ 36Figura 5 - Construir a Lista de Funcionalidades ........................................................ 40Figura 6 - Planejar por Funcionalidade ..................................................................... 43Figura 7 - Detalhar por Funcionalidade ..................................................................... 47Figura 8 - Construir por Funcionalidade .................................................................... 52Figura 9 - Medindo o Progresso ................................................................................ 54Figura 10 - Quadro de Progresso .............................................................................. 55Figura 11 - Diferenças entre as metodologias ........................................................... 56Figura 12 - Modelo Abrangente ................................................................................. 61Figura 13 - Modelo Abrangente Final ........................................................................ 62Figura 14 - Lista de Funcionalidades ........................................................................ 63Figura 15 - Diagrama de Caso de Uso ...................................................................... 63Figura 16 - Atividades e seus Programadores-Líderes ............................................. 65Figura 17 – A nova Lista de Funcionalidades ........................................................... 67Figura 18 - Quadro de Desenvolvimento ................................................................... 68Figura 19 - Plano de Desenvolvimento ..................................................................... 69Figura 20 - FddViewer e o Parking Lot ...................................................................... 71
  • 9. LISTA DE TABELASTabela 1 - Peso dos Atores ....................................................................................... 25Tabela 2 - Peso dos Fatores Técnicos ...................................................................... 26Tabela 3 - Peso dos Fatores Ambientais .................................................................. 27Tabela 4 - Comparação entre as Metodologias......................................................... 57Tabela 5 - Classes e seus Proprietários .................................................................... 65Tabela 6 - Escala de 5 Pontos da FDD ..................................................................... 67
  • 10. LISTA DE ABREVIATURA E SIGLASAPI Application Programming InterfaceCMM Capability Maturity ModelCMMI Capability Maturity Model IntegrationEF Environmental FactorFASE Formulário de Alteração da Situação do EleitorFDD Feature-Driven DevelopmentFTP File Transfer ProtocolIBGE Instituto Brasileiro de Geografia e EstatísticaOOSE Object-Oriented Software EngineeringRAE Requerimento de Alistamento EleitoralRUP Rational Unified ProcessTCF Technical Complexity FactorTCP/IP Transmission Control Protocol / Internet ProtocolUAW Unadjusted Actor WeightUCP Use Case PointsUUCP Unadjusted Use Case PointsUUCW Unadjusted Use Case WeightUML Unified Modeling Language
  • 11. SUMÁRIO1. INTRODUÇÃO ................................................................................................ 132. FUNDAMENTAÇÃO TEÓRICA ...................................................................... 152.1 METODOLOGIAS DE DESENVOLVIMENTO ................................................. 152.2 MODELO EM CASCATA ................................................................................. 172.3 METODOLOGIA ORIENTADA A OBJETOS ................................................... 182.3.1 Conceitos Fundamentais de Orientação a Objetos ................................. 192.3.2 UML Em Cores ............................................................................................ 212.4 ESTIMATIVA PELO MÉTODO DE CASOS DE USO ...................................... 242.4.1 Calculando o Peso dos Atores do Sistema ............................................. 252.4.2 Calculando o Peso dos Casos de Uso ..................................................... 252.4.3 Calculando Fatores de Ajuste ................................................................... 262.4.4 Fatores Técnicos ........................................................................................ 262.4.5 Fatores Ambientais .................................................................................... 272.4.6 Calculando o Porte do Sistema................................................................. 282.5 METODOLOGIAS ÁGEIS ............................................................................... 292.6 DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES ............................. 312.6.1 As Práticas da FDD .................................................................................... 322.6.2 Os papéis da FDD....................................................................................... 332.6.3 Os Processos da FDD ................................................................................ 342.6.4 DMA – Desenvolver um Modelo Abrangente ........................................... 362.6.5 CLF – Construir a Lista de Funcionalidades ........................................... 392.6.6 PPF – Planejar por Funcionalidade .......................................................... 422.6.7 DPF – Detalhar por Funcionalidade .......................................................... 462.6.8 CPF – Construir por Funcionalidade ........................................................ 512.6.9 Medindo o Progresso do Desenvolvimento ............................................. 54
  • 12. 2.7 COMPARANDO AS METODOLOGIAS ........................................................... 553. ESTUDO DE CASO ........................................................................................ 583.1 EQUIPE DO PROJETO ................................................................................... 593.2 EXECUÇÃO DO PROCESSO ......................................................................... 603.2.1 DMA - Desenvolver um Modelo Abrangente ............................................ 603.2.2 CLF - Construir a Lista de Funcionalidades ............................................ 623.2.3 PPF - Planejar por Funcionalidade ........................................................... 643.2.4 Estimativas ................................................................................................. 674. RESULTADOS ................................................................................................ 705. CONCLUSÃO ................................................................................................. 726. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................... 74
  • 13. 131. INTRODUÇÃOPalavras-chave: Metodologia, Mudança, Agilidade.Na computação, o desenvolvimento de software é o ato de elaborar e implementarum sistema computacional, isto é, transformar a necessidade de um utilizador ou deum mercado em um produto de software (BIRRELL, 1985).Por ser uma atividade caótica em sua maior parte, o desenvolvimento de softwaresnormalmente é um eterno ciclo "programar e depurar". O software é escrito sem umplanejamento claramente definido e o projeto do sistema é repleto de váriasdecisões de curto prazo. Isso funciona muito bem se o sistema é pequeno - mas àmedida que o sistema cresce, torna-se cada vez mais difícil adicionar novosrecursos (funcionalidades) a ele.Defeitos subsequentes se tornam cada vez mais dominantes e cada vez maisdifíceis de serem eliminados. Uma longa fase de testes e depuração depois que osoftware está finalizado é um sinal típico de um sistema desse tipo.Por ser uma atividade cujo tempo é muito difícil, praticamente impossível, de serestimada, a fase de testes entra em confronto direto com o cronograma planejado.Uma das soluções para esses problemas é a adoção de uma metodologia. Com oobjetivo de torná-lo mais previsível e mais eficiente, as metodologias impõemdisciplinas rígidas ao desenvolvimento de software. Elas fazem isso através deprocessos detalhados com uma forte ênfase em planejamento.Um dos principais problemas é que se tem a noção que elas são verdadeiraspanacéias, o que não o são. Outro grande problema nas metodologias tradicionais éque estas são extremamente burocráticas: há tanta coisa a se fazer para segui-lasque o todo o ritmo de desenvolvimento fica mais lento.
  • 14. 14Como uma reação a tais metodologias, um novo grupo delas surgiu nos últimosanos. Durante algum tempo elas foram conhecidas como metodologias leves, masagora o termo mais aceito é Metodologias Ágeis.Agilidade tornou-se então uma palavra quase que mágica quando se descreve umametodologia de software. Tudo é ágil. Uma equipe ágil é uma equipe esperta, capazde responder adequadamente às mudanças. Uma equipe ágil reconhece que osoftware é desenvolvido por indivíduos trabalhando em equipes e que asespecialidades dessas pessoas e sua capacidade de colaborar estão no âmago dosucesso do projeto.Mas a adoção de uma metodologia ágil traz realmente agilidade a uma equipe dedesenvolvimento? E o que seria essa agilidade?Trocar a metodologia tradicional utilizada, que bem ou mal, fornece documentação,estimativa de prazo e consequentemente estimativa de custo, por uma metodologianova não seria arriscado, ou até mesmo irresponsável?Que impactos teríamos na equipe e nos clientes?Verificar e responder essas questões são os objetivos deste trabalho.Adotaremos o Desenvolvimento Dirigido a Funcionalidades (FDD) em uma equipede desenvolvimento que até então sempre utilizou uma metodologia tradicional. Aequipe desenvolverá seu primeiro software utilizando a FDD.Faremos a estimativa de prazo de entrega utilizando a metodologia de Pontos deCasos de Uso. Assim poderemos comparar os resultados e verificar a produtividadede cada desenvolvedor e da equipe como um todo.
  • 15. 152. FUNDAMENTAÇÃO TEÓRICA2.1 METODOLOGIAS DE DESENVOLVIMENTOMetodologia de desenvolvimento de software pode ser considerada um conjunto denormas utilizadas para estruturar, planejar e controlar o processo dedesenvolvimento de software. Uma grande variedade de metodologias tem surgido eevoluído ao longo dos anos, cada uma com suas vantagens e desvantagens.As metodologias foram originalmente propostas para colocar ordem no caos dodesenvolvimento de software. A história tem indicado que esses modelosconvencionais têm trazido certa dose de estrutura útil para o trabalho de engenhariade software e tem fornecido um roteiro razoavelmente efetivo para as equipes dedesenvolvimento.Entretanto, o trabalho de desenvolvimento de software e o produto que ele produzpermanecem no “Limite do Caos”, como é definida por Nogueira (2000, p.5): O limite do caos é definido como um estado natural entre ordem e caos, um amplo compromisso entre estrutura e surpresa. O limite do caos pode ser visualizado como um estado instável, parcialmente estruturado (...). É instável porque é constantemente atraído para o caos ou para a ordem absoluta. Temos a tendência de pensar que ordem é o estado ideal da natureza. Isso pode ser um erro. A pesquisa (...) apóia a teoria de que operação fora do equilíbrio gera criatividade, processos auto-organizados e crescentes retornos. Ordem absoluta significa a ausência de variabilidade, o que poderia ser uma vantagem em ambientes imprevisíveis. A modificação ocorre quando existe alguma estrutura tal que a modificação pode ser organizada, mas não tão rígida que não possa ocorrer. Caos em excesso, por outro lado, pode tornar impossível a coordenação e coerência. A falta de estrutura nem sempre significa desordem.
  • 16. 16Com tudo isso há uma crescente procura por metodologias de desenvolvimento.Entre os vários relatórios e depoimentos existentes, cito particularmente o ExtremeChaos Report, produzido em 2001 pelo Standish Group, largamente utilizado econhecido (Figura 1). Figura 1 - The Extreme Chaos Report (2001) Fonte: Site Standish Group – www.standishgroup.comPodemos ver neste gráfico que apenas 28% dos projetos de desenvolvimento desoftware são concluídos com sucesso, dentro do prazo, custo e qualidadeesperados. Melhorou em relação ao relatório anterior, o “The Chaos Report” de 1994que era de 16%, mas ainda estamos muito longe do poderíamos chamar de ideal.De quem é a culpa desse cenário? Dos processos, das ferramentas, dos analistas,dos desenvolvedores ou dos clientes? Ou é de todos? Ou de ninguém? “Nenhumfloco de neve em uma avalanche se sente responsável”, citando Stanislaw J. Lec(1962), escritor polonês.
  • 17. 172.2 MODELO EM CASCATASegundo Birrel (1985), o modelo clássico ou cascata foi proposto por Winston W.Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitaçãogeral. Esse modelo foi derivado de modelos de atividade de engenharia com o fimde estabelecer ordem no desenvolvimento de grandes produtos de software.Comparado com outros modelos de desenvolvimento, este é mais rígido e menosadministrativo.Esse é um dos mais importantes modelos, e é referência para muitos outrosmodelos, servindo de base para muitos projetos modernos. A versão original destemodelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizadohoje em dia. Neste modelo o desenvolvimento é visto como um fluir continuamentepara baixo, como uma cascata, através das fases de levantamento de requisitos,projeto, implementação, testes e implantação (Figura 2). Figura 2 - Modelo em CascataGrande parte do sucesso do modelo cascata está no fato dele ser orientado paradocumentação. No entanto deve salientar-se que a documentação abrange mais doque arquivo de texto, abrange representações gráficas e simulações.
  • 18. 18Os princípios básicos do modelo em cascata são: 1. O projeto é dividido em fases sequenciais, com algumas sobreposições entre as fases; 2. A ênfase está no planejamento, horários, prazos, orçamentos e implementação de um sistema inteiro; 3. Um controle rígido é mantido ao longo do ciclo de vida do projeto através da utilização de uma vasta documentação escrita, bem como através da aprovação formal de cada fase antes de começar a próxima.Esse modelo de desenvolvimento apresenta os seguintes problemas: 1. Pressão do risco no tempo; 2. Custa muito consertar erros; 3. Cada etapa tem uma documentação que precisa ser aprovada para que se de início a etapa seguinte; 4. Aumenta o risco de cancelamento do projeto; e 5. Esse approach1 tende a mascarar os riscos.2.3 METODOLOGIA ORIENTADA A OBJETOSSegundo Retamal (2009), a orientação a objetos é um paradigma de análise, projetoe programação de sistemas de software baseado na composição e interação entrediversas unidades de software chamadas de objetos.A análise e projeto orientados a objetos têm como meta identificar o melhor conjuntode objetos para descrever um sistema de software. O funcionamento deste sistemase dá através do relacionamento e troca de mensagens entre estes objetos.1 Do inglês: postura, política, método, abordagem, linha.
  • 19. 192.3.1 Conceitos Fundamentais de Orientação a Objetos Classe representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos. Exemplo de classe: Os seres humanos. Objeto é uma instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos da classe Humanos: João, José, Maria. Atributos são os dados ou informações do objeto, basicamente a estrutura de dados que vai representar a classe. Exemplos: Funcionário: nome, endereço,telefone, CPF, ….; Carro: nome, marca, ano, cor, …; Livro: autor, editora, ano. Métodos definem as habilidades dos objetos. Bidu é uma instância da classe Cachorro, portanto tem habilidade para latir, implementada através do método deUmLatido(). Um método em uma classe é apenas uma definição. A ação só ocorre quando o método é invocado através do objeto, no caso Bidu. Dentro do programa, a utilização de um método deve afetar apenas um objeto em particular; todos os cachorros podem latir, mas você quer que apenas Bidu dê o latido. Normalmente, uma classe possui diversos métodos, que no caso da classe Cachorro poderiam ser sente(), coma() e morda(). Mensagem é uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito por sua classe. Também pode ser direcionada diretamente a uma classe (através de uma invocação a um método dinâmico).
  • 20. 20Sobrecarga é a utilização do mesmo nome para símbolos ou métodos comoperações ou funcionalidades distintas. Geralmente diferenciam-se osmétodos pela sua assinatura.Herança (ou generalização) é o mecanismo pelo qual uma classe (sub-classe)pode estender outra classe (super-classe), aproveitando seuscomportamentos (métodos) e estados possíveis (atributos). Há Herançamúltipla quando uma sub-classe possui mais de uma super-classe. Essarelação é normalmente chamada de relação “é um”. Um exemplo de herança:Mamífero é super-classe de Humano. Ou seja, um Humano é um mamífero.Associação é o mecanismo pelo qual um objeto utiliza os recursos de outro.Pode tratar-se de uma associação simples “usa um” ou de um acoplamento“parte de”. Por exemplo: Um humano usa um telefone. A tecla “1″ é parte deum telefone.Encapsulamento consiste na separação de aspectos internos e externos deum objeto. Este mecanismo é utilizado amplamente para impedir o acessodireto ao estado de um objeto (seus atributos), disponibilizando externamenteapenas os métodos que alteram estes estados. Exemplo: você não precisaconhecer os detalhes dos circuitos de um telefone para utilizá-lo. A carcaçado telefone encapsula esses detalhes, provendo a você uma interface maisamigável (os botões, o monofone e os sinais de tom).Abstração é a habilidade de concentrar nos aspectos essenciais de umcontexto qualquer, ignorando características menos importantes ouacidentais. Em modelagem orientada a objetos, uma classe é uma abstraçãode entidades existentes no domínio do sistema de software.Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de umamesma superclasse podem invocar métodos que têm a mesma assinatura(lista de parâmetros e retorno) mas comportamentos distintos, especializadospara cada classe derivada, usando para tanto uma referência a um objeto do
  • 21. 21 tipo da superclasse. A decisão sobre qual o método que deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução, através do mecanismo de ligação tardia. No caso de polimorfismo, é necessário que os métodos tenham exatamente a mesma identificação, sendo utilizado o mecanismo de redefinição de métodos. Esse mecanismo de redefinição não deve ser confundido com o mecanismo de sobrecarga de métodos. Interface é um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface. Pacotes são referências para organização lógica de classes e interfaces.2.3.2 UML Em CoresSegundo Coad (1999), na busca de um padrão de construção de software Orientadoao Objeto e sua representação, em 1994 Ivar Jacobson, Grady Booch e JimRumbaugh realizaram o feito de unificarem essas idéias em uma única ferramenta, aqual deram o nome inicial de Método Unificado. Em 1995 incluíram os métodosOOSE e Objectory e em 1996 deram o nome de UML.UML é uma ferramenta que nos auxilia na modelagem de sistemas, dos maissimples aos mais complexos.A finalidade da UML é proporcionar um padrão para preparação de planos dearquitetura de projetos de sistemas, incluindo aspectos conceituais, como processosde negócios e funções de sistema, além de itens concretos, como as classesescritas em determinada linguagem de programação, esquemas de bancos dedados e componentes de software reutilizáveis (BOOCH, RUMBAUGH eJACOBSON, 1999).
  • 22. 22A UML em cores é um conjunto de padrões de quatro cores associadas aosdiagramas da UML (COAD, LEFEBVRE, DE LUCA, 1999).A UML tipicamente identifica um estereótipo com um comentário entre colchetes ouentre “<<” e “>>” para cada objeto.As cores adicionam uma dimensão a mais ao diagrama, como se fossem camadasextras de informação, aumentando a quantidade de conteúdo que podemosexpressar sem ocupar mais espaço. Mas isso não é novidade. Mesmo nosdiagramas Entidade-Relacionamento já se usava cores distintas para identificaráreas afins naquele monte de tabelas. Por exemplo: financeiro em vermelho,controle de estoque em azul, contabilidade em verde, etc.Além de tornarem o modelo mais agradável de ver, as cores identificamimediatamente o propósito de cada classe, oferecendo uma compreensão muitomaior sobre o negócio e as entidades participantes.Ao longo de centenas de modelos domínio, tornou-se claro que quatro grandes"tipos" de classes apareceu de novo e de novo - apenas nome diferente para seadequar ao domínio.Estas foram denominadas arquétipos2 (depois de muita discussão), que se destina atransmitir que as classes de um determinado arquétipo seguirão mais ou menos amesma forma. Ou seja, os atributos, os métodos, as associações e as interfaces sãobastante semelhantes entre as classes de um determinado arquétipo.Embora as cores reais variem, identificamos os arquétipos usando as quatro coresbásicas, em tons pastéis por serem mais suaves: rosa, amarelo, verde e azul. Outromotivo é porque as “notinhas autocolantes” (Post-it) também são encontradasnessas cores, o que facilita seu uso durante a modelagem inicial (RETAMAL, 2009).2 arquétipo. s.m. 1 modelo ou padrão passível de ser reproduzido em simulacros ou objetossemelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: porextensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa).
  • 23. 23Ao tentar classificar um dado domínio classe, tipicamente uma pergunta sobre a corpadrão nesta ordem: Momento-Intervalo Ele representa um momento ou intervalo de tempo. Representa algo que necessita ser registrado, por razões de negócio ou até mesmo legal, que ocorre em algum momento no tempo ou durante um intervalo de tempo. São atividades, eventos e serviços. Um momento-intervalo também pode ter “mi- detalhes”, ou seja, ser composto por pequenas etapas do evento total. Exemplos: Uma venda é algo que acontece num certo momento. Uma estada é o período de tempo que se fica hospedado em um hotel. Para identificar esse arquétipo usamos a cor rosa e o estereótipo <<moment-interval>>. Também se usa a sigla MI. Para os detalhes, usamos o estereótipo <<mi- detail>>. Pessoa, Coisa, Lugar Algo concreto, inequivocamente identificável. Representa uma pessoa (física ou jurídica), um determinado local (endereço, casa, privado ou público) ou algum objeto, geralmente concreto. São entidades que devem ser registradas no sistema por desempenharem papéis nas atividades (momentos-intervalos). Uma mesma pessoa pode participar de eventos distintos através de papéis diferentes. Identificamos esse arquétipo com a cor verde e o estereótipo correspondente: <<party>>, <<thing>> ou <<place>>. Papel É uma forma de participar em uma atividade. É a representação de um papel que é desempenhado por alguma pessoa, lugar ou coisa, em um determinado evento do negócio (momento-intervalo). É mais comumente aplicado a pessoas, mas é possível utilizá-lo com lugares e até mesmo com coisas. Um aeroporto pode desempenhar o papel de local de origem, destino ou escala de um vôo. Sua cor é o amarelo e o estereótipo é <<role>>. Descrição É simplesmente um catálogo, que classifica como descrição ou "rótulos" um objeto. É como um item num catálogo, definindo as características de uma determinada coisa, lugar ou até mesmo pessoa (menos comum, mas possível). Usado para concentrar dados comuns a diversos objetos, possibilitando perguntas de negócio interessantes, como a quantidade de objetos de um determinado tipo. Aparece na cor azul (quase cinza, dependendo da ferramenta de modelagem) e usa-se o estereótipo <<description>>.Por que é importante reconhecer o arquétipo de cada objeto? Um arquétipo já nosdiz muita coisa sobre um objeto, oferecendo características, funções erelacionamentos que nos ajudam a definir melhor cada um sem, no entanto, nos
  • 24. 24forçar a seguir o modelo. Podemos ganhar bastante em tempo e precisão seguindoas recomendações que os arquétipos nos oferecem.A técnica também tornou mais fácil determinar aspectos do modelo de domínio – emespecial para recém-chegados à modelagem. Por exemplo, simplesmente olhandoprimeiro para a cor rosa em um diagrama, é fácil reconhecer as classes maisimportantes para um determinado domínio.2.4 ESTIMATIVA PELO MÉTODO DE CASOS DE USOA análise de sistemas Orientados a Objetos já utiliza, comumente, os diagramas deCasos de Uso (Use Cases) da UML para descrever as funcionalidades do sistemade acordo com a forma de utilização por parte dos usuários.A técnica de análise de dimensão por Casos de Uso foi criada para permitir que sejapossível estimar o tamanho do sistema ainda na fase de levantamento de Casos deUso, utilizando-se dos próprios documentos gerados nesta fase de análise comosubsídio para o cálculo dimensional.A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 porKARNER, da Objectory (hoje, Rational Software). Ela baseia-se em dois métodosbastante utilizados - o mecanismo de Pontos de Função e uma metodologiaconhecida como Mk II, uma adaptação da técnica de Pontos de Função, bastanteutilizada na Inglaterra.A forma de lançar uma estimativa é o principal diferencial da métrica por Casos deUso: o método trata de estimar o tamanho de um sistema de acordo com o modocomo os usuários o utilizarão, a complexidade de ações requerida por cada tipo deusuário e uma análise em alto nível dos passos necessários para a realização decada tarefa.
  • 25. 252.4.1 Calculando o Peso dos Atores do SistemaO primeiro passo no cálculo do sistema é classificar os atores envolvidos em cadacaso de uso, de forma a obter um somatório de pontos não-ajustado. A classificaçãode atores utiliza a Tabela 1: o peso total dos atores do sistema (UAW) é calculadopela soma dos produtos do número de atores de cada tipo pelo respectivo peso.Tabela 1 - Peso dos AtoresTipo de Ator Peso DescriçãoAtor simples 1 Outro sistema acessado através de uma API de programaçãoAtor médio 2 Outro sistema interagindo através de um protocolo de comunicação, como TCP/IP ou FTPAtor complexo 3 Um usuário interagindo através de uma interface gráfica2.4.2 Calculando o Peso dos Casos de UsoUma vez calculado o peso dos atores do sistema, partimos para o cálculo do pesodos casos de uso (UUCW):1. Se o caso de uso for considerado simples - isto é, contiver uma interface com usuário simplificada e utilizar apenas uma entidade em um banco de dados - caso de uso é considerado fácil e tem peso 5.2. Se o caso de uso envolve uma interface mais trabalhada e utiliza-se de duas ou mais entidades de banco de dados, ele é definido como médio e recebe um peso 10.3. Se o caso de uso envolver 3 ou mais entidades em um banco de dados e contiver uma interface mais complexa, este recebe um peso de 15.O peso total não ajustado (UUCP) é calculado pelo somatório entre os pesos deatores e casos de uso: UUCP = UAW + UUCW
  • 26. 262.4.3 Calculando Fatores de AjusteO método de ajuste é constituído de duas partes - um cálculo de fatores técnicos,cobrindo uma série de requisitos funcionais do sistema; e um cálculo de fatores deambiente, requisitos não-funcionais associados ao processo de desenvolvimento –tais como experiência da equipe, motivação e estabilidade do projeto. Estes doisfatores geram multiplicadores distintos, que devem ser aplicados ao peso total não-ajustado (UUCP), calculado anteriormente.Os dois modificadores utilizam-se de um mesmo mecanismo de pesos: para cadarequisito listado em suas tabelas, deve ser atribuído um valor que determina ainfluência do requisito no sistema, variando entre 0 e 5 - sendo que o valor 0 indicanenhuma influência, 3 indica influência moderada e 5 indica forte influência.2.4.4 Fatores TécnicosUtilizamos a Tabela 2 para calcular o fator de complexidade técnica do sistema(TCF)Tabela 2 - Peso dos Fatores TécnicosFator Requisito PesoT1 Sistema Distribuído 2T2 Tempo de Resposta 2T3 Eficiência 1T4 Processamento Complexo 1T5 Código Reusável 1T6 Facilidade de Instalação 0,5T7 Facilidade de Uso 0,5T8 Portabilidade 2T9 Facilidade de Mudança 1
  • 27. 27T10 Concorrência 1T11 Recursos de Segurança 1T12 Acessível por Terceiros 1T13 Requer Treinamento Especial 1O cálculo do TCF é feito pela seguinte fórmula: TCF = 0,6 + (0,01 x TFactor)O valor TFactor é obtido pelo somatório dos níveis de influência atribuídos a cadafator (T1 a T13) multiplicados pelo seu peso correspondente.2.4.5 Fatores AmbientaisA Tabela 3 mostra os fatores ambientais previstos pela metodologia de Pontos deCaso de Uso e seus pesos associados.Tabela 3 - Peso dos Fatores AmbientaisFator Descrição PesoE1 Familiaridade com RUP ou outro processo formal 1,5E2 Experiência com a aplicação em desenvolvimento 0,5E3 Experiência em Orientação a Objetos 1E4 Presença de analista experiente 0,5E5 Motivação 1E6 Requisitos estáveis 2E7 Desenvolvedores em meio-expediente -1E8 Linguagem de programação difícil 2No caso dos Fatores Ambientais, o nível de influência indica o nível dedisponibilidade de cada recurso no decorrer do projeto: desta forma, determinar que
  • 28. 28um dado fator tem nível de influência alta (isto é, atribuir a ele o valor 5) significadizer que este fator está presente no projeto como um todo e influencia seudesenvolvimento. Da mesma forma, atribuir um valor de influência zero (nenhumainfluência) a um fator indica que o mesmo não está presente no processo dedesenvolvimento.A título de ilustração podemos dizer que, um grau de influência mínimo (0) atribuídoao fator E3 indica uma equipe com total desconhecimento de Orientação a Objetos -enquanto que o grau máximo (5) indica a disponibilidade de uma equipe experienteneste paradigma de desenvolvimento.O fator ambiental (EF) é calculado pela seguinte fórmula: EF = 1,4 + (-0,03 x EFactor)Onde o valor de EFactor é dado pela soma dos produtos entre o peso de cada fator(E1 a E8) e seu grau de influência atribuído, como no cálculo da variável TFactor,abordada anteriormente.Note que a maioria dos fatores ambientais tendem a diminuir o valor em Pontos deCaso de Uso do sistema: isto reflete o ganho de velocidade proporcionado pelosdiversos fatores ambientais descritos na tabela, quando os mesmos encontram-sedisponíveis.2.4.6 Calculando o Porte do SistemaFinalmente, podemos calcular o valor total do sistema em Use Case Points (UCP)utilizando-se da seguinte fórmula: UCP = UUCP x TCF x EF
  • 29. 29Segundo Karner (1993), podemos estimar o tempo necessário para odesenvolvimento do projeto calculando-se uma média de 20 horas de trabalho porPonto de Caso de Uso (UCP), sendo que experiências demonstram uma variaçãoentre 15 e 30 horas por ponto.2.5 METODOLOGIAS ÁGEISO termo “Metodologias Ágeis” tornou-se popular no ano de 2001, quando dezessetegrandes pensadores em processo de desenvolvimento de software se encontrarampara que cada um explicasse a maneira como desenvolviam projetos de software,como trabalhavam para que a equipe respondesse rapidamente às mudanças(MARTIN, 2003).A partir deste encontro, foi então criada a “Aliança Ágil” e o estabelecimento dosvalores do “Manifesto Ágil”. Eles declararam (MANIFESTO, 2009): Manifesto para o Desenvolvimento Ágil de Software Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Indivíduos e interações mais que processos e ferramentas. Software que funciona mais que documentação detalhada. Colaboração do cliente mais que negociações contratuais. Responder às mudanças mais que seguir um plano. Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo. (Tradução livre de www.agilemanifesto.org)O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas,documentação, negociação de contratos ou planejamento, mas mostrar o valorsecundário que estes possuem diante dos indivíduos e interações, do bomfuncionamento do software, da colaboração do cliente e das respostas velozes às
  • 30. 30modificações. Esses conceitos estão mais relacionados à forma que as pequenas emédias empresas trabalham, devido a estarem habituadas a mudanças.A Aliança Ágil define 12 princípios para aqueles que querem alcançar agilidade: 1. Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software com valor. 2. Receber mudanças nos requisitos, mesmo tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente. 3. Entregar frequentemente software que funciona, desde poucas semanas até poucos meses, com uma preferência pela menor escala de tempo. 4. Pessoal de negócio e desenvolvedores devem trabalhar juntos diariamente por todo o projeto. 5. Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o apoio necessários e confie neles para realizarem o trabalho. 6. O método mais eficiente e eficaz de transmitir informação para e dentro da equipe de desenvolvimento é a conversação face a face. 7. Software que funciona é a medida primordial de progresso. 8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 9. Atenção contínua a excelência técnica e bom desenho (design) elevam a agilidade. 10. Simplicidade (a arte de maximizar a quantidade de trabalho não realizado) é essencial. 11. As melhores arquiteturas, requisitos e desenhos (designs) emergem de equipes auto-organizadas. 12. Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz, e então afina e ajusta seu comportamento de acordo.Podemos afirmar que as Metodologias Ágeis promovem um processo degerenciamento de projeto que incentiva a inspeção e a adaptação frequentes.
  • 31. 31Incentiva também o trabalho em equipe, auto-organização, entrega frequente erápida de software com qualidade.2.6 DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADESFeature-Driven Development (FDD) é uma metodologia iterativa e incremental degerenciamento e engenharia de software, que combina as melhores práticas deoutras abordagens ágeis com técnicas centradas no modelo, que podem escalarpara equipes e projetos maiores. A FDD também é caracterizada por uma ênfase naqualidade em todo o processo e um monitoramento de progresso direto, preciso,intuitivo e acurado. Sua principal finalidade é a entrega tangível e frequente desoftware funcional.Foi originalmente concebido por Peter Coad e Jeff De Luca como um modelo práticode processo para engenharia de software orientada a objetos. Stephen Palmer eJohn Felsing estenderam e melhoraram o trabalho de Coad e De Luca descrevendoum processo ágil e adaptativo que pode ser aplicado a projetos de software(PALMER e FELSING, 2002).“Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionaise as mais extremas, proporcionando uma transição mais suave para organizaçõesmais conservadoras, e a retomada da responsabilidade para as organizações que sedesiludiram com as propostas mais radicais” (RETAMAL, 2009).A FDD inicia com a criação de um modelo de objetos do domínio do problema, emcolaboração com os especialistas no domínio. Usando a informação vinda daatividade de modelagem e de quaisquer outras atividades de coleta de requisitosque já possam ter ocorrido, os desenvolvedores prosseguem para a criação da listade funcionalidades. A seguir, um plano primordial é elaborado e atribuem-seresponsabilidades. Então, equipes pequenas e formadas dinamicamentedesenvolvem as funcionalidades, realizando repetidamente iterações de projeto
  • 32. 32(design) e construção, que duram não mais do que duas semanas e, geralmente,são muito mais curtas (PALMER e FELSING, 2002).No contexto da FDD, uma funcionalidade “é uma característica, uma funçãovalorizada pelo cliente que pode ser implementada em até duas semanas” (PALMERe FELSING, 2002). O conceito é muito próximo de requisito funcional.2.6.1 As Práticas da FDDAs oito práticas da FDD são: 1. Modelagem de Objetos do Domínio: Consiste na exploração e explicação do domínio do problema; 2. Desenvolvimento por Funcionalidade: Desenvolvimento e acompanhamento do progresso através da lista de funcionalidades; 3. Posse individual de classe (código): Cada classe possui um único desenvolvedor responsável, e um desenvolvedor pode ter várias classes em sua posse; 4. Equipes de Funcionalidades: Formação de equipes pequenas e dinâmicas; 5. Inspeções: Uso dos melhores métodos conhecidos de detecção de erros; 6. Builds regulares: Garantir que existe um sistema sempre disponível e demonstrável para o cliente; 7. Gerenciamento de configuração: Habilita acompanhamento do histórico do código-fonte. Pode ser utilizado um software de controle de versões; 8. Relatório / Visibilidade de Resultados: É feito um acompanhamento através de análises nas informações do software e verifica-se como está o andamento dos processos de desenvolvimento.
  • 33. 332.6.2 Os papéis da FDDOs principais papéis que são definidos na FDD são os seguintes: Gerente de Projeto ► Responsável por todos os assuntos administrativos do projeto, o que inclui o gerenciamento de recursos, orçamento, equipamentos e outros. Sua principal meta é fornecer subsídios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto; Gerente de Desenvolvimento ► Responsável por liderar o dia-a-dia do desenvolvimento do produto. Por ser o responsável por resolver qualquer conflito técnico que exista entre programadores-líderes, deve possuir boa experiência no desenvolvimento de software e nas tecnologias que são utilizadas no projeto; Arquiteto ► Responsável pela última palavra em toda arquitetura do sistema. Também possui bastante experiência técnica em modelagem orientada a objetos, e habilidade para atuar como facilitador na absorção das regras de negócio; Programador-líder ► Responsável por liderar pequenos grupos de desenvolvedores durante a construção das funcionalidades do produto. Também atua como desenvolvedor e, normalmente, é atribuída a ele a propriedade das classes mais complexas do sistema. Possui, ainda, papel fundamental nas fases de absorção do conhecimento de negócio e no planejamento das funcionalidades;
  • 34. 34 Proprietários de código/classe (Desenvolvedores) ► Compõe as equipes de funcionalidades, desenvolve, diagrama, testa e documenta as funcionalidades a ele atribuídas pelo Programador- Líder; e Especialistas do domínio (negócio) ► Apresenta à equipe do projeto as necessidades para que o software possua valor real para os clientes. Fornecer aos desenvolvedores maior detalhamento sobre determinada funcionalidade, além de fornecer feedback das entregas para todos os envolvidos.Em projetos maiores e que possuam tal necessidade, outros papéis podem serincluídos no projeto, tais como: Gerente de Versão; Guru da Linguagem; Criador de Ferramentas; Testadores; Implantadores; e Redator Técnico.É importante ressaltar que é permitida, e comumente realizada, a atribuição de maisde um papel no projeto para a mesma pessoa.2.6.3 Os Processos da FDDA FDD é composta por cinco processos (Figura 3), divididos em duas fases.
  • 35. 35 Figura 3 – As Fases e os Processos da FDD Fonte: Site Heptagon – www.hetpagon.com.brSegundo Retamal (2009), a primeira fase é chamada de Concepção ePlanejamento (pensar um pouco antes de fazer) e a segunda de Construção (fazerde forma iterativa).Os três primeiros processos são executados no início do projeto (tipicamente duramno máximo duas semanas): DMA - Desenvolver um Modelo Abrangente; CLF - Construir a Lista de Funcionalidades; PPF - Planejar Por Funcionalidade.Os dois últimos são feitos em cada iteração (normalmente de uma ou duassemanas): DPF - Detalhar Por Funcionalidade; CPF - Construir Por Funcionalidade.
  • 36. 36Serão apresentadas detalhadamente as características que compreendem essesprocessos (PALMER e FELSING, 2002) com tradução do Adail (RETAMAL, 2009).2.6.4 DMA – Desenvolver um Modelo AbrangenteÉ uma atividade inicial que abrange todo o projeto, realizada por membros dodomínio do negócio e por desenvolvedores, sob a orientação de um modelador deobjetos experiente, no papel de arquiteto-líder (Figura 4). Figura 4 - Desenvolver um Modelo Abrangente
  • 37. 37Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, sãorealizados estudos mais detalhados sobre o domínio do negócio para cada área aser modelada. Após cada estudo dirigido sobre o domínio, pequenos grupos sãoformados por membros do domínio do negócio sendo estudado e pordesenvolvedores, que comporão seus próprios modelos que satisfaçam o domínioem questão. Os pequenos grupos apresentam seus modelos para serem revisadospor parceiros e para discussão. Um dos modelos propostos, ou uma combinaçãodos modelos, é selecionado por consenso, tornando-se, assim, o modelo paraaquela área do domínio do negócio. Realiza-se, então, uma combinação do modeloda área do domínio dentro de um modelo abrangente, ajustando a forma do modelose for necessário.O modelo de objetos é, então, iterativamente atualizado em seu conteúdo peloprocesso nº 4 “Detalhar por Funcionalidade”.Critérios de Entrada Os especialistas no domínio do negócio, os programadores-líderes e o arquiteto-líder foram selecionados.Atividades: 1. Formar a Equipe de Modelagem Responsabilidade: Gerente do Projeto Obrigatória A equipe de modelagem é composta de membros permanentes das áreas do domínio do negócio e de desenvolvimento, especificamente os especialistas no domínio e os programadores-líderes. É feito um rodízio com os outros integrantes do projeto através das sessões de modelagem, de modo que todo mundo tenha a chance de participar e ver o processo em ação. 2. Estudo Dirigido Sobre o Domínio Responsabilidade: Equipe de Modelagem
  • 38. 38 Obrigatória Um especialista no domínio do negócio apresenta uma visão geral da área do domínio que será modelada. Essa apresentação deve também incluir informação que estiver relacionada a esta área do domínio, mas não necessariamente uma parte de sua implementação.3. Estudar a Documentação Responsabilidade: Equipe de Modelagem Opcional A equipe estuda os documentos de referência ou de requisitos disponíveis, tais como modelos de objetos, requisitos funcionais (tradicionais ou no formato de casos de uso), modelos de dados e guias do usuário.4. Desenvolver o Modelo Responsabilidade: Equipe de Modelagem em Pequenos Grupos Obrigatória Formando grupos com não mais do que três componentes, cada pequeno grupo comporá um modelo que suporte a área do domínio. O arquiteto-líder pode propor um modelo base para facilitar o progresso das equipes. Um membro de cada grupo apresenta o modelo proposto por seu grupo para a área do domínio. O arquiteto-líder também pode propor outros modelos alternativos. A equipe de modelagem seleciona um modelo proposto ou compõe um modelo pela combinação das idéias propostas nos modelos apresentados.5. Refinar o Modelo de Objetos Abrangente Responsabilidade: Arquiteto-Líder e Equipe de Modelagem Obrigatória
  • 39. 39 Frequentemente, o modelo de objetos abrangente é atualizado com novas formas de modelo produzidas pelas iterações da atividade “Desenvolver o Modelo” descrito acima.Verificação Avaliação Interna e Externa Responsabilidade: Equipe de Modelagem, Negócio Obrigatória Realiza-se uma auto-avaliação ou uma avaliação interna através da participação ativa dos especialistas no domínio. Quando necessária, uma avaliação externa pode ser feita pedindo-se ao negócio (usuários) que confirme ou esclareça as questões que afetam o modelo.Critérios de Saída O resultado do processo é o modelo de objetos: Diagramas de classes com foco na forma do modelo, isto é, quais classes estão no domínio, como estão conectadas umas às outras e sob quais restrições; Métodos e atributos identificados são colocados nas classes; Diagrama(s) de sequência e/ou de máquina de estados se houver; Comentários sobre o modelo para registrar o motivo pelo qual uma forma de modelo foi escolhida e/ou quais alternativas foram consideradas.2.6.5 CLF – Construir a Lista de FuncionalidadesÉ uma atividade inicial que abrange todo o projeto, para identificar todas asfuncionalidades que satisfaçam aos requisitos (Figura 5).
  • 40. 40 Figura 5 - Construir a Lista de FuncionalidadesUma equipe, geralmente composta apenas por programadores-líderes do processonº 1, é formada para decompor funcionalmente o domínio em áreas de negócio,atividades de negócio dentro delas e passos dentro de cada atividade de negócio,formando assim a lista categorizada de funcionalidades. A categorização de maisalto nível para a lista de funcionalidades vem da divisão do domínio feita pelosespecialistas do domínio no processo nº 1.Critérios de Entrada Os especialistas no domínio do negócio, os programadores-líderes e o arquiteto-líder foram selecionados.Atividades: 1. Formar a Equipe da Lista de Funcionalidades Responsabilidade: Gerente do Projeto, Gerente de Desenvolvimento
  • 41. 41 Obrigatória A equipe é composta por programadores-líderes da equipe de modelagem do primeiro processo. 2. Construir a Lista de Funcionalidades Responsabilidade: Equipe da Lista de Funcionalidades Obrigatória A equipe deve identificar o conjunto de funcionalidades usando o conhecimento adquirido no processo nº 1. Esta é simplesmente uma decomposição funcional nas áreas definidas a partir da divisão do domínio pelos especialistas em cada domínio nos diversos estudos dirigidos realizados no processo nº 1. Ela é decomposta em áreas que englobam atividades de negócio, que são, por sua vez, decompostas em passos (funcionalidades). As funcionalidades são funções granulares, expressas em termos que possuem valor para o cliente, usando o seguinte modelo de nomeação: <ação> <resultado> < por | para | de | a > <objeto> Exemplos: calcular o total de uma venda, adicionar o produto a um carrinho de compras, exibir as especificações técnicas de um produto. As funcionalidades são granulares, de acordo com a regra de que uma funcionalidade não levará mais do que duas semanas para ser completada. Duas semanas são um limite superior; a maioria das funcionalidades leva muito menos tempo do que isso. Quando um passo de uma atividade de negócio parece maior do que duas semanas, o passo é quebrado em passos menores, que então se tornam funcionalidades.Verificação Avaliação Interna e Externa
  • 42. 42 Responsabilidade: Equipe da Lista, Negócio Obrigatória Realiza-se uma auto-avaliação ou uma avaliação interna através da participação ativa dos membros da equipe de modelagem. Quando necessária, uma avaliação pode ser feita pedindo-se aos especialistas no domínio do negócio da equipe de modelagem ou ao negócio (usuários) que confirmem ou esclareçam as questões que afetam a lista de funcionalidades.Critérios de Saída O resultado do processo é a lista de funcionalidades: Uma lista de áreas de negócio; Para cada área, uma lista de atividades de negócio dentro daquela área; Para cada passo da atividade de negócio, uma funcionalidade que satisfaça ao passo.2.6.6 PPF – Planejar por FuncionalidadeÉ uma atividade inicial que abrange todo o projeto, para produzir o plano dedesenvolvimento (Figura 6).
  • 43. 43 Figura 6 - Planejar por FuncionalidadeO gerente de projeto, o gerente de desenvolvimento e os programadores-líderesplanejam a ordem na qual as funcionalidades serão implementadas, baseada nasdependências entre elas, na carga de trabalho da equipe de desenvolvimento etambém na complexidade das funcionalidades a serem implementadas. As principaisatividades neste processo não são uma sequência estrita. Como muitas atividadesde planejamento, elas são consideradas em conjunto, com refinamentos feitos apartir de uma ou mais atividades e então considerando os outros novamente.Um cenário típico é levar em conta a sequência de desenvolvimento, depois levarem conta a atribuição das atividades de negócio aos programadores-líderes e, aofazê-lo, considerar quais das classes principais (apenas) são atribuídas a quaisdesenvolvedores (lembrar que o programador-líder também é um desenvolvedor).Quando esse equilíbrio for alcançado, e a sequência de desenvolvimento e aatribuição das atividades de negócio aos programadores-líderes estiveremessencialmente completadas, então a posse das classes estará completada (alémdas classes principais que já foram consideradas para posse).
  • 44. 44Critérios de Entrada O processo Construir a Lista de Funcionalidades foi completado.Atividades 1. Formar a Equipe de Planejamento Responsabilidade: Gerente do Projeto Obrigatória A equipe de planejamento é composta pelo gerente de desenvolvimento e pelos programadores-líderes. 2. Determinar Sequência de Desenvolvimento Responsabilidade: Equipe de Planejamento Obrigatória A equipe de planejamento deve atribuir uma data (mês e ano apenas) para o término de cada atividade de negócio. A identificação da atividade de negócio e a data de término (e dessa forma a sequência de desenvolvimento) são baseadas em: Dependências entre as funcionalidades em termos de classes envolvidas; Distribuição da carga de trabalho entre os proprietários das classes; Complexidade das funcionalidades a serem implementadas; Adiantamento das atividades de negócio de alto risco ou complexidade; Consideração de qualquer marco externo (visível) do projeto, como versões “beta”, demonstrações, pontos de verificação e “todos os produtos” que satisfaçam tais marcos. 3. Atribuir Atividades de Negócio aos Programadores-Líderes Responsabilidade: Equipe de Planejamento Obrigatória
  • 45. 45 A equipe de planejamento deve atribuir programadores-líderes como proprietários de atividades de negócio. A atribuição é baseada em: Sequência de desenvolvimento; Dependências entre as funcionalidades em termos de classes envolvidas; Distribuição da carga de trabalho entre os proprietários das classes (lembrar que os programadores-líderes também são proprietários de classes); Complexidade das funcionalidades a serem implementadas. 1. Atribuir Classes aos Desenvolvedores Responsabilidade: Equipe de Planejamento Obrigatória A equipe de planejamento deve atribuir desenvolvedores como proprietários de classes. Os desenvolvedores são proprietários de várias classes. A atribuição das classes aos desenvolvedores é baseada em: Distribuição da carga de trabalho entre os desenvolvedores; Complexidade das classes; Uso das classes (ex. alta utilização); Sequência de desenvolvimento.Verificação Auto-Avaliação Responsabilidade: Equipe de Planejamento Obrigatória Como o planejamento é uma atividade de equipe, realiza-se uma auto- avaliação pela participação ativa dos programadores-líderes, gerente de desenvolvimento e gerente de projeto.Critérios de Saída
  • 46. 46 O resultado do processo é o plano de desenvolvimento, consistindo em: Atividades de negócio com datas de término (mês e ano); Programadores-líderes atribuídos a atividades de negócio; Áreas com datas de término (mês e ano), derivadas da data do último término de suas respectivas atividades de negócio; Lista das classes e seus respectivos desenvolvedores proprietários (a lista de proprietários de classes).2.6.7 DPF – Detalhar por FuncionalidadeÉ uma atividade executada para cada funcionalidade, para produzir o pacote deprojeto (design) para ela (Figura 7).
  • 47. 47 Figura 7 - Detalhar por FuncionalidadeExistem dois tipos de desenvolvedores: os proprietários de classes e osprogramadores-líderes. Os programadores-líderes são os desenvolvedores maisexperientes. A eles são atribuídos funcionalidades a serem construídas. Entretanto,eles não as constroem sozinhos. Ao invés disso, o programador-líder identifica quaisclasses estão envolvidas para se desenvolver a funcionalidade e reúne seusproprietários de classes, criando uma equipe para desenvolver aquelafuncionalidade. O programador-líder age como um coordenador, designer e mentor,enquanto os proprietários de classes fazem a maior parte da programação dasfuncionalidades.Certo número de funcionalidades é agendado para desenvolvimento ao atribuí-las aum programador-líder. Ele seleciona as funcionalidades para desenvolvimento apartir de sua “caixa de entrada” de funcionalidades atribuídas. Ele pode escolherdiversas funcionalidades que utilizem as mesmas classes. Operacionalmente, comfrequência acontece o caso de “conjuntos” de funcionalidades serem agendados
  • 48. 48para desenvolvimento de uma vez pelo programador-líder. Tal conjunto é chamadode Pacote de Trabalho do Programador-Líder (PTPL).O programador-líder, então, forma uma equipe de funcionalidades, identificando osproprietários das classes (desenvolvedores) que provavelmente serão envolvidos nodesenvolvimento das funcionalidades que ele selecionou. Esta equipe produz o(s)diagrama(s) de sequência para a(s) funcionalidade(s) atribuída(s). O programador-líder, então, refina o modelo de objetos, baseado no conteúdo do(s) diagrama(s) desequência. Os desenvolvedores escrevem os prefácios das classes e métodos.Realiza-se uma inspeção no projeto (design).Critérios de Entrada O processo de planejamento foi completado.Atividades 1. Formar a Equipe de Funcionalidades Responsabilidade: Programador-Líder Obrigatória O programador-líder identifica as classes que provavelmente serão envolvidas no projeto deste conjunto de funcionalidades e, consequentemente, atualiza o banco de dados de funcionalidades. Da lista de proprietários de classes, o programador-líder identifica os desenvolvedores necessários para formar a equipe de funcionalidades. Como parte deste passo, o programador-líder cria um novo pacote de projeto (design) para a(s) funcionalidade(s) como parte do Pacote de Trabalho. 2. Estudo Dirigido do Domínio Responsabilidade: Especialista no Domínio Opcional O especialista no domínio apresenta uma visão geral da área do domínio para a funcionalidade a ser projetada. Essa apresentação deve também incluir
  • 49. 49 informação que estiver relacionada a esta funcionalidade, mas que não seja necessariamente uma parte de sua implementação. Esta é uma atividade opcional, baseada na complexidade da funcionalidade e/ou de suas interações.3. Estudar a Documentação de Referência Responsabilidade: Equipe de Funcionalidades Opcional A equipe de funcionalidades estuda o(s) documento(s) de referência para a funcionalidade a ser projetada, todos os memorandos de confirmação, desenhos de telas, especificações de interface com sistemas externos e qualquer outra documentação de suporte. Esta é uma atividade opcional, baseada na complexidade da funcionalidade e/ou de suas interações.4. Desenvolver o(s) Diagrama(s) de Sequência Responsabilidade: Equipe de Planejamento Opcional Desenvolver o(s) diagrama(s) de sequência necessário(s) para a funcionalidade a ser projetada. Os arquivos do(s) diagrama(s) devem ser submetidos ao sistema de controle de versões. Quaisquer projetos (designs) alternativos, decisões de projeto, esclarecimentos de requisitos e comentários também são registrados e descritos na seção de alternativas de projeto (design) do Pacote de Projeto (Design).5. Refinar o Modelo de Objetos Responsabilidade: Programador-Líder Obrigatória O programador-líder cria uma área para a equipe de funcionalidades para a(s) funcionalidade(s). Esta área pode ser um diretório em um servidor de arquivos ou um diretório em seus próprios computadores, que são copiados para o servidor pelo programador-líder quando necessário, ou utiliza-se uma área de
  • 50. 50 trabalho fornecida pelo sistema de controle de versões. O propósito da área da equipe de funcionalidades é para que o trabalho em andamento possa ser compartilhado e estar visível pelos membros da equipe de funcionalidades, mas invisível para o resto do projeto. O programador-líder refina o modelo para adicionar novas classes, métodos, atributos e/ou fazer alterações aos já existentes, baseado no(s) diagrama(s) de sequência definido(s) para a(s) funcionalidade(s). Isto resulta na atualização dos arquivos fontes da linguagem de implementação na área da equipe de funcionalidades. O programador-líder cria diagramas do modelo num formato publicável. Esses arquivos devem ser submetidos ao sistema de controle de versões e publicados na intranet do projeto. 6. Escrever Prefácios de Classes e Métodos Responsabilidade: Equipe de Funcionalidades Obrigatória Utilizando os arquivos fontes da linguagem de implementação atualizados pela atividade “Refinar o Modelo de Objetos”, que estão na área da equipe de funcionalidades, o proprietário das classes escreve os prefácios de classe e métodos para cada item definido pela funcionalidade e pelo(s) diagrama(s) de sequência. Isto inclui tipos de parâmetros, tipos de retorno, exceções e mensagens. Uma vez que cada desenvolvedor completou sua tarefa, o programador-líder gera a documentação da API usando e a submete para publicação na intranet do projeto.Verificação Inspeção do Projeto (Design) Responsabilidade: Equipe de Funcionalidades Obrigatória Realiza-se uma inspeção no projeto (design) com os membros da equipe de funcionalidades ou com outros membros do projeto. A decisão de inspecionar
  • 51. 51 com a equipe de funcionalidades ou com outros membros do projeto cabe ao programador-líder. Após o aceite, uma lista de tarefas é gerada para cada classe afetada, e cada membro da equipe inclui suas tarefas à sua agenda de tarefas. O programador-líder também deve combinar as alterações da área compartilhada pela equipe de funcionalidades de volta ao sistema de controle de versões.Critérios de Saída O resultado do processo é um Pacote de Projeto (Design) inspecionado com sucesso. O pacote de projeto consiste em: Uma capa com comentários, que completa e descreve o pacote de projeto de tal forma a ser suficiente para futuros revisores; Os requisitos referenciados (se houver) na forma de documentos e de todos os memorandos de confirmação relacionados, e documentação de apoio; O(s) diagrama(s) de sequência; Alternativas de projeto (design) (se houver); O modelo de objetos com classes, métodos e atributos novos/atualizados; A saída gerada para os prefácios de classes e métodos, criados ou modificados por esse projeto (design); Lista de tarefas e agendamentos para itens de ação nas classes afetadas para cada membro da equipe.2.6.8 CPF – Construir por FuncionalidadeÉ uma atividade executada para cada funcionalidade, para produzir uma função comvalor para o cliente (Figura 8).
  • 52. 52 Figura 8 - Construir por FuncionalidadeComeçando com o pacote de projeto (design), os proprietários de classesimplementam os itens necessários para que suas classes suportem o projeto paraesta funcionalidade. O código desenvolvido passa pelo teste de unidade e pelainspeção – a ordem aqui é determinada pelo programador-líder. Após passar pelainspeção, o código é promovido à versão atual (build).Critérios de Entrada O processo Detalhar por Funcionalidade foi completado, isto é, o pacote de projeto (design) passou com sucesso pela inspeção.Atividades 1. Implementar Classes e Métodos Responsabilidade: Equipe de Funcionalidades Obrigatória Os proprietários de classes implementam os itens necessários para satisfazer aos requisitos de suas classes para esta funcionalidade.
  • 53. 53 2. Inspecionar o Código Responsabilidade: Equipe de Funcionalidades Obrigatória Uma inspeção no código, com membros da equipe de funcionalidades ou outros membros do projeto (a decisão cabe ao programador-líder), é realizada antes ou após o teste de unidade (a decisão também cabe ao programador- líder). 3. Teste de Unidade Responsabilidade: Equipe de Funcionalidades Obrigatória Os proprietários de classes testam seus códigos para certificar que todos os requisitos de suas classes foram satisfeitos. O programador-líder determina quais testes de unidade no nível da equipe de funcionalidades são necessários (se houver). Isto é, se algum teste envolvendo as classes desenvolvidas para esta funcionalidade é exigido. 4. Promover à Versão Atual (Build) Responsabilidade: Programador-Líder e Equipe de Funcionalidades Obrigatória As classes somente podem ser promovidas para a versão atual (build) após uma inspeção de código com sucesso. O programador-líder monitora as classes sendo promovidas individualmente, através de informações dos desenvolvedores, e é o ponto de integração para a funcionalidade inteira.Verificação Inspeção do Código e Teste de Unidade Responsabilidade: Programador-Líder e Equipe de Funcionalidades Obrigatória
  • 54. 54 Uma inspeção de código com sucesso, juntamente com o término dos testes de unidade com sucesso, forma a verificação da saída deste processo. A inspeção do código e o teste de unidades são descritos acima.Critérios de Saída O resultado do processo é: Classe(s) e/ou método(s) que passaram na inspeção de código com sucesso; Classe(s) que foi(ram) promovida(s) à versão atual (build); O término de uma função com valor para o cliente (funcionalidade).2.6.9 Medindo o Progresso do DesenvolvimentoO progresso do desenvolvimento na FDD é medido na Etapa de Construção –Detalhar por Funcionalidade e Construir por Funcionalidade. Figura 9 - Medindo o Progresso
  • 55. 55São 6 marcos (milestones) bem definidos, conforme a Figura 9. A cada etapa opercentual respectivo é agregado ao total de progresso da funcionalidade.E assim podemos montar um quadro de progresso por Atividade de Negócio (Figura10): Figura 10 - Quadro de Progresso Fonte: Site Heptagon – www.hetpagon.com.br2.7 COMPARANDO AS METODOLOGIASO desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visãode alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. Omodelo em cascata é uma das metodologias tradicionais com mais ênfase noplanejamento, seguindo seus passos através da captura dos requisitos, análise,projeto, codificação e testes em uma sequência pré-planejada e restrita.
  • 56. 56O progresso é geralmente medido em termos de entrega de artefatos –especificação de requisitos, documentos de projeto, planos de teste, revisão docódigo e outros. O modelo em cascata resulta em uma substancial integração eesforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente seestende por vários meses ou anos. O tamanho e dificuldade deste esforço deintegraçã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 paraagregar valor ao negócio cedo, e continuamente agregar novas funcionalidadesatravés do ciclo de vida do projeto (Figura 11). Figura 11 - Diferenças entre as metodologiasAlgumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo ociclo de cascata inteiro em cada iteração.A Tabela 4 resume as principais diferenças entre as duas metodologias.
  • 57. 57Tabela 4 - Comparação entre as MetodologiasMetodologia Tradicional Metodologia ÁgilPrevisibilidade AdaptabilidadeControlar a incerteza Lidar com a incertezaBurocrática Documentação essencialExcesso de documentação Mudanças rápidasEnfatizam os aspectos de engenharia do Enfatizam os aspectos humanos dodesenvolvimento desenvolvimentoTeorias Básicas: Teorias Básicas: Gerenciamento Total da Produção Enxuta Qualidade Teoria das Restrições Controle Estatístico de ProcessoA FDD coloca mais ênfase em diretrizes e técnicas de gestão de projeto do quemuitas outras metodologias ágeis. À medida que os projetos crescem em tamanho ecomplexidade, a gestão de projeto ad hoc é frequentemente inadequada. Éessencial que os desenvolvedores, os gerentes e o cliente entendam o estado doprojeto – que avanços foram feitos e que problemas foram encontrados. Se apressão quanto ao prazo de entrega for significativa, é crítico determinar se asfuncionalidades foram adequadamente planejadas.
  • 58. 583. ESTUDO DE CASOEste capítulo apresenta a aplicação da metodologia FDD em um projeto concreto dedesenvolvimento de um novo produto.Para ilustrar a aplicação do modelo proposto num cenário real e analisar osresultados obtidos, foi realizado um estudo de caso no ano de 2007 no TribunalRegional Eleitoral de Mato Grosso, através de observação pessoal junto a equipe dedesenvolvimento e a comparação da estimativa de entrega entre a metodologiatradicional e a metodologia ágil.Esta empresa foi selecionada pela facilidade de acesso às informações, uma vezque o autor deste trabalho é funcionário concursado, chefe da Seção de Análise eDesenvolvimento.A empresa não possuía qualquer nível de maturidade de processo (como CMM,CMMI, etc.), nem utilizava metodologia padronizada (por exemplo: RUP,metodologias ágeis, etc.). O modelo de ciclo de vida de desenvolvimentopredominante nos projetos realizados pela empresa era o modelo em cascata,estando mais para “aos trancos e barrancos”, com as estimativas de prazo dedesenvolvimento sendo calculadas por pontos de casos de uso.O projeto selecionado para realizar este estudo foi o desenvolvimento de um novoproduto denominado Acompanhamento Permanente do Eleitorado.A aplicação do modelo proposto contou com o apoio dos diretores da empresa, oque facilitou a realização do trabalho de pesquisa.Apesar de contar com o apoio da direção da empresa para a realização do estudode caso, o inicio do projeto foi cercado de incertezas, por parte de todos osenvolvidos no projeto. O modelo proposto significou uma mudança com relação àsmetodologias que se tornaram norma na indústria de software, e desta forma,necessitou uma mudança na mentalidade da gerência.
  • 59. 59O Gerente de Projeto, que neste caso coincidiu com o Treinador, constantementeestava empenhado em identificar quem deveria estar fazendo o que, ao mesmotempo em que estava construindo o ambiente de desenvolvimento adequado(ferramentas, cultura, comunicação etc.).Tínhamos um pouco mais de dois meses para concluir o projeto. Estávamos no dia19/06/2007 e o prazo de entrega foi definido para ser no máximo em 31/08/2007.Para tornar o processo mais adaptável às incertezas e conseguir responder maisrápido aos requisitos emergentes, as iterações foram definidas com o período deduas semanas.3.1 EQUIPE DO PROJETOA equipe que participou deste projeto foi composta por sete pessoas comexperiência e que trabalhavam de forma bastante integrada em um mesmo espaçofísico, facilitando a troca de informações e conhecimentos (inclusive com a presençados clientes do produto, que no caso era a Corregedoria).Estas considerações são importantes para definir o contexto onde foi realizado oensaio e reduzir o escopo das discussões, não levando em consideração ascomplexidades referentes à comunicação de grandes equipes, dispersasgeograficamente, e inexperiência do pessoal envolvido.A equipe foi assim formada: Um Gerente de Projeto, que também exerceu os papéis de Treinador e de Programador-Líder (autor do trabalho); Um Especialista de Negócio, que também exerceu o papel de Arquiteto; Um Gerente de Desenvolvimento, que também exerceu o papel de Programador-Líder; Um Especialista de Negócio; e Três Desenvolvedores.
  • 60. 603.2 EXECUÇÃO DO PROCESSO3.2.1 DMA - Desenvolver um Modelo AbrangenteFormar a Equipe de ModelagemSendo a equipe pequena, resolvemos que todos os membros do projeto fariam parteda Equipe de Modelagem.Estudo Dirigido Sobre o DomínioO objetivo do projeto é ser uma ferramenta de Acompanhamento Estatístico doEleitorado. Isso ajudará a Corregedoria Eleitoral a identificar possíveis fraudes edeterminar revisões no eleitorado. Através de gráficos e relatórios faremos esseacompanhamento.Para isso ele terá que: 1. Acompanhar as Inscrições e as Transferências de Títulos de Eleitor no Cadastro de Eleitores do Estado de Mato Grosso, pois de acordo com a legislação eleitoral, se o total de transferências de títulos do ano em curso for 10% maior em relação às transferências do ano anterior, é preciso fazer uma revisão eleitoral; e 2. Acompanhar o percentual do eleitorado em relação às estimativas de população dos municípios feitas pelo IBGE. De acordo com a legislação eleitoral, quando esse percentual for superior a 80%, é preciso fazer uma revisão eleitoral.
  • 61. 61Desenvolver o ModeloDepois de conhecer melhor os objetivos do projeto, começamos a elaborar ummodelo, utilizando a UML em Cores. Dividimos a equipe em duas para que cadauma apresenta-se uma proposta.Alguns problemas sugiram aqui, com alguns membros se preocupando com aInterface Gráfica, se iria ser uma aplicação Web, questionamentos sobre o Banco deDados e outros fatores. Neste momento tive que intervir e lembrá-los que naquelemomento estávamos focados em entender O QUE o sistema deverá fazer e nãoCOMO irá fazê-lo.As duas propostas apresentadas foram muito semelhantes. Juntamos as idéias deambos e chegamos ao seguinte modelo abrangente (Figura 12). 1 0..* «moment-interval» «party» «moment-interval» transferencia eleitor 0..* 1 revisao 0..* 1 1 0..* «place» «moment-interval» municipio inscricao Figura 12 - Modelo AbrangenteRefinar o Modelo de Objetos AbrangenteApós mais algumas explanações, como a necessidade de cadastramento dos postoseleitorais e necessidade de autenticação de usuário, o Modelo Abrangente Final foio seguinte (Figura 13):
  • 62. 62 1 0..* «moment-interval» «party» «moment-interval» transferencia eleitor 0..* 1 revisao 0..* 0..* 1 1 1 0..* «description» «place» «moment-interval» posto_eleitoral 0..* 1 municipio inscricao 0..* 0..* 0..* 1 1 1 Tem Munic. Próximo «party» usuario Figura 13 - Modelo Abrangente Final3.2.2 CLF - Construir a Lista de FuncionalidadesFormar a Equipe da Lista de FuncionalidadesA equipe foi formada pelos dois Programadores-Líderes, assim definido peloGerente de Projeto.Construir a Lista de FuncionalidadesIdentificamos o conjunto de funcionalidades usando o conhecimento adquirido naFase DMA – Desenvolver um Modelo Abrangente. Também identificamos as Áreasde Negócio apresentadas. Depois estas áreas foram decompostas em Áreas deAtividades de Negócio, que, por sua vez, foram decompostas em funcionalidades.A Lista de Funcionalidades é a seguinte:
  • 63. 63 Acompanhamento Permanente do Eleitorado Nº Nome da Feature 1 Quadro Comparativo Eleitorado x IBGE 1.1 Cadastrar as Estimativas do IBGE 1.2 Gerar Gráfico com Percentual Eleitorado x IBGE 2 Cadastros 2.1 Cadastrar os Municípios Sede de Zona e seus Postos Eleitorais 2.2 Cadastrar os Municípios Vizinhos 2.3 Cadastrar Usuários do Sistema 2.4 Controlar o Acesso de Usuários 3 Operações do Cadastro 3.1 Gerar Gráfico de Operações Geral Anual 3.2 Gerar Gráfico de Operações Geral Mensal 3.3 Gerar Gráfico de Operações Comparativo Anual 3.4 Gerar Gráfico de Operações Comparativo Mensal 4 Quantitativo de Transferências 4.1 Gerar Gráfico de Transferências para um Munic. Por UF 4.2 Gerar Gráfico de Transferências para um Munic. Por Munic. Origem 4.3 Gerar Gráfico de Transferências por Bairro de Origem 4.4 Gerar Relatório de Detalhe da Lista de Transferência 4.5 Gerar Relatório de Histórico do Eleitor (RAE/FASE) Figura 14 - Lista de FuncionalidadesPara que pudéssemos fazer a estimativa de prazo pelo método de Pontos de Casode Uso, desenvolvemos o diagrama de Caso de Uso (Figura 15). Cadastrar Mun. Sede e P.E. Cadastrar Estimativas IBGE Cadastrar Mun. Vizinhos Gerar Gráfico Eleitorado x IBGE Operador Gerar Gráfico 3.1 Gerar Gráfico 3.2 Gerar Gráfico 3.3 Cadastrar UsuáriosUsuário Avançado Gerar Gráfico 3.4 Gerar Gráfico 4.1 Administrador Gerar Gráfico 4.2 Gerar Gráfico 4.3 Gerar Gráfico 4.4 Gerar Gráfico 4.5 Figura 15 - Diagrama de Caso de Uso
  • 64. 64A estimativa por Pontos de Caso de Uso ficou assim:UAW = 3 x 3 = 9 (3 Atores complexos)UUCW = 15 + 10 + 150 = 175 (3 Simples + 1 Médio + 10 Complexos)UUCP = 175 + 9 = 184TCF = 0,6 + (0,1 x 36) = 0,96EF = 1,4 + (-0,03 x 17) = 0,89UCP = 184 x 3,8 x 1,04 = 157,21Tempo médio de desenvolvimento ........... 3.144,2h - 56 dias úteis - ± 2,5 mesesTempo máximo de desenvolvimento ........ 4.716,3h - 84 dias úteis - ± 4 mesesTempo mínimo de desenvolvimento ......... 2.358,1h - 42 dias úteis - ± 2 mesesIsso considerando a equipe de 7 pessoas trabalhando 8h/dia. Ou seja, na melhorestimativa estaríamos muito próximos do prazo máximo de desenvolvimento.3.2.3 PPF - Planejar por FuncionalidadeFormar a Equipe de PlanejamentoA Equipe de Planejamento será formada pelo Gerente de Desenvolvimento, pelosProgramadores-Líderes, pelo Especialista de Negócio e pelo cliente.Determinar Seqüência de DesenvolvimentoEsta sequência é baseada em: Dependência entre as funcionalidades em termos de classes envolvidas; Distribuição de carga de trabalho entre os proprietários das classes; Complexidade das funcionalidades a serem implementadas; Adiantamento das atividades de negócio de alto risco ou complexidades; e Prioridade do cliente.
  • 65. 65Segundo o cliente, suas prioridades são: 1 – Quadro comparativo do Eleitorado xIBGE; 2 – Gráficos das Operações do Cadastro; e 3 – Gráficos e Relatórios doQuantitativo de Transferências.Por questão de dependência, definimos que faríamos primeiro a etapa Cadastro edepois as demais de acordo com a necessidade do cliente.Atribuir Atividades de Negócio aos Programadores-LíderesA distribuição ficou de acordo com a Figura 16, onde PL-1 é o Programador-Líder 1e PL-2 é o Programador-Líder 2. Acompanhamento Permanente do Eleitorado Nº Nome da Atividade de Negócio Prog. Líder 1 Quadro Comparativo Eleitorado x IBGE PL-1 2 Cadastros PL-2 3 Operações do Cadastro PL-2 4 Quantitativo de Transferências PL-1 Figura 16 - Atividades e seus Programadores-LíderesAtribuir Classes aos DesenvolvedoresA distribuição das classes ficou assim (Tabela 5):Tabela 5 - Classes e seus ProprietáriosClasse ProprietárioINSCRICAO D1TRANSFERENCIA D2REVISAO D3ELEITOR D3MUNICIPIO D1USUARIO D2POSTO_ELEITORAL D1
  • 66. 66Onde D1, D2 e D3 são, respectivamente, Desenvolvedor 1, Desenvolvedor 2 eDesenvolvedor 3.Nesta etapa do projeto, o cliente surgiu com novas necessidades, ou seja, novasfuncionalidades.Essas novas funcionalidades atenderiam a situação em que o eleitor se encontracom inscrição cancelada em razão de sentença prolatada em processo de revisãode eleitorado. O Código FASE para essa situação é o 469.Demos esse nome (FASE 469) a essa nova atividade de negócio.Com isso tivemos que atualizar a Lista de Funcionalidades e definir seusDesenvolvedores, que ficou então assim (Figura 17): Acompanhamento Permanente do Eleitorado Nº Nome da Feature Desenv. 1 Quadro Comparativo Eleitorado x IBGE PL-1 1.1 Cadastrar as Estimativas do IBGE D3 1.2 Gerar Gráfico com Percentual Eleitorado x IBGE D1,D2 2 Cadastros PL-2 2.1 Cadastrar os Municípios Sede de Zona e seus Postos Eleitorais D1 2.2 Cadastrar os Municípios Vizinhos D1 2.3 Cadastrar Usuários do Sistema D2 2.4 Controlar o Acesso de Usuários D2 3 Operações do Cadastro PL-2 3.1 Gerar Gráfico de Operações Geral Anual D1,D2,D3 3.2 Gerar Gráfico de Operações Geral Mensal D1,D2,D3 3.3 Gerar Gráfico de Operações Comparativo Anual D1,D2,D3 3.4 Gerar Gráfico de Operações Comparativo Mensal D1,D2,D3 4 Quantitativo de Transferências PL-1 4.1 Gerar Gráfico de Transferências para um Munic. Por UF D2 4.2 Gerar Gráfico de Transferências para um Munic. Por Munic. Origem D2 4.3 Gerar Gráfico de Transferências por Bairro de Origem D2 4.4 Gerar Relatório de Detalhe da Lista de Transferência D1 4.5 Gerar Relatório de Histórico do Eleitor (RAE/FASE) D3 4.6 Gerar Documento para Revisão Eleitoral (Carta ao Eleitor) D3 4.7 Gerar Gráfico Geral - Comparação Ano Anterior D1 5 Fase 469 PL-2
  • 67. 67 5.1 Gerar Gráfico de Gráfico Geral Anual D1 5.2 Gerar Gráfico de Gráfico Geral Mensal D2 5.3 Gerar Gráfico de Gráfico Comparativo Anual D3 Figura 17 – A nova Lista de Funcionalidades3.2.4 EstimativasA FDD não define uma prática “oficial” para estimativas. RETAMAL (2009) sugereuma tabela de medidas não-lineares, baseadas em certo grau de dificuldade paraserem utilizadas em projetos FDD que façam uso dos arquétipos da UML em Cores,a qual chamou de Tabela de 5 Pontos (Tabela 6).Tabela 6 - Escala de 5 Pontos da FDDNº Estimado de Classes Complexidade Esforço na Funcionalidade (Pessoa-Dia) 1 1 0,5 2 2 1 3 3 2 4 4 4 5 5 8 (ou mais)Depois que estimamos o tempo de desenvolvimento de cada funcionalidade,montamos o seguinte quadro de desenvolvimento (Figura 18):
  • 68. 68 Figura 18 - Quadro de DesenvolvimentoAssim, estimamos a entrega do sistema para 17/08/2007.
  • 69. 69A fase de Concepção e Planejamento durou do dia 20 de junho a 29 de junho de2007. O início da fase de Construção ficou marcado para o dia 02/07/2007.Pacotes de EntregaOs pacotes de entrega foram assim definidos (Figura 19): Figura 19 - Plano de DesenvolvimentoPlataforma e Ferramentas de DesenvolvimentoNa Justiça Eleitoral o banco de dados utilizado é o Oracle. Assim esse foi o bancode dados utilizado.Desenvolvemos o sistema com o Borland Delphi – RAD Studio 2007. A plataformaescolhida foi Web (Asp.Net 2.0). Para os relatórios e gráficos utilizamos o Crystal
  • 70. 70Reports XI. E para o controle de versões utilizamos o Borland StarTeam. Toda aequipe já era familiarizada e treinada nessas ferramentas.4. RESULTADOSO software foi desenvolvido no prazo estipulado pela equipe. O cliente ficou muitosatisfeito com o resultado final3, superando as suas expectativas.A forma como a FDD define o processo de desenvolvimento é muito agradável etodos na equipe gostaram da experiência.O fato de termos alguns prazos pré-estabelecidos não torna a metodologia rígida,pois na maioria dos casos as funcionalidades foram concluídas antes do prazo.A maneira como é dividida as tarefas e o fato das classes terem seus proprietários,faz com que os desenvolvedores não fiquem presos a um só tipo de tarefa.Antes, dividíamos o trabalho assim: o desenvolvedor 1 fará os cadastros, odesenvolvedor 2 fará os relatórios e assim por diante.Com a metodologia anterior, nós raramente conseguíamos desenvolver os projetosdentro do prazo. Como não havia a definição certa de quem faria o que, odesenvolvimento ia meio que “aos trancos e barrancos”.Em nível gerencial, a FDD nos fornece alguns relatórios de acompanhamento,dentre eles destaco o Parking Lot.Utilizando a ferramenta freeware FDDViewer, é bem fácil gerar esse gráfico e assimacompanhar o progresso de desenvolvimento.3 Observação: Por questões de sigilo dos dados do Cadastro Nacional de Eleitores, bem comonormas definidas pelo próprio Código Eleitoral Brasileiro, não foi permitido que fossem mostradasaqui as telas do sistema desenvolvido.
  • 71. 71Veja na Figura 20 a visão do Parking Lot no dia 20 de julho de 2007: Figura 20 - FddViewer e o Parking Lot
  • 72. 725. CONCLUSÃOA ênfase na definição de funcionalidades fornece os seguintes benefícios: 1. Como as funcionalidades são pequenas, os usuários podem descrevê-las com maior facilidade, entender melhor como elas se relacionam umas com as outras mais prontamente e revisá-las melhor quanto a erros ou omissões; 2. As funcionalidades podem ser organizadas em um agrupamento hierárquico relacionado ao negócio; 3. Como uma funcionalidade é um incremento de software passível de entrega, a equipe desenvolve características operacionais a cada uma ou duas semanas; 4. As representações de projeto e código são mais fáceis de inspecionar; e 5. Planejamento de projeto, cronograma e monitoramento são guiados pela hierarquia de funcionalidades e não por um conjunto de tarefas de engenharia de software arbitrariamente adotado.Só lembrando que “ágil” não é necessariamente “rápido”. Agilidade aqui tem a vercom a flexibilidade para lidar com mudanças, obter resultados em produção, entreoutros. Ao adotar uma metodologia ágil para projetos de um ano não quer dizer quevamos finalizar em seis meses ou algo assim.Usar uma metodologia ágil não é para todos. Existem várias coisas para se ter emmente se você decidir trilhar este caminho. Entretanto, eu acredito que estas novasmetodologias são amplamente aplicáveis e deveriam ser utilizadas por mais pessoasque hoje consideram em fazê-lo.No ambiente de hoje, onde a metodologia mais comum é a de codificar e consertar,aplicar mais disciplina que o caos certamente irá ajudar.A abordagem ágil tem a vantagem de ser um passo muito menos largo que usaruma metodologia pesada. Aqui, uma das principais vantagens das metodologias
  • 73. 73ágeis é justamente sua leveza. Processos simples são muito mais propensos deserem seguidos quando você está acostumado a eles, do que nenhum processo.A adoção de uma Metodologia Ágil de Projetos como qualquer tecnologia, deve seracompanhada de uma revisão no comportamento, nas políticas, nas métricas e nasregras da organização e das pessoas.
  • 74. 746. REFERÊNCIAS BIBLIOGRÁFICASBIRRELL, Nick. A Practical Handbook for Software Development. 1.ed.Cambridge University Press, 1985.COAD, Peter; LEFEBVRE; Eric, DE LUCA, Jeff. Java Modeling In Color With UML:Enterprise Components and Process. 1.ed. Prentice Hall, 1999.JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The Unified SoftwareDevelopment Process. 1.ed. Indianápolis: Addison Wesley, 1999.KARNER, Gustav. Resource Estimation for Objectory Projects. ObjectorySystems, 1993.MANIFESTO for Agile Software Development, 2001. NET. Disponível em:<http://www.agilemanifesto.org>. Acesso em: 28 Jan.2009.MARTIN, Robert. Agile Software Development: Principles, Patterns, andPractices. 1.ed. Prentice Hall. 2003.NOGUEIRA, Juan C.; JONES, Carl e LUQI. Surfing the Edge of Chaos:Applications to Software Engineering, Command and Control Research andTechnology Symposium, Naval Post Graduate School. 2000. NET. Disponível em:<http://www.dodccrp.org/events/2000_CCRTS/html/pdf_papers/Track_4/075.pdf>.Acesso em 26 Jan. 2009.PALMER, Stephen R.; FELSING, John M. A Practical Guide to Feature-DrivenDevelopment. 1.ed. Prentice Hall. 2002.RETAMAL, Adail M. FDD – Feature-Driven Development, 2009. NET. Disponívelem: <http://www.heptagon.com.br/fdd>. Acesso em: 28 Jan. 2009.

×