ANÁLISE E APLICAÇÃO DE MODELOS DE MATURIDADE DO SOFTWARE
ENGINEERING INSTITUTE
Álvaro Rocha (
amrocha@ufp.pt
)
Universidade Fernando Pessoa
Faculdade de Ciência e Tecnologia
Praça 9 de Abril, 349
4249-004 Porto, Portugal
RESUMO
O desenvolvimento de software é, pela natureza inerentemente complexa do software, um processo
crítico. São muitos os casos em que o software é disponibilizado para além do tempo previsto e com
um custo superior ao orçamentado, bem como é muitas vezes baixa a qualidade do software resultante.
Os modelos de maturidade para o processo de desenvolvimento software são instrumentos que podem
ajudar a minorar estes problemas, pois baseiam-se em práticas de desenvolvimento de software de
provadas. Neste artigo apresentamos as características dos modelos de maturidade, analisamos os
principais modelos de maturidade do Software Engineering Institute (SEI), apresentamos um estudo
de casos da aplicação do Capability Maturity Model for Software (SW-CMM) no diagnóstico da
maturidade, e tecemos algumas considerações sobre a utilização de modelos de maturidade do SEI no
diagnóstico e na melhoria da maturidade do processo de software.
PALAVRAS-CHAVE: Organização do Processo de Desenvolvimento de Software, Modelos de
Maturidade, Qualidade do Software.
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": 1. INTRODUÇÃO
O desenvolvimento de software usável e fiável é um processo difícil de implementar para muitas organizações. Muitas vezes o software é entregue atrasado, excede os custos previstos e não implementa as funcionalidades requeridas ou tem outros problemas de qualidade [Vicente et al. 1996, Clark 2000]. A natureza inerentemente complexa do software amplifica os problemas e aumenta a importância e o tamanho dos projectos. Uma forma de contornar tais problemas é através de um esforço focado na melhoria do processo de desenvolvimento de software.
A melhoria do processo tem por objectivo melhorar a capacidade da organização para ir ao encontro das suas metas. Especificamente, as melhorias visam a predicabilidade, o controlo e a eficiência.
Por melhoria da predicabilidade entende-se que as estimativas são mais próximas do esforço actual requerido. Por melhoria do controlo entende-se que a variância entre progressos de diferentes projectos para tarefas similares diminui. Por melhoria da eficiência entende-se que os recursos usados para uma dada função/tarefa diminuem.
Iniciativas de processos de melhoria são geralmente tomadas com base em normas e modelos de maturidade. Neste artigo apresentamos as características dos modelos de maturidade, analisamos os principais modelos de maturidade do Software Engineering Institute (SEI) para o processo de desenvolvimento de software, apresentamos um estudo de casos da aplicação do SW-CMM no diagnóstico da maturidade, e tecemos algumas considerações em função dos resultados dos casos estudados.
2. MODELOS DE MATURIDADE
Os modelos de maturidade são referenciais que se baseiam na premissa de que as entidades (pessoas, organizações, áreas funcionais, processos, etc.) evoluem através de um processo de desenvolvimento, crescimento ou maturação ao longo tempo, em direcção à perfeição ou maturidade, atravessando um determinado número de estádios distintos.
Os modelos de maturidade têm vindo a ser usados largamente em várias áreas para descrever uma grande variedade de fenómenos [Burn 1994, King e Teo 1997]. Estes modelos assumem que padrões predicáveis, conceptualizados em termos de estádios, existem no crescimento das entidades [Greiner 1972, Smith et al. 1985, Burn 1994]. Normalmente, os estádios de maturidade são [Lavoie e Culbert 1978, Rocha 2000, Klimbo 2001]: (1) sequenciais (e cumulativos) por natureza, (2) ocorrem como uma progressão hierárquica que não é facilmente reversível e (3) envolvem um largo leque de estruturas e actividades humanas e organizacionais.
Vários modelos de maturidade têm sido propostos ao longo do tempo, quer para a evolução geral das organizações, quer para a evolução da Função Sistemas de Informação, quer especificamente para a evolução do Processo de Desenvolvimento de Software. Estes modelos diferem principalmente no número de estádios, variáveis de evolução e áreas de foco. Cada um destes modelos identifica certas características que tipificam o alvo em diferentes estádios de maturidade.
Um trabalho pioneiro sobre o amadurecimento das organizações foi conduzido por Greiner (1972). Este focou-se na organização como um todo, desenvolvendo o entendimento da evolução das práticas de gestão com base na forma como uma organização amadurece. Greiner descreveu cinco estádios de maturidade pelos quais passa uma organização, e declarou que a idade, a dimensão e a taxa de crescimento da sua indústria são os factores de influência principais na determinação do estádio em que uma organização se encontra. Recentemente, Greiner (1998) adicionou um novo estádio ao seu modelo inicial de modo a torná-lo válido com o funcionamento em rede/parceria das organizações actuais.
Nolan (1973) foi o primeiro investigador a introduzir um modelo de maturidade na área dos sistemas informação. A sua primeira proposta baseou-se no tipo de tecnologia usada e no valor do orçamento em sistemas de informação como uma indicação da maturidade da gestão da função sistemas de informação, usando uma curva em “S”, consistindo em quatro estádios. A última versão do modelo de Nolan [Mutsaers et al. 1997] consiste em nove estádios, usando três curvas de crescimento em “S”, em que cada uma das curvas corresponde a uma era de evolução da maturidade.
O primeiro modelo de maturidade para o processo de desenvolvimento de software surgiu apenas em 1987 [Humphrey 1987a,b]. O modelo consistiu numa resposta a uma solicitação do Departamento de Defesa dos Estados Unidos, que delegou no SEI a tarefa de formalizar e obter um mecanismo expedito para seleccionar fornecedores no âmbito do desenvolvimento de software. Pretendia-se que fossem seleccionados apenas fornecedores que apresentassem uma maturidade superior de desenvolvimento de software.
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": Este modelo é o bem conhecido SW-CMM (Capability Maturity Model for Softawre). A principal assunção do SW-CMM é que a qualidade pode ser cultivada e proporcionada através de controlo. Neste caso, a entidade a ser controlada é o processo de desenvolvimento de software. O modelo SW-CMM tem cinco estádios de maturidade.
O SW-CMM descreve os elementos chave para um efectivo processo de desenvolvimento de software. Os seus estádios de maturidade indicam a capacidade do processo. Cada estádio (exceptuando o primeiro) contém “áreas chave”. As áreas chave representam objectivos a serem alcançados pela organização de desenvolvimento de software e estão organizadas por “características comuns”, as quais por sua vez são baseadas em “práticas chave”. O modelo completo indica o caminho de melhoria do processo de desenvolvimento de software.
As vantagens óbvias dos modelos de maturidade para a organização do processo de desenvolvimento de software são: a sua simplicidade, o que faz com que sejam fáceis de entender e comunicar; proporcionarem o diagnóstico e o “ranking” da maturidade do processo; proporcionarem a identificação dos pontos fortes e fracos do processo, sendo estes posteriormente usados como entradas em processos de planeamento da melhoria orientados pela evolução provada e sequencial proposta nos modelos de maturidade; e proporcionarem comparações entre diferentes organizações/processos de desenvolvimento de software.
A abordagem original consistia de modelos de maturidade em estádios. Posteriormente foi também introduzido o conceito de modelos de maturidade contínuos. Num modelo contínuo é usado o conceito de maturidade de área do processo em vez de apenas maturidade do processo de software. Assim, a maturidade é interpretada no contexto de áreas do processo. Ou seja, um processo de desenvolvimento de software pode desenvolver-se simultânea e distintamente em diferentes áreas.
3. MODELOS DE MATURIDADE DO SOFTWARE ENGINEERING INSTITUTE (SEI)
O Software Engineering Institute foi a entidade responsável pela introdução dos modelos de maturidade na área da organização do processo de desenvolvimento de software. O seu primeiro modelo é o SW-CMM [Humphrey 1987a,b]. Como o SW-CMM não cobria tópicos relacionados com a gestão das pessoas que desenvolvem software, o SEI introduziu o P-CMM (People Capability Maturity Model) [Curtis e tal. 1995] com o objectivo de o complementar. Aplicações do SW-CMM mostraram alguma dificuldade quando o modelo era seguido na íntegra por pequenas organizações e em pequenos projectos de software, e mostraram também que muitas outras organizações se encontravam no primeiro estádio de maturidade. Por esse motivo, Humphrey (1995) introduziu o PSP (Personal Software Process), pois os engenheiros de software que se encontram num alto estádio de disciplina, quando reunidos num mesmo processo, farão com que a organização esteja pelo menos no segundo estádio de maturidade do SW-CMM. Como o SW-CMM [Paulk et al. 1993] também não cobria as primeiras fases do desenvolvimento de sistemas (determinação e especificação de requisitos, etc.) levou a que o SEI introduzisse o SE-CMM (Systems Engineering Capability Maturity Model) [Bate et al. 1995]. É, pela primeira vez, e com este modelo, adoptada pelo SEI a abordagem contínua, baseado na estrutura e na norma emergente ISO 15504/SPICE [SPICE 1996], em vez da até então abordagem em estádios. Recentemente, o SEI introduziu o CMMI (Capability Maturity Model Integration) com o objectivo de integrar os seus principais modelos de desenvolvimento de sistemas e evitar, entre outras coisas, duplicações e ambiguidades entre modelos. Por enquanto vão coexistindo duas abordagens deste modelo [CMMI 2002a,b]: abordagem contínua e abordagem em estádios.
Nas próximas secções apresentam-se e analisam-se resumidamente os modelos SW-CMM, PSP e CMMI. Os dois primeiros porque têm sido até ao momento grandes referências no processo de desenvolvimento de software. E o último pelo facto do SEI querer torná-lo, no futuro, o seu único modelo.
3.1. SW-CMM: Capability Maturity Model for Software
O SW-CMM [Humphrey 1987a,b, 1989, Paulk et al. 1993] foi o primeiro modelo desenvolvido na área da maturidade da organização do processo de desenvolvimento de software. A iniciativa pertenceu ao Departamento de Defesa dos Estados Unidos, que delegou no SEI a tarefa de formalizar e obter um mecanismo expedito para seleccionar fornecedores de software.
O esforço SW-CMM foi baseado nos princípios da TQM1 e na melhoria contínua do processo de desenvolvimento de software. Desde que foi apresentado por Humphrey (1987a,b), tem recebido grande atenção das comunidades académica e profissional [e.g., Hather et al. 1996, Mathiassen e Sorensen 1996, Vicente et al. 1996, Soares 1997, Pressman 1997, Martinig 1998, Rocha 2000].
1 A TQM (Total Quality Management) é a forma de uma organização atingir a excelência através de melhorias graduais e contínuas dos seus
processos. A procura de melhorias graduais e contínuas, quer pela resolução de problemas quer pela prospecção de oportunidades, deve ser assim uma atitude assumida pelas organizações a tempo inteiro [Zultner 1993].
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": O SW-CMM v1.1 [Paulk et al. 1993] descreve os princípios e as práticas subjacentes à maturidade do processo de desenvolvimento software e pretende ajudar as organizações a melhorar esse processo através de um caminho evolutivo que vai desde um processo "ad hoc" e caótico até um processo de software maduro e disciplinado. O modelo caracteriza o processo de desenvolvimento de software num de cinco estádios de maturidade, em que um estádio mais elevado indica uma maior maturidade do processo, que por sua vez é associado a um menor risco e a uma maior produtividade e qualidade (tabela 1):
Tabela 1: O modelo SW-CMM 1.1 [adaptado de Paulk (1993)].
Estádio Foco Áreas Chave do Processo Resultado
5 Optimizado (Realimentado)
processo a ser constantemente melhorado
Prevenção de defeitos
Gestão de alterações tecnológicas Gestão de alterações do processo
Produtividade e Qualidade
4 Gerido (Quantitativo)
processo e produto medido
Gestão quantitativa do processo Gestão da qualidade do software
3 Definido (Qualitativo) processo definido e institucionalizado Organização do processo Definição do processo Formação
Gestão integrada de software Engenharia de software Coordenação inter-grupos Revisões (testes) 2 Repetível (Intuitivo) processo dependente de indivíduos Gestão de requisitos Planeamento de projectos
Acompanhamento e inspecção do projecto Gestão da subcontratação
Gestão de configurações
Verificação da qualidade de software
1 Inicial (Ad hoc)
processo caótico Risco
Predição, eficiência e controlo do processo de desenvolvimento de software são os elementos chave para uma organização se mover ao longo dos cinco estádios. Excepto para o Estádio 1, cada um dos outros estádios de maturidade é decomposto em várias áreas chave. Essas áreas chave são consideradas as áreas críticas onde uma organização se deve focar para melhorar o seu processo de software.
Cada área chave do processo é descrita em termos das práticas chave que contribuem para a satisfação dos seus objectivos, como ilustra a figura 1. As práticas chave descrevem a infra-estrutura e as actividades específicas que mais contribuem para a efectiva implementação e institucionalização da área chave do processo.
Cada prática chave é normalmente descrita por numa única frase, geralmente seguida por uma descrição mais detalhada que pode incluir exemplos. Estas práticas chave, também referidas como práticas chave de alto nível, sustentam as políticas, procedimentos e actividades fundamentais para a área chave do processo. As componentes da descrição detalhada que as caracteriza são referidas frequentemente como sub-práticas.
As práticas chave descrevem o "que" deve ser feito, mas não devem ser interpretadas como mandamento de "como" os objectivos devem ser atingidos. Práticas alternativas podem acompanhar os objectivos das áreas chave. Portanto, as práticas chave devem ser interpretadas racionalmente [Paulk et al. 1993], ou seja, de acordo com cada caso específico.
As áreas chave estão organizadas por configurações comuns. As configurações comuns são atributos que indicam quer a implementação quer a institucionalização da respectiva área chave do processo de modo efectivo, repetível e permanente.
As áreas chave do processo foram definidas por estádios de maturidade, como ilustrado na tabela 1. O caminho para se atingirem os objectivos de uma área chave do processo pode divergir de projecto para projecto em consequência das diferenças dos diversos domínios de aplicação. No entanto, todos os objectivos constantes da área chave do processo têm de ser atingidos pela organização para satisfazer essa área chave do processo. Quando esses objectivos são atingidos numa base contínua, ao longo dos projectos, a organização pode considerar-se como tendo institucionalizado a capacidade do processo caracterizada pela área chave do processo.
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": Figura 1: Estrutura do modelo SW-CMM [adaptado de Paulk (1993)].
Nem todas as áreas do processo de desenvolvimento e manutenção de software são descritas no SW-CMM. A palavra "chave" pressupõe que existem áreas que não foram identificadas como aspectos críticos para o processo. Embora outras áreas afectem o desempenho do processo, as áreas chave do processo foram identificadas devido à sua efectividade no aperfeiçoamento dos processos das organizações. Devem ser vistas como os requisitos para atingir o estádio optimizado de maturidade.
Do mesmo modo que todos os objectivos de uma área chave do processo têm de ser atingidos para a área chave do processo ser considerada satisfeita, o estádio de maturidade também somente é atingido quando se satisfazem todas as áreas chave do processo que o caracterizam.
As avaliações de maturidade subjacentes ao SW-CMM consistem na aplicação de um questionário de resposta booleana. Para que uma organização esteja num específico estádio de maturidade, todas as suas áreas chave, mais as dos estádios precedentes, têm de estar implementadas e institucionalizadas na organização.
3.2. PSP –Personal Software Process
O PSP é um modelo de melhoria evolutiva desenvolvido por Humphrey (1995) para o nível individual, de modo a fornecer um mecanismo de auto-aprendizagem através da experiência, medida e feedback. Este mecanismo habilita os engenheiros de software a entenderem as suas fraquezas e potencialidades bem como a melhorar a sua capacidade e desempenho.
O PSP pode ser aplicado à maioria das tarefas de engenharia de software dado que a sua estrutura é simples e independente da tecnologia - não prescreve linguagens, ferramentas ou métodos de concepção específicos [Humphrey 1996].
Os conceitos de processo do PSP são apresentados numa série de passos. Cada passo, como ilustrado na figura 2, inclui todos os elementos dos passos anteriores mais os adicionados. A introdução destes conceitos ajuda os engenheiros a aprenderem métodos de disciplina pessoal.
Uma das razões que levou Humphrey a desenvolver o modelo PSP deve-se ao facto da aplicação dos princípios do modelo SW-CMM ter encontrado muitas dificuldades ao nível de pequenos grupos de engenheiros de software. O SW-CMM é um modelo de melhoria do processo focado na organização que potencia e facilita bom trabalho, mas não o garante. Portanto, os engenheiros têm de usar práticas pessoais efectivas [Humphrey 1996]. O modelo PSP apresenta princípios de melhoria do processo, ao nível individual dos engenheiros, associados à produção eficiente de produtos de qualidade. Para terem um bom desempenho, os engenheiros necessitam do suporte de um ambiente disciplinado, o que significará que o PSP será mais efectivo em organizações próximas ou acima do estádio 2 do modelo SW-CMM.
O PSP e o SW-CMM suportam-se mutuamente. O SW-CMM proporciona o suporte de ambiente ordenado que os engenheiros necessitam para realizarem trabalho superior; e o PSP equipa os engenheiros de forma a realizarem trabalho de alta qualidade e participa na melhoria organizacional do processo. Por conseguinte, um
Capacidade do Processo Objectivos Implementação / Institucionalização Actividades / Infraestrutura
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": dos objectivos do PSP é expandir a grandes programas a produtividade dos engenheiros tipicamente experientes no desenvolvimento de pequenos programas.
Figura 2: Evolução do processo PSP [adaptado de Humphrey (1995, 1996, 2000)]. 3.3 CMMI – Capability Maturity Model Integration
O modelo CMMI é um projecto iniciado em 1998 pelo SEI com o objectivo de integrar num só modelo vários dos seus modelos. Actualmente o CMMI integra os modelos (1) SW-CMM v2.0 draft C; (2) SE-CMM v1.1; e (3) IPD-CMM v0.98 draft – Integrated Product Development Capability Maturity Model.
Os objectivos específicos do CMMI são: substituir todos os modelos CMM por um único modelo em finais de 2003, eliminando inconsistências e reduzindo duplicações; aumentar a clareza e o entendimento pelo uso de terminologia comum, estilo consistente e componentes comuns; e assegurar conformidade com a norma emergente 15504/SPICE da ISO.
O CMMI proporciona uma eficiente e efectiva avaliação e melhoria de múltiplos processos de diferentes disciplinas numa organização; a redução de custos de formação e avaliação; uma visão comum e integrada de melhoria para todos os elementos de uma organização; e um novo meio de representar informação de disciplinas específicas numa norma, por intermédio de processos de melhoria provados.
A primeira versão final do CMMI v1.0 surgiu em 2000. A mais recente, CMMI v1.1, é do início de 2002 [CMMI 2002a,b]. Em cada uma das versões, o CMMI disponibiliza diferentes combinações dos modelos do SEI. O CMMI SE/SW é a combinação que mais interessa neste documento, por ser aquela que está mais relacionada e que cobre todo o processo de desenvolvimento de software.
As organizações podem optar entre duas abordagens do CMMI para melhoria do processo: (1) abordagem contínua; e (2) abordagem em estádios. No primeiro caso para uma representação contínua do processo semelhante à do modelo SE-CMM e à da norma emergente 15504/SPICE da ISO; e no segundo caso para uma representação em estádios do processo semelhante à do modelo SW-CMM.
Na representação em estádios, as áreas do processo estão agrupadas entre os estádios 2-5, como no SW-CMM, num total de 5 estádios: (1) Inicial; (2) Gerido; (3) Definido; (4) Gerido Quantitativamente; e (5) Optimizado. Cada área do processo contém a implementação de práticas (actividades) para atingir o objectivo da área do processo. Todas as práticas (configurações comuns) têm de ocorrer para que a área do processo atinja o objectivo.
Na representação contínua, como mostra a figura 3, uma área do processo contém práticas específicas para atingir o propósito da área do processo. Algumas destas práticas podem residir em estádios de maturidade mais elevados (práticas avançadas). As práticas genéricas são agrupadas para definir estádios de maturidade e são adicionadas às práticas específicas de cada área do processo para atingir um estádio de maturidade para a área do
PSP0 Processo corrente Medidas básicas Medida Pessoal PSP0.1 Codificação standard Medida de tamanho Proposta de melhoria do processo PSP1 Estimação do tamanho Relatório de teste PSP1.1 Planeamento de tarefas Planeamento de calendarização PSP2 Revisões de código Revisões de concepção PSP2.1 Concepção de templates Planeamento Pessoal Qualidade Pessoal PSP3 Desenvolvimento cíclico Processo Cíclico
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": processo. Neste caso, o número de estádios de maturidade é 6: (0) Incompleto; (1) Realizado; (2) Gerido; (3) Definido; (4) Gerido Quantitativamente; e (5) Optimizado.
Figura 3. Arquitectura do CMMI – abordagem contínua [adaptado de CMMI 2002a].
A representação contínua possui mais práticas específicas do que a representação em estádios, porque a primeira comporta dois tipos de práticas (básicas e avançadas) enquanto a segunda tem apenas um tipo de práticas específicas.
Na representação contínua, as práticas genéricas existem para os estádios de 1 a 5, por sua vez, na representação em estádios só existem práticas genéricas nos estádios 2 e 3.
Na tabela 2 apresentam-se alguns argumentos que podem ajudar a escolher entre a aplicação da abordagem em estádios ou a aplicação da abordagem contínua.
Tabela 2. Abordagem em Estádios versus Abordagem Contínua.
Abordagem em Estádios Abordagem Contínua
1. Segue uma sequência de melhorias provada, iniciando com práticas de gestão básicas;
2. Potencia comparações baseadas em estádios de maturidade;
3. Facilita a migração a partir do SW-CMM.
1. Permite escolher a ordem da melhoria baseado nos objectivos do negócio e áreas de risco;
2. Potencia comparações baseadas em áreas do processo ou estádios de maturidade;
3. Potencia comparações com a ISO 15504/SPICE
4. APLICAÇÃO DO SW-CMM NA DETERMINAÇÃO DA MATURIDADE
Os modelos de maturidade são instrumentos que orientam as organizações de software em direcção a uma maturidade superior, baseado em práticas já provadas. Para uma organização conhecer o estádio de maturidade em que se encontra, de modo a poder encetar um processo de melhoria, tem de o diagnosticar. Normalmente os modelos de maturidade disponibilizam um questionário para recolha de dados. Esses dados quando tratados segundo o algoritmo de cálculo subjacente ao modelo levam à determinação do estádio de maturidade.
Aqui retratamos uma experiência de aplicação do questionário de maturidade do SW-CMM [Zubrow et al. 1994] em cinco organizações portuguesas. Importa referir que a aplicação do questionário não apresentou dificuldades, tendo-se pautado como um instrumento de levantamento de dados regido por um bom grau de clareza e objectividade.
Tabela 3: Organizações estudadas.
Emp. Negócio Colaboradores Função SI Descrição
A Banca e
seguros
12691 400 Um dos principais grupos financeiros e seguradores do país
B Governo 260 150 Instituto de informática e finanças de um dos
maiores ministérios do governo português
C Alimentação 1286 33 Uma das maiores empresas de bebidas do país
D Comércio
electrónico
32 24 Uma das primeiras e das maiores empresas de
comércio electrónico do país
E Ensino 296 7 Universidade privada
Estádios de Maturidade
Objectivos Genéricos
Área do Processo 1 Área do Processo 2 Área do Processo 3 Objectivos Específicos
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": O levantamento foi realizado junto de cinco organizações pertencentes a áreas de negócio distintas, a saber: banca e seguros, governo, alimentação, comércio electrónico e ensino. O número total de colaboradores, bem como os que constituem a função SI, também é diversificado entre elas. A tabela 3 apresenta estruturada e resumidamente as organizações estudadas.
A tabela 4 sintetiza os resultados de maturidade conseguidos por área chave e estádios de maturidade do processo em cada uma das organizações.
Tabela 4: Síntese dos resultados da maturidade do processo de software.
Áreas Chave Emp. A Emp. B Emp. C Emp. D Emp. E
Gestão de Requisitos 50% 66,7% 0% 33,3% 0%
Planeamento de Projectos de Software 28,6% 57,1% 28,6% 14,3% 71,4% Vigilância Acompanhamento Projectos de Software 28,6% 71,4% 14,3% 0% 71,4%
Gestão da Sub-contratação de Software 37,5% 37,5% 0% 0% 0%
Verificação da Qualidade de Software 50% 37,5% 0% 0% 75%
Gestão de Configurações 0% 62,5% 25% 0% 62,5%
32,4% 55,5% 11,3% 7,9% 46,7%
Concentração no Processo Organizacional 57,1% 85,7% 0% 14,3% 42,9%
Definição do Processo Organizacional 0% 83,3% 0% 16,7% 0%
Programas de Treino 100% 42,9% 57,1% 0% 71,4%
Gestão da Integração de Software 0% 66,7% 0% 0% 0%
Engenharia do Produto de Software 50% 50% 0% 16,7% 0%
Coordenação Inter-Grupos 0% 71,4% 0% 0% 0%
Revisões por Pares 0% 16,7% 33,3% 0% 0%
29,6% 59,5% 12,9% 6,8% 16,3%
Gestão Quantitativa do Processo 0% 28,6% 0% 0% 0%
Gestão da Qualidade de Software 0% 71,4% 0% 0% 0%
0% 50% 0% 0% 0%
Prevenção de Defeitos 0% 71,4% 28,6% 14,3% 0%
Gestão da Mudança da Tecnologia 42,9% 57,1% 14,3% 0% 28,6%
Gestão da Mudança do Processo 14,3% 28,6% 0% 14,3% 0%
19% 52,4% 14,3% 9,5% 9,5%
Sendo rigoroso na aplicação dos critérios de cálculo subjacentes ao modelo SW-CMM, todas as organizações estudadas seriam caracterizadas como residindo no primeiro estádio de maturidade (Inicial), pois qualquer área chave do processo tem que obter 100% para que todos os seus objectivos estejam atingidos. O resultado não é de estranhar, uma vez que diversos autores [e.g., Vicente et al. 1996, Soares 1997] referem o elevado grau de exigência deste modelo.
Não acreditando que não haja diferenças de maturidade entre as organizações, resolvemos aplicar uma tolerância ao critério de cálculo do SW-CMM. A tabela 5 apresenta os estádios de maturidade em que se encontraria cada uma das organizações em função de valores de tolerância diferentes.
Tabela 5: Estádios de maturidade, por organização, para valores de tolerância diferentes.
As organizações que apresentam melhores resultados são a A e a B. Poder-se-á concluir que, apesar de todas as organizações serem pouco maduras face aos critérios de cálculo sugeridos pelo SW-CMM, as empresas A e B são, apesar de tudo, as mais avançadas.
Os estádios de maturidade obtidos seguindo rigorosamente o algoritmo do SW-CMM levam-nos a sugerir que, antes das organizações se preocuparem com a maturidade colectiva da organização do processo de desenvolvimento de software se devem preocupar com a maturidade/disciplina individual dos seus engenheiros (modelo PSP: [Humphrey 1995, 2000]).
Tolerância Emp. A Emp. B Emp. C Emp. D Emp. E
0% 1 1 1 1 1
25% 1 1 1 1 1
50% 1 5 1 1 1
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": Quando isso acontecer, pelo menos as organizações encontrar-se-ão no segundo estádio de maturidade do SW-CMM. A partir daí, é então necessário desenvolver práticas colectivas que conduzam as organizações a estádios de maturidade superiores.
Cremos também que, para além do PSP, a abordagem contínua do CMMI pode ser uma outra alternativa à grande exigência do SW-CMM, pois a maturidade é aferida no contexto de áreas do processo em vez de ser apenas no contexto da organização do processo.
5. CONCLUSÕES
No presente artigo apresentamos as características dos modelos de maturidade, analisamos os principais modelos de maturidade do Software Engineering Institute, apresentamos um estudo de casos da aplicação do Capability Maturity Model for Software no diagnóstico da maturidade, e tecemos algumas considerações em função dos resultados dos casos estudados.
Face aos resultados de maturidade conseguidos com a aplicação do instrumento de diagnóstico do SW-CMM em cinco organizações portuguesas, verificamos que todas se encontravam no primeiro estádio de maturidade. Isto leva-nos a concluir que o modelo SW-CMM tem um elevado grau de exigência e que não facilita a distinção de maturidade entre organizações. Nós não acreditamos que não existam diferenças de maturidade entre as organizações estudadas.
Com base nestas conclusões julgamos que o modelo PSP deve ser uma alternativa ou um complemento ao modelo SW-CMM quando a organização é pequena e/ou o processo de software é imaturo ou caótico. Julgamos também que a abordagem contínua do modelo CMMI poderá proporcionar mais facilmente distinções de maturidade entre organizações.
Finalizamos, dizendo que esperamos que trabalhos futuros possam vir a reforçar as conclusões aqui derivadas. 6. REFERÊNCIAS
Bate, R., Kuhn, D. Wells, C., et al. (1995), A Systems Engineering Capability Maturity Model, V1.1, Software Engineering Institute, CMU/SEI-95-MM-003, November 1995.
Burn, J. (1994), “A revolutionary staged growth model of information systems planning”, Proceedings of the Fifteenth International
Conference on Information Systems, Vancouver, British Columbia, Canada, pp. 395-406.
Clark, B. (2000), “Quantifying the Effects of Process Improvement on Effort”, IEEE Software, Novembro/Dezembro, pp. 65-69.
CMMI (2002a), Capability Maturity Model Integration, Version 1.1, Continuous Representation, Software Engineering Institute, CMU/SEI-2002-TR-001/ESC-TR-2002-001.
CMMI (2002b), Capability Maturity Model Integration, Version 1.1, Staged Representation, Software Engineering Institute, CMU/SEI-2002-TR-002/ESC-TR-2002-002.
Curtis, B., Hefley, W. e Miller, S. (1995), People Capability Maturity Model, Software Engineering Institute, CMU/SEI-95-MM-02, September 1995.
Greiner, L. (1972), “Evolution and Revolution as Organizations Grow”, Harvard Business Review, nº 6, pp. 37-46. Greiner, L. (1998), “Revolution is still inevitable”, Harvard Business Review, nº 3, pp. 62-63.
Hather, R., Burd, E. e Boldyreff, C. (1996), “A method for application management maturity assessment”, Information and Software
Technology, Vol. 38, nº 11, pp. 701-709.
Humphrey, W. (1987a), Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/SEI-87-TR-11, June 1987.
Humphrey, W. (1987b), A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, September 1987.
Humphrey, W. (1989), Managing de Software Process, Addison Wesley. Humphrey, W. (1995), A Discipline for Software Engineering, Addison Wesley.
Humphrey, W. (1996), “Using a Defined and Measured Personal Software Process”, IEEE Software, V. 13, nº 3, pp. 77-88. Humphrey, W. (2000), The Personal Software Process (PSP), CMU/SEI-2000-TR-022.
King, W. e Teo, T. (1997), “Integration between Business Planning and Information Systems Planning: Validating a Stage Hypothesis”,
Decision Sciences, Vol. 28, nº 2, pp. 279-307.
Klimbo, G. (2001), “Knowledge Management and Maturity Models: Building Common Understanding”, Proceedings of the 2nd
European Conference on Knowledge Management, 8-9/11/2001, Bled, Slovenia.
Lavoie, D. e Culbert, A. (1978), “Stages in organization and development”, Human Relations, nº 31, pp. 417-438. Martinig, F. (1998), Usage of quality models, Methods & Tools, Vol. 6, nº 8, pp. 11-15.
Rocha, A., 2003, "Organização do Processo de Desenvolvimento de Software: Análise e Aplicação de Modelos de Maturidade do SEI": Mathiassen, L. e Sorensen, C. (1996), “The capability maturity model and CASE”, Information Systems Journal, Vol. 6, nº 3, pp. 195-208. Mutsaers, E., Zee, H. e Giertz, H. (1997), “The Evolution of Information Technology”, BIK-Blad (Nolan Norton & Co., Utrecht), Vol. 2, nº 2, pp. 15-23.
Nolan, R. (1973), "Managing de computer resource: a stage hypotesis", Communications of de ACM, Vol. 16, nº 7, pp. 399-405.
Paulk, M., Curtis, B., Chrissis, M. e Weber, C. (1993), Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-024.
Pressman, R. (1997), Software Engineering: a practitioner´s approach, 4ª ed., McGrawHill.
Rocha, A. (2000), Influência da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos, Tese de Doutoramento, Universidade do Minho.
Smith, G., Mitchell, R. e Summer, E. (1985), “Top level management priorities in different stages of the organizational life cycle”, Academy
of Management Journal, Vol. 28, nº 4, pp. 799-820.
Soares, N. (1997), Avaliação da Maturidade do Processo de Software, Dissertação de Mestrado, Universidade do Minho. SPICE V1.00 (1996), ISO/IEC Software Process Assessment. ISO.
Vicente, B., António, C. e Barreira, J. (1996), Qualidade no Software, Projecto Aquis, Instituto Português da Qualidade. Zubrow, D. et al. (1994), Maturity Questionnaire, Special Report, CMU/SEI-94-SR-07, Software Engineering Institute. Zultner, R. (1993), “TQM for Technical Teams”, Communications of the ACM, Vol. 36, n. 10, pp. 79-91.
