Embed Size (px)
DESCRIPTION
Trabalho de Conclusão de Curso (Monografia) do Curso de Pós-Graduação em Engenharia de Sistemas
Citation preview
ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB
CURSO DE ENGENHARIA DE SISTEMAS
JORGE LUIS BUBLITZ
DESENVOLVIMENTO ÁGIL DIRIGIDO A FUNCIONALIDADES
CUIABÁ – MT 2009
JORGE LUIS BUBLITZ
DESENVOLVIMENTO Á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
JORGE LUIS BUBLITZ
DESENVOLVIMENTO ÁGIL DIRIGIDO A FUNCIONALIDADES
Aprovado em __ de __________ de 2009. _________________________________ _________________________________ _________________________________
CUIABÁ – MT 2009
Dedico este trabalho a todas as pessoas
que sempre me apoiaram e me apóiam.
Minha esposa pelo esforço e paciência
durante essa fase de estudos.
Ao Prof. Me. Hélio Maluf, que despertou
em mim o gosto pela Matemática e conse-
quentemente pela Informática.
AGRADECIMENTOS
Agradeço a Deus por tudo.
Aos meus pais pela oportunidade que me
deram de estudar e pelo exemplo dado.
Ao Adail Heptaman, amigo e mestre FDD.
“Antes de partir para a guerra, é de suma
importância atacar a estratégia inimiga”
(Sun Tzu)
RESUMO
O estudo tem como objetivo verificar e comprovar se uma metodologia ágil de desenvolvimento de software trás realmente agilidade ao processo de produção. Para tal foi realizada uma pesquisa através de estudo de caso: a equipe desenvolveu um software utilizando a metodologia de Desenvolvimento Dirigido a Funcionalidades, sendo este o primeiro projeto que se utilizou essa nova metodologia. Até então utilizávamos a técnica de estimativa do prazo de desenvolvimento por pontos de casos de uso e o desenvolvimento em cascata. Normalmente nossas estimativas de prazo de entrega não se cumpriam e era muito difícil nos adaptar e responder às mudanças de requisitos que ocorriam durante o desenvolvimento. Verificou-se que alguns membros da equipe tinham dúvidas sobre como 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 a estimativa da técnica anterior. Concluiu-se que a metodologia realmente cumpre o que propõe, pois mesmo com mudanças nos requisitos do software, o prazo final de entrega foi cumprido, bem como a capacidade da equipe de se adequar as mudanças.
LISTA DE FIGURAS
Figura 1 - The Extreme Chaos Report (2001) ........................................................... 16
Figura 2 - Modelo em Cascata .................................................................................. 17
Figura 3 – As Fases e os Processos da FDD............................................................ 35
Figura 4 - Desenvolver um Modelo Abrangente ........................................................ 36
Figura 5 - Construir a Lista de Funcionalidades ........................................................ 40
Figura 6 - Planejar por Funcionalidade ..................................................................... 43
Figura 7 - Detalhar por Funcionalidade ..................................................................... 47
Figura 8 - Construir por Funcionalidade .................................................................... 52
Figura 9 - Medindo o Progresso ................................................................................ 54
Figura 10 - Quadro de Progresso .............................................................................. 55
Figura 11 - Diferenças entre as metodologias ........................................................... 56
Figura 12 - Modelo Abrangente ................................................................................. 61
Figura 13 - Modelo Abrangente Final ........................................................................ 62
Figura 14 - Lista de Funcionalidades ........................................................................ 63
Figura 15 - Diagrama de Caso de Uso ...................................................................... 63
Figura 16 - Atividades e seus Programadores-Líderes ............................................. 65
Figura 17 – A nova Lista de Funcionalidades ........................................................... 67
Figura 18 - Quadro de Desenvolvimento ................................................................... 68
Figura 19 - Plano de Desenvolvimento ..................................................................... 69
Figura 20 - FddViewer e o Parking Lot ...................................................................... 71
LISTA DE TABELAS
Tabela 1 - Peso dos Atores ....................................................................................... 25
Tabela 2 - Peso dos Fatores Técnicos ...................................................................... 26
Tabela 3 - Peso dos Fatores Ambientais .................................................................. 27
Tabela 4 - Comparação entre as Metodologias ......................................................... 57
Tabela 5 - Classes e seus Proprietários .................................................................... 65
Tabela 6 - Escala de 5 Pontos da FDD ..................................................................... 67
LISTA DE ABREVIATURA E SIGLAS
API Application Programming Interface
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
EF Environmental Factor
FASE Formulário de Alteração da Situação do Eleitor
FDD Feature-Driven Development
FTP File Transfer Protocol
IBGE Instituto Brasileiro de Geografia e Estatística
OOSE Object-Oriented Software Engineering
RAE Requerimento de Alistamento Eleitoral
RUP Rational Unified Process
TCF Technical Complexity Factor
TCP/IP Transmission Control Protocol / Internet Protocol
UAW Unadjusted Actor Weight
UCP Use Case Points
UUCP Unadjusted Use Case Points
UUCW Unadjusted Use Case Weight
UML Unified Modeling Language
SUMÁRIO
1. INTRODUÇÃO ................................................................................................ 13
2. FUNDAMENTAÇÃO TEÓRICA ...................................................................... 15
2.1 METODOLOGIAS DE DESENVOLVIMENTO ................................................. 15
2.2 MODELO EM CASCATA ................................................................................. 17
2.3 METODOLOGIA ORIENTADA A OBJETOS ................................................... 18
2.3.1 Conceitos Fundamentais de Orientação a Objetos ................................. 19
2.3.2 UML Em Cores ............................................................................................ 21
2.4 ESTIMATIVA PELO MÉTODO DE CASOS DE USO ...................................... 24
2.4.1 Calculando o Peso dos Atores do Sistema ............................................. 25
2.4.2 Calculando o Peso dos Casos de Uso ..................................................... 25
2.4.3 Calculando Fatores de Ajuste ................................................................... 26
2.4.4 Fatores Técnicos ........................................................................................ 26
2.4.5 Fatores Ambientais .................................................................................... 27
2.4.6 Calculando o Porte do Sistema................................................................. 28
2.5 METODOLOGIAS ÁGEIS ............................................................................... 29
2.6 DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES ............................. 31
2.6.1 As Práticas da FDD .................................................................................... 32
2.6.2 Os papéis da FDD....................................................................................... 33
2.6.3 Os Processos da FDD ................................................................................ 34
2.6.4 DMA – Desenvolver um Modelo Abrangente ........................................... 36
2.6.5 CLF – Construir a Lista de Funcionalidades ........................................... 39
2.6.6 PPF – Planejar por Funcionalidade .......................................................... 42
2.6.7 DPF – Detalhar por Funcionalidade .......................................................... 46
2.6.8 CPF – Construir por Funcionalidade ........................................................ 51
2.6.9 Medindo o Progresso do Desenvolvimento ............................................. 54
2.7 COMPARANDO AS METODOLOGIAS ........................................................... 55
3. ESTUDO DE CASO ........................................................................................ 58
3.1 EQUIPE DO PROJETO ................................................................................... 59
3.2 EXECUÇÃO DO PROCESSO ......................................................................... 60
3.2.1 DMA - Desenvolver um Modelo Abrangente ............................................ 60
3.2.2 CLF - Construir a Lista de Funcionalidades ............................................ 62
3.2.3 PPF - Planejar por Funcionalidade ........................................................... 64
3.2.4 Estimativas ................................................................................................. 67
4. RESULTADOS ................................................................................................ 70
5. CONCLUSÃO ................................................................................................. 72
6. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................... 74
13
1. INTRODUÇÃO
Palavras-chave: Metodologia, Mudança, Agilidade.
Na computação, o desenvolvimento de software é o ato de elaborar e implementar
um sistema computacional, isto é, transformar a necessidade de um utilizador ou de
um mercado em um produto de software (BIRRELL, 1985).
Por ser uma atividade caótica em sua maior parte, o desenvolvimento de softwares
normalmente é um eterno ciclo "programar e depurar". O software é escrito sem um
planejamento claramente definido e o projeto do sistema é repleto de várias
decisõ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 novos
recursos (funcionalidades) a ele.
Defeitos subsequentes se tornam cada vez mais dominantes e cada vez mais
difíceis de serem eliminados. Uma longa fase de testes e depuração depois que o
software está finalizado é um sinal típico de um sistema desse tipo.
Por ser uma atividade cujo tempo é muito difícil, praticamente impossível, de ser
estimada, 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 o
objetivo de torná-lo mais previsível e mais eficiente, as metodologias impõem
disciplinas rígidas ao desenvolvimento de software. Elas fazem isso através de
processos detalhados com uma forte ênfase em planejamento.
Um dos principais problemas é que se tem a noção que elas são verdadeiras
panacé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-las
que o todo o ritmo de desenvolvimento fica mais lento.
14
Como uma reação a tais metodologias, um novo grupo delas surgiu nos últimos
anos. Durante algum tempo elas foram conhecidas como metodologias leves, mas
agora o termo mais aceito é Metodologias Ágeis.
Agilidade tornou-se então uma palavra quase que mágica quando se descreve uma
metodologia de software. Tudo é ágil. Uma equipe ágil é uma equipe esperta, capaz
de responder adequadamente às mudanças. Uma equipe ágil reconhece que o
software é desenvolvido por indivíduos trabalhando em equipes e que as
especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do
sucesso do projeto.
Mas a adoção de uma metodologia ágil traz realmente agilidade a uma equipe de
desenvolvimento? 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 metodologia
nova 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 equipe
de desenvolvimento que até então sempre utilizou uma metodologia tradicional. A
equipe desenvolverá seu primeiro software utilizando a FDD.
Faremos a estimativa de prazo de entrega utilizando a metodologia de Pontos de
Casos de Uso. Assim poderemos comparar os resultados e verificar a produtividade
de cada desenvolvedor e da equipe como um todo.
15
2. FUNDAMENTAÇÃO TEÓRICA
2.1 METODOLOGIAS DE DESENVOLVIMENTO
Metodologia de desenvolvimento de software pode ser considerada um conjunto de
normas utilizadas para estruturar, planejar e controlar o processo de
desenvolvimento de software. Uma grande variedade de metodologias tem surgido e
evoluído ao longo dos anos, cada uma com suas vantagens e desvantagens.
As metodologias foram originalmente propostas para colocar ordem no caos do
desenvolvimento de software. A história tem indicado que esses modelos
convencionais têm trazido certa dose de estrutura útil para o trabalho de engenharia
de software e tem fornecido um roteiro razoavelmente efetivo para as equipes de
desenvolvimento.
Entretanto, o trabalho de desenvolvimento de software e o produto que ele produz
permanecem 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
Com tudo isso há uma crescente procura por metodologias de desenvolvimento.
Entre os vários relatórios e depoimentos existentes, cito particularmente o Extreme
Chaos Report, produzido em 2001 pelo Standish Group, largamente utilizado e
conhecido (Figura 1).
Figura 1 - The Extreme Chaos Report (2001)
Fonte: Site Standish Group – www.standishgroup.com
Podemos ver neste gráfico que apenas 28% dos projetos de desenvolvimento de
software são concluídos com sucesso, dentro do prazo, custo e qualidade
esperados. Melhorou em relação ao relatório anterior, o “The Chaos Report” de 1994
que 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? “Nenhum
floco de neve em uma avalanche se sente responsável”, citando Stanislaw J. Lec
(1962), escritor polonês.
17
2.2 MODELO EM CASCATA
Segundo 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ção
geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim
de estabelecer ordem no desenvolvimento de grandes produtos de software.
Comparado com outros modelos de desenvolvimento, este é mais rígido e menos
administrativo.
Esse é um dos mais importantes modelos, e é referência para muitos outros
modelos, servindo de base para muitos projetos modernos. A versão original deste
modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado
hoje em dia. Neste modelo o desenvolvimento é visto como um fluir continuamente
para 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 Cascata
Grande parte do sucesso do modelo cascata está no fato dele ser orientado para
documentação. No entanto deve salientar-se que a documentação abrange mais do
que arquivo de texto, abrange representações gráficas e simulações.
18
Os 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 OBJETOS
Segundo Retamal (2009), a orientação a objetos é um paradigma de análise, projeto
e programação de sistemas de software baseado na composição e interação entre
diversas unidades de software chamadas de objetos.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto
de objetos para descrever um sistema de software. O funcionamento deste sistema
se dá através do relacionamento e troca de mensagens entre estes objetos.
1 Do inglês: postura, política, método, abordagem, linha.
19
2.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
Sobrecarga é a utilização do mesmo nome para símbolos ou métodos com
operações ou funcionalidades distintas. Geralmente diferenciam-se os
métodos pela sua assinatura.
Herança (ou generalização) é o mecanismo pelo qual uma classe (sub-classe)
pode estender outra classe (super-classe), aproveitando seus
comportamentos (métodos) e estados possíveis (atributos). Há Herança
múltipla quando uma sub-classe possui mais de uma super-classe. Essa
relaçã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 de
um telefone.
Encapsulamento consiste na separação de aspectos internos e externos de
um objeto. Este mecanismo é utilizado amplamente para impedir o acesso
direto ao estado de um objeto (seus atributos), disponibilizando externamente
apenas os métodos que alteram estes estados. Exemplo: você não precisa
conhecer os detalhes dos circuitos de um telefone para utilizá-lo. A carcaça
do telefone encapsula esses detalhes, provendo a você uma interface mais
amigável (os botões, o monofone e os sinais de tom).
Abstração é a habilidade de concentrar nos aspectos essenciais de um
contexto qualquer, ignorando características menos importantes ou
acidentais. Em modelagem orientada a objetos, uma classe é uma abstração
de entidades existentes no domínio do sistema de software.
Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma
mesma superclasse podem invocar métodos que têm a mesma assinatura
(lista de parâmetros e retorno) mas comportamentos distintos, especializados
para cada classe derivada, usando para tanto uma referência a um objeto do
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 Cores
Segundo Coad (1999), na busca de um padrão de construção de software Orientado
ao Objeto e sua representação, em 1994 Ivar Jacobson, Grady Booch e Jim
Rumbaugh realizaram o feito de unificarem essas idéias em uma única ferramenta, a
qual deram o nome inicial de Método Unificado. Em 1995 incluíram os métodos
OOSE e Objectory e em 1996 deram o nome de UML.
UML é uma ferramenta que nos auxilia na modelagem de sistemas, dos mais
simples aos mais complexos.
A finalidade da UML é proporcionar um padrão para preparação de planos de
arquitetura de projetos de sistemas, incluindo aspectos conceituais, como processos
de negócios e funções de sistema, além de itens concretos, como as classes
escritas em determinada linguagem de programação, esquemas de bancos de
dados e componentes de software reutilizáveis (BOOCH, RUMBAUGH e
JACOBSON, 1999).
22
A UML em cores é um conjunto de padrões de quatro cores associadas aos
diagramas da UML (COAD, LEFEBVRE, DE LUCA, 1999).
A UML tipicamente identifica um estereótipo com um comentário entre colchetes ou
entre “<<” e “>>” para cada objeto.
As cores adicionam uma dimensão a mais ao diagrama, como se fossem camadas
extras de informação, aumentando a quantidade de conteúdo que podemos
expressar sem ocupar mais espaço. Mas isso não é novidade. Mesmo nos
diagramas 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 identificam
imediatamente o propósito de cada classe, oferecendo uma compreensão muito
maior 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 se
adequar ao domínio.
Estas foram denominadas arquétipos2 (depois de muita discussão), que se destina a
transmitir que as classes de um determinado arquétipo seguirão mais ou menos a
mesma forma. Ou seja, os atributos, os métodos, as associações e as interfaces são
bastante semelhantes entre as classes de um determinado arquétipo.
Embora as cores reais variem, identificamos os arquétipos usando as quatro cores
básicas, em tons pastéis por serem mais suaves: rosa, amarelo, verde e azul. Outro
motivo é porque as “notinhas autocolantes” (Post-it) também são encontradas
nessas 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 objetos
semelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: por extensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa).
23
Ao tentar classificar um dado domínio classe, tipicamente uma pergunta sobre a cor
padrã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á nos
diz muita coisa sobre um objeto, oferecendo características, funções e
relacionamentos que nos ajudam a definir melhor cada um sem, no entanto, nos
24
forçar a seguir o modelo. Podemos ganhar bastante em tempo e precisão seguindo
as recomendações que os arquétipos nos oferecem.
A técnica também tornou mais fácil determinar aspectos do modelo de domínio – em
especial para recém-chegados à modelagem. Por exemplo, simplesmente olhando
primeiro para a cor rosa em um diagrama, é fácil reconhecer as classes mais
importantes para um determinado domínio.
2.4 ESTIMATIVA PELO MÉTODO DE CASOS DE USO
A análise de sistemas Orientados a Objetos já utiliza, comumente, os diagramas de
Casos de Uso (Use Cases) da UML para descrever as funcionalidades do sistema
de 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 seja
possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de
Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como
subsídio para o cálculo dimensional.
A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por
KARNER, da Objectory (hoje, Rational Software). Ela baseia-se em dois métodos
bastante utilizados - o mecanismo de Pontos de Função e uma metodologia
conhecida como Mk II, uma adaptação da técnica de Pontos de Função, bastante
utilizada na Inglaterra.
A forma de lançar uma estimativa é o principal diferencial da métrica por Casos de
Uso: o método trata de estimar o tamanho de um sistema de acordo com o modo
como os usuários o utilizarão, a complexidade de ações requerida por cada tipo de
usuário e uma análise em alto nível dos passos necessários para a realização de
cada tarefa.
25
2.4.1 Calculando o Peso dos Atores do Sistema
O primeiro passo no cálculo do sistema é classificar os atores envolvidos em cada
caso de uso, de forma a obter um somatório de pontos não-ajustado. A classificação
de atores utiliza a Tabela 1: o peso total dos atores do sistema (UAW) é calculado
pela soma dos produtos do número de atores de cada tipo pelo respectivo peso.
Tabela 1 - Peso dos Atores
Tipo de Ator Peso Descrição
Ator simples 1 Outro sistema acessado através de uma API de
programação
Ator médio 2 Outro sistema interagindo através de um protocolo de
comunicação, como TCP/IP ou FTP
Ator complexo 3 Um usuário interagindo através de uma interface gráfica
2.4.2 Calculando o Peso dos Casos de Uso
Uma vez calculado o peso dos atores do sistema, partimos para o cálculo do peso
dos 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 de
atores e casos de uso:
UUCP = UAW + UUCW
26
2.4.3 Calculando Fatores de Ajuste
O 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 de
ambiente, requisitos não-funcionais associados ao processo de desenvolvimento –
tais como experiência da equipe, motivação e estabilidade do projeto. Estes dois
fatores 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 cada
requisito listado em suas tabelas, deve ser atribuído um valor que determina a
influência do requisito no sistema, variando entre 0 e 5 - sendo que o valor 0 indica
nenhuma influência, 3 indica influência moderada e 5 indica forte influência.
2.4.4 Fatores Técnicos
Utilizamos a Tabela 2 para calcular o fator de complexidade técnica do sistema
(TCF)
Tabela 2 - Peso dos Fatores Técnicos
Fator Requisito Peso
T1 Sistema Distribuído 2
T2 Tempo de Resposta 2
T3 Eficiência 1
T4 Processamento Complexo 1
T5 Código Reusável 1
T6 Facilidade de Instalação 0,5
T7 Facilidade de Uso 0,5
T8 Portabilidade 2
T9 Facilidade de Mudança 1
27
T10 Concorrência 1
T11 Recursos de Segurança 1
T12 Acessível por Terceiros 1
T13 Requer Treinamento Especial 1
O 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 cada
fator (T1 a T13) multiplicados pelo seu peso correspondente.
2.4.5 Fatores Ambientais
A Tabela 3 mostra os fatores ambientais previstos pela metodologia de Pontos de
Caso de Uso e seus pesos associados.
Tabela 3 - Peso dos Fatores Ambientais
Fator Descrição Peso
E1 Familiaridade com RUP ou outro processo formal 1,5
E2 Experiência com a aplicação em desenvolvimento 0,5
E3 Experiência em Orientação a Objetos 1
E4 Presença de analista experiente 0,5
E5 Motivação 1
E6 Requisitos estáveis 2
E7 Desenvolvedores em meio-expediente -1
E8 Linguagem de programação difícil 2
No caso dos Fatores Ambientais, o nível de influência indica o nível de
disponibilidade de cada recurso no decorrer do projeto: desta forma, determinar que
28
um dado fator tem nível de influência alta (isto é, atribuir a ele o valor 5) significa
dizer que este fator está presente no projeto como um todo e influencia seu
desenvolvimento. Da mesma forma, atribuir um valor de influência zero (nenhuma
influência) a um fator indica que o mesmo não está presente no processo de
desenvolvimento.
A título de ilustração podemos dizer que, um grau de influência mínimo (0) atribuído
ao 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 experiente
neste 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 de
Caso de Uso do sistema: isto reflete o ganho de velocidade proporcionado pelos
diversos fatores ambientais descritos na tabela, quando os mesmos encontram-se
disponíveis.
2.4.6 Calculando o Porte do Sistema
Finalmente, 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
Segundo Karner (1993), podemos estimar o tempo necessário para o
desenvolvimento do projeto calculando-se uma média de 20 horas de trabalho por
Ponto de Caso de Uso (UCP), sendo que experiências demonstram uma variação
entre 15 e 30 horas por ponto.
2.5 METODOLOGIAS ÁGEIS
O termo “Metodologias Ágeis” tornou-se popular no ano de 2001, quando dezessete
grandes pensadores em processo de desenvolvimento de software se encontraram
para 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 dos
valores 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 valor
secundário que estes possuem diante dos indivíduos e interações, do bom
funcionamento do software, da colaboração do cliente e das respostas velozes às
30
modificações. Esses conceitos estão mais relacionados à forma que as pequenas e
mé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 de
gerenciamento de projeto que incentiva a inspeção e a adaptação frequentes.
31
Incentiva também o trabalho em equipe, auto-organização, entrega frequente e
rápida de software com qualidade.
2.6 DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES
Feature-Driven Development (FDD) é uma metodologia iterativa e incremental de
gerenciamento e engenharia de software, que combina as melhores práticas de
outras abordagens ágeis com técnicas centradas no modelo, que podem escalar
para equipes e projetos maiores. A FDD também é caracterizada por uma ênfase na
qualidade em todo o processo e um monitoramento de progresso direto, preciso,
intuitivo e acurado. Sua principal finalidade é a entrega tangível e frequente de
software funcional.
Foi originalmente concebido por Peter Coad e Jeff De Luca como um modelo prático
de processo para engenharia de software orientada a objetos. Stephen Palmer e
John Felsing estenderam e melhoraram o trabalho de Coad e De Luca descrevendo
um 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 tradicionais
e as mais extremas, proporcionando uma transição mais suave para organizações
mais conservadoras, e a retomada da responsabilidade para as organizações que se
desiludiram com as propostas mais radicais” (RETAMAL, 2009).
A FDD inicia com a criação de um modelo de objetos do domínio do problema, em
colaboração com os especialistas no domínio. Usando a informação vinda da
atividade de modelagem e de quaisquer outras atividades de coleta de requisitos
que já possam ter ocorrido, os desenvolvedores prosseguem para a criação da lista
de funcionalidades. A seguir, um plano primordial é elaborado e atribuem-se
responsabilidades. Então, equipes pequenas e formadas dinamicamente
desenvolvem as funcionalidades, realizando repetidamente iterações de projeto
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ção
valorizada pelo cliente que pode ser implementada em até duas semanas” (PALMER
e FELSING, 2002). O conceito é muito próximo de requisito funcional.
2.6.1 As Práticas da FDD
As 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
2.6.2 Os papéis da FDD
Os 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
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 ser
incluí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 mais
de um papel no projeto para a mesma pessoa.
2.6.3 Os Processos da FDD
A FDD é composta por cinco processos (Figura 3), divididos em duas fases.
35
Figura 3 – As Fases e os Processos da FDD
Fonte: Site Heptagon – www.hetpagon.com.br
Segundo Retamal (2009), a primeira fase é chamada de Concepção e
Planejamento (pensar um pouco antes de fazer) e a segunda de Construção (fazer
de forma iterativa).
Os três primeiros processos são executados no início do projeto (tipicamente duram
no 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 duas
semanas):
DPF - Detalhar Por Funcionalidade;
CPF - Construir Por Funcionalidade.
36
Serão apresentadas detalhadamente as características que compreendem esses
processos (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 do
domínio do negócio e por desenvolvedores, sob a orientação de um modelador de
objetos experiente, no papel de arquiteto-líder (Figura 4).
Figura 4 - Desenvolver um Modelo Abrangente
37
Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são
realizados estudos mais detalhados sobre o domínio do negócio para cada área a
ser modelada. Após cada estudo dirigido sobre o domínio, pequenos grupos são
formados por membros do domínio do negócio sendo estudado e por
desenvolvedores, que comporão seus próprios modelos que satisfaçam o domínio
em questão. Os pequenos grupos apresentam seus modelos para serem revisados
por parceiros e para discussão. Um dos modelos propostos, ou uma combinação
dos modelos, é selecionado por consenso, tornando-se, assim, o modelo para
aquela área do domínio do negócio. Realiza-se, então, uma combinação do modelo
da área do domínio dentro de um modelo abrangente, ajustando a forma do modelo
se for necessário.
O modelo de objetos é, então, iterativamente atualizado em seu conteúdo pelo
processo 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
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
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 as
funcionalidades que satisfaçam aos requisitos (Figura 5).
40
Figura 5 - Construir a Lista de Funcionalidades
Uma equipe, geralmente composta apenas por programadores-líderes do processo
nº 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 mais
alto nível para a lista de funcionalidades vem da divisão do domínio feita pelos
especialistas 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
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
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 de
desenvolvimento (Figura 6).
43
Figura 6 - Planejar por Funcionalidade
O gerente de projeto, o gerente de desenvolvimento e os programadores-líderes
planejam a ordem na qual as funcionalidades serão implementadas, baseada nas
dependências entre elas, na carga de trabalho da equipe de desenvolvimento e
também na complexidade das funcionalidades a serem implementadas. As principais
atividades neste processo não são uma sequência estrita. Como muitas atividades
de planejamento, elas são consideradas em conjunto, com refinamentos feitos a
partir 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 levar
em conta a atribuição das atividades de negócio aos programadores-líderes e, ao
fazê-lo, considerar quais das classes principais (apenas) são atribuídas a quais
desenvolvedores (lembrar que o programador-líder também é um desenvolvedor).
Quando esse equilíbrio for alcançado, e a sequência de desenvolvimento e a
atribuição das atividades de negócio aos programadores-líderes estiverem
essencialmente completadas, então a posse das classes estará completada (além
das classes principais que já foram consideradas para posse).
44
Crité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
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
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 de
projeto (design) para ela (Figura 7).
47
Figura 7 - Detalhar por Funcionalidade
Existem dois tipos de desenvolvedores: os proprietários de classes e os
programadores-líderes. Os programadores-líderes são os desenvolvedores mais
experientes. 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 quais
classes estão envolvidas para se desenvolver a funcionalidade e reúne seus
proprietários de classes, criando uma equipe para desenvolver aquela
funcionalidade. O programador-líder age como um coordenador, designer e mentor,
enquanto os proprietários de classes fazem a maior parte da programação das
funcionalidades.
Certo número de funcionalidades é agendado para desenvolvimento ao atribuí-las a
um programador-líder. Ele seleciona as funcionalidades para desenvolvimento a
partir de sua “caixa de entrada” de funcionalidades atribuídas. Ele pode escolher
diversas funcionalidades que utilizem as mesmas classes. Operacionalmente, com
frequência acontece o caso de “conjuntos” de funcionalidades serem agendados
48
para desenvolvimento de uma vez pelo programador-líder. Tal conjunto é chamado
de Pacote de Trabalho do Programador-Líder (PTPL).
O programador-líder, então, forma uma equipe de funcionalidades, identificando os
proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no
desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz 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) de
sequê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
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
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
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 com
valor para o cliente (Figura 8).
52
Figura 8 - Construir por Funcionalidade
Começando com o pacote de projeto (design), os proprietários de classes
implementam os itens necessários para que suas classes suportem o projeto para
esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela
inspeção – a ordem aqui é determinada pelo programador-líder. Após passar pela
inspeçã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
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
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 Desenvolvimento
O progresso do desenvolvimento na FDD é medido na Etapa de Construção –
Detalhar por Funcionalidade e Construir por Funcionalidade.
Figura 9 - Medindo o Progresso
55
São 6 marcos (milestones) bem definidos, conforme a Figura 9. A cada etapa o
percentual respectivo é agregado ao total de progresso da funcionalidade.
E assim podemos montar um quadro de progresso por Atividade de Negócio (Figura
10):
Figura 10 - Quadro de Progresso Fonte: Site Heptagon – www.hetpagon.com.br
2.7 COMPARANDO AS METODOLOGIAS
O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão
de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O
modelo em cascata é uma das metodologias tradicionais com mais ênfase no
planejamento, 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
O progresso é geralmente medido em termos de entrega de artefatos –
especificação de requisitos, documentos de projeto, planos de teste, revisão do
código e outros. O modelo em cascata resulta em uma substancial integração e
esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se
estende por vários meses ou anos. O tamanho e dificuldade deste esforço de
integração e teste é uma das causas das falhas do projeto em cascata. Métodos
ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos
(mas um pequeno subconjunto do todo) num período de poucas semanas ou meses.
Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para
agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades
através do ciclo de vida do projeto (Figura 11).
Figura 11 - Diferenças entre as metodologias
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o
ciclo de cascata inteiro em cada iteração.
A Tabela 4 resume as principais diferenças entre as duas metodologias.
57
Tabela 4 - Comparação entre as Metodologias
Metodologia Tradicional Metodologia Ágil
Previsibilidade Adaptabilidade
Controlar a incerteza Lidar com a incerteza
Burocrática Documentação essencial
Excesso de documentação Mudanças rápidas
Enfatizam os aspectos de engenharia do desenvolvimento
Enfatizam os aspectos humanos do desenvolvimento
Teorias Básicas:
Gerenciamento Total da Qualidade
Controle Estatístico de Processo
Teorias Básicas:
Produção Enxuta
Teoria das Restrições
A FDD coloca mais ênfase em diretrizes e técnicas de gestão de projeto do que
muitas outras metodologias ágeis. À medida que os projetos crescem em tamanho e
complexidade, a gestão de projeto ad hoc é frequentemente inadequada. É
essencial que os desenvolvedores, os gerentes e o cliente entendam o estado do
projeto – que avanços foram feitos e que problemas foram encontrados. Se a
pressão quanto ao prazo de entrega for significativa, é crítico determinar se as
funcionalidades foram adequadamente planejadas.
58
3. ESTUDO DE CASO
Este capítulo apresenta a aplicação da metodologia FDD em um projeto concreto de
desenvolvimento de um novo produto.
Para ilustrar a aplicação do modelo proposto num cenário real e analisar os
resultados obtidos, foi realizado um estudo de caso no ano de 2007 no Tribunal
Regional Eleitoral de Mato Grosso, através de observação pessoal junto a equipe de
desenvolvimento e a comparação da estimativa de entrega entre a metodologia
tradicional e a metodologia ágil.
Esta empresa foi selecionada pela facilidade de acesso às informações, uma vez
que o autor deste trabalho é funcionário concursado, chefe da Seção de Análise e
Desenvolvimento.
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 desenvolvimento
predominante nos projetos realizados pela empresa era o modelo em cascata,
estando mais para “aos trancos e barrancos”, com as estimativas de prazo de
desenvolvimento sendo calculadas por pontos de casos de uso.
O projeto selecionado para realizar este estudo foi o desenvolvimento de um novo
produto denominado Acompanhamento Permanente do Eleitorado.
A aplicação do modelo proposto contou com o apoio dos diretores da empresa, o
que facilitou a realização do trabalho de pesquisa.
Apesar de contar com o apoio da direção da empresa para a realização do estudo
de caso, o inicio do projeto foi cercado de incertezas, por parte de todos os
envolvidos no projeto. O modelo proposto significou uma mudança com relação às
metodologias que se tornaram norma na indústria de software, e desta forma,
necessitou uma mudança na mentalidade da gerência.
59
O Gerente de Projeto, que neste caso coincidiu com o Treinador, constantemente
estava empenhado em identificar quem deveria estar fazendo o que, ao mesmo
tempo 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 dia
19/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 mais
rápido aos requisitos emergentes, as iterações foram definidas com o período de
duas semanas.
3.1 EQUIPE DO PROJETO
A equipe que participou deste projeto foi composta por sete pessoas com
experiência e que trabalhavam de forma bastante integrada em um mesmo espaço
físico, facilitando a troca de informações e conhecimentos (inclusive com a presença
dos clientes do produto, que no caso era a Corregedoria).
Estas considerações são importantes para definir o contexto onde foi realizado o
ensaio e reduzir o escopo das discussões, não levando em consideração as
complexidades referentes à comunicação de grandes equipes, dispersas
geograficamente, 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
3.2 EXECUÇÃO DO PROCESSO
3.2.1 DMA - Desenvolver um Modelo Abrangente
Formar a Equipe de Modelagem
Sendo a equipe pequena, resolvemos que todos os membros do projeto fariam parte
da Equipe de Modelagem.
Estudo Dirigido Sobre o Domínio
O objetivo do projeto é ser uma ferramenta de Acompanhamento Estatístico do
Eleitorado. Isso ajudará a Corregedoria Eleitoral a identificar possíveis fraudes e
determinar revisões no eleitorado. Através de gráficos e relatórios faremos esse
acompanhamento.
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
Desenvolver o Modelo
Depois de conhecer melhor os objetivos do projeto, começamos a elaborar um
modelo, utilizando a UML em Cores. Dividimos a equipe em duas para que cada
uma apresenta-se uma proposta.
Alguns problemas sugiram aqui, com alguns membros se preocupando com a
Interface Gráfica, se iria ser uma aplicação Web, questionamentos sobre o Banco de
Dados e outros fatores. Neste momento tive que intervir e lembrá-los que naquele
momento estávamos focados em entender O QUE o sistema deverá fazer e não
COMO irá fazê-lo.
As duas propostas apresentadas foram muito semelhantes. Juntamos as idéias de ambos e chegamos ao seguinte modelo abrangente (Figura 12).
«moment-interval»
revisao
«party»
eleitor
«moment-interval»
inscricao
«moment-interval»
transferencia
«place»
municipio
0..*1 0..*1
0..*1 0..*1
0..*
1
0..*
1
0..* 10..* 1
Figura 12 - Modelo Abrangente
Refinar o Modelo de Objetos Abrangente
Após mais algumas explanações, como a necessidade de cadastramento dos postos
eleitorais e necessidade de autenticação de usuário, o Modelo Abrangente Final foi
o seguinte (Figura 13):
62
«party»
eleitor
«moment-interval»
inscricao
«party»
usuario
«moment-interval»
revisao
«place»
municipio
«description»
posto_eleitoral
«moment-interval»
transferencia
0..*1 0..*1
0..*1 0..*1
0..*
1
0..*
1
0..* 10..* 1
0..*
1
0..*
1
0..*
1
Tem Munic. Próximo
0..*
1
Tem Munic. Próximo
0..* 10..* 1
0..*
1
0..*
1
0..*
1
0..*
1
Figura 13 - Modelo Abrangente Final
3.2.2 CLF - Construir a Lista de Funcionalidades
Formar a Equipe da Lista de Funcionalidades
A equipe foi formada pelos dois Programadores-Líderes, assim definido pelo
Gerente de Projeto.
Construir a Lista de Funcionalidades
Identificamos o conjunto de funcionalidades usando o conhecimento adquirido na
Fase DMA – Desenvolver um Modelo Abrangente. Também identificamos as Áreas
de Negócio apresentadas. Depois estas áreas foram decompostas em Áreas de
Atividades de Negócio, que, por sua vez, foram decompostas em funcionalidades.
A Lista de Funcionalidades é a seguinte:
63
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)
Acompanhamento Permanente do Eleitorado
Figura 14 - Lista de Funcionalidades
Para que pudéssemos fazer a estimativa de prazo pelo método de Pontos de Caso
de Uso, desenvolvemos o diagrama de Caso de Uso (Figura 15).
Gerar Gráfico 3.4
Gerar Gráfico 4.1
Gerar Gráfico 3.1
Operador
Gerar Gráfico 4.5
Gerar Gráfico 3.3
Cadastrar Mun. Vizinhos
Usuário Avançado
Gerar Gráfico 3.2
Gerar Gráfico 4.2
Cadastrar Mun. Sede e P.E.
Administrador
Gerar Gráfico Eleitorado x IBGE
Gerar Gráfico 4.4
Cadastrar Usuários
Cadastrar Estimativas IBGE
Gerar Gráfico 4.3
Figura 15 - Diagrama de Caso de Uso
64
A 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 = 184
TCF = 0,6 + (0,1 x 36) = 0,96
EF = 1,4 + (-0,03 x 17) = 0,89
UCP = 184 x 3,8 x 1,04 = 157,21
Tempo médio de desenvolvimento ........... 3.144,2h - 56 dias úteis - ± 2,5 meses
Tempo máximo de desenvolvimento ........ 4.716,3h - 84 dias úteis - ± 4 meses
Tempo mínimo de desenvolvimento ......... 2.358,1h - 42 dias úteis - ± 2 meses
Isso considerando a equipe de 7 pessoas trabalhando 8h/dia. Ou seja, na melhor
estimativa estaríamos muito próximos do prazo máximo de desenvolvimento.
3.2.3 PPF - Planejar por Funcionalidade
Formar a Equipe de Planejamento
A Equipe de Planejamento será formada pelo Gerente de Desenvolvimento, pelos
Programadores-Líderes, pelo Especialista de Negócio e pelo cliente.
Determinar Seqüência de Desenvolvimento
Esta 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
Segundo o cliente, suas prioridades são: 1 – Quadro comparativo do Eleitorado x
IBGE; 2 – Gráficos das Operações do Cadastro; e 3 – Gráficos e Relatórios do
Quantitativo de Transferências.
Por questão de dependência, definimos que faríamos primeiro a etapa Cadastro e
depois as demais de acordo com a necessidade do cliente.
Atribuir Atividades de Negócio aos Programadores-Líderes
A distribuição ficou de acordo com a Figura 16, onde PL-1 é o Programador-Líder 1
e 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íderes
Atribuir Classes aos Desenvolvedores
A distribuição das classes ficou assim (Tabela 5):
Tabela 5 - Classes e seus Proprietários
Classe Proprietário
INSCRICAO D1
TRANSFERENCIA D2
REVISAO D3
ELEITOR D3
MUNICIPIO D1
USUARIO D2
POSTO_ELEITORAL D1
66
Onde D1, D2 e D3 são, respectivamente, Desenvolvedor 1, Desenvolvedor 2 e
Desenvolvedor 3.
Nesta etapa do projeto, o cliente surgiu com novas necessidades, ou seja, novas
funcionalidades.
Essas novas funcionalidades atenderiam a situação em que o eleitor se encontra
com inscrição cancelada em razão de sentença prolatada em processo de revisão
de 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 seus
Desenvolvedores, 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
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 Funcionalidades
3.2.4 Estimativas
A FDD não define uma prática “oficial” para estimativas. RETAMAL (2009) sugere
uma tabela de medidas não-lineares, baseadas em certo grau de dificuldade para
serem 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 FDD
Nº Estimado de Classes na Funcionalidade
Complexidade Esforço (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
Figura 18 - Quadro de Desenvolvimento
Assim, estimamos a entrega do sistema para 17/08/2007.
69
A fase de Concepção e Planejamento durou do dia 20 de junho a 29 de junho de
2007. O início da fase de Construção ficou marcado para o dia 02/07/2007.
Pacotes de Entrega
Os pacotes de entrega foram assim definidos (Figura 19):
Figura 19 - Plano de Desenvolvimento
Plataforma e Ferramentas de Desenvolvimento
Na Justiça Eleitoral o banco de dados utilizado é o Oracle. Assim esse foi o banco
de dados utilizado.
Desenvolvemos o sistema com o Borland Delphi – RAD Studio 2007. A plataforma
escolhida foi Web (Asp.Net 2.0). Para os relatórios e gráficos utilizamos o Crystal
70
Reports XI. E para o controle de versões utilizamos o Borland StarTeam. Toda a
equipe já era familiarizada e treinada nessas ferramentas.
4. RESULTADOS
O software foi desenvolvido no prazo estipulado pela equipe. O cliente ficou muito
satisfeito com o resultado final3, superando as suas expectativas.
A forma como a FDD define o processo de desenvolvimento é muito agradável e
todos 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, o
desenvolvedor 2 fará os relatórios e assim por diante.
Com a metodologia anterior, nós raramente conseguíamos desenvolver os projetos
dentro do prazo. Como não havia a definição certa de quem faria o que, o
desenvolvimento 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 assim
acompanhar o progresso de desenvolvimento.
3 Observação: Por questões de sigilo dos dados do Cadastro Nacional de Eleitores, bem como
normas definidas pelo próprio Código Eleitoral Brasileiro, não foi permitido que fossem mostradas aqui as telas do sistema desenvolvido.
71
Veja na Figura 20 a visão do Parking Lot no dia 20 de julho de 2007:
Figura 20 - FddViewer e o Parking Lot
72
5. CONCLUSÃO
A ê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 ver
com a flexibilidade para lidar com mudanças, obter resultados em produção, entre
outros. Ao adotar uma metodologia ágil para projetos de um ano não quer dizer que
vamos finalizar em seis meses ou algo assim.
Usar uma metodologia ágil não é para todos. Existem várias coisas para se ter em
mente se você decidir trilhar este caminho. Entretanto, eu acredito que estas novas
metodologias são amplamente aplicáveis e deveriam ser utilizadas por mais pessoas
que 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 usar
uma metodologia pesada. Aqui, uma das principais vantagens das metodologias
73
ágeis é justamente sua leveza. Processos simples são muito mais propensos de
serem seguidos quando você está acostumado a eles, do que nenhum processo.
A adoção de uma Metodologia Ágil de Projetos como qualquer tecnologia, deve ser
acompanhada de uma revisão no comportamento, nas políticas, nas métricas e nas
regras da organização e das pessoas.
74
6. REFERÊNCIAS BIBLIOGRÁFICAS
BIRRELL, 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 Software
Development Process. 1.ed. Indianápolis: Addison Wesley, 1999.
KARNER, Gustav. Resource Estimation for Objectory Projects. Objectory
Systems, 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, and
Practices. 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 and
Technology 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-Driven
Development. 1.ed. Prentice Hall. 2002.
RETAMAL, Adail M. FDD – Feature-Driven Development, 2009. NET. Disponível
em: <http://www.heptagon.com.br/fdd>. Acesso em: 28 Jan. 2009.
