CMM e qualidade: caso Dataprev
Heitor M. Quintella (UFF) hquintel@unisys.com.br
Rosana Fernandes Osório (UFF) rosana.osorio@rj.previdenciasocial.gov.br
Resumo
Este artigo reúne os resultados de uma pesquisa realizada ao processo de desenvolvimento de 20 projetos de sistemas e seus respectivos produtos. O problema que se apresentava se constituía em saber quais seriam os impactos na qualidade de produtos de software na Dataprev (Empresa de tecnologia e Informações da Previdência Social), sob a ótica do cliente, ocasionados pela utilização das práticas e proposições do CMM (Capability maturity Model) no desenvolvimento de projetos de software. A amostra foi retirada da Dataprev. O objetivo da pesquisa foi primeiro identificar em que nível do CMM está classificado cada projeto de software. O segundo foi avaliar a percepção que os usuários têm da qualidade dos produtos de software gerado pelos projetos. O referencial teórico utilizado foi o instrumento para avaliar a qualidade do serviço (SERVQUAL) de Valerie A. Zeithaml, A. Parasuraman e Leonard L. Berry e o Modelo de Maturidade de Capabilidade de Software (CMM) do Instituto de Engenharia de Software (SEI).
Palavras Chaves: Qualidade, CMM, Sistemas 1. Introdução
A introdução da tecnologia de informação está ocasionando nas organizações e nas sociedades mudanças radicais, alterando não só a forma de administrar as empresas, mas também as exigências dos clientes com relação à qualidade dos seus produtos. Uma das razões que impulsiona as organizações a buscarem a qualidade é a competitividade.
Apesar de toda a evolução da tecnologia da informação, muitos problemas ainda persistem quanto à condução e implementação de projetos de sistemas de informação. A atividade de tecnologia da Informação no mundo vem tendo problemas. Segundo números do Standish
Group International em 2000, 27% dos projetos de software foram finalizados no tempo e
custo previstos, 40% dos projetos de software foram cancelados antes de finalizarem e 42% dos projetos de software estavam fora da funcionalidade proposta originalmente.
O cenário atual apresenta um contexto de múltiplas opções tecnológicas, crescente exigência dos clientes, limitações do corpo técnico em relação às ferramentas, seja pela busca do conhecimento que ainda não domina, neste caso, implicando nos custos e no aumento da duração dos projetos, ou pela tentativa de adaptar a solução encontrada à tecnologia que domina. A implicação, neste caso, seria a incorporação de requisitos falsos criados tão somente pelas restrições da plataforma tecnológica do ambiente, uso inadequado e/ou inexistência de métricas, uma vez que o sucesso dos sistemas de informação está fortemente influenciado pelos projetos que os desenvolvem.
Mesmo em organizações indisciplinadas, entretanto, alguns projetos isolados produzem excelentes resultados. Quando tais projetos são bem sucedidos, é geralmente graças a esforços heróicos de uma equipe dedicada, e não através da repetição de métodos provados de uma organização com um processo de software maduro. Na falta de um processo de software que abranja toda a organização, a repetição dos resultados depende inteiramente de se ter algumas pessoas disponíveis para o próximo projeto. Sucesso que depende da disponibilidade de pessoas específicas não provê bases para a melhoria da produtividade e qualidade na
organização por um longo período. Melhoramentos contínuos só podem ocorrer através de esforços focados e sustentados na direção da construção de uma infra-estrutura de processo de efetivo desenvolvimento de software e práticas de gestão.
Em virtude do cenário apresentado, foi realizada uma pesquisa, que teve como objetivo avaliar se a adoção do CMM (Modelo de Maturidade de Capabilidade de Software) no desenvolvimento de projetos de software para promover a melhoria da qualidade dos produtos criados, tendo em vista a percepção dos respectivos usuários destes produtos.
Segundo Paulk (1993 a) e Paulk (1993 b), apud Fiorini, Soeli (1998) CMM é:
“CMM é uma estrutura (framework) que descreve os principais elementos de um processo de software efetivo. O CMM descreve os estágios através dos quais organizações de software evoluem quando elas definem, implementam, medem controlam e melhoram seus processos de software. O CMM fornece uma diretriz para a seleção de estratégias de melhoria de processos, permitindo a determinação da capacitação dos processos correntes e a conseqüente identificação das questões mais críticas para a melhoria de processo e qualidade de software. Desta forma, provê e descreve um caminho de melhoria evolutiva a partir de um processo ad
hoc para um processo maduro e altamente disciplinado. Este caminho de melhoria é definido
por cinco níveis de maturidade: Inicial, Repetitivo, Definido, Gerenciado e Em Otimização.”
2. Metodologia
Para realização dessa pesquisa, foi utilizado o método hipotético dedutivo segundo Popper, que prega que o conhecimento científico evolui a partir de hipóteses.
A partir deste ponto, Popper constrói sua visão do método científico, o racionalismo crítico, e também do conhecimento em geral. Ambos progridem através do que ele chama de conjecturas e refutações. Isto significa que a busca do conhecimento se inicia com a formulação de hipóteses, que por sua vez, procuram resolver problemas, e continua com tentativas de refutação dessas hipóteses, através de testes que envolvem observações ou experimentos.
3. Hipótese
O uso do CMM (Modelo de Maturidade de Capabilidade de Software) no desenvolvimento de projetos de software promove a melhoria da qualidade percebida pelo usuário.
4. População
O problema dessa pesquisa está representado pela Dataprev – Empresa de Tecnologia e Informações da Previdência Social. A empresa tem como missão: dotar a Previdência e Assistência Social de soluções em tecnologia da informação, com segurança, disponibilidade e utilidade, a preços competitivos. A empresa possui representação em cada estado tendo sua matriz localizada em Brasília. A pesquisa foi feita nos seguintes estados: Rio de Janeiro, Brasília, Paraná, Santa Catarina, Minas Gerais, Espírito Santo, São Paulo.
5. Amostra
Foram escolhidos 20 projetos de sistemas da Dataprev (Empresa de Tecnologia e Informações da Previdência Social).
A expectativa era relacionar um número maior de projetos, mais seria necessário que os projetos de sistemas tivessem a mesma arquitetura.
As diretrizes da Dataprev definem o uso que a organização fará da tecnologia de informação, buscando sempre um elevado grau de consistência e aderência da informática à estratégia da
Organização. Sendo assim, os projetos selecionados para a pesquisa, são projetos implementados com arquitetura de 3 camadas.
A arquitetura 3 camadas possui as seguintes características:
Aplicações N-camadas são mais facilmente modificáveis para suportar alterações nas regras de negócio.
Aplicações N-camadas são altamente escaláveis.
Uma arquitetura N-camadas oferece melhor performance de todas as arquiteturas de aplicação.
A separação lógica das camadas também permite a alteração das plataformas onde as camadas estão distribuídas, resultando em um alto grau de escalabilidade. Enquanto ocorrem transações, tempos de resposta, ou mudanças de taxa de transferência, uma camada pode ser movida da plataforma onde é executada para outra mais poderosa – ou pode ser dividida entre outras máquinas – sem impactar as outras camadas.
A construção e a manutenção de aplicações N-camadas são mais baratas, pois a maior parte do código é pré-construído ou compartilhado por outras aplicações.
Os projetos selecionados foram implantados nos últimos 03 anos.
6. Instrumento De Medida
Utilizou-se como referencial de medida para avaliação da qualidade dos produtos de software o questionário extraído de Zeithaml et al (1990) - SERVQUAL - e para verificação em que nível do CMM os projetos de software estão enquadrados, utilizou-se o questionário elaborado, tendo por base o Modelo de Maturidade de Capabilidade de Software, versão 1.1, Paulk et al (1993 a).
7. Coleta De Dados
A pesquisa foi aplicada através de duas etapas:
A primeira etapa consistiu em pesquisa via e-mail, por meio de questionário, com 60 gerentes e/ou responsáveis pelo processo de desenvolvimento dos projetos de software, com objetivo de identificar em que nível do CMM estava classificado cada projeto de software.
A análise estatística foi realizada pelo teste t de Student para amostras independentes, para verificar se existia diferença significativa nos escore médio dos aspectos do SERVQUAL e nas questões individuais entre dois grupos estabelecidos pelo questionário do CMM.
O critério de determinação de significância adotado foi o nível de 5%, ou seja, quando o p, valor do teste estatístico, for menor ou igual a 0,05, então existe significância estatística. A análise estatística foi processada pelo software estatístico SAS® System.
Os grupos foram definidos de acordo com o seguinte critério:
O projeto pertencerá ao maior nível cujo escore médio, obtido pelo CMM, for maior ou igual a 3.
Desta forma, foi observado que:
9 projetos atingiram escore médio ≥ 3 apenas no nível 1; 5 projetos atingiram escore médio ≥ 3 no nível 2;
3 projetos atingiram escore médio ≥ 3 no nível 3; 2 projetos atingiram escore médio ≥ 3 no nível 4;
1 projeto não atingiu escore médio ≥ 3 em nenhum dos níveis. Este projeto não participou da análise estatística.
Foi definido, para fins de análise estatística, dois grupos:
Grupo 1: 9 projetos de nível 1;
Grupo 2: 10 projetos de nível 1 evoluindo para nível 2.
Segundo Paulk (1993 a) os projetos de sistemas que estão classificados no nível 1 do CMM, apresentam as seguintes características:
No Nível Inicial, a organização tipicamente não fornece um ambiente estável para desenvolvimento e manutenção de software. Quando uma organização não dispõe de práticas de gestão bem estabelecidas, os benefícios das boas práticas de desenvolvimento de software são minados pelo planejamento ineficiente e por sistemas onde os compromissos são sempre reativos, ou seja, uma reação a algum acontecimento não planejado.
Durante uma crise, os projetos tipicamente abandonam os procedimentos que foram planejados e partem para a codificação e testes. O sucesso depende inteiramente de ser ter um gerente excepcional e uma equipe de software madura e eficiente. Ocasionalmente, gerentes de software capazes e que dispõem de força podem resistir às pressões para se obter atalhos no processo de software; mas quando eles deixam o projeto, a sua influência estabilizadora se vai com eles. Mesmo um forte processo de desenvolvimento não pode superar a instabilidade criada pela ausência de práticas sólidas de gestão.
No Nível Repetível, as políticas de gestão de projeto de software e os procedimentos para implementar aquelas políticas são estabilizados. O planejamento e a gestão de novos projetos são baseados na experiência com projetos similares. Um objetivo alcançado com o nível 2 é a institucionalização dos processos para os projetos de software, que permitem as organizações repetir as práticas bem sucedidas desenvolvidas em projetos anteriores, embora os processos específicos implementados pelos projetos possam diferir. Um processo efetivo pode ser caracterizado como experiente, reforçado, treinado, medido e capaz de melhorar.
Os projetos nas organizações de nível 2 têm instalado controles básicos de gestão de software. Os compromissos realistas do projeto são baseados em resultados observados em projetos anteriores e nos requisitos do projeto atual. Os gerentes de software do projeto acompanham os custos, os cronogramas e as funcionalidades do software; os problemas com compromissos são identificados quando surgem.
Os requisitos de software e os produtos de trabalho desenvolvidos para satisfazê-los são congelados e a integridade dos mesmos é controlada. Os padrões do projeto de software são definidos e a organização garante que eles sejam seguidos fielmente. O projeto de software trabalha com os seus subcontratados, se existirem, para estabelecer uma forte relação cliente-fornecedor.
A segunda etapa consistiu em pesquisa via e-mail, por meio de questionário, com 60 usuários e/ou equipes de atendimento dos produtos de software, com objetivo de avaliar as percepções que os usuários têm da qualidade dos produtos de software gerados pelos projetos.
7.1. Objetivo 1. Análise dos aspectos do SERVQUAL.
A tabela 01 fornece a média, erro padrão (EP) mínimo, máximo dos escores dos aspectos do SERVQUAL, segundo o grupo. O valor da estatística t e o respectivo nível de significância (p valor) foram calculados para os cinco aspectos e para o geral. O aspecto geral corresponde às 19 questões do SERVQUAL.
Aspecto Grupo n Média E.P. Mínimo Máximo t p valor Elementos TangÍveis I 9 4,50 0,32 3,5 6,25 -1,38 0,18 II 10 5,06 0,26 3,5 6,17 Confiabilidade I 9 4,17 0,34 3 5,8 -1,45 0,16 II 10 4,96 0,42 3,13 7 Capacidade de Resposta I 9 4,91 0,28 3,5 6 -1,84 0,082 II 10 5,65 0,29 3,67 6,5 Segurança I 9 4,67 0,25 3,67 5,67 -2,11 0,049 II 10 5,60 0,35 2,67 6,5 Empatia I 9 4,84 0,22 4 6 -1,84 0,082 II 10 5,51 0,28 3,5 6,38 ServQual Geral I 9 4,62 0,21 3,92 5,63 -2,13 0,047 II 10 5,36 0,26 3,47 6,1
E.P.: Erro Padrão;
Tabela 01: Análise descritiva e estatística dos aspectos do SERVQUAL, segundo o grupo.
Conclusão: Analisando os aspectos do SERVQUAL observou-se, que o escore médio
do aspecto segurança (p = 0,049) e do geral (p = 0,047) do grupo 2 foi significativamente maior que do grupo 1. Isto mostra que a expectativa dos usuários do grupo 2, relativa à “segurança” ou de uma forma “geral”, estão de acordo com a avaliação dada pelos gerentes, segundo o CMM (nível 1 evoluindo para nível 2).
Podemos dizer que, existe uma tendência (isto é, p valor entre 0,05 e 0,10) do grupo 2 apresentar escore médio dos aspectos Capacidade de Resposta e Empatia superior ao do grupo 1. A perda da significância estatística foi devida ao número pequeno de casos estudados. Provavelmente, para uma amostra maior de projetos, esta diferença será significativa.
Segundo um estudo para analisar a avaliação da qualidade do serviço, Valerie A. Zeithaml, A. Parasuraman e Lenard L. Berry realizaram em 1983 um trabalho sobre como os clientes e fornecedores do serviço avaliam a qualidade do serviço.
Com os resultados obtidos, foi desenvolvido um modelo conceitual da qualidade do serviço e um instrumento para avaliar a qualidade do serviço (SERVQUAL).
O SERVQUAL é um instrumento de escala múltiplo com alto nível de viabilidade e validez, baseado na definição conceitual da qualidade do serviço e em cinco dimensões que encontraram-se na pesquisa feita, que ajuda as empresas a compreender melhor as expectativas e percepções que os clientes têm com respeito ao serviço.
As cinco dimensões foram definidas da seguinte maneira:
1. Elementos Tangíveis: Aparência das instalações físicas, equipamento, pessoal e materiais
de comunicação.
2. Confiabilidade: Habilidade para realizar o serviço de forma confiável precisa e
consistente.
3. Capacidade de Resposta: Disposição e vontade para ajudar os clientes e proporcionar o
serviço prontamente.
4. Segurança: Conhecimentos e atenção mostrados pelos empregados e suas habilidades
para transmitir confiança, segurança e credibilidade.
5. Empatia: Atenção individualizada, facilidade de contato (acesso) e comunicação que as
8 Conclusão
A hipótese foi corroborada, logo considera-se que as práticas utilizadas pelo Modelo de Maturidade de Capabilidade de Software promove a melhoria da qualidade, segundo a percepção do usuário.
Buscando complementar este estudo, o quadro nº 01 mostra a relação dos objetivos com as respostas encontradas na pesquisa realizada no processo de desenvolvimento de software e seus respectivos produtos da empresa em estudo.
Objetivo Geral: Avaliar se a adoção do CMM (Modelo de Maturidade de Capabilidade de Software) no desenvolvimento de projetos de software promove a melhoria da qualidade dos produtos criados, tendo em vista a percepção dos respectivos usuários destes produtos.
Resposta ao Objetivo número 1 Objetivo Específico 1
Identificar em que nível do CMM está classificado cada projeto de software.
Os grupos foram definidos de acordo com o seguinte critério:
O projeto pertencerá ao maior nível cujo escore médio, obtido pelo CMM, for maior ou igual a 3.
Desta forma, foi observado que:
9 projetos atingiram escore médio ≥ 3 apenas no nível 1; 5 projetos atingiram escore médio ≥ 3 no nível 2; 3 projetos atingiram escore médio ≥ 3 no nível 3; 2 projetos atingiram escore médio ≥ 3 no nível 4;
1 projeto não atingiu escore médio ≥ 3 em nenhum dos níveis. Este projeto não participou da análise estatística.
Foram encontrados com base em análise estatística, dois grupos: Grupo 1: 9 projetos de nível 1;
Grupo 2: 10 projetos de nível 1 evoluindo para nível 2. Resposta ao Objetivo número 2
Objetivo Específico 2
Avaliar a percepção que os usuários têm da qualidade dos produtos de software gerados pelos projetos.
Foi mostrado na análise estatística que, a qualidade percebida pelos usuários do grupo 2 de uma forma “geral” é compatível com a avaliação dada pelos gerentes, segundo o CMM (Nível 1 evoluindo para o nível 2). Quadro 01: Resposta aos objetivos do problema
A resposta encontrada acerca do problema pesquisado é mostrada no quadro nº 02.
Hipótese Resposta à Hipótese
O uso do CMM (Modelo de Maturidade de Capabilidade de Software) no desenvolvimento de projetos de software promove a melhoria da qualidade percebida pelo usuário.
A hipótese foi corroborada, logo, considera-se que as práticas utilizadas pelo Modelo de Maturidade de Capabilidade de Software promove a melhoria da qualidade, segundo a percepção do usuário.
Quadro 02:Resposta à hipótese
A hipótese e a resposta a primeira questão chave em relação a dimensão da qualidade – elementos tangíveis do SERVQUAL, mostra no quadro nº 03 e na figura nº 01 a qualidade percebida pelos usuários dos produtos de software.
Questões Chave – Questionário SERVQUAL Respostas às Questões Chave Dimensão da Qualidade: Elementos Tangíveis
1. Qual a qualidade percebida pelo cliente em relação aos produtos de software, nos seguintes itens: aparência das instalações físicas, equipamento, pessoal e materiais de comunicação?
Analisando o escore médio da questão referente ao aspecto Elemento Tangível do SERVQUAL observou-se, que o escore médio da questão Q1 (p=0,01) do grupo 2 foi significativamente maior que o grupo 1. Isto mostra que, em algumas questões individuais, a percepção dos usuários do grupo 2 está de acordo com a avaliação dada pelos gerentes, segundo o CMM (nível 1 evoluindo para nível 2). Conforme mostrado na figura 01.
e sc o re m é di o + 2 E P I II I II I II I II 0 1 2 3 4 5 6 7 Q 1 p = 0,01 Q 2 Q 3 Q 4 p = 0,53 p = 0,19 p = 0,24
Figura 01: Escore médio das questões referente ao aspecto Elementos Tangíveis, segundo o grupo.
A hipótese e a resposta à segunda questão chave em relação à dimensão da qualidade – confiabilidade do SERVQUAL, mostra no quadro nº 04 e na figura nº 02 a qualidade percebida pelos usuários dos produtos de software.
Questões Chave – Questionário SERVQUAL Respostas às Questões Chave Dimensão da Qualidade: Confiabilidade
2. Qual a qualidade percebida pelo cliente, quanto à habilidade na disponibilização dos produtos de software conforme prometido, de forma confiável, precisa e consistente?
Analisando o escore médio da questão referente ao aspecto Confiabilidade do SERVQUAL observou-se, que o escore médio da questão Q5 (p=0,007) e Q6 (p = 0,033) do grupo 2 foi significativamente maior que o grupo 1. Isto mostra que, em algumas questões individuais, a percepção dos usuários do grupo 2 está de acordo com a avaliação dada pelos gerentes, segundo o CMM (nível 1 evoluindo para nível 2). Conforme mostrado na figura 02.
Quadro 04:Resposta à segunda questão chave em relação à dimensão da qualidade – Confiabilidade.
e sc o re m é di o + 2 E P I II I II I II I II I II 0 1 2 3 4 5 6 7 Q5 p = 0,007 Q6 Q7 Q8 p = 0,03 p = 0,26 p = 0,57 Q9 p = 0,97
Figura 02: Escore médio das questões referente ao aspecto Confiabilidade, segundo o grupo.
A hipótese e a resposta a terceira questão chave em relação a dimensão da qualidade – capacidade de resposta do SERVQUAL, mostra no quadro nº 05 e na figura nº03 a qualidade percebida pelos usuários dos produtos de software.
Questões Chave – Questionário SERVQUAL Respostas às Questões Chave Dimensão da Qualidade: Capacidade de
Resposta
3. Qual a qualidade percebida pelo cliente em relação aos produtos de software, quanto à disposição para auxiliar os clientes e proporcionar o serviço imediatamente?
Analisando o escore médio da questão referente ao aspecto Capacidade de Resposta do SERVQUAL, podemos dizer que, existe uma tendência (isto é, p valor entre 0,05 e 0,10) do grupo 2 apresentar escore médio superior ao do grupo 1. A perda da significância estatística foi devida ao número pequeno de casos estudados. Provavelmente, para uma amostra maior de projetos, esta diferença será significativa. Conforme mostrado na da tabela 1 na figura 03.
e s co re m é d io + 2E P I II I II I II 0 1 2 3 4 5 6 7 Q 1 0 p = 0 ,1 1 Q 1 1 Q 1 2 p = 0 ,1 1 p = 0 ,1 1
Figura 03:. Escore médio das questões referente ao aspecto Capacidade de Resposta, segundo o grupo.
A hipótese e a resposta à quarta questão chave em relação à dimensão da qualidade – segurança do SERVQUAL, mostra no quadro nº 06 e na figura nº04 a qualidade percebida pelos usuários dos produtos de software.
Questões Chave – Questionário SERVQUAL Respostas às Questões Chave Dimensão da Qualidade: Segurança
4. Qual a qualidade percebida pelo cliente em relação aos produtos de software, nos seguintes itens: conhecimento para responder a todas as perguntas relacionadas com o projeto de software, atenção mostrada pelas equipes de atendimento e suas habilidades para transmitir confiança, segurança e credibilidade?
Analisando o escore médio da questão referente ao aspecto Segurança do SERVQUAL observou-se, que o escore médio da questão Q13 (p=0,038) do grupo 2 foi significativamente maior que o grupo 1. Isto mostra que, em algumas questões individuais, a percepção dos usuários do grupo 2 está de acordo com a avaliação dada pelos gerentes, segundo o CMM (nível 1 evoluindo para nível 2). Conforme mostrado na figura 04.
Quadro 06:Resposta à quarta questão chave em relação à dimensão da qualidade – Segurança.
e s c o r e m é di o + 2 E P I II I II I II 0 1 2 3 4 5 6 7 Q 1 3 p = 0 , 0 3 Q 1 4 Q 1 5 p = 0 , 0 9 p = 0 , 0 7
Figura 04:. escore médio das questões referente ao aspecto Segurança, segundo o grupo.
A hipótese e a resposta a quinta questão chave em relação a dimensão da qualidade – empatia do SERVQUAL, mostra no quadro nº 07 e na figura nº 05 a qualidade percebida pelos usuários dos produtos de software.
Questões Chave – Questionário - Servqual Respostas às Questões Chave Dimensão da Qualidade: Empatia
5. Qual a qualidade percebida pelo cliente em relação aos produtos de software, quanto à atenção individualizada, facilidade de contato, acesso e comunicação?
Analisando o escore médio da questão referente ao aspecto Empatia do SERVQUAL observou-se, que o escore médio da questão Q17 (p=0,031) do grupo 2 foi significativamente maior que o grupo 1. Isto mostra que, em algumas questões individuais, a percepção dos usuários do grupo 2 está de acordo com a avaliação dada pelos gerentes, segundo o CMM (nível 1 evoluindo para nível 2).
Também podemos dizer que, existe uma tendência (isto é, p
valor entre 0,05 e 0,10) do grupo 2 apresentar escore médio
superior ao do grupo 1. A perda da significância estatística foi devida ao número pequeno de casos estudados. Provavelmente, para uma amostra maior de projetos, esta diferença será significativa. Conforme mostrado na figura 05.
e s c o re m é di o + 2 E P I II I II I II I II 0 1 2 3 4 5 6 7 Q 16 p = 0 ,4 9 Q 17 Q 18 Q 19 p = 0 ,0 3 p = 0 ,0 9 p = 0 ,1 8
Figura 05: Escore médio das questões referente ao aspecto Empatia, segundo o grupo.
A hipótese e as questões chave dividida nos cinco níveis do CMM (Modelo de Maturidade de Capabilidade de Software), mostra no quadro nº 08 em que nível do CMM foram classificados os projetos de software.
Questões Chave – Questionário CMM Respostas às Questões Chave Nível 1 do CMM
1. O processo de software é constantemente alterado ou modificado a medida que o trabalho progride (processo “ad hoc”)?
Foram encontrados com base em análise estatística os seguintes grupos:
Grupo 1: 9 projetos de nível 1;
Grupo 2: 10 projetos de nível 1 evoluindo para nível 2. Conforme resultado da análise estatística, foi identificado que o processo de software da Dataprev é constantemente alterado ou modificado a medida que o trabalho progride. Nível 2 do CMM
2. O processo de software mantém um planejamento e um acompanhamento estável, podendo repetir a experiência para novos projetos?
Apesar da pesquisa ter mostrado que 10 projetos, são possíveis candidatos a classificação Nível 2 do CMM, a Dataprev não mantém um planejamento e acompanhamento do processo de software integrado com todas as áreas envolvidas no processo de desenvolvimento dos projetos. Nível 3 do CMM
3. A organização possui um processo de desenvolvimento e manutenção de software padronizado, consistente e utilizado em todos os projetos de software?
Não foi encontrado para fins da análise estatística um grupo de projetos classificados no Nível; 3 do CMM.
Nível 4 do CMM
4. O processo de software da organização, já padronizado é medido e opera dentro dos limites estabelecidos?
Não foi definido para fins da análise estatística um grupo de projetos classificados no Nível 4 do CMM.
Nível 5 do CMM
5. A organização trabalha com inovação do processo de software, identificando as oportunidades de aperfeiçoamento, fortalecendo o processo de maneira pró-ativa e objetivando a prevenção de falhas?
Não foi definido para fins da análise estatística um grupo de projetos classificados no Nível 5 do CMM.
Quadro 08: Respostas às questões chave dividida nos cinco níveis do CMM (Modelo de Maturidade de Capabilidade de Software).
Referências
A EMPRESA. Disponível em http://www.dataprev.gov.br/aprese/aempresa.shtm . Acesso em nov. 2002. FIORINI, Soeli T.; STAA, A.V. e BAPTISTA, R.M. Engenharia de Software com CMM. Rio de Janeiro: Brasport, 1998, pp346.
JERROLD, H. ZAR. Biostatistical Analysis. Quarta Edição. New Jersey: Prentice Hall. Capítulo 8, 1999. QUINTELLA, H. M. Fatores Humanos e Tecnológicos da Competitividade. Relatório de Pesquisa. UFF, 1997.
PAULK , M.C.; CURTIS, B.; CHRISSIS, M.B. e WEBER, C.V. Capability Maturity Model for Software. Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, 1993a.
PAULK, M.C.; GARCIA, S.M.; CHRISSIS, M.B.; WEBER, C.V, BUSH, M.; Key Pratices of the Capability Maturity Model, Version 1.1; Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93TR-25, ESC-TR-93-178.; February 1993b.
SEI–Software Engineering Institute. Carnegie Mellon,, Disponível em http://www.sei.cmu.edu/. Acesso em 2002.
ZEITHAML, Valerie A.; PARASURAMAN, A.; BERRY, Leonard L. Delivering Quality Service. New
