Aplicação da ISO/IEC TR 15504 na Melhoria do Processo
de Desenvolvimento de Software de uma Pequena Empresa
Odair Jacinto da Silva1, Carlos Alberto Borges1, Clênio Sampaio Salviano2, Adalberto N. Crespo2, Ana Lúcia Sampaio2, Ana Cristina Roullier3
1Ampla Consultoria em Informação – Campinas – SP – Brazil 2Centro de Pesquisas Renato Archer (CenPRA) – Campinas – SP – Brazil 3Centro Tecnológico de Informática 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 Informação, a small software development company.
Resumo. Este artigo descreve os resultados obtidos com a aplicação da
ISO/IEC TR 15504 como referência para a melhoria do processo de desenvolvimento de software da Ampla Consultoria em Informação, uma empresa de desenvolvimento de software de pequeno porte.
1. Introdução
A Ampla Consultoria em Informação (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 Barão Geraldo.
A Ampla tem, desde o início 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 são, em sua maioria, grandes empresas, multinacionais em muitos casos. Os projetos têm entre 2 e 6 meses de duração 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 transparência. Não obstante, grande parte de seus projetos era finalizada com sucesso e possuia qualidade. A maioria entrava em produção com pouco atraso no cronograma e pouca variação 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 instituição, a UFLATEC, foi convidada a participar devido a experiência 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. Avaliação e Definição dos Processos
O modelo adotado pelo CenPRA [3] é constituído de seis etapas: 1) Iniciar o ciclo e definir as metas, 2) Avaliar as práticas 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 horária do projeto.
Figura 1 - Projeto
A primeira fase foi composta pela elicitação do negócio da empresa, estratégias e objetivos. A escolha da ISO/IEC TR 15504 se deu devido à flexibilidade para adaptações às necessidades da Ampla. Decidiu-se utilizar cinco processos da futura norma, para o nível 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 avaliação para estes cinco processos, até o nível 3 de capacidade, para descobrir as práticas utilizadas. A avaliação foi feita através de entrevistas para coleta de dados, num total de oito horas. A avaliação foi feita de acordo com o método de avaliação criado pelo CenPRA, com base no modelo RAPID [7].
Os resultados indicaram nível 2 de capacidade para ORG.5 Measurement e nível 1 para os outros [4].
A Ampla adota conceitos do Rational Unified Process (RUP) para definir suas atividades e ciclo de projeto, utiliza Análise de Pontos de Função para estimativas, análise 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 informações com mais de 40.000 horas de projetos que servem para refinar as estimativas baseadas em análise de pontos de função e custos de forma geral.
Após a avaliação um plano simples de melhoria foi estabelecido, visando duas frentes de trabalho: 1) A definição do Processo da Fábrica de Software da Ampla Consultoria em Informação e 2) Estabelecer um processo de Teste de Software.
3. Desenvolvimento
A definição do Processo da Fábrica de Software da Ampla Consultoria em Informação (PFSA) iniciou-se com um mapeamento das práticas utilizadas, algumas documentadas, mas nem sempre repetidas e outras não documentadas. A Ampla possuia poucos artefatos mas nenhum processo para seguir, o que dificultava a evolução dos artefatos utilizados e a criação (ou eliminação) de outros.
O PFSA foi definido e criado como um fluxo com seis fases, cada uma com atividades, regras do processo, papéis e artefatos que deveriam ser produzidos. As fases são: Prospecção, Proposta, Execução, Garantia e Encerramento. Os principais artefatos gerados são: atas de reunião, proposta de projeto de software, documento de especificação, plano de projeto, plano de testes e relatório de aceitação. Para cada um foi definido um modelo que deve ser utilizado pelos líderes de projeto e analistas
O processo de Teste de Software foi definido com base no Guia para Elaboração 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, versão 2.0, dada às suas características: forte uso de cálculos estatísticos e matemáticos e precisão exigida, em alguns casos até a sétima casa decimal. Usuários deste tipo de software, em geral, têm dúvidas quanto aos cálculos realizados pelo programa, assim, um plano de teste serviu para: a) estabelecer os procedimentos básicos de testes para assegurar a qualidade do produto final e b) um documento de validação dos cálculos, que é fornecido ao cliente.
4. Processo da Fábrica de Software
A primeira versão do Processo da Fábrica de Software da Ampla Consultoria em Informação, (PFSA), foi definido em Dezembro de 2002 com as cinco fases acima relacionadas e aqui descritas em mais detalhes:
• Prospecção: Nesta fase estão descritas as atividades relacionadas aos primeiros
contatos com clientes (patrocinadores do projeto e/ou futuros usuários). Nesta fase alguns artefatos foram criados para auxiliar no entendimento das
necessidades e desejos dos usuários. O uso de prototipação das principais interfaces é, quando possível, sempre utilizado. As interfaces prototipadas são sempre reutilizadas no projeto.
• Proposta: A análise dos requisitos e interfaces dos protótipos gerados na fase de
Prospecção são entradas para a geração do documento de Proposta de Projeto de Software (PPS). Este artefato contém, entre outras informações, a relação dos requisitos funcionais e não funcionais necessários para atender aos requisitos e desejos dos clientes. Nesta fase pode ser necessário revisar tais necessidades, que causarão alterações na PPS.
• Execução: Na execução geramos o artefato Documento de Especificação (DE)
com detalhes sobre a arquitetura e projeto do software a ser desenvolvido. Neste documento existe uma seção para que seja verificada a possibilidade de reutilização de componentes já desenvolvidos em outros projetos, no entanto ainda não existe um controle rigoroso sobre este assunto. É um ponto a ser evoluído. O desenvolvimento da aplicação também está dentro desta fase. Todos os artefatos sobre testes são desenvolvidos nesta fase (Plano, Projeto, Casos, Procedimento, Diário e Resumo de Testes).
• Garantia: Na garantia está incluída a validação do sistema pelo usuário (um
artefato é gerado), treinamento, instalação e configuração do software. A garantia inicia-se nesta fase.
• Encerramento: Reuniões postmortem.
A Ampla está avaliando o PFSA em todos os projetos de software que desenvolveu desde sua definição. Como esperado, sugestões e ajustes estão surgindo, no entanto já é possível notar que alguns clientes reagiram positivamente em relação ao novo processo, indicando que o caminho está correto.
5. Conclusões
• Mesmo em ambientes pequenos de desenvolvimento é possível basear-se na
15504 para melhoria de processo.
• A 15504 pode integrar-se com outras normas e processos tais como IEEE 829 e
RUP.
• É necessário definir um processo para que ele possa melhorar. Um banner do
PFSA foi feito e colocado na diretoria da Ampla e na sala de reuniões. Todos os novos projetos devem seguir o PFSA, quando não é possível, o assunto é discutido e o mesmo é ajustado, se necessário.
• 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 cúmplice
do mesmo, ou seja, é mais fácil seguir com o projeto.
6. Agradecimentos
• SEBRAE/FINEP/PATME. • Núcleo SOFTEX – Campinas. • CenPRA – LQPS.
7. Referências
[1] Adalberto Nobiato Crespo, Mária Regina Martins Martinez, Mário Jino, Miguel de Teive Argollo Júnior (2001), “Guia para Elaboração 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] Clênio F. Salviano (2000), “Abordagem para melhoria de Processo”, Technical Report, Centro de Pesquisas Renato Archer – CenPRA.
[4] Clênio F. Salviano, Ana Lúcia Sampaio e Angelina Penteado (2002), “Resultado da Avaliação de Processos Selecionados de uma Pequena Empresa de Software Segundo a Futura Norma ISO/IEC 15504 – Empresa: Ampla Consultoria em Informação”, 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.
