Procedimento de Medição e Análise do Modelo para Pequenos Grupos (MPG)

Transcrição

1 Procedimento de Medição e Análise do Modelo para Pequenos Grupos (MPG) Rita de Cássia Bitencourt Cardoso 1, Alexandre Marcos Lins de Vasconcelos 2, Ana Cristina Rouiller 3, Afonso Celso Soares 4 1, 4 Inatel - Instituto Nacional de Telecomunicações Avenida João de Camargo Santa Rita do Sapucaí MG Brasil 2 Centro de Informática Universidade Federal de Pernambuco Av. Professor Luis Freire, S/N Recife PE Brasil 3 epartamento de Ciência da Computação Universidade Federal de Lavras Cx Postal 37 CEP Lavras MG Brasil ritacardoso@inatel.br, amlv@ufpe.br, acr@comp.ufla.br, acsoares@inatel.br Abstract. This article presents an analysis and measurement s procedure. It is composed of politics, plan and reports. This procedure was added to the MG Model for Small Groups. That is a software development process and belongs to Inatel - Institute National Telecommunications, according to SW-CMM level 2. Resumo. Este artigo apresenta um procedimento de medição e análise composto de políticas, plano e relatório. Este procedimento foi adicionado ao MPG - Modelo para Pequenos Grupos.. O MPG é um processo de desenvolvimento de software de propriedade do Inatel - Instituo Nacional de Telecomunicações e é concordante com o nível 2 do SW-CMM. 1. Introdução Nos últimos dois anos, as gerências do ICC Inatel Competence Center - departamento de desenvolvimento de software do Inatel receberam relatórios de medições e análise dos projetos. Foi detectado, entretanto, que as informações dos relatórios não eram suficientes para uma análise conclusiva. Outro fator era que as atividades de medições e análises exigiam um grande esforço dos responsáveis, pois o modelo não tinha um procedimento claro de como fazer as medições. A deficiência dos relatórios era comprovada pelo número de dúvidas sobre a utilização e construção dos mesmos. Mesmo considerando que o MPG [1] é baseado no modelo SW-CMM [2], a definição e utilização dos relatórios de medição e análise não estavam adequados às necessidades de informações gerencias. Tais informações necessitavam de um processo claro, adequado, bem aceito e utilizado com sucesso de acordo com as necessidades da organização. Com a criação do Procedimento de Medição e Análise, o MPG [1] passou a ter um processo mais simples para medir e analisar os projetos. No próximo tópico é apresentada uma abordagem do MPG [1] e também como ele é constituído. No terceiro tópico é apresentado o Procedimento de Medição e Análise. As conclusões e as perspectivas futuras com este procedimento são apresentadas no quarto tópico. 2. O MPG O MPG [1] é um modelo de desenvolvimento de software que implementa o nível 2 de maturidade do SW-CMM [2] e foi baseado no RUP - Rational Unified Process [3]. Este modelo foi ajustado para que pudesse ser utilizado em pequenas organizações ou pequenos grupos fabricante de software. O MPG [1] é constituído de um documento mestre e se ramifica em outros três documentos, que definem procedimentos que são específicos a cada etapa gerencial de desenvolvimento. O documento MPG [1] descreve todas as políticas organizacionais, todas responsabilidades gerenciais de papeis e de grupos e as características dos documentos de processo de projeto. Os procedimentos derivados do documento mestre cobrem, cada um, uma etapa do ciclo de vida de desenvolvimento de um sistema. 101

2 Procedimento de Medição e Análise do Modelo para Pequenos Grupos Estes procedimentos são: Procedimento de Gerência de Projetos, responsável pela gerência de requisitos, planejamento e acompanhamento de projetos; Procedimento de Garantia da Qualidade, responsável pela garantia da qualidade do processo e do projeto; e o Procedimento de Gerência de Configuração e Mudança, responsável pela configuração e mudança. Esta representação pode ser vista na estrutura básica do MPG (figura 1). Todos estes procedimentos estão baseados em atividades de trabalho. Estas atividades encontramse descritas tanto na forma textual quanto na forma visual, por meio de diagramas de atividades que fazem uso de artefato que é um produto de trabalho. Este produto de trabalho, por sua vez, é desenvolvido durante uma determinada atividade dentro do processo de desenvolvimento de um sistema, de checklist que contém uma relação de itens e servem para avaliar e validar um ou mais artefatos. Estes últimos são produzidos por uma atividade e por templates (modelos, gabaritos ou esqueletos de um protótipo de artefato), que contêm orientações para a criação deste artefato. 102 Figura 1 - A Estrutura básica do Modelo para Pequenos Grupos - MPG 3. Procedimento de Medição e Análise (pma) Para a melhoria contínua do MPG [1] foi acrescentado ao modelo o Procedimento de Medição e Análise. Este procedimento contém um processo simplificado para medição e análise de desenvolvimento de software. Ele foca as necessidades de informação, conforme sugerido pelo modelo CMMI [4]. O objetivo do pma é fornecer informações concisas e claras sobre os projetos em desenvolvimento. Desta forma os gerentes podem mitigar riscos e tomar decisões com dados e fatos reais. A nova estrutura do MPG com a inclusão do Procedimento de Medição e Análise pode ser vista na figura 2. O Procedimento de Medição e Análise é composto de políticas, plano e relatório de medição e análise. As políticas estão definidas no documento mestre MPG [1]. O pma (figura 3) descreve as atividades necessárias, os artefatos de entrada e os critérios de entrada, os artefatos de saída e os critérios de saída. Este procedimento é utilizado ao final de cada fase do desenvolvimento (concepção, elaboração, construção e transição) e tem por finalidade medir e analisar tamanho, recursos, custo, cronograma, performance e eficácia da tecnologia utilizada durante o desenvolvimento de um sistema. Todas as atividades de medição e análise para um determinado sistema seguem o Plano de Medição e Análise, descrito no Plano de Desenvolvimento de Software, cuja responsabilidade de preenchimento é do Grupo de Garantia da Qualidade ou do Grupo de Processo de Engenharia de Software e do Líder de Projeto, do respectivo sistema. A aprovação o Plano de Medição e Análise é feita pela Gerência de Desenvolvimento de Sistema.

3 Rita de Cássia Bitencourt Cardoso, Ana Cristina Rouiller Figura 2 - Nova Estrutura do Modelo para Pequenos Grupos MPG com pma Figura 3 Diagrama de atividades 101

4

5 Rita de Cássia Bitencourt Cardoso, Ana Cristina Rouiller O Plano de Medição e Análise tem por finalidade planejar as medidas de informação a serem coletadas e analisadas, conforme se pode visualizar na Tabela 1, pois cada projeto tem necessidades específicas de informação. São as necessidades de informação que direcionam a seleção das medidas de informação [5]. No início da fase de concepção, os responsáveis identificam as medidas que serão coletadas durante o desenvolvimento do sistema, quais serão os artefatos de entrada, as ferramentas utilizadas, o responsável pela coleta e análise das informações, data em que ocorrerão as coletas de dados e a divulgação do Relatório de Medição e Análise para a Gerência de Sistema, Gerência de Desenvolvimento de Sistema e para o Líder de Projetos. Os objetivos deste plano são integrar as coletas de dados aos processos geradores de dados, proverem uma fonte central de definições de medidas e análises e integrar os relatórios de análise aos processos de tomadas de decisões [4]. Tabela 1: Necessidades de informação Categoria de informação Conceito mensurável Medidas candidatas Tamanho Componentes Esforço estimado Esforço real Tamanho estimado Tamanho real Mudanças Defeitos LOC Tabelas Classes Cronograma Alcance de Marcos Tempo de duração das fases Recurso e Custo Esforço por Integrante Esforço estimado por fase Esforço real por fase Custo por Integrante Custo estimado por fase Custo real por fase Esforço por Atividade Esforço estimado por fase Esforço real por fase Custo do Sistema Custo estimado por fase Custo real por fase Qualidade Conformidade do Processo Numero de auditorias por fase Numero de desvios Configuração e mudança Volatilidade da Tecnologia Mudanças na Baseline Na coleta das medidas, o Grupo de Garantia da Qualidade ou o Grupo de Processo de Engenharia de Software deve criar o Relatório de Medição e Análise para o projeto. Este relatório é uma planilha que contém os procedimentos de como o mesmo será utilizado. A eficácia da medição depende da fonte onde as mesmas serão coletadas. Para que esta eficácia seja alcançada é de suma importância que os dados a serem coletados sejam mantidos íntegros, durante todo o desenvolvimento do sistema. Durante a análise das medidas coletadas, o Grupo de Garantia da Qualidade ou o Grupo de Processo de Engenharia de Software deve sintetizar qualquer problema ou discrepância, identificada na medição, no Relatório de Medição e Análise, descrevendo a fonte do problema e avaliando os possíveis riscos que possam prejudicar o sucesso do projeto. Sugestões e alternativas para a melhora do projeto ou processo devem ser acrescentadas a esta análise. Ao final do projeto o Grupo de Garantia da Qualidade ou o Grupo de Processo de Engenharia de Software deve comunicar os resultados deste relatório a todos participantes do projeto, devendo também anexá-lo à base de dados de projetos anteriores. Isto irá contribuir para que estas informações possam ser utilizadas no auxílio de estimativas futuras. 101

6

7 Rita de Cássia Bitencourt Cardoso, Ana Cristina Rouiller Figura 4 Medição de tamanho Figura 5 Medição do cronograma 101

8 Procedimento de Medição e Análise do Modelo para Pequenos Grupos Figura 6 Medição de recurso e custo por integrante F 102

9 Rita de Cássia Bitencourt Cardoso, Ana Cristina Rouiller Figura 7 Medição de recurso e custo por atividade 103

10 Procedimento de Medição e Análise do Modelo para Pequenos Grupos Figura 8 Medição das atividades do GGQ Durante a medição do tamanho são inseridos no Relatório de Medição o tamanho do componente que foi estimados na Planilha de Estimativas para cada fase do desenvolvimento. Nesta planilha são inseridos o Status da documentação, funcionalidade, testes unitários e testes de integração do componente, são inseridos também o esforço estimado e real para o desenvolvimento do mesmo. As mudanças proposta e feitas durante todo o ciclo de vida. Os defeitos encontrados, corrigidos e abertos, as linhas de código do são coletas juntamente com a quantidade de classes e tabelas que foram necessárias. Na medição do cronograma são inseridos as estimativas das datas iniciais, data finais e a duração em dias para cada fase de desenvolvimento do projeto que estão descritas na Planilha de Estimativas em confronto com as medidas coletas ao final de cada fase. Figura 9 Medição das atividades do GCM As estimativas dos recursos e custos por integrante são inseridos no Relatório de Medição onde são identificados o estorço de cada integrante do projeto e o seu respectivo custo. Ao final de cada fase são coletas informações do sistema de registro de atividades. A medição dos recursos e custos por atividade são inseridos no Relatório de Medição onde são identificados o estorço gasto em cada fase do projeto afim de avaliar o processo utilizado. O objetivo desta medição e verificar as atividades dos Grupos de Garantia da Qualidade e Configuração e Mudanças. Todas as análises descrita em cada planilha do Relatório de Medição visam apresentar os problemas encontrados, os riscos associados ao problemas e as possíveis soluções do projeto como também do processo usado. 104

11 Procedimento de Medição e Análise do Modelo para Pequenos Grupos Conclusões e perspectivas futuras A inclusão do Procedimento de Medição e Análise no MPG [1] forneceu um entendimento claro do que e como as atividades de medição e análise devem ser feitas. Verificou-se também que o esforço necessário com esta atividade pôde ser reduzido substancialmente se comparamos com outros sistemas desenvolvidos pelo ICC (veja tabela 2). Tabela 2. Esforço com atividades de medição e análise Sistemas Esforço sem pma Esforço com pma Acme 15:38 Time 16:24 Orquídea 17:31 Prime 19:31 Hathor 12:56 O grande desafio do Procedimento de Medição e Análise é monitorar o processo de desenvolvimento de software visando manter a produtividade nos níveis estimados, contribuir para a redução de defeitos e o esforço consumido com manutenções devido a retrabalho, mantendo o orçamento sob controle [4]. Além disto, espera-se que a Gerência de Sistema, a Gerência de Desenvolvimento de Sistema e o Líder de Projeto consigam prever os riscos de um projeto com maior rapidez e qualidade. Espera-se ainda que possibilite maior suporte à tomada de decisões caso surjam problemas e, finalmente, avaliar e comunicar resultados de produtividade aos envolvidos. Como perspectivas futuras pretende-se ajustar integralmente o Procedimento de Medição e Análise ao CMMI nível 2, sendo que encontra-se em estudo o desenvolvimento de uma ferramenta automatizada para medição e análise do Inatel Competence Center. [5] PSM (2002) Practical Software Measurement. Objective Information for Decision Makers J. McGarry, D. Card, C. Jones, B.Layman, E. Clark, J. Dean, E. Hall 5. Referências [1] Inatel (2002) Modelo para Pequenos Grupos - MPG V1.0, Inatel Competence Center [2] SEI (1995) The Capability Maturity Model. Guidelines for Improving the Software Process. Carnegie Mellon University, Software Engineering Institute, Addison- Wesley. [3] Rational (2002) Rational Unified Process - RUP Rational Software Corporation. [4] SEI (2002) Capability Maturity Model Integration. Guidelines for Process Integration and Product Improvement, Carnegie Mellon University, Software Engineering Institute. Chrissis Konrad Shrum.. 102