UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS UNIDADE ACADÊMICA DE EDUCAÇÃO CONTINUADA PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO DA TECNOLOGIA DA INFORMAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS UNIDADE ACADÊMICA DE EDUCAÇÃO CONTINUADA PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO DA TECNOLOGIA DA INFORMAÇÃO ANTONIO VICENTE KLEIN A INFLUÊNCIA DA GERÊNCIA DE REQUISITOS NA RETENÇÃO DO CONHECIMENTO NAS EMPRESAS DESENVOLVEDORAS DE SOFTWARE São Leopoldo 2007

2 ANTONIO VICENTE KLEIN A INFLUÊNCIA DA GERÊNCIA DE REQUISITOS NA RETENÇÃO DO CONHECIMENTO NAS EMPRESAS DESENVOLVEDORAS DE SOFTWARE Trabalho de conclusão de curso apresentado como requisito parcial para a obtenção do título de Especialista em Administração da Tecnologia da Informação pela Universidade do Vale do Rio dos Sinos (Unisinos). Orientador: Prof. Dr. Cláudio Reis Gonçalo São Leopoldo 2007

3 RESUMO O tema da retenção do conhecimento tem ocupado com freqüência os executivos e profissionais das empresas de desenvolvimento de software. E esta preocupação se intensifica toda vez que algum importante profissional muda de empresa, levando consigo todo o conhecimento adquirido durante sua permanência na empresa. Este trabalho procura mostrar como a adoção da gerência de requisitos pode contribuir para que a empresa se aproprie do conhecimento que, muitas vezes por falta de um processo organizado e por falta de hábito para documentação, está na mente dos profissionais ou está codificado e escondido dentro do códigofonte dos seus programas. Este trabalho se baseou em uma pesquisa realizada com 19 empresas desenvolvedoras de software estabelecidas em Porto Alegre e em sua Região Metropolitana onde se buscou identificar o modelo de processo de desenvolvimento adotado para a qualidade do software e a profundidade da retenção do conhecimento. Palavras-chave: Conhecimento. Requisito. Qualidade de Software. Modelo CMMI. Modelo MPS.BR.

4 LISTA DE QUADROS Quadro 1: processo de formação do conhecimento Quadro 2: níveis de maturidade do processo segundo o CMMI Quadro 3: áreas de processo dos níveis de maturidade segundo o CMMI Quadro 4: áreas de processo dos níveis de maturidade segundo o MPS.BR Quadro 5: empresas de acordo com seu porte Quadro 6: empresas de acordo com o domínio do seu software Quadro 7: empresas de acordo com seu ramo de atividade Quadro 8: empresas por modelo de qualidade de software Quadro 9: empresas por elementos de resposta Quadro 10: atuação dos elementos na empresa Quadro 11: formação acadêmica dos elementos Quadro 12: experiência dos elementos em projetos de melhoria de qualidade de software Quadro 13: respostas quanto à gerência de requisitos Quadro 14: respostas quanto à formalização do aceite dos requisitos Quadro 15: respostas quanto à especificação dos projetos Quadro 16: respostas quanto ao uso da metodologia Quadro 17: respostas quanto à base de conhecimento Quadro 18: respostas quanto aos benefícios adicionais Quadro 19: respostas quanto à especificação dos projetos por grupo funcional Quadro 20: respostas quanto ao uso da metodologia por grupo funcional Quadro 21: respostas quanto à base de conhecimento por grupo funcional Quadro 22: homogeneidade das respostas quanto ao método de trabalho Quadro 23: homogeneidade das respostas quanto à base de conhecimento

5 LISTA DE ABREVIATURAS ABNT Associação Brasileira de Normas Técnicas BID Banco Interamericano de Desenvolvimento CMM Capability Maturity Model CMMI - Capability Maturity Model Integration FINEP Financiadora de Estudos e Projetos IEC International Eletrotechnical Comission ISO - International Organization for Standardization MPS.BR Melhoria do Processo do Software Brasileiro SEI - Software Engineering Institute of Carnegie Mellon University Pittsburg (USA) SOFTEX Associação para a Promoção de Excelência do Software Brasileiro

6 SUMÁRIO 1. INTRODUÇÃO CONCEITUAÇÃO DO CONHECIMENTO Dado Informação Conhecimento Ativos Intangíveis OS MODELOS CMMI E MPS.BR O Modelo CMMI O Modelo MPS.BR A Gerência de Requisitos METODOLOGIA DE PESQUISA Natureza da Pesquisa Instrumento de Pesquisa As Empresas Pesquisadas Os Elementos Participantes Análise da Pesquisa Análise por modelo de referência Quanto ao levantamento de requisitos Quanto à aceitação dos requisitos Quanto à transformação dos requisitos em especificação Quanto ao uso de metodologia Quanto à base de conhecimento Quanto aos benefícios adicionais Análise por grupo funcional Análise das empresas representativas Análise dos relatos livres CONCLUSÕES CONSIDERAÇÕES ADICIONAIS REFERÊNCIAS ANEXOS... 55

7 7 INTRODUÇÃO A rapidez com que a Tecnologia da Informação evolui e a necessidade das empresas que fazem da Tecnologia da Informação o seu negócio acompanhar essa evolução torna o ambiente extremamente competitivo. Essa evolução constante e essa competição exigem dessas empresas a capacidade de oferecer produtos e serviços de alta qualidade tanto técnica quanto funcional. Acompanhar a evolução tecnológica por si só já é um trabalho árduo que exige capacidade de investimento e pessoal qualificado onde o tempo dado a essas empresas para absorver essa evolução é cada vez menor. Essa evolução ajuda a tornar o ambiente extremamente competitivo e a busca pela melhoria da qualidade de software é uma necessidade constante. Para obter a melhoria da qualidade as empresas desenvolvedoras de software têm tido uma crescente motivação à melhoria dos seus processos de produção com a incorporação das melhores práticas mundiais preconizadas pelos modelos consagrados. Uma das preocupações iniciais dos modelos de qualidade está na capacidade das empresas em gerenciar corretamente os requisitos técnicos e funcionais dos seus produtos de software. Isso é emblemático uma vez que uma das grandes preocupações das empresas desenvolvedoras de software, e das menores de forma mais enfática, está na documentação, ou na falta da documentação, dos seus projetos de software. Garcia (2006) relata que para o Quality Assurance Institute, dos EUA, 70% dos problemas de sistemas são de especificação, ou da falta de especificação, pois apenas 60% das informações formais e informais estão documentadas. Para Hammer (2002, p. 122) os desenvolvedores de software geralmente são pessoas talentosas, mas que não mostram nenhum interesse por disciplina ou normas. Geralmente consideram que seu trabalho é algo artístico e criativo, em vez de algo sujeito a procedimentos de engenharia. A falta de recursos, a falta de um modelo apropriado ou, muito comumente, a falta de hábito e os aspectos culturais como os citados por Hammer (2002), fazem com que o conhecimento dos softwares por elas desenvolvidos não esteja documentado nem disseminado. Conseqüentemente, o conhecimento não está disponível todos para aqueles que dele venham a necessitar durante a vida útil do produto de software. Este conhecimento está somente na mente daqueles que o criaram e muitas vezes é necessário abrir o código-fonte para descobrir o que determinado programa faz e como o faz. O conhecimento é de poucos e não está disponível para a empresa.

8 8 As empresas que atuam dessa forma correm sérios riscos de perder sua especialidade estratégica com a eventual perda daqueles funcionários que detêm esse conhecimento, que detêm o monopólio do conhecimento. Podemos caracterizar como monopólio quando uma única pessoa possui o conhecimento. E quando há monopólio de conhecimento o efeito é similar ao monopólio do mercado de produtos e serviços: o conhecimento terá um preço alto porque não existe concorrência (DAVENPORT e PRUSAK, 1998). Com a gestão do conhecimento, há a probabilidade de que projetos se sustentem na ausência de um ou mais indivíduos específicos, pois os projetos passam a ser uma iniciativa da organização, não um projeto individual (DAVENPORT e PRUSAK, 1998). Nas empresas prestadoras de serviço os bens ativos mais valiosos são os bens intangíveis identificados pelo conhecimento que a empresa tem em suas especialidades. O valor da maioria dos produtos e serviços depende principalmente como os fatores intangíveis baseados nos conhecimento como know-how tecnológico, projeto do produto, apresentação de marketing, compreensão do cliente, criatividade pessoal e inovação podem ser desenvolvidos (NONAKA e TAKEUCHI,1997). Os modelos consagrados para a melhoria da qualidade do software dão uma ênfase especial à gerência de requisitos nas primeiras fases de sua implementação, pois ela serve de base e sustentação para as fases posteriores numa aposta clara aos benefícios da codificação e da explicitação do conhecimento. Davenport e Prusak (1998, p.106) compartilham dessa idéia quando afirmam que codificar o conhecimento é fundamental para incrementar seu valor na organização. A codificação dá permanência para o conhecimento que, de outra forma, existiria apenas na mente das pessoas. Este trabalho pretende apurar se esses modelos podem influenciar na retenção de conhecimento, se eles podem contribuir para a permanência do conhecimento através dos seus processos de documentação dos requisitos de software, da aceitação formal desses requisitos pelos clientes e da transformação desses requisitos em especificações funcionais dos projetos de software. Este trabalho se estrutura da seguinte forma: após esta introdução, na seção 2 é apresentada uma breve conceituação de gestão de conhecimento. Na seção 3 são apresentados

9 9 os modelos CMMI e MPS.BR com ênfase para a Gerência de Requisitos. Na seção 4 é apresentado o perfil das empresas pesquisadas. Na seção 5 é apresentada a pesquisa, na seção 6 são apresentadas as conclusões da pesquisa e na seção 7 são apresentadas as considerações adicionais. Finalmente, o Anexo A apresenta o questionário utilizado como instrumento de coleta de dados para a pesquisa.

10 10 2 CONCEITUAÇÃO DO CONHECIMENTO Para Campos (2004, p.51), o conhecimento está se tornando o principal fator de sobrevivência dos indivíduos, das empresas e da sociedade. Se tomarmos essa afirmação como uma verdade, gerenciar o conhecimento passa a se ser essencial para a sobrevivência de cada um dos atores que compõe esse cenário, ou seja, para os indivíduos em seu crescimento e realização pessoal, para as empresas no seu papel de fomentadoras do crescimento e da sociedade como conseqüência. O interesse pelo conhecimento aumentou a partir da constatação de que só sobrevivem as organizações que aprendem continuamente e através do conhecimento é possível descobrir como as organizações devem atuar hoje para melhorar seus produtos e serviços amanhã (DAVENPORT e PRUSAK, 1998). A gestão do conhecimento fomenta a aquisição do conhecimento, a distribuição do conhecimento e, essencialmente, a utilização do conhecimento. Kruglianskas e Terra (2003, p. 112) a definiram como sendo todo o esforço sistemático realizado pela organização para identificar, capturar, compartilhar, obter, criar, organizar, utilizar, melhorar, reter e medir seu conhecimento. É uma estratégia que transforma ativos intangíveis informação armazenada e talentos dos seus membros em produtividade, valor e aumento de competitividade. Ensina corporações, de gerentes a empregados, a como produzir e otimizar habilidades como uma entidade coletiva. Falar sobre gestão do conhecimento é falar sobre algo relativamente novo e deve ser abordado com cuidado. Em algumas situações os termos mais comuns são usados como sinônimos e isso provoca uma certa confusão no entendimento e equívocos no tratamento. A maior confusão ainda é feita quando se propõe a definir o que é dado, o que é informação e o que é conhecimento. Mas o que é, afinal, conhecimento? Conhecimento não é dado, nem informação embora esteja relacionado a ambos. As diferenças entre esses termos são bastante sutis e conhecer suas diferenças e seus significados é essencial para uma boa gestão de conhecimento.

11 Dado Para Davenport e Prusak (1998, p.2) dados são um conjunto de fatos distintos e objetivos, relativos a eventos [...] e são utilitariamente descritos como registros estruturados de transações. Assim, dados são os registros das transações de uma organização organizados em sistemas de informação simples ou complexos que analisados isoladamente são desprovidos de um significado. Os dados do registro de operação de compra de uma loja de artigos de vestuário, por exemplo, podem revelar quando foi feita a compra, que artigos foram comprados, quanto se gastou, como se pagou. Mas não revelam porque o comprador preferiu esta loja e não aquela, porque ele optou por este artigo e não aquele, se ele foi bem atendido, se a loja está bem administrada, se está gerando lucro. Davenport e Prusak (1998, p.2) relatam que para Peter Drucker informações são dados dotados de relevância e propósito o que os levou a deduzir que dados, por si só, tem pouca relevância ou propósito. Os dados das organizações lançados em modernos sistemas de informação ou em simples fichas de anotações são necessários e alguns setores dependem fortemente deles. Mas somente juntar dados não é suficiente para garantir o sucesso da organização. Dados em excesso podem dificultar a identificação e extração de algum significado que realmente importe. É essencial entender que dados são desprovidos de um significado inerente. Dados apenas descrevem uma parte do que aconteceu; não fornecem julgamento nem interpretação e nem qualquer base sustentável para a tomada de decisão, não podem dizer o que fazer. Porém, os dados são importantes porque são matéria-prima essencial para a criação da informação (DAVENPORT e PRUSAK, 1998). 2.2 Informação Quando falamos ou escrevemos, nos valemos da linguagem para transmitir nossos conhecimentos para outras pessoas. Podemos chamar esse tipo de comunicação de informação associando a palavra informação tanto aos fatos quanto à comunicação entre eles. Sob essa

12 12 ótica, a informação é ideal para transmitir o conhecimento explícito, pois é rápida, segura e independente da sua origem. Na era da tecnologia da informação essas três características adquirem importância vital, pois o computador foi criado para lidar com informações (SVEIBY, 1998). Sveiby (1998) também chama a atenção para a confusão que pode haver entre conhecimento e informação notadamente no setor da tecnologia da informação, onde podem até ser usados como sinônimos. Assim como Sveiby, também Davenport e Prusak (1998, p. 4) entendem informação como uma mensagem (comunicação) passada na forma de um documento ou de uma comunicação audiovisual. E para eles, essencialmente, a informação tem por finalidade mudar o modo como o destinatário vê algo, exercer algum impacto sobre seu julgamento e comportamento. Ela deve informar; são dados que fazem a diferença. É importante perceber que quem decide se uma mensagem contém informação ou não, se ela realmente informa é o receptor e não o emissor. O receptor dirá se aquela mensagem está dotada da relevância e propósito segundo a definição de Peter Drucker citada anteriormente. Ainda de acordo com Davenport e Prusak (1998), de forma diferente do dado, a informação tem significado e ela própria tem uma forma: ela está organizada para alguma finalidade. Um dado transforma-se em informação quando o seu criador lhes acrescenta significado e isso pode ocorrer através de vários métodos: Contextualização: sabemos qual a finalidade dos dados coletados. Categorização: conhecemos as unidades de análise ou os componentes essenciais dos dados. Cálculo: os dados podem ser analisados matemática ou estatisticamente. Correção: os erros são eliminados dos dados. Condensação: os dados podem ser resumidos para uma forma mais concisa.

13 Conhecimento O estudo do conhecimento e seus fundamentos filosóficos vêm ocupando o pensamento do homem desde muito antes de Cristo. A resposta à pergunta o que é conhecimento orienta a história da filosofia desde o período grego. Platão definiu o conhecimento como sendo uma crença verdadeira justificada, definição que ainda é aceita de um modo geral pelos filósofos ocidentais (NONAKA e TAKEUCHI, 1997). Segundo Neto apud Grayling (2006) esta definição de Platão é uma definição padrão e para Nonaka e Takeuchi (1997) é uma definição tradicional do conhecimento. Davenport e Prusak (1998, p. 6) definem conhecimento como sendo uma mistura fluida de experiência condensada, valores, informação contextual e insight experimentado, a qual proporciona uma estrutura para avaliação e incorporação de novas experiências e informações. Ele tem origem e é aplicado na mente dos conhecedores. Nas organizações, ele costuma estar embutido não só em documentos ou repositórios, mas também em rotinas, processos, práticas e normas organizacionais. Essa definição nos mostra que o conhecimento não é puro nem simples. O conhecimento é uma combinação de vários elementos e depende da interação das pessoas, de como elas interpretam os conceitos sobre algo e como agem. Sveiby (1998) também compartilha dessa idéia quando define conhecimento como uma capacidade de agir e diz que a definição pode ter mais de uma dezena de significados, mas o que define mesmo é o contexto em que o termo é empregado; o conhecimento não pode ser destacado de seu contexto. Logo, ele não é puro, nem simples, mas uma combinação de acordo com o contexto em que ele é utilizado e seu conceito é compreendido pela maneira como é utilizado. Segundo a definição de Davenport e Prusak (1998), o conhecimento deriva da informação da mesma forma que a informação deriva de dados. Ela, porém depende totalmente da ação das pessoas e ocorre através de diversas ações: Comparação: de que forma as informações relativas a esta situação se comparam a outras situações conhecidas? Conseqüências: que implicações estas informações trazem para as decisões e tomadas de ação?

14 14 Conexões: quais as relações deste novo conhecimento com o conhecimento já acumulado? Conversação: o que as outras pessoas pensam desta informação? Como podemos observar a geração do conhecimento ocorre através das ações das pessoas e das ações entre elas. O conhecimento é obtido de indivíduos, de grupos de conhecedores ou até de rotinas da organização e é entregue através de meios estruturados, como livros, documentos, manuais e de contatos pessoa a pessoa. O quadro 1 adaptado de Kruglianskas e Terra (2003), sintetiza, a partir das definições de Davenport e Prusak (1998), as principais distinções entre dados, informações e conhecimento e mostra resumidamente como dados podem ser transformados em informação e como informações podem ser transformadas em conhecimento. Pensar sobre conhecimento não chega a ser uma novidade. Sócrates e os demais pensadores gregos já o faziam na sua época. A novidade é passar a enxergá-lo como ativo corporativo ou, mais explicitamente, um ativo intangível, provedor de vantagem competitiva sustentável em alguns casos talvez o único provedor, entender que é necessário gerenciálo e cuidar dele com o mesmo zelo dedicado aos ativos tangíveis com todos os desafios necessários para gerenciá-lo (KRUGLIANSKAS e TERRA (2003). E, outra novidade segundo Davenport e Prusak (1998), é que hoje em dia, a necessidade de se extrair o máximo valor do conhecimento organizacional é muito maior que no passado.

15 15 Dados Conjunto de fatos distintos e objetivos, relativos a eventos [...] e são utilitariamente descritos como registros estruturados de transações. Informação Uma mensagem que tem por finalidade mudar o modo como o destinatário vê algo, exercer algum impacto sobre seu julgamento e comportamento. Ela deve informar; são dados que fazem a diferença. Conhecimento É uma mistura fluida de experiência condensada, valores, informação contextual e insight experimentado, a qual proporciona uma estrutura para avaliação e para incorporação de novas experiências e informações. Ele tem origem e é aplicado na mente dos conhecedores. Nas organizações ele costuma estar embutido não só em documentos ou repositórios, mas também em rotinas, processos, práticas e normas organizacionais. A transformação de dados em informação ocorre por meio de: Contextualização: sabemos qual a finalidade dos dados coletados. Categorização: conhecemos as unidades de análise ou os componentes essenciais dos dados. Cálculo: os dados podem ser analisados matemática ou estatisticamente. Correção: os erros são eliminados dos dados. Condensação: os dados podem ser resumidos para uma forma mais concisa. A transformação da informação em conhecimento ocorre por meio de: Comparação: de que forma as informações relativas a esta situação se comparam a outras situações conhecidas? Conseqüências: que implicações estas informações trazem para as decisões e tomadas de ação? Conexões: quais as relações deste novo conhecimento com o conhecimento já acumulado? Conversação: o que as outras pessoas pensam desta informação? Quadro 1: processo de formação do conhecimento Fonte: Baseado em Kruglianskas e Terra (2003) 2.4 Ativos Intangíveis Talvez mais importante que o seu conceito ou qual a forma utilizada para o seu gerenciamento, é reconhecer que o ativo é um bem valioso para as organizações.

16 16 Sveby (1998) define ativos intangíveis como sendo ativos que não estão contabilizados no balanço patrimonial das empresas. Para ele, como os ativos intangíveis não são negociados rotineiramente, seu valor somente aparece, de forma indireta, no mercado de ações ou quando uma empresa troca de mãos. Os ativos intangíveis podem ser classificados em três tipos distintos, de acordo com Sveiby (1998): (i) competência individual caracterizada pela escolaridade, experiência e capacidade de saber agir dos indivíduos; (ii) estrutura interna caracterizada por patentes, softwares, processos, conceitos, modelos, sistemas legais, pesquisa e desenvolvimento, cultura, manuais; (iii) estrutura externa caracterizada pelas marcas, relações com clientes e fornecedores, reputação e imagem da organização. Nota-se que Sveiby (1998) enfatiza, através de sua classificação, a importância da atuação dos indivíduos. Para ele, a competência do individuo, na sua capacidade de saber agir, é o fator gerador dos ativos tangíveis e intangíveis. E, restringindo ao contexto deste trabalho, o autor também reconhece a importância dos processos, dos modelos e dos manuais. Em organizações do conhecimento, existem poucos equipamentos além de funcionários. Como somente as pessoas podem agir, os funcionários passam a ser tanto mentores desse equipamento quanto o próprio equipamento (SVEIBY, 1998). Reter esses funcionários nem sempre é possível por diversas razões. Assim, a necessidade de se adotar mecanismos para reter esse conhecimento fica aqui mais uma vez evidenciada. Organizações de tecnologia como a Microsoft, a Sun e outras onde seu valor de mercado é muitas vezes maior que seu valor contábil, registrado nos balanços podem ser chamadas de organizações do conhecimento. Seus ativos intangíveis são muito mais valiosos que seus ativos tangíveis. Seus funcionários são altamente qualificados e seu trabalho consiste, em grande parte, em converter informação em conhecimento. Ao contrário dos bens e serviços, o conhecimento cresce quando é compartilhado (SVEIBY, 1998). Transformar essa teoria em prática, através da gestão do conhecimento para adquirir ou criar conhecimento, garanti-lo como um bem da organização, e não do indivíduo, através de mecanismos de retenção; disseminá-lo para a organização propicia a geração de ainda mais conhecimento e, por conseqüência, mais valor para a organização. Kruglianskas e Terra (2003) reconhecem que nas organizações da economia digital os ativos intangíveis ganharam valor maior que os ativos tangíveis e aceitam a premissa de que o

17 17 conhecimento é o maior impulsionador desses ativos intangíveis. Para também eles, gerenciar o conhecimento torna-se essencial para alavancar e sustentar o crescimento das organizações.

18 18 3 OS MODELOS CMMI E MPS.BR Na busca incansável para aperfeiçoar o desenvolvimento de software e obter produtos com níveis desejáveis de qualidade as empresas têm lançado mão de diversas estratégias e técnicas gerenciais. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Sommerville (2004, p. 477) contribui com essa abordagem ao afirmar que a melhoria do processo significa compreender os processos existentes e modificá-los, a fim de melhorar a qualidade do produto. Neste contexto de melhoria de processo para obtenção da qualidade surgiram os modelos de referência para melhoria dos processos de desenvolvimento e aquisição de software como o CMMI e MPS.BR entre outros. 3.1 O Modelo CMMI O CMMI é um modelo de referência para a melhoria de processos, bem como para avaliação da capacidade e maturidade dos processos de software concebido pelo SEI da Universidade Carnegie Mellon Pittsburg (EUA). O CMMI é uma evolução do modelo CMM também desenvolvido pelo SEI. O CMMI está fundamentado em conceitos de qualidade total e gestão de mudança e seu objetivo é prover um guia para melhorar os processos organizacionais e sua habilidade em gerenciar o desenvolvimento, aquisição e manutenção dos produtos e serviços melhorando a eficiência, o retorno do investimento e a efetividade através da utilização de um modelo que integra disciplinas como engenharia de sistema e engenharia de software que são inseparáveis no desenvolvimento de um sistema. O CMMI organiza as práticas que já foram provadas como sendo efetivas, em uma estrutura que ajuda a organização a estabelecer prioridades para a melhoria e fornece um guia para a implementação destas melhorias.

19 19 O CMMI permite duas representações: Contínua: todas as áreas de processo podem ser implementadas paralelamente, sem seguir a divisão dos níveis de maturidade. Busca priorizar e concentrar esforços para aquelas melhorias que representam maior impacto nos objetivos de negócio da organização e que minimizam as áreas de riscos; Estágios: As áreas de processo estão agrupadas por níveis de maturidade e considera a sucessão de estágios bem definidos (níveis 1 a 5), que dão o caminho para alcançar processos estáveis, maduros e consistentes, alinhados com os objetivos de negócio da empresa. Na representação do CMMI por estágios, existem cinco níveis de maturidade, cada uma constituindo uma camada na formação do alicerce para o processo continuado de melhoria: 1 Inicial, 2 - Gerenciado, 3 - Definido, 4 Quantitativamente Gerenciado e 5 De Otimização. No quadro 2 estão representados os cinco níveis de maturidade e a evolução de um nível para outro. Melhoria contínua 5 De Otimização Processo quantitativamente previsível 4 Quantitativamente Gerenciado Processo padronizado, consistente 3 Definido Processo disciplinado 2 Gerenciado 1 Inicial Quadro 2: níveis de maturidade do processo segundo o CMMI Fonte: Herbert (2006)

20 20 Os níveis de maturidade são formados por um conjunto pré-definido de áreas de processo e são medidos verificando se os objetivos específicos e genéricos que se aplicam a cada um desses conjuntos de áreas de processo foram atingidos. Área de processo é um agrupamento de práticas relacionadas em determinada área que, quando executadas coletivamente, satisfazem um conjunto de metas consideradas importantes para a promoção de melhorias na área em questão. No quadro 3 são De Otimização Nível 5 Quantitativamente Gerenciado Nível 4 Definido Nível 3 Gerenciado Nível 2 Áreas de Processo - Análise e Resolução Causal - Inovação e Implantação Organizacional - Performance do Processo Organizacional - Gerenciamento Quantitativo de Projetos - Desenvolvimento de Requisitos - Solução Técnica - Integração de Produto - Verificação - Validação - Foco no Processo Organizacional - Definição do Processo Organizacional - Treinamento Organizacional - Gerenciamento Integrado de Projetos - Gerenciamento de Riscos - Integração de Equipe - Gerenciamento Integrado de Fornecedores - Análise de Decisão e Resolução - Ambiente Organizacional para Integração - Gerenciamento de Requisitos - Planejamento de Projeto - Monitoramento e Controle do Projeto - Gerenciamento de Contratos com Fornecedores - Medição e Análise - Garantia da Qualidade de Processo e de Produto - Gerência de Configuração Quadro 3: áreas de processo dos níveis de maturidade segundo o CMMI Fonte: Herbert (2006) OBS.: para o nível 1 inicial, o CMMI não define nenhuma área de processo assumindo a forma da organização para gerenciar seus processos.

21 O Modelo MPS.BR O MPS.BR, assim como o CMMI, é um modelo de referência que visa definir e aprimorar um modelo de melhoria e avaliação de processo de software. Foi desenvolvido pela SOFTEX com o apoio do Ministério da Ciência e Tecnologia, da FINEP e do BID. O MPS.BR surgiu como uma alternativa, embora não exclusivamente, para as micro, pequenas e médias empresas de software brasileiras, de forma a atender as suas necessidades de negócio e busca ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. O MPS.BR tem como referência para a construção e aprimoramento a Norma Internacional ISO/IEC 12207, a Norma Internacional ISO/IEC e a CMMI-SE/SW¹ e se propõe compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Ele se baseia nos conceitos de maturidade e capacidade de processo para a avaliação de melhoria de qualidade e produtividade de produtos de produtos de software e serviços correlatos. O MPS.BR define oito níveis de maturidade que são uma combinação entre processos e sua capacidade onde, de forma similar ao CMMI, onde cada nível estabelece um patamar de evolução de processo, caracterizando estágios de melhoria da implementação de processos na organização. Os oito níveis de maturidade são G -Parcialmente Gerenciado, F Gerenciado, E - Parcialmente Definido, D - Largamente Definido, C Definido, B - Gerenciado Quantitativamente e A - Em Otimização. O nível A é o nível mais alto e equivale ao nível 5 do CMMI. De forma similar ao CMMI, os níveis de maturidade são formados por um conjunto prédefinido de processos e são medidos verificando se os propósitos e resultados esperados de cada um dos processos foram atingidos. Leva em consideração, também, informações adicionais e o grau de refinamento e institucionalização com que o processo é executado na organização. ¹ O CMMI-SE/SW é a disciplina para engenharia de sistemas e de software do CMMI.

22 22 No quadro 4 são apresentados os processos considerados pelo MPS.BR e o seu enquadramento de acordo com o respectivo nível de maturidade. Nível Áreas de Processo Em Otimização - Implantação de Invocações na Organização Nível A - Análise de Causas e Resolução Gerenciado - Desempenho do Processo Organizacional Quantitativamente - Gerência Quantitativa do Projeto Nível B Definido - Análise de Decisão e Resolução Nível C - Gerência de Riscos - Desenvolvimento de Requisitos Largamente Definido - Solução Técnica Nível D - Integração de Produto - Verificação - Validação Parcialmente Definido - Treinamento Nível E - Definição do Processo Organizacional - Avaliação e Melhoria do Processo Organizacional - Adaptação do Processo para Gerência do Projeto - Medição Gerenciado - Gerência de Configuração Nível F - Aquisição - Garantia da Qualidade Parcialmente Gerenciado - Gerência de Requisitos Nível G - Gerência do Projeto Quadro 4: áreas de processo dos níveis de maturidade segundo o MPS.BR Fonte: Guia Geral do MPS.BR disponível em acessado em novembro/2006. OBS.: o MPS.BR define processos para o primeiro nível de maturidade, diferentemente do CMMI. 3.3 Gerência de Requisitos Antes de definir gerência de requisitos, cabe definir o que é requisito. De acordo com o Dicionário da Língua Portuguesa, requisito é a condição necessária a um determinado fim, à realização de um objetivo. Para a Engenharia de Software, de uma maneira geral, requisitos são uma condição ou necessidade de um usuário para resolver um problema ou alcançar um

23 23 objetivo. Requisitos podem ser definidos como sendo as necessidades expressadas pelos usuários (TONSIG, 2003). A essa definição podemos ainda acrescentar que os requisitos condicionam a qualidade do software (LEITE, 2001). Unindo esses conceitos às especificações dos modelos CMMI e MPS.BR podemos entender requisitos como sendo as necessidades, os desejos e as expectativas das partes interessadas que identificados, analisados, detalhados e entendidos são formalmente documentados (registrados) e formalmente aceitos. Requisitos são a base a partir da qual a qualidade dos produtos de software é medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. A partir desses conceitos, entender o que se deseja construir antes de começar a fazê-lo passa a ser fundamental para obtenção da qualidade dos produtos. Assim como Leite condiciona a qualidade do software aos requisitos, também para a norma NBR ISO/IEC 12207¹ os requisitos são essenciais para qualidade quando determina, em seu processo de garantia de qualidade, que os produtos de software estejam em conformidade com seus requisitos especificados. Os requisitos podem ser classificados como requisitos funcionais e requisitos não funcionais. O primeiro está diretamente ligado à funcionalidade do software, aquilo que os clientes ou usuários querem ou precisam que o software ofereça enquanto o segundo reflete os requisitos que expressam restrições que o software deve atender e a qualidade que o software deve ter (LEITE, 2001; TONSIG, 2003; SOMMERVILLE, 2004). Para Leite (2001), abordar qualidade como requisitos não funcionais integra aspectos de qualidade na definição do próprio software. E, assim, a tarefa de gerenciar requisitos passa a cuidar não só de aspectos funcionais, como também de aspectos de qualidade, passa a ser um processo de gerência de qualidade, enfim. O MPS.BR denomina o processo de Gerência de Requisitos e o CMMI o denomina de Gerenciamento de Requisitos. É somente uma pequena diferença de nomenclatura, pois ambos exercem a mesma função e a definição do propósito de ambas é idêntica: gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre esses requisitos e os planos de trabalho do projeto (SOFTEX, p.24; CARNEGIE MELLON UINIVERSITY, p.372). ¹ A NBR ISO/IEC é a tradução publicada da ISO/IEC pela ABNT.

24 24 Observa-se que o processo para gerenciar requisitos está definido nos níveis iniciais de maturidade de ambos os modelos. Isso é sintomático, pois gerenciar adequadamente o que se pretende com o produto a ser desenvolvido é fundamental para o alcançar os resultados desejados. Além disso, os requisitos são base de conhecimento para outros processos do desenvolvimento de um produto de software como o Desenvolvimento de Requisitos e a Solução Técnica. Sem o entendimento correto dos requisitos não é possível fazer uma especificação funcional e técnica adequada. De acordo como o MPS.BR, para a exercer uma gerência de requisitos adequadamente de acordo com os modelos e garantir a sua aceitação é necessário: Estabelecer uma comunicação contínua como os fornecedores dos requisitos; Obter o entendimento dos requisitos; Estabelecer uma aceitação formal dos requisitos através de critérios objetivos; Estabelecer e manter o comprometimento com os requisitos; Estabelecer e manter a rastreabilidade entre os requisitos, os planos do projeto e os produtos de trabalho; Identificar e corrigir as inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos; gerenciar as mudanças ao longo do projeto.

25 25 4. METODOLOGIA DE PESQUISA Yin (2001) descreveu um projeto de pesquisa como um plano que conduz o pesquisador através do processo de coletar, analisar e interpretar observações em um modelo lógico de provas que lhe permite fazer inferências relativas às relações causais entre as variáveis sob investigação. Um projeto de pesquisa pode ser conduzido pelo método de estudos de caso, pois estes auxiliam substancialmente a compreender como as organizações e seus indivíduos agem e porque agem dessa forma (YIN, 2001). Guiado por esse argumento de Yin, adotou-se a metodologia de estudo de caso na avaliação do comportamento das empresas em relação aos seus modelos de desenvolvimento de software. O foco principal deste estudo está em demonstrar se é possível reter conhecimento pela adoção da gerência de requisitos e demais processos que a utilizam como insumo. Como foco secundário são avaliados alguns benefícios obtidos indiretamente pela adoção da gerência de requisitos. 4.1 Natureza da Pesquisa A natureza da pesquisa apresentada neste trabalho adota o método de múltiplos casos de estudo (YIN, 2001), pois seus resultados podem avaliados pela análise do grupo de empresas que adotam os modelos CMM/CMMI ou MPS.BR como modelo de referência para seu processo de qualidade de software e pela análise do grupo de empresas que não adotam nenhum destes modelos, ainda que sigam um modelo próprio. Pode-se ainda traçar uma comparação de comportamento entre estes grupos. Os resultados também podem ser avaliados agrupando-se os elementos pela função que exercem na sua empresa e traçar um comparativo entre esses grupos. Dessa forma, as respostas foram agrupadas sob os seguintes grupos:

26 26 GRUPO A: elementos das empresas que adotam o CMMI ou MPS.BR como modelo de referência em seus processos; GRUPO B: elementos das empresas que não adotam os modelos CMMI ou MPS.BR como modelo de referência em seus processos; GRUPO C: elementos que exercem funções de gestão (empresários, gerentes e coordenadores); GRUPO D: elementos que exercem funções operacionais (analistas, programadores e consultores). Algumas empresas que participaram desta pesquisa podem ser analisadas de forma individual, pois designaram mais de um profissional para respondê-la. E, para respondê-la, designaram profissionais de perfil variado e que exercem funções diferentes em suas atividades. Essa análise individual também pode ser caracterizada como de múltiplos casos de estudo. 4.2 Instrumento de Pesquisa O instrumento de pesquisa adotado para a coleta de dados consiste em um questionário com questões baseadas no referencial teórico dos modelos CMMI e MPS.BR. Além disso, o questionário permite que o participante relate casos relevantes ao tema, baseado em sua experiência profissional. Na elaboração do questionário se adotou estratégias de levantamento e de estudo de caso que utilizam questões do tipo quem, o que, onde, quantos, quanto, como e por que e que focalizam acontecimentos contemporâneos (YIN, 2001). Numa pesquisa, quando um número ímpar de categorias (opções de resposta) é usado, a posição intermediária representa uma categoria neutra e pode ter uma influência significativa nas respostas. Porém quando se o pesquisador quiser forçar uma resposta ou acreditar que não há nenhuma resposta neutra ou indiferente, deve ser usada uma escala de classificação com um número par de categorias (MALHOTRA, 2005). O questionário da pesquisa está divido em quatro blocos:

27 27 O Bloco 1 identifica o perfil dos elementos que responderam à pesquisa identificando tempo de experiência, formação acadêmica e função exercida. O Bloco 2 identifica o perfil das empresas identificando a sua localização, o seu porte, o ramo de atividade, seu mercado e o modelo de referência usado em seu processo de desenvolvimento. No Bloco 3 se utilizou a técnica com número par de respostas, pois se acreditou que para várias categorias não havia uma resposta neutra e para outras se pretendeu forçar uma reposta. O Bloco procura identificar o comportamento da empresa em relação ao seu processo de desenvolvimento e uma posição neutra poderia comprometer o resultado da pesquisa. O Bloco 3 está subdivido em seis subconjuntos de questões: as questões 1 a 6 referem-se ao levantamento de requisitos; as questões 7 a 9 referem-se aos mecanismos de aceitação dos requisitos; as questões 10 e 11 referem-se aos mecanismos de especificação de software; as questões 12 e 13 referem ao uso de metodologia; as questões 14, 15 e 18 referem-se à base de conhecimento; as questões 17 e 19 a 21 referem-se aos benefícios adicionais. Vários elementos não responderam a pergunta 16 e outros, quando responderam, o fizerem de maneira incorreta. Por este motivo a questão não será considerada neste estudo. O Bloco 4 é um espaço para relato livre sobre casos em que a existência do registro de requisitos tenham beneficiado a empresa e sobre casos em que a ausência do registro de requisitos tenha prejudicado a empresa. 4.3 As Empresas Pesquisadas A população desta pesquisa consiste em 19 empresas brasileiras de desenvolvimento de software situadas em Porto Alegre, Grande Porto Alegre e Vale dos Sinos, no estado do Rio Grande do Sul. A seleção das empresas contou com a colaboração de gestores de pólos tecnológicos e de profissionais ligados à implementação de modelos de qualidade de software Foram

28 28 selecionadas empresas que adotam processos de qualidade de software utilizando como referência os modelos CMM/CMMI ou MPS.BR e empresas que adotam nenhum destes modelos como referência em seus processos de qualidade de software ou que não adotam nenhum processo formal para qualidade de software. Foram convidadas 23 empresas sendo que o convite foi feito através de convites pessoais, por telefone ou por . Responderam à pesquisa 19 empresas das quais 12 estão sediadas em Porto Alegre, 2 na Grande Porto Alegre e 5 possuem sede no Vale dos Sinos. São empresas que se classificaram como micro, pequenas, médias ou grandes, que possuem uma força de trabalho de profissionais e destes, estão envolvidos diretamente com o desenvolvimento de software. Na classificação das empresas de acordo com a quantidade de profissionais, temos empresas de 3 a 500 profissionais envolvidos com desenvolvimento de software conforme ilustrado no quadro 5. Classificação Empresas Profissionais (média) Profissionais (total) Micro 3 3,33 10 Pequena 8 22, Media 6 136, Grande Total Quadro 5: empresas de acordo com seu porte Fonte: elaborado pelo autor O domínio do software desenvolvido pelas empresas pesquisadas é bastante heterogêneo e as empresas, em sua maioria, atua em mais de um domínio. O quadro 6 ilustra a classificação das empresas pesquisadas de acordo com o domínio do software por elas desenvolvido.

29 29 Domínio do software Quantidade Administração privada 9 Administração pública 7 Agronegócio 3 Bancário 9 Comércio 10 Direito/Jurídico 3 Educação 4 Energia 4 Construção Civil 1 Entretenimento 2 Financeiro 9 Indústria 8 Meio Ambiente 2 Qualidade e Produtividade 3 Saúde 8 Serviços 9 Telecomunicações 4 Transportes 5 Outros 2 Quadro 6: empresas de acordo com o domínio do seu software Fonte: elaborado pelo autor. O ramo de atividade das empresas pesquisadas também é bastante heterogêneo e a maioria das empresas atua em mais de ramos de atividade de desenvolvimento de software. O quadro 7 ilustra a classificação das empresas pesquisadas de acordo com seu ramo de atividade. Ramo de atividade Quantidade Desenvolvimento de software-pacote para comercialização 14 Desenvolvimento de software sob encomenda 13 Desenvolvimento de customização para ERP 6 Desenvolvimento de software embarcado 3 Desenvolvimento de software para Internet 10 Quadro 7: empresas de acordo com seu ramo de atividade Fonte: elaborado pelo autor Quanto ao modelo de referência para seus processos de qualidade de software, algumas empresas pesquisadas adotam mais de um modelo de referência e duas delas também adotam a

30 30 norma ISO. Porém a norma ISO é adotada em conjunto com os modelos CMM/CMMI e MPS.BR e não de forma exclusiva sendo, por isso, não considerada neste estudo. Há um significativo número de empresas que adotam nenhum desses modelos ou não possui nenhum processo padrão de qualidade software. O CMMI é uma evolução do modelo CMM também desenvolvido pelo SEI e, para efeitos desta pesquisa, as empresas que adotam um modelo ou outro serão enquadradas na mesma classificação. O quadro 8 ilustra a classificação das empresas de acordo com seu modelo de referência de qualidade de software. Modelo de qualidade de software Quantidade CMM/CMMI 6 MPS.BR 7 ISO 2 Modelo próprio ou nenhum 9 Quadro 8: empresas por modelo de qualidade de software Fonte: elaborado pelo autor Observações: algumas empresas utilizam mais de um modelo 4.4 Os Elementos Participantes O elemento do qual foram coletados os dados desta pesquisa é o profissional envolvido em processos de desenvolvimento de software. Este profissional pode ser um gerente de equipes de desenvolvimento, gerente de projeto, gerente de qualidade, analista de sistemas e programadores entre outros. Responderam a esta pesquisa 52 profissionais pertencentes ao quadro de profissionais das 19 empresas pesquisadas, dos quais 29 atuam em empresas que adotam o CMM/CMMI ou MPS.BR como método de referência para a qualidade de seus processos de software e 23 atuam em empresas que adotam nenhum destes modelos como referência em seus processos de qualidade de software.

31 31 Várias empresas atenderam à solicitação para que mais de um elemento respondesse à pesquisa e houvesse, dessa forma, variação de perfil na atuação. O objetivo era colher diferentes visões sobre o tema. O quadro 9 ilustra a quantidade de elementos de resposta por empresa. Elementos de resposta Quantidade de empresas Quantidade de Elementos Com 1 elemento 8 8 Com 2 elementos 3 6 Com 3 elementos 1 3 Com 4 elementos 3 12 Mais de 5 elementos 4 23 Total Quadro 9: empresas por elementos de resposta Fonte: elaborado pelo autor A atuação dos elementos participantes da pesquisa nas empresas vai de empresários a gerentes, analistas e programadores. A presença de empresários se justifica, pois há empresas pequenas e micro-empresas no universo pesquisado e estes atuam também, ora como gerentes de projetos, ora como analistas de sistemas. O quadro 10 ilustra a atuação na empresa. Por esse quadro podemos observar há 10 empresários, 21 elementos exercem funções gerenciais ou de coordenação de equipes e 30 exercem funções operacionais. Atuação na empresa Quantidade Empresário 10 Gerente de informática 4 Gerente de qualidade 4 Gerente de projeto 5 Gerente de desenvolvimento 3 Gerente de produto 2 Coordenador de desenvolvimento 3 Analista de Sistemas 14 Analista de Qualidade de software 1 Programador 14 Consultor de TI 1 Quadro 10: atuação dos elementos na empresa Fonte: elaborado pelo autor Observações: alguns elementos exercem mais de uma função.

32 32 A grande maioria dos elementos possui formação acadêmica em áreas relacionadas com a informática. Um dos elementos possui mestrado, 13 possuem especialização e 9 possuem MBA. O quadro 11 ilustra a formação acadêmica dos elementos. Formação acadêmica Quantidade Análise de Sistemas 15 Engenharia de Software 0 Ciência da Computação 15 Tecnólogo em Processamento de Dados 14 Outras áreas 6 Quadro 11: formação acadêmica dos elementos Fonte: elaborado pelo autor A experiência dos elementos é evidenciada pelo tempo de atuação em projetos de software e é bastante significativa, visto que 36 deles possuem tempo de atuação superior a 5 anos, 13 possuem tempo de atuação entre 2 e 5 anos e apenas 3 atuam por menos de 2 anos. Na avaliação da participação em projetos de melhoria da qualidade de software, 17 ainda não participaram de projetos dessa natureza e, dos 35 que já participam (participaram), 10 atuam (atuaram) em tempo integral e 25 em tempo parcial. Dos 35 que atuam (atuaram) em projetos de melhoria de qualidade de software, 5 atuam (atuaram) há mais de 5 anos em projetos de melhoria de qualidade de software, 9 entre 2 e 5 anos e 21 atuam (atuaram) há menos de 2 anos. Em termos de quantidade de projetos de melhoria de qualidade de software em que estes elementos atuam (atuaram), 19 participam (participaram) de menos de 2 projetos, 13 participam (participaram ) de 2 a 5 projetos e 4 participam (participaram) de mais de 5 projetos de melhoria de qualidade de software. O quadro 12 ilustra como os elementos participantes se classificaram quanto à sua experiência em projetos de melhoria de qualidade software.

33 33 Experiência em qualidade de software Quantidade Excelente 0 Alta 12 Média 19 Baixa 13 Nenhuma 8 Quadro 12: experiência dos elementos em projetos de melhoria de qualidade de software Fonte: elaborado pelo autor 4.5 Análise da Pesquisa Nesta seção são consolidados e analisados os dados obtidos na pesquisa realizada nas empresas citadas na seção 4.3 e respondida pelos elementos descritos na seção 4.4. De acordo com Yin (2001) a análise dos dados consiste em examinar, categorizar, classificar em tabelas ou, do contrário, recombinar evidências tendo em vista as proposições iniciais do estudo. A partir dessa definição, o primeiro passo foi classificar as respostas da pesquisa em 6 conjuntos de acordo com sua categoria. Os três primeiros conjuntos compõem-se de respostas sobre três atividades que fazem parte do processo de gerência de requisitos ou que são diretamente dependentes dele. O quarto conjunto compõe-se de repostas sobre o uso de metodologia, o quinto conjunto compõe-se de respostas sobre a base de conhecimento existente e o sexto conjunto compõe-se de respostas sobre benefícios adicionais decorrentes do uso da gerência de requisitos. Para examinar as evidências sob diversos pontos de vista, a análise foi dividida em quatro partes. A primeira análise foi realizada por modelo de referência para a qualidade de software. Para esta análise as respostas dos elementos foram divididas em dois grupos de acordo com modelo de referência para a qualidade de software adotado pelas empresas em seu processo de desenvolvimento. O GRUPO A é constituído pelas respostas dos 29 elementos das 10 empresas que adotam o modelo CMM/CMMI ou o modelo MPS.BR ou a ambos como referência para a