Aplicao da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa

Odair Jacinto da Silva1, Carlos Alberto Borges1, Clnio Sampaio Salviano2, Adalberto N. Crespo2, Ana Lcia Sampaio2, Ana Cristina Roullier3
1 2 3

Ampla Consultoria em Informao Campinas SP Brazil

Centro de Pesquisas Renato Archer (CenPRA) Campinas SP Brazil

Centro Tecnolgico de Informtica da Univ. Federal de Lavras (UFLATEC) Lavras MG Brazil

{odair, carlos}@amplaconsultoria.com.br, {clenio.salviano, adalberto.crespo,ana-lucia.andrade}@cenpra.gov.br, acr@comp.ufla.br

Abstract. This paper describes the results achieved in a software process improvement (SPI) based on ISO/IEC TR 15504 used as reference by Ampla Consultoria em Informao, a small software development company. Resumo. Este artigo descreve os resultados obtidos com a aplicao da ISO/IEC TR 15504 como referncia para a melhoria do processo de desenvolvimento de software da Ampla Consultoria em Informao, uma empresa de desenvolvimento de software de pequeno porte.

1. Introduo
A Ampla Consultoria em Informao (Ampla) uma pequena empresa de desenvolvimento de projetos de software. Fundada em 1995 e instalada em Campinas, SP, nas proximidades da Universidade de Campinas (UNICAMP), no distrito de Baro Geraldo. A Ampla tem, desde o incio de suas atividades, como foco principal o desenvolvimento de projetos de software. Esta rea representa cerca de 90% de seu faturamento mensal. Os clientes da Ampla so, em sua maioria, grandes empresas, multinacionais em muitos casos. Os projetos tm entre 2 e 6 meses de durao e envolvem entre 2 e 4 profissionais. A Ampla resolveu realizar um projeto de melhoria de seu processo de desenvolvimento porque seu processo possuia pouca transparncia. No obstante, grande parte de seus projetos era finalizada com sucesso e possuia qualidade. A maioria entrava em produo com pouco atraso no cronograma e pouca variao nos custos Em 2001 o Centro de Pesquisas Renato Archer (CenPRA) foi contactado para orientar a empresa em seu projeto de melhoria de processo. O CenPRA j tinha realizado oito projetos como este, desde 1999. Uma terceira instituio, a UFLATEC, foi convidada a participar devido a experincia de sua pesquisadora, Ana Cristina Roullier. A pesquisadora desenvolveu o ProGer Process Model [2], um modelo para gerenciamento do processo de projetos de software, para pequenas empresas. O ProGer baseado no

PMBOK:2000 e na ISO/IEC TR 15504 [6]. ProGer foi desenvolvido como parte da tese de doutorado da pesquisadora e validado em 81 empresas de pequeno porte.

2. Avaliao e Definio dos Processos

O modelo adotado pelo CenPRA [3] constitudo de seis etapas: 1) Iniciar o ciclo e definir as metas, 2) Avaliar as prticas atuais, 3) Planejar melhorias, 4) Implementar as melhorias, 5) Verificar os resultados e aprender e 6) Institucionalizar as melhorias. Estas etapas foram realizadas entre Junho e Dezembro de 2002. A Figura 1 exibe as etapas, o cronograma e carga horria do projeto.

Figura 1 - Projeto A primeira fase foi composta pela elicitao do negcio da empresa, estratgias e objetivos. A escolha da ISO/IEC TR 15504 se deu devido flexibilidade para adaptaes s necessidades da Ampla. Decidiu-se utilizar cinco processos da futura norma, para o nvel 2 de capacidade. Os processo escolhidos foram: CUS.2 Suply, CUS.3 Requirement Elicitation, MAN.2 Project Management, ENG.1.6 Software Test e ORG.5 Measurement. Estes processos foram selecionados de forma a cobrir as necessidades de melhoria de processo da Ampla.

Figura 2 Mapeamento entre os processos selecionados e PFSA Uma equipe do CenPRA realizou a avaliao para estes cinco processos, at o nvel 3 de capacidade, para descobrir as prticas utilizadas. A avaliao foi feita atravs de entrevistas para coleta de dados, num total de oito horas. A avaliao foi feita de acordo com o mtodo de avaliao criado pelo CenPRA, com base no modelo RAPID [7].

Os resultados indicaram nvel 2 de capacidade para ORG.5 Measurement e nvel 1 para os outros [4]. A Ampla adota conceitos do Rational Unified Process (RUP) para definir suas atividades e ciclo de projeto, utiliza Anlise de Pontos de Funo para estimativas, anlise e gerenciamento de projetos para acompanhamento do cronograma e custos de projeto. Importante destacar que os desenvolvedores da Ampla registram todas as suas atividades numa base de dados (RegAtiv) desde 1999. O registro no estilo Personal Software Process (PSP) [8] e resulta num banco de dados de informaes com mais de 40.000 horas de projetos que servem para refinar as estimativas baseadas em anlise de pontos de funo e custos de forma geral. Aps a avaliao um plano simples de melhoria foi estabelecido, visando duas frentes de trabalho: 1) A definio do Processo da Fbrica de Software da Ampla Consultoria em Informao e 2) Estabelecer um processo de Teste de Software.

3. Desenvolvimento
A definio do Processo da Fbrica de Software da Ampla Consultoria em Informao (PFSA) iniciou-se com um mapeamento das prticas utilizadas, algumas documentadas, mas nem sempre repetidas e outras no documentadas. A Ampla possuia poucos artefatos mas nenhum processo para seguir, o que dificultava a evoluo dos artefatos utilizados e a criao (ou eliminao) de outros. O PFSA foi definido e criado como um fluxo com seis fases, cada uma com atividades, regras do processo, papis e artefatos que deveriam ser produzidos. As fases so: Prospeco, Proposta, Execuo, Garantia e Encerramento. Os principais artefatos gerados so: atas de reunio, proposta de projeto de software, documento de especificao, plano de projeto, plano de testes e relatrio de aceitao. Para cada um foi definido um modelo que deve ser utilizado pelos lderes de projeto e analistas O processo de Teste de Software foi definido com base no Guia para Elaborao de Documentos de Teste de Software [1] criado pelo CenPRA com base na IEEE 829 Standards for Software Testing Documentation [5] e como projeto piloto foi escolhido um produto da empresa, o SIQ-Metrologia, verso 2.0, dada s suas caractersticas: forte uso de clculos estatsticos e matemticos e preciso exigida, em alguns casos at a stima casa decimal. Usurios deste tipo de software, em geral, tm dvidas quanto aos clculos realizados pelo programa, assim, um plano de teste serviu para: a) estabelecer os procedimentos bsicos de testes para assegurar a qualidade do produto final e b) um documento de validao dos clculos, que fornecido ao cliente.

4. Processo da Fbrica de Software

A primeira verso do Processo da Fbrica de Software da Ampla Consultoria em Informao, (PFSA), foi definido em Dezembro de 2002 com as cinco fases acima relacionadas e aqui descritas em mais detalhes: Prospeco: Nesta fase esto descritas as atividades relacionadas aos primeiros contatos com clientes (patrocinadores do projeto e/ou futuros usurios). Nesta fase alguns artefatos foram criados para auxiliar no entendimento das

necessidades e desejos dos usurios. O uso de prototipao das principais interfaces , quando possvel, sempre utilizado. As interfaces prototipadas so sempre reutilizadas no projeto. Proposta: A anlise dos requisitos e interfaces dos prottipos gerados na fase de Prospeco so entradas para a gerao do documento de Proposta de Projeto de Software (PPS). Este artefato contm, entre outras informaes, a relao dos requisitos funcionais e no funcionais necessrios para atender aos requisitos e desejos dos clientes. Nesta fase pode ser necessrio revisar tais necessidades, que causaro alteraes na PPS. Execuo: Na execuo geramos o artefato Documento de Especificao (DE) com detalhes sobre a arquitetura e projeto do software a ser desenvolvido. Neste documento existe uma seo para que seja verificada a possibilidade de reutilizao de componentes j desenvolvidos em outros projetos, no entanto ainda no existe um controle rigoroso sobre este assunto. um ponto a ser evoludo. O desenvolvimento da aplicao tambm est dentro desta fase. Todos os artefatos sobre testes so desenvolvidos nesta fase (Plano, Projeto, Casos, Procedimento, Dirio e Resumo de Testes). Garantia: Na garantia est includa a validao do sistema pelo usurio (um artefato gerado), treinamento, instalao e configurao do software. A garantia inicia-se nesta fase. Encerramento: Reunies postmortem.

A Ampla est avaliando o PFSA em todos os projetos de software que desenvolveu desde sua definio. Como esperado, sugestes e ajustes esto surgindo, no entanto j possvel notar que alguns clientes reagiram positivamente em relao ao novo processo, indicando que o caminho est correto.

5. Concluses
Mesmo em ambientes pequenos de desenvolvimento possvel basear-se na 15504 para melhoria de processo. A 15504 pode integrar-se com outras normas e processos tais como IEEE 829 e RUP. necessrio definir um processo para que ele possa melhorar. Um banner do PFSA foi feito e colocado na diretoria da Ampla e na sala de reunies. Todos os novos projetos devem seguir o PFSA, quando no possvel, o assunto discutido e o mesmo ajustado, se necessrio. A equipe de desenvolvimento pode seguir um processo sem perder flexibilidade (ou criatividade). O fato de ter um processo definido e envolver seu cliente nele torna-o cmplice do mesmo, ou seja, mais fcil seguir com o projeto. A automatizao de processos no requisito para possu-lo.

6. Agradecimentos
SEBRAE/FINEP/PATME. Ncleo SOFTEX Campinas. CenPRA LQPS.

7. Referncias
[1] Adalberto Nobiato Crespo, Mria Regina Martins Martinez, Mrio Jino, Miguel de Teive Argollo Jnior (2001), Guia para Elaborao de Documentos de Teste de Software, Technical Report, Centro de Pesquisas Renato Archer CenPRA. [2] Ana Cristina Roullier (2001), Gerenciamento de Projetos de Software para Empresas de Pequeno Porte, Tese de Doutorado, UFPE. [3] Clnio F. Salviano (2000), Abordagem para melhoria de Processo, Technical Report, Centro de Pesquisas Renato Archer CenPRA. [4] Clnio F. Salviano, Ana Lcia Sampaio e Angelina Penteado (2002), Resultado da Avaliao de Processos Selecionados de uma Pequena Empresa de Software Segundo a Futura Norma ISO/IEC 15504 Empresa: Ampla Consultoria em Informao, Technical Report, Centro de Pesquisas Renato Archer CenPRA. [5] The Institute of Electrical and Electronics Engineers (1998), IEEE STD 829 Standard for Software Testing Documentation, IEEE Computer Society. [6] The International Organization for Standardization and The International Electrotechnical Commission, ISO/IEC TR 15504 Software Process Assessment. [7] T. P. Rout, A. Tufley, B. Cahil and B. Hodgen (2000), The Rapid Assessment of Software Process Capability, The First International SPICE Conference. [8] Watts S. Humphrey (1997), Introduction to the Personal Software Process, SEI Series in Software Engineering.