Contribuição dos modelos de qualidade e maturidade na melhoria dos processos de software

Contribution of quality and maturity models to software process improvement

Contribuição dos modelos de qualidade e maturidade na melhoria dos processos de software

Contribution of quality and maturity models to software process improvement

Antonio Carlos Tonini; Marly Monteiro de Carvalho; Mauro de Mesquita Spinola

EPUSP

RESUMO

Grande parte das empresas desenvolvedoras de software criou seu próprio processo de trabalho. Devido à rápida expansão do mercado de software, a concorrência ocorre muito mais em custo do que em diferenciação. Para obter vantagem competitiva, as empresas devem atualizar-se continuamente na tecnologia, buscar a maturidade nos processos e eliminar a ineficiência operacional. Isso requer um envolvimento das pessoas, dos processos e da organização como um todo. O artigo discute a implementação de melhorias nos processos de software segundo os principais modelos de qualidade e de maturidade. Com base em um Estudo de Casos Múltiplos, verifica-se que a melhoria dos processos de software requer que a melhoria ocorra primeiramente entre cada um dos desenvolvedores e, a seguir, envolva os grupos de desenvolvimento e por fim, a organização como um todo. A pesquisa conclui que os modelos de qualidade e maturidade servem como orientadores do processo de melhoria.

Palavras-chave: Maturidade; CMMI; TSP/PSP; PMMM / OPM3; Sistemas ISO/IEC.

ABSTRACT

Many software development companies have developed their own work method. Due to the fast software market growth, the competition focuses more on cost than on differentiation. To achieve competitive advantage, software developer organizations must continually update their technology, reach high level process maturity and eliminate all the operational inefficiency. These procedures involve people, processes and the whole organization. The aim of the paper is to discuss software process improvement implementation according to the most important quality and maturity models. Based on a Multiple Case Study, it is verified that the software process improvement needs firstly individual improvement and, later, it involves the developer teams and the whole organization. The research concludes that the quality and maturity models must be used as improvement process drivers.

Key words: Maturity; CMMI; TSP/PSP; PMMM / OPM3; ISO/IEC systems.

1. INTRODUÇÃO

O consumo de software tem aumentado de forma acelerada nos últimos anos e tem despertado o interesse por este tipo de negócio no mundo inteiro, tornando o software uma commodity. Grande parte das empresas deste ramo nasceu pequena, desenvolveu uma cultura própria de trabalho que, em um primeiro momento, se mostrou eficaz e possibilitou o crescimento da empresa (ROCHA et al., 2001).

Os clientes de software desejam ver suas necessidades e expectativas atendidas, entregues no prazo acordado, sem custos adicionais, sem sustos e percalços e esperam contar com suporte ao longo de todo ciclo de vida. Desta forma, para os desenvolvedores não basta uma boa campanha de marketing, um portfólio respeitável e um preço baixo; devem demonstrar competência para entregar e suportar esse produto dentro dos níveis de serviço especificados.

Em outras palavras, isto significa que cada vez menos há espaço para a informalidade. A busca e a sustentabilidade de vantagem competitiva ocorre em termos de enfoque no custo de cada um dos projetos realizados. Assim, qualquer ponto forte ou ponto fraco é, em última instância, uma função do seu impacto sobre o seu custo operacional e sobre a satisfação do cliente (PORTER, 1985). As estratégias de negócio devem ser estipuladas com base na visão do cliente e na adequação da infra-estrutura, o que significa considerar positivamente qualquer oportunidade de resolução de problemas e melhoria de desempenho (HESKETT et al., 1997). A adoção de um modelo de maturidade se tornou uma exigência e um passaporte para comercialização internacional de produtos de software (SALVIANO et al., 2004).

A competência exigida dos desenvolvedores de software se manifesta no domínio da tecnologia, no controle dos processos operacionais, na gestão tática e na gestão dos negócios, o que requer a demonstração de controle sobre seus processos operacionais, tanto os internos, quanto os atinentes às relações externas. A empresa deve exercitar-se na disciplina do controle e ganhar rapidamente elevados padrões de maturidade (RABECHINI JUNIOR, 2003).

A formulação e implementação de uma metodologia particular é fundamental para desenvolver competências necessárias ao sucesso empresarial (BOUER; CARVALHO, 2005).

A estrutura organizacional é um fator crítico de sucesso para a implementação de qualquer estratégia, pois ela fornece elementos para a inferência sobre os principais direcionadores de mudança e sustentação a uma estratégia organizacional (PATAH; CARVALHO, 2002).

Mesmo que seja fundamental que cada organização adote um modelo específico e particular, o foco não é criar novos modelos, mas utilizar com sabedoria as melhores práticas indicadas, adaptando-as para a realidade empresarial, ou seja, internalizar as melhores práticas da engenharia de software (ROCHA et al., 2001).

2. OBJETIVO E METODOLOGIA

O objetivo da pesquisa é entender como as organizações desenvolvedoras de software implementam procedimentos de melhoria nos processos de desenvolvimento e como elas utilizam e combinam os diversos modelos de qualidade e maturidade.

O artigo discute inicialmente o conceito de maturidade e competência, necessários para a investigação e a compreensão dos modelos de qualidade e maturidade, cujas características são apresentadas em seguida. Estes conceitos teóricos permitem elaborar os principais constructos teóricos que fundamentam as dimensões da maturidade no desenvolvimento e gerenciamento dos projetos de software.

O artigo apresenta também os resultados de uma pesquisa de campo, realizada na forma de Estudo de Casos Múltiplos, que procurou investigar como ocorreu o lançamento dos procedimentos de melhoria e como as empresas utilizaram e combinaram para si os conhecimentos e as práticas recomendados nos diversos modelos de qualidade e de maturidade.

As informações foram obtidas em três organizações brasileiras desenvolvedoras de software que implementaram melhorias nos seus processos de desenvolvimento. Os dados primários foram coletados junto a diversas pessoas de cada uma das organizações, através de entrevistas semi-estruturadas, que permitiram verificar a contribuição de mais de um modelo em cada um dos casos.

Como fruto deste trabalho, foi constatado o caminho trilhado pelas organizações para a implementação da melhoria nos processos de desenvolvimento de software e também se confirmou o conjunto de constructos teóricos identificados na literatura especializada.

3. REVISÃO DA LITERATURA

A indústria de software pode ser dividida em dois grandes nichos: software genérico e software aplicativo. O primeiro se caracteriza por oferecer novos produtos de software, enquanto o segundo se vale da tecnologia e produtos de software genéricos já disponíveis para produzir software e serviços adequados às necessidades computacionais de cada cliente em particular.

Os clientes dos produtos de software aplicativo esperam ter seus requisitos entendidos e traduzidos em funcionalidades computacionais e ainda contam com o suporte do desenvolvedor ao longo do ciclo de vida do software. Para que o atendimento contínuo pós-venda se concretize torna-se crítico para a organização garantir que a qualidade de seus processos de desenvolvimento seja captada pelos clientes e influa positivamente na satisfação pelo produto e serviço fornecidos (CARD, 2002).

Neste último, o cliente prioriza a perenidade do atendimento do desenvolvedor, esperando que este mantenha o produto de software sempre alinhado às suas necessidades, independentemente da quantidade de modificações a que ele deva se submeter (FENTON; PFLEEGER, 1997).

Para a implementação de estratégias focadas em custo, dois aspectos se tornam imprescindíveis: os processos de negócio e os recursos envolvidos. Enquanto os primeiros se constituem nas ações a serem executadas para atingir os objetivos de negócio, os recursos são os meios empregados para a sua realização e são constituídos pelas pessoas e suas competências individuais e coletivas disponibilizadas em prol da consecução dos processos de negócio e das ações específicas de implementação das estratégias (RAY et al., 2004).

Para implementar as melhorias nos processos de software, a empresa pode utilizar alguns caminhos: as práticas recomendadas nos modelos de qualidade e maturidade já existentes, o desenvolvimento de uma modelo próprio e específico ou, então, adaptar para si as práticas dos modelos já existentes.

3.1. Maturidade e Competência

Em um mercado crescente de demanda e oferta, as oportunidades de negócios são inúmeras e atrativas, abrindo a possibilidade, num primeiro momento, de produtos com menor qualidade. Contudo, o acirramento da concorrência manifesta-se na mesma proporção das oportunidades e os produtos de software concorrem num mercado mundial aberto, onde ainda não há muitas barreiras ou restrições formais ou legais. A tecnologia é facilmente acessível, a capacidade criativa de prover soluções computacionais é quase ilimitada, os produtos são bastante similares (commodities), os preços estão relativamente padronizados e o tempo necessário de disponibilização (time-to-market) é muito curto. As diferenças competitivas que encantam e convencem o cliente passam pelos critérios da confiança de ter uma solução eficaz e duradoura e, ao mesmo tempo, descartável e substituível com facilidade (ROCHA et al., 2001). Para tanto, os desenvolvedores devem ter processos de desenvolvimento estáveis e capazes de suportar a volatilidade das soluções. Para atingir esse patamar, as organizações devem desenvolver e manter a competência adequada - com mais eficiência e eficácia (capability); o exercício contínuo de melhoria faz com que a organização atinja o mais alto patamar de maturidade (maturity), de acordo com suas possibilidades (forças e fraquezas) e objetivos empresariais (CHRISSIS et al., 2003).

Maturidade é um objetivo móvel, visto que seus principais elementos (tecnologia, metodologia e gestão) mudam continuamente em função do mercado, dos negócios e das pessoas (RABECHINI JUNIOR, 2003). O importante não é a maturidade em si, que é apenas um estado ou um ponto dinâmico, mas a competência em identificar e buscar o nível necessário e suficiente, através da obtenção de conhecimento (saber o quê), do desenvolvimento das habilidades (saber como) e a atitude em alinhá-la com os objetivos do negócio (saber o porquê) (FLEURY; FLEURY, 2000).

A competência se manifesta pela predisposição à aprendizagem e pode ser decomposta (sem pretender ser definitiva nem exaustiva) em diversos aspectos: organizar e dirigir as oportunidades, administrar o progresso, identificar as heterogeneidades de indivíduos e grupos, aplicar o aprendizado no trabalho, estimular o trabalho de equipe, compartilhar a gestão, envolver os responsáveis, buscar novas metodologias e tecnologias, administrar continuamente a disciplina de aprendizagem (PERRENOUD, 1999).

Gerar competências em equipe é uma tarefa árdua, de longo prazo que exige maturidade, diretrizes bem claras e um forte alinhamento com as necessidades gerenciais (RABECHINI JR.; CARVALHO, 2003).

O desenvolvimento de software é, por um lado, uma atividade artesanal, pois o resultado depende da forma particular com que o desenvolvedor aplica seus conhecimentos tecnológicos, para transformar o requisito do usuário em um artefato computacional. Por outro lado, ele é construído segundo padrões ou métodos largamente difundidos pela Engenharia de Software (PFLEEGER, 2004) e adotado pelo grupo de desenvolvimento da empresa. O produto de software depende, portanto, do esforço coletivo de uma equipe (aspecto de equipe) e está inserido no ambiente empresarial, sujeito às incertezas do resultado, mudanças e disponibilidade de recursos (aspecto organizacional).

As competências necessárias para a melhoria dos processos de trabalho estão relacionadas com as dimensões de conhecimento, postura gerencial e organização do trabalho; por outro lado, envolvem as pessoas, as equipes e a organização como um todo (ANDERSEN; JESSEN, 2002). O Quadro 1 apresenta alguns dos fatores que relacionam as dimensões e os envolvidos.

3.2. Modelos de qualidade e maturidade

Os modelos objetivam assegurar e dar visibilidade à robustez dos processos relativos aos produtos de software, bem como às atividades necessárias para a sua gestão.

3.2.1. Os modelos SW-CMM / CMMI

O SW-CMM (Software Capability Maturity Model) foi publicado em setembro de 1987 pelo SEI (Software Engineering Institute) para que o Departamento de Defesa dos EUA pudesse ter acesso à capacidade de desenvolvimento dos seus fornecedores de produtos de software. Foi desenvolvido pelo SEI em conjunto com a Universidade Carnegie Mellon University de Pittsburgh e apresenta cinco níveis de maturidade, cada qual correspondendo a um conjunto de requisitos estruturais para as áreas-chave do processo de desenvolvimento de software (CMMI-1 e 2, 2002) (HUMPHREY, 1989) (PAULK et al., 1997).

O SW-CMM não era recomendado para melhorias de processos específicos do desenvolvimento de software (CARVALHO et al., 2003). Por esta razão e também para se adequar a outros modelos (como à norma ISO/IEC 15504), o SEI lançou o CMMI (Capability Maturity Model Integration) que é um modelo unificado e entende que nem todas as organizações desenvolvedoras de software executam todos os processos do ciclo de desenvolvimento e que é possível realizar melhorias somente em alguns processos; segundo esta interpretação, a maturidade das organizações é um processo gradual que é alcançado pelo exercício das melhores práticas (PAULK et al., 1997).

Por esta razão, o modelo contempla duas representações, uma estagiada e a outra contínua. A representação estagiada mantém os cinco níveis de maturidade do SW-CMM, sendo que cada um deles é caracterizado por um conjunto de áreas-chave cuja aderência é necessária para se atingir maturidade. Os estágios são os seguintes: 1 - inicial, 2 - gerenciado, 3 - definido, 4 - gerenciado quantitativamente e 5 - otimizado. Na representação contínua, o modelo prevê a avaliação do nível de capacitação (fazer com qualidade - capability) de cada uma das áreas de processo individualmente. Isso permite que a organização atenda aos processos que lhe sejam afins (CHRISSIS et al., 2003).

A adoção do modelo CMMI estagiado implica que a organização deve atingir cada nível de maturidade na seqüência em que o modelo apresenta, iniciando a primeira meta pelo nível 2 de maturidade. Para tanto, a organização deve demonstrar o atendimento às exigências das seguintes áreas de processos:

• Planejamento de projetos - estabelecer e manter planos com as atividades e os produtos de trabalho do desenvolvimento e manutenção de todos os projetos, cada qual segundo seu escopo, elaborar os orçamentos e cronogramas. Prevê também a formalização do compromisso, através das revisões periódicas e com a disponibilização dos recursos;

• Monitoramento e controle de projetos - fornecer o entendimento do progresso do projeto e identificar os desvios, os riscos, os dados de controle e as ações corretivas;

• Medições e análises - desenvolver e manter as medições necessárias para prover informações de gerenciamento adequadas à organização;

• Gerenciamento de requisitos - identificar os requisitos funcionais e não funcionais do produto e as correspondentes mudanças;

• Gerenciamento de configuração - identificar os itens de configuração dos produtos finais e de seus componentes (

  baselines), sua integridade e mudanças;

• Gerenciamento da qualidade do produto e do processo - prover a visibilidade objetiva e a comunicação adequada do andamento e da qualidade do processo e dos produtos de trabalho e final;

• Gerenciamento dos acordos de fornecimento - gerenciar a aquisição de produtos, a seleção dos fornecedores e cumprir mutuamente as responsabilidades e manter os registros do aceite e de transferência.

Para cada uma das áreas, devem ser elaboradas políticas para manter o compromisso, garantir o patrocínio, habitar os gestores para planejar e controlar os recursos envolvidos e a evolução do produto, com o devido treinamento, autoridade e responsabilidade, direcionar os esforços para a conclusão do desenvolvimento e verificar continuamente a conformidade do processo e dos produtos (COHEN et al., 2002).

Um dos fatores limitantes deste modelo é que ele requer um grupo de especialistas em cada empresa, voltado única e exclusivamente para a melhoria de processos. Considerando que em grande parte das empresas, especialmente em grupos menores, a existência de um grupo especialista não é uma prática comum, o próprio SEI tem recomendado o estabelecimento de modelos voltados para cada desenvolvedor em particular e para os pequenos grupos (HUMPHREY, 1998).

3.2.2. O modelo PSP

Com o propósito de envolver as pessoas e as equipes de desenvolvimento, o SEI elaborou dois modelos complementares: O PSP (Personal Software Process) e o TSP (Team Software Process). Estão estruturados com base em medidas do processo e implementados através de um intenso treinamento. Quando praticados em conjunto, fazem com que os processos de desenvolvimento atinjam altos níveis de maturidade, o que facilita enormemente a adoção de um modelo de maturidade para a organização (JANISZEWSKI e GEORGE, 2004).

O modelo PSP está direcionado para a pessoa do desenvolvedor de software.

Os desenvolvedores de software criam suas próprias práticas quando aprendem a escrever programas, não importando o quanto se desenvolvam na profissão. A mudança de comportamento, exigida na melhoria de processos, passa a ser, portanto, um problema de ordem pessoal. Se os desenvolvedores não internalizarem as mudanças, nem as equipes o farão, tampouco as organizações (HUMPRHEY, 1998).

Os níveis de maturidade propostos para as pessoas no modelo PSP seguem os mesmos passos do modelo organizacional. No primeiro nível, os desenvolvedores devem tornar-se aptos em elaborar a medição básica de seu trabalho, ou seja, tempo gasto e defeitos encontrados. No próximo nível, eles devem desenvolver a habilidade em elaborar o planejamento pessoal dos trabalhos técnicos, dando ênfase ao planejamento do tempo necessário para a realização de suas atividades. No terceiro nível, a melhoria da qualidade pessoal é estimulada através de processos de revisão do trabalho realizado de forma a prever quantos erros, em média, podem ser cometidos em cada fase do ciclo de desenvolvimento, com base no histórico do desenvolvedor. No nível mais alto, o PSP considera o processo cíclico pessoal, estendendo seu campo de visão para tratar projetos maiores, dividindo-os em pequenos projetos que possam ser tratados a nível pessoal; assim, o desenvolvimento de grandes projetos é realizado de uma forma incremental (HUMPRHEY, 1998).

3.2.3. O modelo TSP

Se o ambiente de trabalho não encorajar os desenvolvedores, dificilmente qualquer iniciativa de melhoria de processos terá muita chance de prosperar. Com base nisso, o SEI lançou o TSP, que é um modelo de maturidade para as equipes de trabalho. O objetivo é capacitar a equipe para que se auto-gerencie, distribuindo entre si as responsabilidades das atividades gerenciais e de apoio. O desenvolvimento deve ocorrer em ciclos incrementais de forma a mitigar os riscos de cada um dos ciclos (launch). Para tanto, antes de se lançar no desenvolvimento, a equipe deve traçar as suas estratégias, conhecendo suas forças, disponibilidades e fraquezas e, só depois disso, elaborar o planejamento e a execução de desenvolvimento.

A estrutura organizacional da equipe de desenvolvimento é um fator crítico de sucesso para a implementação de uma estratégia organizacional (PATAH e CARVALHO, 2002). A necessidade de se buscar novos arranjos organizacionais do trabalho de desenvolvimento de software, fazendo frente aos requisitos dos clientes é sinal de um maior grau de maturidade organizacional no gerenciamento de projetos. O papel principal do gerente é ser o facilitador (coaching) e provedor dos recursos do desenvolvimento (STEPHEN, 2002).

3.2.4. O modelo PMMM

Com base nas principais áreas de conhecimento e nos processos de gerenciamento de projetos abordados pelo PMBOK (Project Management Body of Knowledge) (PMI, 2000) e também na estrutura de cinco níveis do CMMI, o modelo PMMM (Project Management Maturity Model) propõe uma conceituação de maturidade para o gerenciamento de projetos de uma forma mais ampla e genérica (KERZNER, 2000; KERZNER, 2001). Os níveis de maturidade são: nível 1 - linguagem comum nas nove áreas de conhecimento do PMBOK, nível 2 - processos comuns nas fases do Ciclo de Vida no gerenciamento de projetos (embrionária, aceitação pela alta direção, aceitação pela gerência, crescimento e maturidade), nível 3 - metodologia singular, nível 4 - bechmarking e nível 5 - melhoria contínua.

O modelo foi inspirado no modelo SW-CMM (KERZNER, 2000; KERZNER, 2001). Embora se diferencie em muitos aspectos do modelo SW-CMM, o PMMM introduz alguns instrumentos de medição e comparação (benchmarking) do progresso da organização ao longo do modelo de maturidade. Além disso, procura manter a mesma terminologia do modelo SW-CMM, o que facilita as organizações que se valem de ambos os modelos (CARVALHO et al., 2003).

3.2.5. O modelo OPM3

O modelo OPM3 (Organizational Project Management Maturity Model) foi elaborado pelo PMI com o propósito de ser um guia de maturidade multidimensional na gestão de projetos, correlacionando lógica e coerentemente as estratégias e os projetos executados pela organização; ele é uma decorrência de uma evolução natural do PMBOK - 2000 e do Project Management Competency Development Framework (2002). O objetivo do PMI foi elaborar um modelo de maturidade organizacional para a gestão de projetos. As dimensões se referem aos domínios do gerenciamento de projetos (projeto, programa e portfólio), aos estágios do processo de melhoria (padronização, medição, controle e melhoria) e aos grupos de processos de gerenciamento de projetos (iniciação, planejamento, execução, controle e encerramento) (PMI, 2003).

3.2.6. Sistemas e padrões da qualidade

A nova estrutura da ISO 9001:2000 veio facilitar bastante as atividades de software e incorpora um roteiro de relacionamento entre os padrões da Tecnologia da Informação (ISO/IEC JTC1/SC7) e os sistemas de qualidade descritos na ISO 9001. Publicada em 2000, ela foi totalmente reestruturada, apresentando maior clareza na abordagem dos processos.

A ISO 9000-3 (2001) é um guia de referência para a área de desenvolvimento, fornecimento, aquisição e manutenção de produtos de software. Além disso, outras normas ISO oferecem tanto uma visão geral quanto abordagens sobre processos específicos, tais como: produtos de software (ISO 9126), requisitos da qualidade para pacotes de software (ISO 12119) e sobre o processo do ciclo de vida (ISO 12207) (ISO/IEC 12207, 1995) (CARVALHO et al., 2003).

O modelo sugerido pelo sistema de qualidade ISO/IEC, a norma ISO/IEC 15504:1-5 (ISO/IEC 15504, 2003), entende que a melhoria de processos deve ser obtida de forma gradual e contínua, respeitando as características organizacionais e as forças e fraquezas da empresa, além de estar alinhada com os objetivos do negócio. A norma é resultado do projeto SPICE (Software Process Improvement and Capability dEtermination) e propõe a melhoria em 48 processos no desenvolvimento de software. O modelo considera a organização como um todo, não tecendo considerações sobre as pessoas ou equipes (SALVIANO et al., 2004).

A abordagem do modelo SPICE influenciou primeiramente o modelo SW-CMM para a Engenharia de Sistemas e mais recentemente o modelo CMMI (CARVALHO et al., 2003).

3.2.7. Síntese dos modelos de qualidade e maturidade

A maioria dos modelos de qualidade e maturidade tem como alvo a organização como um todo, não se preocupando com as características individuais de cada projeto de desenvolvimento, de cada processo de trabalho e de cada indivíduo ou equipe.

Os modelos PSP e TSP apresentam características próprias para os indivíduos e para as equipes; no entanto não se preocupam também com as especificidades de cada projeto e de cada processo de trabalho.

No entanto, é possível identificar alguns requisitos de ordem genérica e outros de ordem particular para cada projeto e para cada processo de trabalho, conforme mostra o Quadro 2.

Além disso, os diversos modelos de qualidade e maturidade são substancialmente diferentes no que se refere aos níveis de abstração, mas apresentam a possibilidade de se influenciarem mutuamente e se completarem sinergicamente e ainda assim manter a sua consistência interna (CARVALHO et al., 2003).

4. O ESTUDO DE CASO

No sentido de investigar o início do processo de melhoria dos processos de software visando a adoção de um modelo de maturidade, este artigo apresenta o resultado de uma pesquisa empírica, de natureza qualitativa, conduzida por meio do método de Estudo de Casos Múltiplos (YIN, 1998).

O uso do Estudo de Casos Múltiplos permitiu entender os diferentes contextos empresariais, os motivos que as levaram a procurar um modelo de maturidade para os seus processos de software e o caminho trilhado por elas até a implantação do mesmo. Não obstante o fato de haver uma forte similaridade com a realidade de outras empresas, a pesquisa não permite grandes generalizações (CLAVER et al., 2000).

A pesquisa foi realizada em três organizações brasileiras desenvolvedoras de software que aplicam sistematicamente procedimentos de melhoria nos seus processos de desenvolvimento.

A proposição que orientou a pesquisa foi a de que "o lançamento dos procedimentos de melhoria dos processos de software se baseiam nos modelos de qualidade e maturidade e que o caminho adotado pelas organizações considera primeiramente as pessoas, depois os grupos de desenvolvimento e, finalmente, a empresa como um todo".

O instrumento utilizado na pesquisa se constituiu de entrevistas abertas com pessoas de cada uma das organizações que exercem cargos de gerência e cargos técnicos. O foco das entrevistas foi o caminho adotado pela empresa até chegar à decisão da implementação do modelo de maturidade. As opiniões foram confrontadas com o quadro teórico, o que permitiu entender os conceitos das mesmas.

As empresas pesquisadas têm como negócio principal o desenvolvimento de software para terceiros e ao adotar o SW-CMM / CMMI como modelo de maturidade de seus processos de desenvolvimento, trilharam um percurso que é confrontado com a teoria. Não obstante as suas origens, motivações e contextos diferentes, em todas elas, a implantação priorizou a capacitação das pessoas, seguida da capacitação das equipes e por último, a adoção da melhoria como uma ação corporativa.

O quadro 3 procura sintetizar as características marcantes de cada uma das empresas, facilitando uma comparação entre elas.

4.1. Empresa 1

A empresa 1 é originária da área de Tecnologia da Informação (TI) de uma grande empresa multinacional do ramo automotivo. Quando era apenas uma área funcional, não havia pressões sobre a eficiência da área (custo e prazo) tampouco sobre a qualidade do software produzido. Uma vez que a área de TI estava subordinada à Diretoria Industrial, já havia uma cultura de gerenciamento de projetos, divisão do trabalho, elaboração de cronograma, apontamento do tempo gasto nas atividades e cálculo de custo, para efeito de rateio no custo industrial. Além disso, como a organização era certificada pelo sistema ISO 9001 para algumas linhas de produtos de software, diversos colaboradores já tinham conhecimento dos requisitos de um modelo de qualidade e maturidade. Havia estabilidade na equipe de desenvolvedores, o que facilitava o gerenciamento dos requisitos de software e o gerenciamento da configuração.

A empresa de TI surgiu em função da terceirização desta área. Os antigos gerentes se tornaram os seus proprietários. Com isso, teve que competir com outras empresas do mercado para vender serviços para as áreas funcionais da corporação, buscar competência em tecnologia e, ainda, conseguir lucratividade. Perceberam, então, que a única chance de sobrevivência era descobrir a sua real missão e traçar imediatamente algumas estratégias. Foi definido que se deveria buscar a certificação CMMI nível 4 em um prazo máximo de cinco anos e, no contexto desta meta, atingir o nível 2 nos próximos dois anos.

Para isso, as pessoas deveriam internalizar um modelo de maturidade, no que se referia à revisão de seus processos de trabalho e melhoria do produto. Foram incentivados treinamentos das pessoas (PSP), as equipes passaram a receber treinamentos periódicos sobre motivação, liderança e trabalho em conjunto (TSP) e, quando começaram a surgir os primeiros resultados positivos, a empresa iniciou a busca pela certificação CMMI nível 2, estabelecendo como prioridades: primeiro, o gerenciamento de requisitos e de configuração; depois, a garantia da qualidade e por último, as questões de planejamento, controle e medições. Embora objetivem a certificação CMMI com a representação estagiada, o caminho traçado se valerá das recomendações da representação contínua.

Não há evidências sobre a contribuição dos modelos de maturidade em projetos. Para a realização deste artigo, foram entrevistadas pessoas que haviam sido líderes de projeto, enquanto a empresa era uma área funcional e na nova organização da empresa ocupam funções gerenciais relacionadas com o desenvolvimento de software e na equipe de SEPG (Software Engineering Process Group).

4.2. Empresa 2

A empresa 2 é uma subsidiária de um grupo internacional de desenvolvimento de produtos de software, presente em mais de 50 países. Atualmente, é a única organização brasileira certificada pelo SW-CMM com o nível 4 e, em breve, pretende adequar-se ao modelo CMMI. O atingimento do nível 4 do SW-CMM ocorreu antes do prazo estimado, o que tem funcionado como um elemento de sinergia junto aos clientes. Participaram das entrevistas algumas pessoas que acompanharam todo o processo de implantação do processo de melhoria.

A implantação da certificação SW-CMM nível 2 foi bastante tumultuada, pois os colaboradores não foram envolvidos, além do que se registrava no momento uma marcante troca de pessoal por motivos de descontentamento, baixa remuneração e entrosamento entre as equipes. Por esta razão, foi iniciado um trabalho de conscientização das pessoas e das equipes, de acordo com os modelos PSP e o TSP.

O resultado foi uma homogeneização do grupo em termos de expectativas, conhecimentos, habilidades e comprometimento. Foi criado um mecanismo de recompensa para as boas iniciativas das pessoas.

Paralelamente, a empresa procurou cuidar de sua imagem junto aos principais clientes, que entenderam o momento de transição e continuaram prestigiando-a, não obstante uma pequena queda na qualidade do serviço prestado.

Além das áreas chave de processos do SW-CMM, a empresa estabeleceu metas relativas ao suporte de clientes, redução das falhas e modernização tecnológica. Em pouco tempo, com o surgimento dos resultados, a matriz da empresa deu todo o seu apoio, viabilizou aporte financeiro e constituiu uma área de responsabilidade específica para qualidade e maturidade. Além de obter a certificação no modelo SW-CMM nível 2, a empresa também obteve certificação nos sistema ISO/IEC 9000:2000 e em alguns processos da norma 15504.

Conforme os depoimentos, se a filial brasileira estivesse iniciando nos dias atuais a certificação CMMI, certamente optaria pela representação contínua, visto que esta melhor se adequa àquelas empresas que executam todos os processos do desenvolvimento de software, mas também, em determinados momentos, executa com maior ênfase apenas algumas das fases.

Os processos de gestão foram estruturados com base nas melhores práticas do PMBOK, juntamente com os esforços de adoção das práticas do PSP e TSP. Pelo fato de a empresa ter desenvolvido experiência de atuar apenas na elaboração de projetos, isto é, não respondendo por todas as etapas do desenvolvimento de software, a empresa está estudando e se preparando para certificação em maturidade de projetos.

4.3. Empresa 3

A empresa 3 é uma organização genuinamente nacional, que ocupa uma posição de destaque entre os desenvolvedores de sistemas integrados de gestão, conhecidos como Sistemas ERP (Enterprise Resource Planning), tanto no país quanto na América Latina e América Central. Está presente também nos EUA, através de duas filiais de um de seus clientes. Seus produtos são certificados pelo sistema ISO 9001:2000. Ao tentar lançar seu produto no mercado europeu e asiático, percebeu a barreira que lhe impuseram pelo fato de ela não estar certificada em algum modelo de maturidade. Um grupo de pessoas que iniciaram o processo de melhoria contribuiu com suas considerações para a elaboração deste artigo.

Ao iniciar as primeiras ações, percebeu que elas não lhes eram familiares e que as pessoas participavam apenas porque eram obrigadas. Sentiu a necessidade de, primeiramente, incorporar a cultura de maturidade. Para tanto, buscou inspiração nos modelos PSP, TSP e no PMBOK. Como houve uma preocupação da alta direção a respeito, os resultados positivos logo surgiram, na forma de aumento de produtividade e na redução de defeitos. Atualmente, ela se prepara para a certificação CMMI nível 2, mas já constituiu um grupo de estudos e definição de processos operacionais (nível 3 CMMI).

Pelo fato de realizar todas as etapas do desenvolvimento de software pretende atingir a certificação CMMI segundo a representação estagiada.

Embora o gerenciamento de projetos pratique a maioria das áreas de conhecimento do PMBOK, não foram dadas evidências de que a empresa pretenda obter alguma certificação de maturidade na gestão de projetos.

4.4. A análise dos Estudos de Casos

As três organizações buscaram a certificação no modelo de maturidade CMMI, por entenderem que esta seria a estratégia mais acertada para competir no mercado. Todas elas adotaram os modelos PSP e TSP como base da maturidade organizacional, uma vez que entenderam que a capacitação dos indivíduos e das equipes é ingrediente essencial para que a organização atinja o nível inicial da maturidade.

A cronologia com a qual utilizaram os constructos de cada um dos modelos tratados foi a indicada no quadro 4.

A empresa "2" entendeu como importante a abertura do modelo CMMI, proporcionada pela representação contínua, permitindo que uma organização alcance maturidade nos processos que efetivamente execute.

Com exceção da empresa "2", as outras apresentavam fortes conhecimentos e plena adequação da qualidade de seus produtos de acordo com as normas da qualidade do sistema ISO/IEC.

A empresa "2" contou com um trunfo adicional que era a reputação internacional da corporação para suportar seu processo de melhoria.

Embora nas três organizações várias pessoas apresentassem conhecimentos sobre gerenciamento de projeto, apenas a empresa "2" tinha uma estrutura específica de Escritório de Projetos e tem planos concretos de obter certificação neste campo.

Os motivos que levaram estas três organizações a buscar uma certificação de maturidade de seus processos de desenvolvimento estão relacionados diretamente com o ganho em competitividade, visto que nenhuma delas desenvolve software somente para si própria.

Estes resultados apontam para aceitação da proposição formulada indicando que os modelos de qualidade e maturidade servem de suporte para indicar quais os temas em que a organização deve atentar para a melhoria dos processos de desenvolvimento. Tem-se claro que os resultados devem ser entendidos dentro das restrições e limitações naturais de um Estudo de Casos Múltiplos, o que significa que os mesmos podem ser aproveitados para outros contextos com a parcimônia devida.

Por outro lado, a coincidência dos caminhos, isto é, o atendimento aos modelos PSP e TSP se justifica por algumas razões:

• a qualidade do produto de

  software depende exclusivamente da qualidade do profissional que o desenvolve, mesmo considerando todos os padrões estabelecidos. Portanto, elevar o padrão de qualidade dos indivíduos envolvidos no desenvolvimento, tende aumentar a qualidade do produto por eles entregue;

• assim, como o CMMI fornece uma infra-estrutura organizacional para a melhoria contínua dos processos de desenvolvimento de

  software, o PSP aplica estes mesmos conceitos no plano individual;

• as equipes de desenvolvimento de cada organização acabam customizando os padrões metodológicos de desenvolvimento com base nos conhecimentos tácitos de seus membros, da experiência e maturidade adquiridas;

• as metas organizacionais e os objetivos dos programas de melhoria são melhor entendidos e compartilhados pela equipe, criando a sinergia necessária para alavancá-los.

5. CONCLUSÕES

A maturidade é uma meta que só é atingida de forma gradual e persistente e pode significar também que a organização está perfeitamente condicionada para gerenciar seus projetos, isto é, fazê-lo bem e de forma sistemática. A Engenharia de Software foi buscar no gerenciamento de projetos (PMBOK) as melhores práticas para o gerenciamento do desenvolvimento de software, mas pouco tem aproveitado, ainda, as melhores práticas de maturidade orientadas para projeto, até porque elas se inspiraram nos modelos de maturidade para o desenvolvimento de software.

Por outro lado, o CMMI tem incorporado diversas melhorias que o aproximam dos outros modelos, tornando-o cada vez mais completo e consistente. Com isso, tem servido de base para modelos de maturidade em projeto reforçando a sinergia entre projetos em geral e projetos de software.

É notório o aumento de empresas que têm procurado certificação em maturidade, o que, fatalmente, a levará a se tornar uma condição sine-qua-non para a participação no mercado global de software. O perfil das três organizações apresentadas demonstra claramente que os maiores obstáculos a serem vencidos estão dentro da própria organização, devido a práticas consolidadas e à resistência pelas mudanças.

Embora exista uma forte similaridade da forma de atuação de grande parte das empresas brasileiras desenvolvedoras de software deve-se atentar para o fato de que a maioria delas são pequenas empresas e não dispõem de staff e recursos para investir em programas de qualidade, quiçá de maturidade.

Por outro lado, a preocupação com certificação segundo modelos de maturidade está, via de regra, relacionada muito mais com os ganhos de competitividade que a empresa possa ter do que com questões de melhoria interna, mesmo que isso resulte em um custo de desenvolvimento menor.

Mesmo respeitando as fortes limitações da pesquisa realizada, tanto em termos temporais quanto em termos de método adotado, é possível admitir que buscar um modelo de excelência, tendo como ponto de partida o desenvolvedor, parece ser a maneira mais correta, plausível e eficaz. A formulação de um caminho singular para a implementação de melhorias nos processos de desenvolvimento tem grandes chances de trazer benefícios mais duradouros para a organização, pois parte-se dos próprios elementos estruturais, organizacionais e culturais que precisam ser adequadamente abordados para que a empresa possa atingir uma efetiva maturidade organizacional.

Artigo recebido em 08/07/2005

Aprovado para publicação em 04/03/2008

SOBRE OS AUTORES

Antonio Carlos Tonini

Departamento de Engenharia da Produção

Escola Politécnica da Universidade de São Paulo

End.: Av. Prof. Almeida Prado, Travessa 2, 128 - São Paulo - SP - CEP 05508-900

Fone: 55 (11) 3091-5363, r. 425 ou r. 429

Fax: [phone]

E-mail: [e-mail]

Marly Monteiro de Carvalho

Departamento de Engenharia da Produção

Escola Politécnica da Universidade de São Paulo

End.: Av. Prof. Almeida Prado, Travessa 2, 128 - São Paulo - SP - CEP 05508-900

Fone: 55 (11) 3091-5363, r. 425 ou r. 429

Fax: [phone]

E-mail: [e-mail]

Mauro de Mesquita Spinola

Departamento de Engenharia da Produção

Escola Politécnica da Universidade de São Paulo

End.: Av. Prof. Almeida Prado, Travessa 2, 128 - São Paulo - SP - CEP 05508-900

Fone: 55 (11) 3091-5363, r. 425 ou r. 429

Fax: [phone]

E-mail: [e-mail]

• ANDERSEN, E. S.; JESSEN, S. A. Project maturity in organisation. International Journal of Project Management, v. 21, p. 457-461, 2002.
• BOUER, R.; CARVALHO, M. M. Project management maturity: just a singular methodology is enough? Revista Produção, v. 15, n. 3, p. 347-361, 2005.
• CARD, D. N. Managing software quality with defects. Proceedings. 26th Computer Software and Applications Conference, IEEE Computer Society, p. 472-474, 2002.
• CARVALHO, M. M.; LAURINDO, F. J. B.; PESSÔA, M. S. P. Information Technology Project management to achieve efficiency in Brazilian Companies. In: KAMEL, Sherif. (Org.). Managing Globally with Information Technology, Hershey, p. 260-271, 2003.
• CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI: Guide for Process Integration and Product Improvement Boston: Addison-Wesley, 2003.
• CLAVER, E.; GONZALEZ, R.; LLOPIS, J. An analysis of research in information systems (1981-1997). In: Information & Management, v. 37, n. 4, p.181-195, 2000.
• CMM-I-1 (2002) - Capability Maturity Model Integration - version 1.1 - for Systems Engineering and Software Engineering - continuous representation CMU/SEI/SW, V1.1 - CMU/SEI - 2002-TR01. Acesso em: 02 fev. 2004. Disponível em: [www.sei.cmu.edu]
• CMM-I-2 (2002) - Capability Maturity Model Integration for Systems Engineering and Software Engineering - staged representation: version 1.1 CMU/SEI/SW, V1.1 - CMU/SEI - 2002-TR02. Acesso em: 02 fev. 2004. Disponível em: [www.sei.cmu.edu]
• COHEN, S.; DUNN, E.; SOULE, A.; CHASTEK, G.; DONOHOE, P.; McGREGOR, J.D. Successful Product Line Development and Sustainment: A DoD Case Study, Technical Assessments (CMU/SEI-2002-TN-018). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, September, 2002. Acesso em: 02 ago. 2004. Disponível em: [http://www.sei.cmu.edu/publications/sema ]
• FENTON, N. E.; PFLEEGER, S. L. Software metrics: a rigorous approach. International Thomson Computer Press. 2. ed. - 1997.
• FLEURY, A. C. C.; FLEURY, M. T. L. Estratégias Empresariais e Formação de Competências São Paulo: Atlas, 2000.
• GRAY, R. J. Organisational Climate and project success. International Journal of Project Management, 19, p. 103-109, 2001.
• HESKETT, J.; SASSER, W.; SCHLESINGER, L. The value profit chain. The Free Press,1997.
• HUANG S.; TILLEY S. "Towards a Documentation Maturity Model" ACM. In: SIGDOC'03, Oct 12-15, San Francisco, California, USA, 2003.
• HUMPHREY, W. S. Managing the software process Reading, Addison-Wesley (SEI series in software engineering), 1989.
• HUMPHREY, W. S. Pathways to Process Maturity: The Personal Software Process and Team Software Process Acesso em: 17 out. 2004. Disponível em: [http://www.sei.cmu.edu/tsp/publications.html]
• ISO/IEC 12207 - ISO/IEC 12207:1995 - Information Technology: Software Life Cycle Processes. ISO, 1995.
• ISO 9000-3. Software Engineering-guidelines for the application of ISO 9001:2000 to software: working draft. WD4 ISO/IEC JTC-1 /SC7/WG18 N48; 2001.
• ISO/IEC TR 15504. Parts 1-9. Information Technology Software Process.1998.
• JANISZEWSKI, S.; GEORGE, E. "Integrating PSP, TSP, and Six Sigma". In: Software Quality Process (SQP) References, v. 6, n. 4, 2004. Acesso em: 11 dez. 2004. Disponível em: [http://www.asq.org/psq/references]
• KERZNER, H. Applied Project Management Best Practices on Implementation. John Wiley & Sons, USA, 2000.
• KERZNER, H. Strategic Planning for Project Management using a project management Maturity Model. Nova York: John Wiley & Sons, 2001.
• PATAH, L. A.; CARVALHO, M. M. Estruturas de gerenciamento de projetos e competências em equipes de projetos. In: ENEGEP XXII, Curitiba. Porto Alegre: ABEPRO, p. 1-8, 2002.
• PAULK, M. C.; WEBER, C. V.; CURTIS, B.; CHRISSIS, M. B. (eds). The Capability Maturity Model: Guidelines for Improving the Software Process SEI, Addison-Wesley Longman Inc. 1997.
• PERRENOUD, P. Dix nouvelles compétences pour enseigner Paris: ESF Éditeur, 1999.
• PFLEEGER, S. L. Engenharia de Software: teoria e prática São Paulo: Prentice Hall, 2004.
• PMI, Project Management Institute. "A Guide to the Project Management Body of Knowledge (PMBOK)". Project Management Institute Inc 2000.
• PMI, Project Management Institute. "Organizational Project Management Maturity Model (OPM3)". Project Management Institute Inc 2003.
• PORTER, M. Competitive advantage: creating and sustaining superior performance. New York: Free Press, 1985.
• RABECHINI JR. R. A Estruturação de Competências e Maturidade em Gerenciamento de Projetos Tese de Doutorado. Escola Politécnica da USP. São Paulo, 2003.
• RABECHINI JR. R.; CARVALHO, M. M. Perfil das competências em equipes de projetos In: RAE-eletrônica, v. 2, n. 1, jan-jun 2003. Acesso em: 11 dez. 2004. Disponível em: [http://www.rae.com.br/eletrônica/index.cfm]
• RAY, G.; BARNEY, J.; Muhanna, W. A. Capabilities, business processes, and competitive advantage: choosing the dependent variable in empirical tests of resource-based view. Strategic Management Journal v. 25, n. 1; p. 23-37, 2004.
• ROCHA, A. R. C. MALDONADO, J. C.; WEBER, K. C. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001.
• SALVIANO, C. F. JINO, M; MENDES, M. J. "Towards na ISO/IEC 15504 - Based Process Capability Profile Methodology for Process Improvement (PRO2PI)". In: Proceedings of SPICE 2004: The Fourth International SPICE Conference on Process Assessment and Improvement, Lisbon, Portugal, p. 77-84, April 28-29, 2004.
• STEPHEN, D. From the Capability Maturity Model to the Team Software Process Calgary University, Canadá. 2002. Acesso em: 15 out. 2004. Disponível em: [http://sern.ulcagary.ca/~dave/seng621/PSP_TEAM.htm]
• YIN, R.K. Case Study Research: Design and Methods. Newbury Park, Rev. ed. Sage Publications,1998.

Datas de Publicação

• Publicação nesta coleção
  27 Ago 2008
• Data do Fascículo
  2008

Histórico

• Recebido
  08 Jul 2005
• Aceito
  04 Mar 2008