MPS.BR - G Level Assessment Results in a Large Brazilian Finance Corporation

MPS.BR - G Level Assessment Results in a Large Brazilian Finance Corporation Edgard D. Amoroso (Mestrado em Gestão do Conhecimento e Tecnologia da Informação Universidade Católica de Brasília (UCB) Brasília DF Brasil) edgard_amoroso@uol.com.br Fabiano C. Fernandes (Mestrado em Gestão do Conhecimento e Tecnologia da Informação Universidade Católica de Brasília (UCB) Brasília DF Brasil) fabiano_fernandes@yahoo.ca Káthia M. de Oliveira (Mestrado em Gestão do Conhecimento e Tecnologia da Informação Universidade Católica de Brasília (UCB) Brasília DF Brasil) kathia@ucb.br This paper describes the MPS.BR - G level assessment results in a large brazilian finance corporation. This company intends to achieve the MPS.BR - G maturity level and has been adjusting its software development process to complete this goal. This assessment has used the MPS.BR general guide and the MPS.BR assessment guide in order to focus in the G maturity level results, which are Process Management and Requirements Management. The assessment results are presented and directions are suggested to improve both process. Key-Words. MPS.BR, software quality, capability maturity model, project management, requirement management. Diagnóstico do nível G do Modelo de Referência MPS.BR em uma instituição financeira Este artigo descreve uma experiência de aplicação da avaliação do MPS.BR nível G em uma grande empresa do setor financeiro brasileiro. A referida empresa tem como meta a obtenção do nível G de maturidade do modelo MPS.BR e para tanto tem buscado adequar os seus processos de desenvolvimento visando o alcance desta meta. A avaliação utilizou o Guia Geral e o de Avaliação do MPS.BR, focando nos resultados previstos para o nível de maturidade G, que envolve os processos de Gerência de Projetos e Gerência de Requisitos. Os resultados são apresentados e diretrizes são sugeridas para melhoria de ambos os processos. 342

1. Introdução Um dos maiores problemas encontrados no desenvolvimento e manutenção de software está na criação e gerenciamento de processos para as diversas etapas que compõem o seu ciclo de vida. Um processo de software é uma seqüência de etapas, envolvendo métodos, ferramentas e pessoas, executadas para realizar um determinado objetivo (Pressman, 2002: 21). Tornou-se fundamental para as empresas, também as que atuam no sistema financeiro, uma estratégia para definição e gerenciamento desses processos (CMMI, 2002). A instituição financeira avaliada está buscando criar processos para as fases do ciclo de vida de software que ainda não estão devidamente formalizadas na organização e melhorar os processos para as áreas em que os mesmos já se encontram definidos. A maior dificuldade encontrada entre as equipes de desenvolvimento de software é fazer com que as mesmas mudem a sua forma de desenvolvimento e manutenção de sistemas (Pressman, 2002: 829). Juntamente com a criação e redefinição de seus processos a organização pretende alcançar níveis de maturidade no desenvolvimento de suas aplicações, buscando formar e preparar o seu pessoal, certificar a sua maturidade junto a entidades com reconhecimento mundial em qualidade de processos e produtos de software. A obtenção dessa maturidade não é algo que acontece a curto prazo (MPS.BR, 2006a: 5), o tempo médio para se atingir níveis altos de maturidade do CMMI-SE/SW (Capability Maturity Model Integration Systems Engineering / Software Engineering) pode levar de 4 a 10 anos de esforços. Os insucessos não devem causar desmotivação e sim um aprendizado daquilo que devemos corrigir nos processos e formas de trabalho. A organização avaliada encontra-se em um estágio bastante evoluído, em relação aos processos de Gerência de Projetos, Gerência de Configuração e Gerência de Subcontratação. Com relação aos demais processos, existe uma intenção de melhoria daquilo que faz parte da área de Tecnologia da Informação da organização. A avaliação oriunda deste trabalho tem como objetivo verificar qual o grau de aderência da organização em relação ao nível de maturidade G, do modelo de desenvolvimento de software MPS.BR. A seção 2 apresenta uma descrição sucinta do modelo de referência MPS.BR. A seção 3 descreve o método de avaliação utilizado. A seção 4 descreve a avaliação conduzida e apresenta os resultados obtidos e a seção 5 apresenta as conclusões do trabalho. 2. MPS.BR - Melhoria de Processo do Software Brasileiro O programa para MPS.BR (Melhoria de Processo do Software Brasileiro), baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos (MPS.BR, 2006a: 6). O MPS.BR visa atender às necessidades de negócio de micro, pequena e média empresa, oferece também um processo e um método de avaliação que garante que o modelo esteja sendo empregado coerentemente. 343

O MPS.BR possui três componentes: MR-MPS (Modelo de Referência), MA-MPS (Método de Avaliação) e MN-MPS (Modelo de Negócio). Cada componente é descrito através de guias e/ou documentos do MPS.BR. O MR-MPS contém os requisitos que os processos das unidades organizacionais devem atender para estar em sua conformidade. Ele contém as definições dos níveis de maturidade, processos e atributos do processo (MPS.BR, 2006a: 12). 2.1. Modelo de Referência MPS.BR O Modelo de Referência MPS.BR é um modelo de melhoria e avaliação de processo de software que define níveis de maturidade resultantes de uma combinação entre processos e sua capacidade (MPS.BR, 2006a: 14). A capacidade do processo é definida como a habilidade do mesmo em alcançar os objetivos do negócio, atendendo aos atributos de processo relacionados aos processos de cada nível de maturidade. 2.2. Capacidade de Processo A capacidade de processo é representada por determinados AP (Atributos de Processo) descritos em termos de RAP (Resultados Esperados). A capacidade de processo expressa o grau de desenvolvimento e institucionalização com que o processo é executado na organização (MPS.BR, 2006a: 17). Na Tabela 1 temos a definição dos AP e RAP para o nível G do MPS.BR. Atributos de Processo AP 1.1 - O processo é executado. AP 2.1 - O processo é gerenciado. Tabela 1. Nível de maturidade G do MPS.BR Nível G - Gerência de Requisitos e Gerência de Projetos Resultados Esperados RAP1: O processo atinge seus resultados definidos. RAP2: Existe uma política organizacional estabelecida e mantida para o processo; RAP3: A execução do processo é planejada; RAP4: (para o Nível G). A execução do processo é monitorada e ajustes são realizados para atender aos planos; RAP5: Os recursos necessários para a execução do processo são identificados e disponibilizados; RAP6: As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP7: A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto; RAP8: O estado, atividades e resultados do processo são revistos com os níveis adequados de gerência (incluindo a gerência de alto nível) e problemas pertinentes são tratados. 344

O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, no contexto dos requisitos e restrições do projeto. O propósito do processo de Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto (MPS.BR, 2006a: 24). 3. Método de Avaliação do MR-MPS O MA-MPS visa avaliar objetivamente os processos de software de uma organização, atribuição de nível de maturidade do MR-MPS com base nas informações obtidas na avaliação e pode ser aplicado em todos os domínios da indústria de software em empresas de qualquer porte. O processo de avaliação descreve um conjunto de atividades para verificar a maturidade das unidades organizacionais na execução dos processos de software. O processo de avaliação é composto dos subprocessos mostrados na Figura 1. 345

Contratar a avaliação OPÇÃO 1/3 1. Selecionar Instituição Avaliadora (IA) 2. Estabelecer contrato OPÇÃO 2/3 1. Contactar SOFTEX 2. Estabelecer contrato Preparar para a realização da avaliação 1. Planejar a avaliação 2. Preparar a avaliação 3. Conduzir avaliação inicial 4. Completar preparação da avaliação Realizar a avaliação 1. Conduzir avaliação 2. Avaliar o processo de execução da avaliação Documentar os resultados da avaliação 1. Relatar resultados 2. Registrar resultados Figura 1. Processo de avaliação (MPS.BR, 2006b: 6) 3.1. Realizar a Avaliação O propósito do subprocesso Realizar a Avaliação é treinar a equipe, conduzir a avaliação MPS e comunicar seus resultados à unidade organizacional avaliada (MPS.BR, 2006b: 25). A Tabela 2 mostra a escala para caracterização do grau de implementação de um resultado esperado. 346

Tabela 2. Escala para caracterização do grau de implementação de um resultado esperado (MPS.BR, 2006b: 33) Grau de Implementação Totalmente Implementado (T) Largamente Implementado (L) Parcialmente Implementado (P) Caracterização O indicador direto está presente e é julgado adequado; Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação; Não foi notado nenhum ponto fraco substancial O indicador direto está presente e é julgado adequado; Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação; Foi notado um ou mais pontos fracos substanciais O indicador direto não está presente ou é julgado inadequado; Artefatos/afirmações sugerem que alguns aspectos do resultado esperado estão implementados; Pontos fracos foram documentados As regras para agregar a caracterização dos projetos avaliados para se chegar à caracterização da organização podem ser identificadas na Tabela 3. Tabela 3. Regras para agregar a caracterização dos projetos para chegar à caracterização da organização (MPS.BR, 2006b: 35) Caracterização nos projetos Avaliados Todos X Caracterização agregada para a organização X Todos os projetos terminados X Todos T ou L Todos T ou L e os incompletos NA Existem P, mas não existem N Existe N X L L L ou P N, P ou L A caracterização dos atributos de processo avaliados para satisfazer o nível de maturidade pode ser identificada na Tabela 4. 347

Tabela 4. Caracterização de atributos do processo para satisfazer aos níveis MPS (MPS.BR, 2006b: 38) Nível MPS Atributos do processo Caracterização G AP 1.1 e AP 2.1 L ou T A caracterização do grau de implementação dos processos da organização está descrita no Guia de Avaliação do MPS.BR, atividade: caracterizar o grau de implementação dos processos da organização e são resumidos na Tabela 5. Tabela 5. Caracterização do grau de implementação dos processos na organização (MPS.BR, 2006b: 37) Um processo está satisfeito quando: Todos os resultados esperados para o processo foram caracterizados como T (Totalmente implementado) ou L (Largamente implementado), sendo que aproximadamente 85% é T (este valor é uma orientação, valendo sempre a decisão da equipe de avaliação). Considerar que sempre deve ser possível pelo menos uma caracterização L. Logo, deve-se considerar 75% T para processos com 4 resultados, e entre 75% e 85% T para processos com entre 5 e 7 resultados. 4. Avaliação dos Processos de Gerência de Projetos e Gerência de Requisitos Esta seção apresenta uma descrição de como foi conduzida a avaliação e apresenta os resultados obtidos. A avaliação dos processos que compõem o nível G do MR-MPS foi realizada sob a orientação do guia de avaliação MA-MPS, com ajustes de adequação ao contexto da avaliação. Não houve a seleção de uma Instituição Avaliadora credenciada nem será feito o registro da avaliação na base de dados confidencial do SOFTEX, por ser uma avaliação interna da instituição. O processo de avaliação apresentado na Figura 1, foi conduzido por três pessoas, dois são membros externos e um é membro interno da organização. Nenhum membro da equipe de avaliadores participou dos projetos avaliados. Foi estabelecido contato com um representante da alta administração da unidade organizacional a ser avaliada e o mesmo demonstrou o interesse na realização de uma avaliação não oficial do MPS, demonstrando comprometimento com os objetivos e a indicação dos recursos, tempo e pessoal disponível para fornecer informações à avaliação. A equipe de avaliadores se comprometeu a fornecer um documento de feedback contendo o resultado da avaliação, os pontos fortes e aqueles que necessitam melhorias. Também foi expressa toda a confidencialidade mantida no processo de avaliação e a experiência da equipe em desenvolvimento de software e em avaliação MPS.BR. Foram escolhidos dois projetos importantes para a organização, o primeiro ainda em andamento e o segundo já concluído. 348

A seguir serão apresentadas cada uma das atividades do processo de avaliação, conforme disposto na Figura 1. 4.1. Contratar a Avaliação Foi negociado com o representante da alta administração da unidade organizacional os termos para a realização da avaliação citada, sendo que o mesmo aceitou a proposta e formalizou um contrato verbal entre as partes. O tempo definido para coleta e análise das informações na organização não foi maior do que dois dias, conforme disposto no Manual de Avaliação do MPS.BR. 4.2. Preparar para a Realização da Avaliação A partir da reunião realizada com a alta administração da organização foram traçados os primeiros passos para a realização da avaliação, onde foram apontadas as pessoas que de alguma forma poderiam fornecer subsídios, informações e documentos do processo para a avaliação. Os processos avaliados são: Gerência de Requisitos e Gerência de Projetos, onde a empresa possui os processos definidos e disponíveis para toda a organização. Conforme citado anteriormente, foram selecionados dois projetos da área de Informações Gerenciais, sendo um concluído e outro em andamento (fase de codificação). Utilizando o MR-MPS foram identificados os resultados esperados, conforme a Tabela 6. Tabela 6. Identificação dos resultados esperados (MPS.BR, 2006a: 22) GERÊNCIA DE REQUISITOS GRE 1 GRE 2 GRE 3 GRE 4 GRE 5 GRE 6 GRE 7 Uma comunicação contínua com os fornecedores de requisitos é estabelecida O entendimento dos requisitos é obtido A aceitação dos requisitos é estabelecida por meio de critérios objetivos O comprometimento com os requisitos é estabelecido e mantido A rastreabilidade entre os requisitos, os planos do projeto e os produtos de trabalho é estabelecida e mantida Inconsistências entre os planos de projeto, os produtos de trabalho e os requisitos são identificadas e corrigidas Mudanças nos requisitos são gerenciadas ao longo do projeto 349

GERÊNCIA DE PROJETOS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 O escopo do trabalho para o projeto está definido O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados As fase do ciclo de vida do projeto são definidas A visibilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis é avaliada As tarefas, os recursos e a infra-estrutura necessários para contemplar o trabalho são planejados O cronograma e o orçamento do projeto são estabelecidos e mantidos Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados Os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-lo, incluindo questões de privacidade e segurança Os recursos Humanos para o projeto são planejados considerando o perfil e conhecimentos necessários para executar o projeto O esforço e o custo para os produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências técnicas O envolvimento dos interessados no projeto é planejado O planejamento do projeto é revisado com todos os interessados e o compromisso com o mesmo é obtido O planejamento do projeto é monitorado no que se refere a cronograma, custos, recursos, riscos, envolvimento dos interessados e dados Revisões são realizadas em marcos do projeto conforme estabelecido no planejamento Registros e análise dos problemas identificados nas monitorações são estabelecidos Ações corretivas são estabelecidas quando necessário e gerenciadas até a sua conclusão Partindo de cada um dos resultados esperados para os processos a serem avaliados, foram mapeados os artefatos diretos e indiretos que poderão dar a evidência de que os mesmos foram implementados nos projetos avaliados, conforme Tabela 7. 350

Tabela 7. Mapeamento dos resultados esperados para os processos Artefatos Diretos Artefatos Indiretos 1 Documento de especificação do sistema demanda de serviço do cliente Plano de projeto 2 Cronograma do projeto (plano de projeto) Plano de projeto e demanda de serviço do cliente 3 Plano de projeto (EAP) Demanda de serviço do cliente GRE 1 GRE 2 Demanda de serviço do cliente e memória de reunião Documento de requisitos do sistema e memória de reunião Planejamento do projeto (registrado no sistema de controle de projetos) Plano de projeto e demanda de serviço do cliente GRE 3 Documento de requisitos do sistema Relatório de progresso do projeto Esta fase foi facilitada pois o avaliador interno participou do quadro de desenvolvedores da organização agregando o seu conhecimento em todo o ambiente, inclusive de documentação e ferramentas utilizadas no desenvolvimento de sistemas. Nenhum membro da equipe de avaliadores é superior hierárquico de quem foi entrevistado nem participou dos projetos avaliados. Para a obtenção das afirmações necessárias a cada um dos indicadores, foi elaborado um questionário, visando identificar se o indicador está sendo cumprido pela organização, conforme Tabela 8. 351

Tabela 8. Elaboração de afirmações a respeito dos indicadores para os processos 1 2 3 GRE 1 GRE 2 GRE 3 Perguntas Como é coletado o escopo do projeto? Como é feita a estimativa do escopo, produtos de trabalho e estimativa das tarefas do projeto? Como é o ciclo de vida, dentro da unidade de desenvolvimento de aplicativos? Como é realizada a comunicação contínua com os fornecedores de requisitos? Como é obtido o entendimento dos requisitos? Quais os critérios objetivos estabelecidos para a aceitação dos requisitos? Responsáveis pela Resposta Analista de requisitos e gerente de projetos Analista de requisitos e gerente de projetos Analista de requisitos e gerente de projetos Gerente de projetos Equipe de métricas dos projetos e a equipe de requisitos Gerente de projetos A organização disponibilizou aos avaliadores os documentos identificados e os mesmos foram armazenados em um repositório especifico para a realização da avaliação. Os mesmos encontravam-se em um repositório corporativo de dados e nas ferramentas corporativas disponíveis para gerenciamento de projetos e requisitos. Identificados os resultados esperados e a capacitação que a organização deverá comprovar para atingir o objetivo de maturidade do MR-MPS, iniciou-se o processo de mapeamento dos artefatos diretos e indiretos para cada um dos resultados e capacitação. 4.3. Realizar a Avaliação Baseando-se nos resultados esperados, relatados na seção 4.2 e nos conceitos definidos para identificação dos resultados, foram produzidos levando-se em conta os artefatos diretos e indiretos e entrevistas realizadas com funcionários que possam afirmar a implementação do indicador. O nível de implementação dos indicadores foi atribuído, conforme disposto na seção 3.1. Quando da análise dos indicadores visando comprovar se os resultados esperados foram obtidos, o avaliador da área de desenvolvimento da organização apontou em cada um dos documentos analisados onde o mesmo estava implementado. Um exemplo parcial do documento utilizado na análise está disposto na Tabela 9 e na Tabela 10. No documento foram utilizadas cores para registrar o grau de implementação do indicador: verde representa totalmente implementado e amarelo indica parcialmente implementado. 352

Para atribuição dos conceitos para cada um dos indicadores avaliados foi utilizada a Tabela 2, constante da seção 3.1. Tabela 9. Avaliação dos processos (parcial) GERÊNCIA DE PROJETOS 1 O escopo do trabalho para o projeto está definido. Projeto 1 Projeto 2 Conceito Artefatos Diretos Documento de requisito do sistema e demanda de serviço do sistema Artefatos Indiretos Plano de projeto T Afirmações Gerente de projetos 2 O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados. Artefatos Diretos Cronograma do projeto (plano de projeto) Artefatos Indiretos Plano de projeto e demanda de serviço do sistema T Afirmações Equipe de métricas dos projetos e a equipe de requisitos 3 As fases do ciclo de vida do projeto são definidas. Artefatos Diretos Plano de projeto (eap) Amarelo Amarelo Artefatos Indiretos Demanda de serviço do sistema L Afirmações Gerente de projetos 353

Tabela 10. Avaliação dos processos (parcial) GERÊNCIA DE REQUISITOS GRE 1 O escopo do trabalho para o projeto está definido. Projeto 1 Projeto 2 Conceito Artefatos Diretos Artefatos Indiretos Demanda serviço e memória de reunião Planejamento do projeto (sistema gerência projetos) T Afirmações Analista de requisitos e gerente de projetos GRE 2 Artefatos Diretos Artefatos Indiretos O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados. Documento de requisitos do sistema e memória de reunião Plano de projeto e demanda de serviço T Afirmações Analista de requisitos e gerente de projetos GRE 3 As fases do ciclo de vida do projeto são definidas. Artefatos Diretos Documento de requisitos do sistema Amarelo Amarelo Artefatos Indiretos Relatório de progresso do projeto L Afirmações Analista de requisitos e gerente de projetos Em seguida foram mapeados os atributos necessários em termos de capacidade de processo e identificados quais os artefatos (diretos, indiretos e afirmações) que comprovam o nível de capacidade da organização, conforme disposto na Tabela 11 e na Tabela 12. No documento foram utilizadas cores para registrar o grau de implementação do indicador: verde representa totalmente implementado e amarelo indica parcialmente implementado. Para atribuição dos conceitos para cara um dos indicadores avaliados foi utilizada a Tabela 2, constante da seção 3.1. 354

Tabela 11. Avaliação da capacidade do processo (parcial) CAPACIDADE DO PROCESSO GERÊNCIA DE PROJETOS Ap 1.1 - o processo é executado RAP 1 O processo atinge seus resultados definidos Conceito Conceito Artefatos Diretos Metodologia de gerência de projetos estabelecida pelo escritório de projetos Artefatos Indiretos Estrutura organizacional do Eproj T Afirmações Consultor do escritório de projetos RAP 2 Existe uma política organizacional estabelecida e mantida para o processo; Artefatos Diretos Metodologia de gerência de projetos estabelecida pelo escritório de projetos Artefatos Indiretos Estrutura organizacional do Eproj T Afirmações Consultor do escritório de projetos 355

Tabela 12. Avaliação da capacidade do processo (parcial) CAPACIDADE DO PROCESSO GERÊNCIA DE REQUISITOS AP 1.1 - O processo é executado RAP 1 O processo atinge seus resultados definidos Conceito Conceito Artefatos Diretos Metodologia de desenvolvimento de sistemas da organização processo de gerência requisitos Artefatos Indiretos Estrutura organizacional T Afirmações Analista de requisitos e gerente de projetos RAP 2 Existe uma política organizacional estabelecida e mantida para o processo Artefatos Diretos Metodologia de desenvolvimento de sistemas da organização processo de gerência requisitos Amarelo Artefatos Indiretos Estratégia organizacional e estrutura organizacional L Afirmações Analista de requisitos e consultor do Eproj Segundo a preparação apresentada na seção 4.2, foram realizadas entrevistas para obtenção de afirmações à partir de questões elaboradas mostrado na Tabela 13. 356

Tabela 13. Perguntas sobre afirmações de indicadores do processo (parcial) GERÊNCIA DE REQUISITOS GRE 1 GRE 2 GRE 3 Perguntas Como é realizada a comunicação contínua com os fornecedores de requisitos? Como é obtido o entendimento dos requisitos? Quais os critérios objetivos estabelecidos para a aceitação dos requisitos? Respostas O registro inicial do pedido é feito através de uma Demanda Executiva que é devidamente priorizada pelas áreas de negócio e dependendo do tamanho transformando-se em um projeto, manutenção corretiva ou evolutiva de sistemas. É feito o seu registro no aplicativo responsável pelo gerenciamento de requisitos e durante todo o transcorrer de seu ciclo de vida é acompanhado. O entendimento é obtido através de reuniões de coleta de informações e registrado no aplicativo que controla o gerenciamento de requisitos de sistema. O gerenciador de requisitos permite ao usuário verificar se o que está registrado é aquilo que ele necessita para o seu negócio e consequentemente dar a aceitação ou não do pedido. A fase de requisitos somente é dada como encerrada quando aceita pelo usuário da área de negócios. GERÊNCIA DE PROJETOS 1 2 3 Perguntas Como é coletado o escopo do projeto? Como é feita a estimativa do escopo, produtos de trabalho e estimativa das tarefas do projeto. Como é o ciclo de vida, dentro da unidade de desenvolvimento de aplicativos. Respostas Na iniciação do projeto é solicitado ao demandante o preenchimento de dois formulários, um com informações da importância do projeto e funções preliminares a serem implementadas, no segundo um conjunto de informações sobre requisitos funcionais e não funcionais que determinam o tamanho e a complexidade do produto a ser desenvolvido no projeto. Em projetos de médio e pequeno porte, o projeto é submetido para a priorização da área de negócio em conformidade com a disponibilidade de recursos da área de desenvolvimento subordinante. Os projetos mais complexos, que envolvem diversas áreas, os mesmos são submetidos a um comitê organizacional de TI. Dentro da Demanda de Serviços de TI existe uma estimativa por fase, desde a coleta de requisitos até a implantação do produto final. 357

4.4. Documentar os Resultados da Avaliação Uma vez finalizada a avaliação fez-se necessário a compilação das informações coletadas durante o processo avaliatório, separadamente por segmento avaliado, conciliando as informações obtidas conforme apresentado na seção 3.1. No que se refere aos processos de Gerência de Projetos, composto por 16 indicadores e para que seja considerado como satisfeito o processo é necessário que 85% sejam considerados como T (Totalmente Implementado), conforme apresentado na Tabela 14, Tabela 15 e Figura 2. Tabela 14. Resultados consolidados da avaliação do nível G do MPS.BR (Gerência Projetos) GERÊNCIA DE PROJETOS Conceito Conceito Conceito 1 T 7 T 13 T 2 T 8 T 14 T 3 L 9 T 15 T 4 T 10 L 16 T 5 T 11 T 6 T 12 T Conceito Quantidade Percentual Mínimo esperado T 14 87,5 % Total de processos: 16 L 2 12,5 % 85% equivale a: 13,6 358

Tabela 15. Resultados consolidados da avaliação do nível G do MPS.BR (Gerência Projetos) CAPACIDADE DO PROCESSO - GERÊNCIA DE PROJETOS Conceito Conceito RAP 1 T RAP 5 T RAP 2 T RAP 6 L RAP 3 T RAP 7 T RAP 4 T RAP 8 T RESUMO T 7 87,5 % L 1 12,5 % Figura 2.Gráfico de indicadores consolidados da avaliação do nível G GERÊNCIA DE PROJETOS Capacidade do Processo Gerência de Projetos 12,5 12,5 T L T L 87,5 87,5 Considerando as Tabelas 4 e 5 e as informações constantes das Tabelas 14 e 15, o processo de Gerência de Projetos está totalmente satisfeito na organização e aderente ao nível G de maturidade do MPS.BR. No que se refere aos processos de Gerência de Requisitos, composto por 7 indicadores e para que seja considerado como satisfeito o processo é necessário que 75% sejam considerados como T (Totalmente Implementado), conforme apresentado na Tabela 16, Tabela 17 e Figura 3. 359

Tabela 16. Resultados consolidados da avaliação do nível G do MPS.BR (Gerência Requisitos) GERÊNCIA DE REQUISITOS Conceito Conceito Conceito GRE 1 T GRE 4 T GRE 7 T GRE 2 T GRE5 T GRE 3 L GRE6 T Conceito Quantidade Percentual Mínimo esperado T 6 85,7 % Total de processos 7 L 1 14,3 % 75% equivale a: 5,25 Tabela 17. Resultados consolidados da avaliação do nível G do MPS.BR (Gerência Requisitos) CAPACIDADE DO PROCESSO - GERÊNCIA DE REQUISITOS Conceito Conceito RAP 1 T RAP 5 T RAP 2 L RAP 6 L RAP 3 T RAP 7 T RAP 4 T RAP 8 L RESUMO T 5 62,5 % L 3 37,5 % 360

Figura 3.Gráfico de indicadores consolidados da avaliação do nível G GERÊNCIA DE REQUISITOS CAPACIDADE DO PROCESSO GERÊNCIA DE REQUISITOS 14,3 85,7 T L 37,5 62,5 T L Considerando as Tabelas 4 e 5 e as informações constantes da Tabela 16, Tabela 17 e Figura 3, o processo de Gerência de Requisitos está Totalmente Satisfeito na Organização e aderente ao nível G de maturidade do MPS.BR. 4.5. Demais Considerações a Respeito da Avaliação Realizada Conforme acordado com a empresa avaliada, foi elaborado um documento a ser entregue para seu gerente geral, relatando os pontos fortes e fracos observados nos processos avaliados, bem como sugestões para a melhoria de resultados esperados. Uma parte do relatório apresentado na Tabela 18. Tabela 18. Relatório de pontos fortes, fracos e sugestões de melhoria dos processos. Pontos fortes Pontos fracos Sugestões de melhoria Se possível, utilizar um software que O processo de Gerência Alguns documentos não possa implementar o de Projetos está em possuem o controle de controle de versão constante reavaliação. versão muito claro. nos documentos Está sendo implantada uma ferramenta que permitirá um controle mais efetivo dos documentos gerados e suas versões, bem como um acompanhamento mais rigoroso do processo. A ferramenta de Gerência de Projetos que está sendo implantada, conforme depoimento dos líderes de projeto não é muito intuitiva e tem problemas de usabilidade. gerados. Verificar junto ao fornecedor a possibilidade de melhorar a usabilidade da ferramenta em novos releases. 361

O rodízio periódico dos consultores do Escritório de Projetos gera uma uniformização nos procedimentos e uma oxigenação na relação entre o mesmo e os líderes dos projetos das diversas gerências da Unidade de Desenvolvimento de Aplicativos. A criação de indicadores que permitem avaliar a Qualidade dos Requisitos dos sistemas, dando uma visibilidade para a organização, por gerência da área de desenvolvimento de sistemas. Indicadores que permitem avaliar a Qualidade dos Requisitos dos sistemas, dando uma visibilidade para a organização, por gerência da área de desenvolvimento de sistemas. Indicadores que permitem avaliar a quantidade de analistas treinados em Requisitos de Sistemas por gerência. Falta de padronização de formulários de reuniões. Falta de padronização de pastas para guarda de documentos de projetos. Existe uma padronização para identificação individual de projetos, entretanto não existe uma padronização interna, dentro de cada projeto que permita a identificação dos documentos gerados por Gerência. Exemplo: Gerência de Subcontratação, Requisitos, Projetos, Teste, etc. A organização trata a Matriz de Comunicação dentro do Plano de Projeto, entretanto não existe bem clara a identificação de versão dentro da mesma. O detalhamento de alterações e novos acordos podem ser identificados através do Relatório de Acompanhamento e Progresso do Projeto. A organização trata a Matriz de Riscos dentro do Plano de Projeto, entretanto não está clara a identificação de versão. As alterações nos riscos do projeto pode ser identificado através do Relatório de Acompanhamento. Elaboração de um padrão de documentos de reuniões de Projeto, que sirva para qualquer uma das fases do ciclo de vida do projeto, bem como um padrão de nomes e controle de versões. Elaboração de um Framework, por Gerência do processo para armazenamento dos documentos dos projetos, inclusive com padronização do nome dos documentos e controle de versão. Implementar dispositivos que permitam uma melhor visualização do acompanhamento da Matriz de Comunicação do Projeto. Implementar dispositivos que permitam uma melhor visualização do acompanhamento dos Riscos do Projeto. 362

A organização implementou o processo de Gerência de Projetos no ano de 2004, portanto o mesmo passou por diversos processos de evolução, sendo considerado, durante o processo de avaliação como bastante evoluído e consolidado dentro da organização. Quanto ao processo de Gerência de Requisitos, implantado no segundo semestre de 2005, encontra-se em pleno funcionamento, entretanto verifica-se que a sua evolução já se encontra planejada em termos de trabalhos futuros e tem-se observado uma melhoria significativa na qualidade dos projetos gerados a partir de sua implantação. Estatísticas internas mostram que após a consolidação do Escritório de Projetos na organização, houve uma redução sensível na quantidade de alterações nos escopos de projetos, bem como a redução de acordos de prazos dos mesmos. 5. Conclusões A organização avaliada neste trabalho, através de seus processos de Gerência de Requisitos e Gerência de Projetos, possui em seu acordo de trabalho firmado com os recursos da área de desenvolvimento de sistemas, a meta de obtenção do nível de maturidade G do MPS.BR, avaliado neste artigo. Entretanto, não possuía dispositivos capazes de identificar o grau de aderência de seus processos ao referido modelo. Neste artigo foi possível formar uma conciliação de interesses entre a organização e a necessidade de realização de uma avaliação não oficial segundo critérios formais do MA-MPS. A avaliação seguiu tanto o processo do MA-MPS como todas as regras estabelecidas durante a fase inicial do processo. Em linhas gerais, a realização da avaliação seguiu conforme o planejado nas atividades iniciais. Um aspecto a ser notado no evento, é que na preparação dos artefatos necessários para a realização da avaliação foram considerados alguns documentos que não permitiram identificar os resultados esperados, sendo que com a substituição por novos artefatos foi possível observar a sua implementação. O resultado final obtido com esta avaliação é que a organização possui os processos de Gerência de Projetos e Requisitos totalmente satisfeita, sendo considerada apta ao nível G de maturidade do Modelo de Referência MPS.BR. A organização tem como meta final atingir o estágio mais alto do MR MPS. Como proposta de trabalhos futuros, sugerimos dar continuidade ao processo de avaliação informal na organização, avaliando o nível F de maturidade do Modelo de Referência MPS.BR. 363

Referências CMMI Product Team. Capability Maturity Model Integration v. 1.1 - Staged Representation. Software Engineering Institute, Carnegie Melon University, 2002. MPS.BR. Guia Geral Softex Versão 1.1. Disponível em: <http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=211>. Acesso em 24 maio 2006. 2006a MPS.BR. Guia de Avaliação Softex Versão 1.0. Disponível em: < http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=211>. Acesso em 24 maio 2006. 2006b PRESSMAN, R. S. Engenharia de Software. 5. ed. McGraw-Hill, 2002. 364