Im plantade Processo o

O sd e sa fiodsa im p la od e u m proce ssod e so fware nta t

artin s @ d extra sw.co m

Ed it
e d tie.m

heira de Computao p ela Unicamp,com a liza em Ad m in is t o ra o

Eng en e sp e ci p el F a atuand Qualid

e Martins

De que se trata o artigo?

Neste artigo veremos quais so os principais desa- fios e benefcios da implantao de um processo de desenvolvimento de software. Sero descritos aspectos importantes do processo que foi definido, bem como as ferramentas que foram desenvolvi- das para dar suporte sua implantao.

se tornar algo oneroso e difcil de manter.

satisfao dos clientes e previsibilidade de custo e prazo. O estabelecimento de um processo, bem definido, diminui a dependncia da empresa em relao s pessoas e possibilita a disseminao de melhores prticas, documentos e conhecimento.

Para que serve?

A implantao de um processo de desenvolvi- mento tem se mostrado como um fator primor- dial de sucesso para as empresas de sof tware. Entretanto, para ser um projeto de sucesso, deve ser planejado para refletir a realidade e dinmica da empresa, caso contrrio pode

Em que situao o tema til?

Para as empresas que esto planejando implantar um processo de desenvolvimento de sof tware.

aqueles que se referem a

14

E n g en h a ria So ftwa re M ag azin-eIm p la od e Proce ss o de nta

Pr o C E SS o

Atualmente, existem vrios modelos de processo de software e um dos mais conhecidos e utilizados o RUP Rational Unifed Process, comprado pela IBM. O RUP baseado em orientao a objetos e documentado utilizando a linguagem UML Unified Modeling Language. considerado um processo pesado, que preferencialmente deve ser utilizado em grandes projetos e equipes. Porm, como fortemen- te customizvel, possvel adapt-lo para qualquer empresa. Quando o RUP foi lanado, grandes empresas tentaram aplic-lo em suas reas de desenvolvimento de software. Fo-

Figura 1. Fases do ProUD 2.0

ram realizados grandes investimentos e nem todos obtiveram o sucesso almejado. O principal problema foi acreditar que o RUP poderia ser utilizado da forma como estava definido sem que fosse gasto esforo e tempo para identificar de que forma o RUP se encaixaria na estrutura da empresa. O caso que iremos detalhar exatamente como a Dextra Siste- mas (www.dext ra.com.br) extraiu do RUP o que era realmente aplicvel s suas necessidades e como esse esforo e investi- mento culminou na melhoria do resultado dos seus projetos e na avaliao MPS.BR nvel F obtida em Maro de 2009.

D efin io o p rocesso d
A Dextra teve um crescimento muito expressivo nos anos de 2006 e 2007 e com isso surgiu a necessidade da definio e implantao de um processo mais formal. A empresa j contava com o ProUD (Processo Unificado Dextra) que se baseava fortemente no RUP. A verso 1.0 do ProUD era bastante enxuta e se aplicava muito bem ao tamanho e caractersticas da empresa e de suas equipes de trabalho at ento. O objetivo da evoluo e melhoria do processo da Dextra era ter um nvel maior de formalizao das atividades e papis, bem como coletar e analisar indicadores de projeto que dessem a visibilidade necessria em relao qualidade do produto,

Planejamento pontualidade nas entregas e previsibilidade de custo. Diante disso, a estratgia da empresa foi novamente aplicar o RUP, utilizando o feedback j obtido no uso do ProUD 1.0 em diversos projetos. A principal meta da Dextra era definir um processo que representasse o que a empresa fazia de melhor nos seus projetos e corrigisse o que ainda poderia melhorar. Com esse foco o plano de trabalho contou com a formao de grupos de trabalho formados por membros das equipes de projetos. Os lderes de cada grupo eram membros do SEPG Software Engineer Process Group e davam o direcionamento necessrio s atividades. O resultado de um ano de trabalho foi o ProUD 2.0. O processo foi dividido em quatro grandes fases, como se v na Figura 1. Na verso 1.0 do ProUD, os nomes das fases eram exatamente iguais s do RUP Concepo, Elaborao, Construo e Transio. Porm, com a utilizao do processo percebeu-se que havia atividades que no RUP eram feitas na fase de Elaborao e que na Dextra fazia mais sentido que fossem executadas na fase

Pr o C E SS o
Nesta fase ocorre a definio do escopo do projeto e de Construo e vice-versa. Desta forma, quisemosde suas fronteiras, assim como o planejamento detalhado de sua execuo. So gerados todos os desvincular planos do projeto plano de comunicao, riscos, infraas fases do ProUD das fases do RUP, criando fases e estrutura, recursos humanos, gesto de configurao e atividades etc. Todos os compromissos internos e com o cliente dentro delas que representam a realidade da empresaso formalizados e aprovados. Esta fase recebe muitos insumos da fase de proposta, que tambm segue um e a melhor forma de trabalho de suas equipes. Segue abaixoprocesso bem definido e formal. Parte das atividades desta fase feita durante a fase de Concepo do RUP. uma breve descrio de cada uma das fases: Refinamento da Soluo Nesta fase os requisitos levantados durante a fase de proposta so detalhados, bem como a arquitetura final da soluo e os aspectos de integrao com outros sistemas. Deve-se, tambm, fazer uma extensiva anlise dos riscos do projeto associados aos requisitos e tecnologia utilizada. O resultado desta fase o detalhamento inicial dos requisitos, prottipos de telas e a definio da arquitetura do sistema. As atividades desta fase so executadas parte na fase de Concepo e parte na fase de Elaborao do RUP. Execuo O foco nessa fase dado implementao das funcionalidades do sistema. A implementao desenvolve-se de maneira iterativa e incremental. A cada iterao implementado um conjunto de casos de uso definidos previamente, tendo passado pelas fases de anlise, projeto, codificao, testes e integrao. O conceito de iteraes faz com que os riscos do projeto sejam reduzidos, pois possvel liberar funcionalidades para os usurios antes de concluir todo o projeto, verificando a adequao do sistema aos requisitos funcionais e tcnicos (escalabilidade, segurana e confiabilidade). Ainda nessa fase, os componentes de software desenvolvidos devem ser implantados nos ambientes de homologao e de produo do cliente. Os treinamentos planejados so preparados e aplicados aos usurios. As atividades desta fase correspondem fase de Construo e Transio do RUP. Encerramento Esta fase se inicia aps o aceite formal do cliente. So gerados documentos de encerramento do projeto, indicadores, lies aprendidas e reunio de fechamento com a equipe. Nesta fase inicia-se a atividade de acompanhamento da operao (operao assistida) e o perodo de garantia do produto.

Ed i o1 4 - E n g e n h a rd e Softwa re M a g a zin 15 ia e

As atividades desta fase so realizadas na fase de Transio do RUP. As disciplinas definidas para o ProUD so muito similares s do RUP e largamente executadas durante os ciclos iterativos da fase de Execuo. So nas iteraes que os requisitos so detalhados, projetados, implementados, testados e integrados ao sistema para homologao pelo cliente. Acreditamos que quanto antes o cliente receber o produto, mesmo que uma verso parcial, mais chances o produto final ter de atender as expectativas do cliente. As disciplinas implementadas no ProUD esto descritas abaixo: Requisitos: tem como objetivo identificar os requisitos do sistema atravs do entendimento das necessidades dos stakeholders. O escopo identificado deve ser mantido e controlado no decorrer do projeto; Anlise e Projeto (ou Anlise e Design): tem como objetivo elaborar a arquitetura do sistema e garantir que a soluo seja implementada no decorrer do projeto; Implementao: tem como objetivo implementar os requisitos identificados, seguindo a arquitetura definida, gerando cdigo fonte testado unitariamente; Testes: tem como objetivo garantir que o produto que ser entregue ao cliente implementa corretamente o que foi solicitado. Alm disso, prov a garantia de que mudanas no sistema no introduziram defeitos ou efeitos indesejados; Implantao/Integrao: tem como objetivo preparar o produto para ser liberado/entregue ao cliente e disponibiliz-lo no ambiente de homologao; Gerncia de Projetos: tem como objetivo planejar e controlar o escopo do projeto, gerenciando as expectativas da equipe, do cliente e da alta direo da

empresa; Gerncia de Configurao e Verso: tem como objetivo manter um conjunto consistente de produtos de trabalho, medida que vo sendo produzidos e alterados.

A Figura 2 mostra como as disciplinas esto relacionadas den- tro de um ciclo iterativo da fase de Execuo. As disciplinas de Gesto de Projetos e Gesto de Configurao e Verso per- meiam toda a cadeia de desenvolvimento, pois so disciplinas de suporte ao desenvolvimento de software. Toda definio do processo foi feita utilizando a ferramenta OpenSource EPF Composer, que possibilita diferentes vises aos usurios, facilitando a busca e visualizao das infor- maes. O EPF Composer publica o processo em formato de um website que normalmente fica disponvel na Intranet da empresa com acesso a todos os seus colaboradores. As fases do ciclo de vida so exibidas em forma de diagramas, onde as atividades esto agrupadas por papel. Cada atividade do diagrama um link para a sua descrio, onde esto deta- lhados os artefatos de entrada, de sada, templates dos produtos de trabalho e papis responsveis pela atividade. A Figura 3 mostra uma tela do ProUD 2.0 publicado atravs do EPF. Pode-se notar que h uma barra de navegao onde o usurio pode percorrer o processo pelo ciclo de vida, pelas disciplinas, pelos papis e produtos de trabalho. Alm de ter um acesso direto a todos os templates de documentos e orientaes de forma rpida e direta.

Figura 2. Ciclo de Vida Iterativo da fase de Execuo

Im p lem entan do P S .BN ve l F oM R

Um dos objetivos do projeto de melhoria e evoluo do ProUD, era a de implementar tambm um modelo de qualidade recon hecido no mercado de software. A empresa escolheu o MPS.BR por ser um programa brasileiro, voltado para a realidade do mercado de pequenas e mdias empresas de desenvolvimento de software. O MPS.BR baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e o Nvel F corresponde ao CMMI 2. O trabalho de implementao do MPS.BR ocorreu em paralelo evoluo do ProUD, e direcionou por vezes, o seu foco. O nvel de maturidade F (Gerenciado) composto pelos processos de Gerncia de Projeto, Gerncia de Requisitos, Aquisio, Gerncia de Configurao, Garantia da Qualidade e Medio. O processo de Aquisio s implementado por empresas que terceirizam o desenvolvimento de software. Todos os processos tm integrao entre si, por isso era necessrio pensar em uma infra-estrutura de ferramentas que possibilitasse a agregao das informaes e, desta forma, minimizasse o custo com replicao de dados. A soluo escolhida foi a implementao e customizao de algumas ferramentas que permitiram a implementao do modelo e que hoje so a grande base dos projetos de desenvolvimento de software da empresa. TRAC O TRAC uma ferramenta OpenSource, com interface web para gerenciamento e controle de mudanas em projetos de desenvolvimento de software. Alm de possibilitar a documentao colaborativa atravs do Wiki, tem integrao com o subversion, permitindo o rastreamento de mudanas nos artefatos do projeto. O TRAC foi c ustomizado de forma a ser o grande central i zador de i n for maes do projeto. As i n for maes esto

16

E n g en h a ria So ftwa re M ag azin-eIm p la od e Proce ss o de nta

Pr o C E SS o

Pr o C E SS o

Figura 3. Site do ProUD 2.0 publicado pelo EPF Comp oser

no Trac, ou em for ma de w i k i, ou em for ma de t ic ket s. Pa ra que a doc u ment a o do projeto pude s s e s er w i k i, foi feit a u ma c u stom i za o onde os w ik i s v i sua l i zados no site so obt idos d i ret a mente do subversion e n o n a ba s e de dados do Trac. De st a for ma pos svel ma nter toda a doc u ment a o d i spon vel v ia web, porm com cont role for ma l de verso. So exemplos de doc u mentos que e st o hoje em for mato w i k i: pla no do projeto, at a s de reu n io, doc u mento de v i so, glos s r io, d ic ion r io de dados, doc u mento de a rqu itet u ra, c a sos de u so en- t re out ros. O for mato w i k i m i n i m i za v r ios problema s referente s a re solu o de con f l itos e merge de a rqu ivos no subversion, dev ido ao fato de s er u m a rqu ivo texto. A Fig u ra 4 u m exemplo de Doc u mento de A rqu itet u ra d i spon vel no Trac.

Para que o registro das demais informaes do projeto pudes- se ser realizado atravs de tickets, estes foram customizados em vrios tipos. Como o TRAC oferece a referncia cruzada entre seus elementos, possvel definir e manter toda a rastreabilidade necessria ao projeto e tambm ao MPS.BR. As seguintes informaes so registradas no TRAC em forma de tickets: requisitos, casos de uso, riscos, mudanas, defeitos, no-conformidades, aes gerenciais e tarefas (importadas do MSProject ou criadas manualmente).

DET A DET Dextra Estimating Tool uma ferramenta de desenvolvimento prprio para realizar as estimativas de todos

Pr o C E SS o
os projetos de desenvolvimento de software da empresa. As estimativas so baseadas em tamanho funcional e o resultado a estimativa de esforo para todas as atividades definidas no processo. Alm disso, possvel tambm realizar a identificao de riscos, requisitos no-funcionais e atividades suplementares. A ferramenta exporta, seguindo templates padres, a lista de requisitos funcionais e no-funcionais do projeto, a lista de riscos e o cronograma detalhado do projeto. Estas informaes so importadas no TRAC, onde sero

ao longo do projeto.

PMA O PMA Sistema de Gesto de Projetos tambm uma ferramenta de desenvolvimento prprio que gerencia o

Figura 4. Documento de Arquitetura em Wiki

apontamento de horas das equipes do projeto e o seu custo. O apontamento realizado de acordo com as atividades do processo, desta forma possvel extrair informaes sobre a

Ed i o1 4 - E n g e n h a rd e Softwa re M a g a zin 17 ia e

acuracidade das estimativas e gerar dados para a reviso do mtodo sempre que necessrio. Alm disso, a ferramenta con- trola o custo dos recursos, gerando as medidas necessrias para o clculo de indicadores referentes ao ndice de performance de custo do projeto. A seguir vamos descrever sucintamente, como implemen- tamos cada um dos processos tendo como base o conjunto de ferramentas descritas acima: Gerncia de Projetos Propsito: estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto que permitam a realizao de correes quando houver desvios significativos no desempenho do projeto. Ns j praticvamos a gerncia de projetos desde o ProUD 1.0, e o trabalho de melhoria de processo foi focado na padronizao dos documentos e artefatos produzidos e a sua disponibilizao para a equipe e o cliente. A documentao passou a ser disponibilizada na ferramenta TRAC de cada projeto, em formato wik i. Foram definidas formas obrigatrias de acompan hamento do projeto cujo registro so atas de reunio e relatrios de stat us. O acompan hamento do projeto tem o objetivo de controlar e monitorar todos os itens que foram detalhados durante o planejamento e confront-los com o realizado. Um fator essencial para a maturidade no processo de gerncia de projetos conseguir fazer uma anlise crtica do que est sendo executado em relao ao planejado em termos de custo, escopo, prazo e riscos e verificar se o projeto ainda continua vivel ou que aes devem ser tomadas para que o projeto seja finalizado com sucesso.

Gerncia de Requisitos Propsito: gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. O processo de gerncia de requisitos era largamente praticado na empresa desde o ProUD 1.0 e o trabalho de melhoria de processo foi focado na padronizao dos documentos gerados por esta disciplina. Os documentos de Viso e de Casos de Uso so disponibilizados no TRAC do projeto, em formato wiki. Alm disso, o uso da DET passou a ser obrigatrio para todos os projetos de desenvolvimento de software, padronizando as estimativas Contudo, a maior mudana neste processo foi a definio do mecanismo de gerenciamento de mudanas dos requisitos. Foi redefinido um processo de anlise de solicitaes de mudanas, onde o uso dos mecanismos de rastreabilidade implementados pelo TRAC imprescindvel. Com a realizao de uma anlise de impacto efetiva das solicitaes de mudana possvel controlar o escopo, custo e prazos do projeto de forma objetiva e transparente para a equipe e cliente.

Gerncia de Configurao Propsito: estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizlos a todos os envolvidos. Apesar da empresa j utilizar o TRAC integrado ao subversion, o que j estabelece uma base bastante slida para o gerenciamento de configurao e verso, a evoluo deste processo no ProUD 2.0 foi grande, e com resultados surpreendentes para os projetos. Foi criado formalmente o papel de Analista de Configurao e foram redefinidas as estruturas de diretrio, padro de nomenclatura, registros de baselines, regras de integrao de arquivos ao repositrio e checklists para auditorias do sistema de con f ig urao. O objet ivo principal deste processo manter o repositrio ntegro e gerar informaes para que se possa extrair a rastreabilidade entre requisitos e cdigo fonte e vice-versa. Para que a rastreabilidade seja construda e mantida necessrio que o sistema de configurao esteja fortemente amarrado e com regras rgidas de integrao de modificaes ao repositrio. As customizaes realizadas no TRAC e a integrao com o subversion foram fatores chave para que se alcanasse a maturidade exigida neste processo. Garantia da Qualidade Propsito: assegurar que os produtos de trabalho e a execu-

o dos processos estejam em conformidade com os planos e recursos predefinidos. Este processo foi criado no ProUD 2.0. A definio do processo consistiu em criar as atividades de auditoria, definir polticas, periodicidade e checklists de avaliao. As auditorias so realizadas no decorrer do projeto e sempre que h entregas para o cliente. As no-conformidades so registradas como tickets no TRAC e tem uma mquina de estados definida para seu acompanhamento. Todas as no-conformidades tm um prazo definido para resoluo e caso no sejam solucionadas so escaladas para alta gerncia da empresa. As auditorias de qualidade so uma forma da empresa garantir que os projetos esto seguindo o processo definido, gerando os produtos de trabalho esperados e dentro dos padres estabelecidos. As auditorias de qualidade em produtos de trabalho que sero entregues ao cliente so de extrema importncia para a empresa, pois garantem uma uniformidade em termos de documentao alm de aumentar a qualidade do produto gerado. Medio Propsito: coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organizao e em seus projetos, de forma a apoiar os objetivos organizacionais. Todos os indicadores da empresa foram refeitos no ProUD 2.0. Foi utilizado o mtodo GQM Goal Question Metrics, onde a diretoria define os objetivos a serem alcanados, perguntas so feitas sobre como os objetivos podem ser atingidos e medidas so identificadas a partir das questes. Foi montada uma

18

E n g en h a ria So ftwa re M ag azin-eIm p la od e Proce ss o de nta

Pr o C E SS o

planilha com 22 indicadores, onde so definidos os mtodos de coleta e anlise, bem como sua periodicidade. Alguns dos indicadores so CPI, SPI, satisfao do cliente, desvio de esti- mativa entre outros. A fcil extrao das medidas para o clculo dos indicadores s possvel pelo fato destas medidas serem registradas nas ferramentas DET, TRAC e PMA. A coleta e anlise de indicadores dos projetos tem se mostra- do como um dos principais benefcios obtidos no ProUD 2.0. A padronizao na coleta das medidas em todos os projetos trouxe um ganho expressivo de visibilidade em termos de custos, prazos, qualidade, desvio de estimativas entre outros. evidente o ganho que este processo trouxe para a alta ge- rncia da empresa.

A avalia o P S .Bn ve l F M R
O ProUD 2.0 foi lanado oficialmente na Dextra em Setembro de 2008. Foram realizados diversos treinamentos e workshops na empresa para divulgao e capacitao das equipes. Todos os projetos que comearam aps o lanamento utilizaram a nova verso do processo. A avaliao foi marcada para Fevereiro de 2009, apenas 5 (cinco) meses aps o lanamento da nova verso do processo. A avaliao envolveu 4 (quatro) projetos e cerca de 35 (trinta e cinco) pessoas que estavam divididas entre os projetos que seriam avaliados. A avaliao composta por uma fase de anlise de documentos e uma fase posterior de entrevistas com os membros das equipes. O resultado da avaliao foi excelente e a empresa foi recomendada para o Nvel F de maturidade do MPS.BR, tendo como principais pontos fortes: a) o conjunto de ferramentas adotado, que automatiza as atividades e traz

maior controle e ganho de produtividade da equipe e b) o envolvimento das equipes dos projetos com o processo. O que interessante ressaltar que esses dois pontos foram justamente a maior preocupao da empresa desde o incio: envolver a empresa na definio do processo e investir em ferramentas que suportassem a sua implantao. O que a experincia tem nos mostrado que a implantao de um processo de software ser sempre custosa e representa um investimento financeiro importante para a empresa. Por outro lado, a empresa ter maior sucesso e retorno deste in- vestimento se o processo for elaborado e construdo dentro da prpria empresa. Um processo no se impe s pessoas, ele se constri junto com elas.
L in k s S ite d o S o tfex Bra s il w ww.so fex.b r/m psb r/ t

S ite o n d e p o s ve l o bte r in fo rm a seosb o R U P w ww.w theex .com /rup/ s re r S ite d a fe r am e TRAC trac .e d ge ll.og/ nta wa r S ite d a ferra m e ta E P F m p o se w ww.e c lipes rg/epf/ n Co r .o Pu b lic a doa a va lia o P S .BFRre a liz a d n a Dextra e m M a r o /2 0 0 9 w ww.so tex .br/ M a f m psbr/_va lia oes/ va lia co.asp ?id= 24 65 a c a a

D seu feed b ack sobreesta edio! A E n g e n h aria S o ftw a re a g a z intem q u ese rfe itaao seug o sto . de M e

D seuv o toso b re a rtig oatra v s o lin k : este , d www.devmedia.com.br/esmag/feedback

Pr o C E SS o

Ed i o14 -

E n g en h ard e ia So ftwa re M a ga zin 19 e