Estudo de Caso Sobre a Aplicao de Metodologia gil

Nery Signorini Neto

Instituto de Pesquisas Tecnolgicas do Estado de So Paulo
Avenida Prof. Almeida Prado, 532. Prdio 56 So Paulo SP Brasil
nery.signorini@mac.com

Abstract. Case study of a software development process used in
an organization compared to the processes and agile methods, such as
the OpenUp. In the organizational context there is a dependency between the
process of development with other processes and methodologies that other
joints strengthen the management of the projects of software development.
Resumo. Estudo de caso de um processo de desenvolvimento de software
utilizado em determinada organizao em comparao aos processos e
mtodos geis, como o OpenUp. No contexto organizacional h uma
dependncia entre o processo de desenvolvimento com outros processos e
outras metodologias que juntas fortalecem o gerenciamento dos projetos de
desenvolvimento de software.
Introduo
Este estudo de caso tem como objetivo a anlise do processo de desenvolvimento de
software utilizado na empresa XYZ Acme luz das metodologias geis, neste caso
especificamente, o OpenUp. O estudo conduzido analisar o processo existente
denominado MDS, 17 projetos executados no perodo de Jan/2006 a Dez/2007 e um
segundo processo, uma instncia criada a partir do processo OpenUp denominado neste
estudo como Open-MDS. Sero analisados todas as caractersticas individuais de cada
processo, suas particularidades e complexidades dentro da organizao estudada.
Um segundo objetivo identificar uma co-relao de possveis dependncias entre
os demais processos e outras metodologias que interagem junto qualquer processo de
desenvolvimento de software.
Contextualizao da Empresa
A empresa analisada uma grande multinacional americana, presente em diversos
pases ao redor do mundo. No Brasil, ela atua no ramo de refrigerantes (beverages),
produtos alimentcios (foods) e salgadinhos (snacks). A empresa composta por
diversas BU-Business Units independentes e com total autonomia para desenvolvimento
de padres prprios e de contrataes para a rea da Tecnologia da Informao (TI).
Possui pouca interao com outras BUs na regio LA (Latin America).

O contexto analisado neste estudo de caso baseado na primeira verso de uma
metodologia de desenvolvimento de sistemas, denominada neste artigo como MDS,
que foi criada por parceiro local e cuja implantao se deu durante o ano de 2005 e
primeiro trimestre de 2006. A metodologia desenvolvida deveria servir tambm para ser
utilizada no gerenciamento de projetos em geral, para controle de mudanas, para o
gerenciamento da qualidade dos artefatos de software e para o controle da verso dos
programas criados e ou modificados.
Problemas Existentes na Organizao
Abaixo esto relacionados os principais problemas e dificuldades encontrados na
organizao no perodo analisado para este artigo.

Havia 4 diferentes fbricas de software contratadas, cada qual responsvel por um
sistema ou grupo de sistemas e interfaces menores. Cada fbrica mantinha seus prprios
padres de desenvolvimento de software independentes umas das outras.
No existia internamente qualquer padro, seja para o desenvolvimento de software,
para modelagem de dados, eliciao de requisitos funcionais e no funcionais,
documentao dos artefatos ou decises arquiteturais.
Devido a fuses, existiam na empresa 3 ERPs
1
(Sistemas: FAS, TRUCK e MFGPRO)
que funcionavam em paralelo e que suportavam grandes partes do negcio. (Na Figura
1 Mapa de interfaces e de sistemas na empresa XYZ Acme, os ERPs esto
identificados na cor Verde).
Os cadastros de produtos, denominados SKUs
2
, eram descentralizados; os produtos
eram includos em qualquer dos ERPs existentes.
Os cadastros bsicos do sistema, denominados Masterfiles, eram uma entidade separada
dos demais sistemas. Sua consistncia e integridade eram mantidas atravs da grande
quantidade de interfaces de atualizao e transformao (ETL
3
) executadas diariamente.
Inexistncia de documentao atualizada dos sistemas contribua para a falta de
conhecimento das equipes responsveis pela manuteno e suporte, gerando perda de
agilidade e acuidade no tratamento de problemas. Manutenes simples acabavam se
transformando em grandes projetos de atualizaes.
Devido a complexidade e do alto grau de acoplamento entre as aplicaes, era comum
a necessidade de atualizaes em dados (updates manuais em tabelas) durante o
processamento, especialmente no processamento de fechamento mensal.
Segundo auditoria realizada internamente, a maturidade dos processos foi avaliada em -
Nota Geral: 1,3. Os graus de avaliao variam do grau mais baixo 1 ao grau mais alto 5
conforme indicado pelo CMM/CMMI
4
, definido a seguir: 1 Catico, 2 Repetitivo, 3
Definido, 4 Controlado e 5 Otimizado).
Mapa Visual dos Sistemas e Interfaces Existentes

1
ERP Enterprise Resource Planning So os sistemas de informao das empresas.
2
SKU - Stock Keeping Unit, Unidade de manuteno de estoque.
3
Extract Transform Load - Extrao Transformao de Dados.
4
CMM/CMMI Capability Maturity Model Integration- So modelos de maturidade de
processos.

Figura 1 Mapa de interfaces e de sistemas na empresa XYZ Acme
Analisando a MDS Existente
A empresa estudada possui uma Metodologia de Desenvolvimento de Sistema
(MDS
5
) prpria, implementada durante o ano de 2005 e no comeo de 2006 e foi
desenvolvida junto a parceiros comerciais com o objetivo de organizar os processos
internos utilizados para o desenvolvimento e gerenciamento de projetos de software.

A metodologia desenvolvida no se restringia apenas aos processos inerentes ao
desenvolvimento, manuteno e evoluo de sistemas ou artefatos de software. A MDS
criada possua tambm uma srie de artefatos adicionais importados de outras
metodologias, como por exemplo: Gerenciamento de escopo, Project charter, Plano
geral do projeto e WBS adotadas do PMI PMBoK [PMI]; Gerenciamento de
mudanas, ITIL - CAB - Change Advisory Board e CMDB [ITIL]; Processo de
qualidade, Data Quality Assurance, Software Quality Assurance, Sarbanes & Oxley
[SOX] e outros Processos e Auditorias Internas
6
.

Neste caso, a MDS foi expandida muito alm de suas habituais fronteiras do
desenvolvimento de software, para poder atender outras demandas internas da rea de
Tecnologia da Informao, como por exemplo: auditorias, controles operacionais,
verso de documentos e para o gerenciamento de projetos de desenvolvimento.

A adoo pela MDS de controles adicionais oriundos de outras metodologias gerou
um total de 81 artefatos reutilizados entre os diversos fluxos e fases existentes. Os
artefatos esto divididos em 54 mandatrios e 27 facultativos.

5
MDS Nome comum para Metodologia de Desenvolvimento de Sistema, esse acrnimo foi
adotado como sendo o nome oficial da metodologia da Companhia e neste artigo.
6
Auditorias Internas so os controles de governana obrigatrios.
A MDS composta por 3 processos principais (Desenvolvimento Principal,
Desenvolvimento Emergencial e Fluxo de Aquisio), 7 sub-processos menores
(Anteprojeto, Anlise, Projeto, Codificao, Homologao, Aguardando Implantao e
Implantao).

Viso dos fluxos e fases da MDS

Tabela 1: Relao de fases, processos e sub-processos e total de artefatos

Viso geral dos artefatos no Fluxo de Desenvolvimento Principal.

Tabela 2: Diviso dos artefatos por Fases

Descrio das fases de um projeto de desenvolvimento
7
com seus principais
artefatos:

1) Fase de Anteprojeto: Fase inicial do projeto de desenvolvimento de software, onde todos
os requisitos funcionais e no-funcionais so identificados e registrados pelos usurios
chaves, gerentes e patrocinadores do projeto.

2) Fase de Anlise: criado o desenho da soluo que ser desenvolvida, algumas decises
arquiteturais comeam a ser levantadas e compreendidas, so tomadas todas as decises
inerentes ao escopo e da arquitetura do sistema.
3) Fase de Projeto: a fase onde se inicia o projeto de desenvolvimento propriamente dito, os
recursos so alocados pelo parceiro comercial (fbrica de software) contratada e/ou
alocados internamente entre as reas usurias.


7
Somente esto descritos neste artigo os artefatos que so mandatrios dentro da MDS.
4) Fase de Codificao: a construo das linhas de cdigos do novo software, o produto
est sendo desenvolvido/codificado pela fbrica de software.

5) Fase de Homologao: Teste de todos os requisitos funcionais que foram registrados na
fase de Anteprojeto. Todo os artefatos devero ser validados e aprovados pelo usurio final.

6) Fase de Aguardando Implantao: Ser solicitada a reviso de todos os artefatos gerados
durante o projeto ante da implantao. Estes artefatos sero validados e aprovados pelos
responsveis pela qualidade e auditoria na rea de TI e de Negcio.

7) Fase de Implantao: O novo sistema ser implantado e disponibilizado ao cliente final.
Durante o estudo de caso foi levado em considerao apenas o fluxo de
desenvolvimento principal, identificado como Desenvolvimento de Software
Principal que o mais completo e o mais utilizado entre todos os fluxos existentes.
Devido a grande quantidade de artefatos mandatrios, os demais fluxos acabaram sendo
incorporados pelo fluxo aqui comentado e acabaram caindo em desuso dentro da
organizao.
Anlise e Coleta das Informaes
O procedimento de coleta para este estudo de caso foi baseado no processo de
desenvolvimento utilizado e na anlise de 17 projetos executados e estudados baseados
no mtodo de anlise de Complexidade x Incertezas [Little]. As aes se resumem nas
coletas e nas anlises dos documentos existentes dos projetos incluindo: escopos,
cronograma, realizaes/entregas, fases, problemas encontrados, lies aprendidas,
aes corretivas e a sensao de usurios, tcnicos e gestores que participaram dos
projetos.

Processo de Anlise:

1) Anlise do contexto organizacional da empresa, levando em considerao a maturidade de
outros processos e controles que interagem com o fluxo de desenvolvimento de software.

2) Anlise em detalhes da metodologia de desenvolvimento de sistemas (MDS) utilizada pela
empresa, incluindo os fluxos e fases de desenvolvimento e todos os artefatos propostos na
metodologia.

3) Estudo dos artefatos mandatrios e obrigatrios determinando sua real importncia ao
processo de desenvolvimento. Os artefatos oriundos de outros processos e outras
metodologias foram identificados e separados, permitindo assim a mesma base de
informao para a anlise comparativa entre a metodologia utilizada (primeiro estudo) e a
nova metodologia proposta (segundo estudo).

4) Foram analisados 17 projetos de desenvolvimento de software durante o perodo de
Jan/2006 a Dez/2007. A comparao entre as metodologias foi baseada nos mtodos geis,
especificamente o OpenUp.
Comparativo entre MDS e OpenUp
Cada projeto tem aspectos e caractersticas nicas, e estes fatores determinam qual
ser o processo mais adequado a ser adotado, ou seja, um processo mais formal ou mais
gil. Entre esses fatores existentes, podemos considerar a localizao, o tamanho das
equipes, a complexidade da arquitetura utilizada, cronogramas/prazos, riscos,
complexidades e incertezas que envolvem o projeto.

Invariavelmente uma boa metodologia de desenvolvimento de sistemas adequada
realidade e a maturidade da organizao, contribui fortemente para o sucesso dos
projetos de desenvolvimento e manuteno dos artefatos de software.

O OpenUp [ECLIPSE] um processo de desenvolvimento de software, baseado nos
princpios geis descritos no Manifesto gil [Agile], (veja Tabela 3 Relao entre
Princpios OpenUp e Princpios geis). Sua estrutura prov total sustentao para o
desenvolvimento, teste e entrega de sistemas e tambm possui uma estrutura malevel
que se adaptar as necessidades de cada organizao ou de cada projeto, seja da
incluso de novos controles, artefatos ou interaes, inclusive com outros processos
existentes dentro da organizao. Exemplo: Gerenciamento de Projetos, ITIL , SOX,
Auditorias internas ou outros controles que sejam necessrios ou impostos pela
organizao. Essa caracterstica facilita sua utilizao e adaptao.

Princpios do OpenUp e seus Respectivos Princpios do Manifesto gil

Tabela 3 Relao entre Princpios OpenUp e Princpios geis [Lyons]

A estrutura do OpenUp formado por camadas, 1 - Micro-Increment; 2 - Iteration
LifeCycle e 3 - Project LifeCycle [Cockburn].

Micro-Increment: o nvel das equipes de trabalho, aonde os recursos contribuem
no desenvolvimento e na concluso das atividades (tasks), por meio de realizaes e
entregas. a realizao das tarefas identificadas.

Iteration LifeCycle: Tem ateno especial ao processo de iterao entre todas as
tarefas, provendo uma viso normalmente semanal das atividades que devero ser
iniciadas. Tem o objetivo de manter as engrenagens funcionando, criando um fluxo
contnuo de produtos criados, testados e aceitos pelos sponsors e stakeholders.

Project LifeCycle: composta pelas fases de desenvolvimento e planejamento do
projeto, prov aos sponsors e stakeholders uma viso ampla do projeto, clareza,
transparncia, controles para riscos, gastos (budget/founding) e do escopo do projeto.
O OpenUp possui 2 tipos de dimenses: Method Content (que define o que ser
entregue, como por exemplo: tarefas, regras, artefatos, guias e etc) e Process Content
(determina quando sero entregues os artefatos, ou seja, sua execuo/realizao no
tempo). O processo constitudo de 4 fases, denominado OpenUp LifeCycle. Sendo
elas: (1 - Inception Phase, 2 - Elaboration Phase, 3 - Construction Phase, 4 -
Transition Phase).

Abaixo, esto relacionados todas as fases, elementos e os objetivos a serem
alcanados por cada fase.

Fases e Iteraes do processo de desenvolvimento de software

Figura 2 OpenUp LifeCycle Process

Abaixo, esto relacionados todas as fases e sub-fases das iterao do OpenUp,
incluindo as atividades e objetivos a serem alcanados dentro da cada fase.


Tabela 4 Descrio das fases e objetivos [Balduino]

Open-MDS Instncia criado a partir do OpenUp
No estudo de caso realizado, a falta de processos que suportam o desenvolvimento
de sistemas contribui para o aumento da complexidade e da probabilidade de insucesso
dos projetos de desenvolvimento de software.
Com a implementao de novos controles e o consequente aumento da maturidade
dos processos j existentes, a MDS pode ser gradualmente migrada para o modelo de
processo proposto pelo OpenUp.
A Open-MDS uma instncia derivada a partir da MDS com base nos princpios
geis do OpenUp. O novo processo mais rpido e malevel podendo ser
completamente adaptada as regras da organizao que a utiliza. Abaixo um
comparativo das fases e artefatos entre os 2 processos.

Comparativo das Fases e Artefatos do OpenUp e equivalentes na MDS

Tabela 5 Comparativo entre OpenUp e seus Artefatos e Fases da MDS
Anlise de projetos sob a MDS
Para o estudo de caso, os projetos foram classificados e pontuados conforme os
critrios definidos no estudo sobre gerenciamento de complexidades e incertezas em
projetos geis [Little].

Para a anlise da Complexidade foram analisados os seguintes critrios:
1 - Team Size;
2 - Mission Criticality;
3 - Team location;
4 - Team capacity;
5 - Domain knowledge gaps;
6 - Dependencies.

Para a anlise das Incertezas, 4 critrios foram analisados:
1 - Market uncertainty;
2 - Technical uncertainty;
3 - Project duration;
4 - Dependencies scope flexibility.

Resultados Obtidos da Anlise dos Projetos

Figura 3 Projetos Gerenciados pela MDS

Entendimento do resultado: 4 projetos (24%) foram classificados como sendo do
tipo: Bulls pelo alto grau de complexidade e de incertezas que os envolviam. Os demais
projetos 13 permaneceram nos quadrantes inferiores (76%), porm com alto grau de
complexidade representando: Cows com 2 (15%) e Dogs com 11 (85%).
Projeo do Estudo sob a tica do Processo Proposto
Foi realizado um segundo estudo com as mesmas informaes de entrada, mas com
a alterao do processo de desenvolvimento de software da MDS para a Open-MDS.

Este segundo estudo apenas uma projeo dos possveis resultados obtidos a partir
da utilizao de uma segunda metodologia mais gil, neste caso do OpenUp.

Projeo dos resultados

Figura 4 Projeo para Projetos Gerenciados pela Open-MDS

Entendimento: Com base no novo processo de desenvolvimento, temos agora
apenas 1 projeto classificado como Bulls que representa 6% do total de projetos. Para o
quadrante imediatamente inferior, temos 2 projetos classificados como Cows, ou seja,
12% do total de projetos. Os demais projetos foram deslocados para o quadrante com
menor complexidade e menor incertezas, com 14 projetos do tipo Dogs com 82%.
Concluso
O estudo de caso aponta uma forte dependncia entre o processo de
desenvolvimento de sistemas analisado neste documento com outros processos
corporativos, como por exemplo: procedimentos operacionais, auditorias internas, SOX
e outros processos de governana institudos e tambm com outras metodologias como:
Gerenciamento de Projetos [PMI] e Gerenciamento de infraestrutura - ITIL [ITIL]. A
falta de outros processos e controles bem definidos e maduros, gerou uma sobrecarga no
nmero total de artefatos obrigatrios e das aprovaes requeridas da MDS, tornando-a
extensa, complexa e de difcil gerenciamento.

Na anlise da Figura 4 Projetos Gerenciados pela MDS, a complexidade da
metodologia causou o deslocamento da maioria dos projetos analisados para os
quadrantes com maior dificuldade de gerenciamento, ou seja, para os quadrantes
Dogs/Cows e Bulls. Todos os projetos, por mais simples que fossem, se tornaram
complexos, lentos e com maior probabilidade de insucesso.

J na Figura 5 Projeo para Projetos Gerenciados pela Open-MDS, onde h
menor complexidade e maior agilidade, a maioria dos projetos ficaram no quadrante
Dogs, mais facilmente controlados e com maior probabilidade de sucesso.
Referncias Bibliogrficas
[PMI] PMI Project Management Institute. Project Management Body of
Knowledge. PMBok 3
rd
.
[ITIL] ITIL Information Technology Infrastructure Library http://www.itil-
officialsite.com/home/home.asp.
[SOX] The Sarbanes-Oxley Act of 2002 (Pub.L. 107-204, 116 Stat. 745, enacted July
30, 2002) http://frwebgate.access.gpo.gov/cgi-
bin/getdoc.cgi?dbname=107_cong_bills&docid=f:h3763enr.tst.pdf
[Little] Little, T. et al - Adaptive Agility - Managing Complexity and Uncertainty
by Little, T., Greene, F., Phillips. T.,Pilger, R. and Poldervaart, R.. Agile Software
Development Conference, June 2004. http://www.toddlittleweb.com/index.html.
[ECLIPSE] Eclipse Process Framework project: www.eclipse.org/epf
[Agile] Manifesto for Agile Software Development: Agile Manifesto:
www.agilemanifesto.org
[Lyons] Lyons, B.: The Open Unified Process: A Brilliant, Collaborative March into
Open Source - http://www.numbersix.com/news/n6articles/openUp.htmlAgile
Manifesto: www.agilemanifesto.org
[Cockburn] Agile Software Development, Cockburn, Alistair. Addison Wesley, 2001.
[Balduino] Balduino, R. Paper - Introduction to OpenUP (Open Unified Process).
Agosto, 2007.