ANAIS A INFLUÊNCIA DA GERÊNCIA DE REQUISITOS NA RETENÇÃO DO CONHECIMENTO EM EMPRESAS DESENVOLVEDORAS DE SOTWARE

A INFLUÊNCIA DA GERÊNCIA DE REQUISITOS NA RETENÇÃO DO CONHECIMENTO EM EMPRESAS DESENVOLVEDORAS DE SOTWARE Espaço reservado para a comissão organizadora (não escreva nada nesta área) RESUMO: Este trabalho visa identificar como a adoção da gerência de requisitos pode contribuir para que as empresas tenham um maior acesso ao conhecimento que está na memória de seus profissionais, ou está oculto dentro do código fonte dos seus programas. Realizou-se uma pesquisa exploratória em 19 empresas desenvolvedoras de software da região metropolitana de Porto Alegre, identificando o modelo de processo de desenvolvimento adotado para a qualidade do software e a existência da retenção de conhecimento. Os resultados assinalam que a gerência de requisitos influencia de forma substancial para a retenção do conhecimento das empresas desenvolvedoras de software. Palavras-chave: Conhecimento, Gerência de Requisitos, Qualidade de Software. 1- INTRODUÇÃO A rapidez com que a Tecnologia da Informação evolui, assim como a necessidade de atualização das empresas que a utilizam para criar valor estratégico em seu negócio, contribui para caracterizar a alta complexidade e competitividade do setor. Para participar deste jogo competitivo, exige-se que as empresas tenham capacidade de investimento tanto na evolução tecnológica por si só, como também, investimentos em desenvolvimento da melhoria constante da qualidade de software. Para promover esta melhoria da qualidade, as empresas desenvolvedoras de software têm tido uma crescente motivação para o avanço da especificação dos seus processos de produção, expressa através da incorporação de melhores práticas mundiais que são preconizadas por modelos legitimados pelo setor. 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 está na documentação, ou na falta da documentação, dos seus projetos de software. O Quality Assurance Institute, dos EUA retrata que 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. Uma das principais razões encontra-se na caracterização do perfil dos desenvolvedores de software, geralmente definido por pessoas talentosas que não se interessam por disciplina ou normas, e que consideram seu trabalho como algo artístico e criativo, ao invés de algo sujeito a procedimentos de engenharia (HAMMER, 2002). 1/14

A falta de recursos, de um modelo apropriado ou, muito comumente, a falta de hábito e aspectos culturais faz com que o conhecimento dos softwares desenvolvido não esteja adequadamente documentado, nem disseminado. Conseqüentemente, o conhecimento não está disponível para todos aqueles que possam precisar acessá-lo durante a vida útil do produto de software. Este conhecimento está somente na mente daqueles que o criaram e, muitas vezes seria necessário abrir o código-fonte para descobrir o que determinado programa faz, e como o faz. O conhecimento torna-se individualizado e não está disponível para a empresa. As empresas que atuam dessa forma podem correr sérios riscos para manter sua capacidade estratégica com a eventual perda daquelas pessoas que detêm esse conhecimento, que o detêm como um monopólio. Pode-se 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, e não projetos individuais (DAVENPORT e PRUSAK, 1998). Nas empresas prestadoras de serviço os ativos mais valiosos são os bens intangíveis, em especial, o conhecimento que a empresa adquiriu na sua experiência criando suas especialidades. O valor da maioria dos produtos e serviços depende principalmente como os fatores intangíveis baseados no 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 (SVEIBY, 1998; NONAKA e TAKEUCHI,1997). Os modelos consagrados para a melhoria da qualidade de software enfatizam, especialmente, a 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. A codificação promove a permanência do conhecimento, o qual, de outra maneira, somente poderia ser acessado na mente das pessoas (DAVENPORT e PRUSAK, 1998). Este trabalho investigou se esses modelos podem influenciar na retenção de conhecimento. Em particular, procurou-se pesquisar se eles são capazes de 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. Não se investigou a comparação/benefícios entre modelos, e sim, se a partir da adoção de um modelo de referência para processos de qualidade de software pode-se perceber maiores evidências sobre retenção de conhecimento, em comparação com empresas que preferem não ter um modelo reconhecido e atuam segundo suas estruturas conceituais vivenciadas. Este trabalho se estrutura da seguinte forma: após esta introdução, na seção 2 apresenta-se uma análise da empresa desenvolvedora de software como organizações baseadas em conhecimento. Na seção 3, comenta-se brevemente as características dos modelos CMMI e MPS.BR com ênfase para a Gerência de Requisitos. Na seção 4, apresenta-se os procedimentos de pesquisa e na seção 5, os resultados e principais elementos analisados na pesquisa. A seguir, na seção 6, as conclusões e considerações finais, e por último, na seção 7, as referências bibliográficas. 2/14

2- AS EMPRESAS DESENVOLVEDORAS DE SOFTWARE COMO ORGANIZAÇÕES BASEADAS EM CONHECIMENTO O conhecimento vem sendo identificado como a mais importante fonte de vantagem competitiva e de performance sustentável da organização (DRUCKER, 1999; SPENDER & GRANT, 1996), assim como uma importante fonte de excelência de performance em ambientes turbulentos (HAMMEL & PRAHALAD, 1997; NONAKA et al., 2001).O gerenciamento do conhecimento sempre existiu nas organizações de alguma forma. Atualmente, a diferença encontra-se no reconhecimento do conhecimento como um ativo estratégico e a crescente compreensão da necessidade de ações gerenciais sistemáticas para a sua promoção. Numa perspectiva epistemológica, Polanyi (1966) argumenta que o conhecimento possui duas espécies: o conhecimento prático e o teórico. O conhecimento prático é chamado de conhecimento tácito e o conhecimento teórico de explícito. Nonaka & Takeuchi (1997) a partir das espécies de conhecimento explícito e tácito propostas por Polanyi (1966), consideram que é possível aplicar esses conceitos de forma mais prática, se algumas distinções claras entre eles forem identificadas: o tácito como o conhecimento do corpo, do aqui e agora, da experiência; e o explícito como o conhecimento da racionalidade, do lá e então, da teoria. Para as empresas desenvolvedoras de software, o problema proposto nesta pesquisa centra-se em uma dessas preocupantes ações gerenciais: criar a capacidade de armazenar o conhecimento adquirido. Reconhecendo-se que neste setor as pessoas atuantes são empreendedoras, inovadoras, e gostam de novos desafios, o problema da memória organizacional torna-se crítico. Reter essas pessoas nem sempre é possível por diversas razões. Assim, a necessidade de se adotar mecanismos para reter esse conhecimento torna-se fator crítico e estratégico para essas organizações sejam competitivas. mercado da tecnologia demanda expertises as quais, normalmente, são desenvolvidas na experiência de desenvolvimento de diferentes produtos. A gestão das empresas desenvolvedoras de software depende, por pressuposto de sobrevivência, de sua precisa atuação como uma organização baseada em conhecimento. A organização baseada em conhecimento é aquela que reconhece, promove e utiliza o conhecimento coletivo e as habilidades das pessoas como as maiores fontes de vantagens competitivas sustentáveis (TOBIN, 1998). Este tipo de organização requer do gerente um desempenho gerencial associado a tornar o conhecimento produtivo, ou seja, aumentar o rendimento daquilo que é conhecido tanto pelo indivíduo como pelo grupo (DRUCKER, 1995). Uma organização baseada em conhecimento necessita estabelecer a diferença entre dado, informação e conhecimento. Considera-se neste artigo que dados são um conjunto de fatos distintos e objetivos, relativos a eventos os quais não possuem um significado inerente (DAVENPORT & PRUSAK, 1998). Informações são os dados que são organizados para descrever uma particular situação ou condição (WIIG, 1993). Em outras palavras, informações são os dados relacionados que fazem a diferença através da expressão de uma mensagem, buscando mudar o modo como o destinatário vê algo, ou seja, exercendo algum impacto sobre o seu ponto de vista, juízo de valor ou comportamento (DAVENPORT & PRUSAK, 1998). E o conhecimento é o resultado da interpretação e aplicação de uma informação disponível que altera 3/14

o referencial de uma pessoa. O conhecimento consiste de verdades e crenças, perspectivas e conceitos, julgamentos e expectativas, metodologias e know-how (WIIG, 1993). Como a gestão do conhecimento é uma área emergente de pesquisa aplicada, muitos autores apresentam diferentes propostas de modelos para implantação com significados muitas vezes semelhantes. Neste estudo, utiliza-se como estrutura conceitual o modelo proposto por Alavi (2001) no qual o processo de gestão do conhecimento ocorre em 4 etapas: (1 a ) criação/aquisição; (2 a ) organização/armazenagem; (3 a ) distribuição e (4 a ) aplicação (ver figura 1). Neste processo, os componentes da gestão do conhecimento são os fatores socioculturais e técnicos da organização, salientando a diferença entre sistemas de gestão do conhecimento (na visão da tecnologia da informação) e a gestão propriamente dita (na visão de ações sócioculturais). A retenção do conhecimento, mencionada neste artigo, trata da retenção do conhecimento explícito como uma das possíveis expressões da experiência das pessoas, segundo processos específicos e característicos que auxiliem compreender particularidades da atividade desempenhada. No caso das empresas desenvolvedoras de software investigou-se a efetividade desses processos quando baseados nos modelos CMMI e MPS.BR, descritos a seguir. 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, 2005). 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). A seguir, comenta-se esses dois modelos: 3.1 O MODELO CMMI O CMMI Capability Maturity Model Integration é 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 (Software Engineering Institute) da Universidade Carnegie Mellon Pittsburg (EUA). O CMMI é uma evolução do modelo CMM - Capability Maturity Model 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. Promove 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, as quais 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. 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 4/14

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. 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. 3.2 O MODELO MPS.BR O MPS.BR Melhoria de Processo do Software Brasileiro 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 Associação para a Promoção de Excelência do Software Brasileiro (SOFTEX) com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do banco Interamericano de Desenvolvimento (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 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 15504 e a disciplina para engenharia de sistemas e de software do CMMI chamada CMMI-SE/SW (Capability Maturity Model Integration for Systems Engineering/Software Engineering) e se propõe ser 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 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, no qual 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. Considera, também, informações adicionais e o grau de refinamento e institucionalização com que o processo é executado na organização. 3.3 GERÊNCIA DE REQUISITOS 5/14

Antes de definir gerência de requisitos, cabe definir o que é requisito. 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 objetivo. Requisitos podem ser definidos como sendo o conjunto de necessidades estabelecido pelo cliente/usuário (TONSIG, 2003). A essa definição pode-se ainda acrescentar que os requisitos condicionam a qualidade do software (LEITE, 2001) Unindo esses conceitos às especificações dos modelos CMMI e MPS.BR compreende-se, para esta pesquisa, 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 e construir antes de começar a fazê-lo tornam-se atividades fundamentais para obtenção da qualidade dos produtos. 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, 2005). 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. 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 com 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. Observa-se que o processo para gerenciar requisitos está definido nos níveis iniciais de maturidade de ambos os modelos. Gerenciar adequadamente o que se pretende com o produto a ser desenvolvido é fundamental para o alcançar os resultados desejados, principalmente, a partir da identificação de inconsistências entre os requisitos e os planos de trabalho do projeto (SOFTEX, 2006; CARNEGIE MELLON UNIVERSITY, 2006). 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 especificações funcionais e técnicas adequadas. 4. PROCEDIMENTOS DE PESQUISA A abordagem utilizada neste estudo foi qualitativa, pois se procurou abranger uma situação específica na qual o processo e o contexto são dimensões básicas para a sua compreensão, através de uma estratégia de pesquisa exploratória. O método de investigação utilizado foi o de múltiplos estudos de casos (YIN, 2001). A metodologia de estudos de casos 6/14

pode ser utilizada para diferentes tipos de pesquisa: a) descrever um fenômeno, b) contruir uma teoria, ou c) avaliar relacionamentos e conceitos teóricos (CAVAYE, 1996). Esta pesquisa procurou avaliar relacionamentos e conceitos teóricos através da investigação em múltiplos casos, sendo que neste artigo apresenta-se a avaliação da retenção do conhecimento em dois grupos: (1) empresas que adotaram o CMM/CMMI ou MPS.BR, como modelos de referência para seus processos de qualidade de software, e (2) empresas que não adotaram o CMM/CMMI ou MPS.BR, como modelos de referência para seus processos de qualidade de software. Também foram investigadas empresas que não adotaram quaisquer processos formais para a qualidade de software. Os instrumentos de pesquisa aplicados foram: a) entrevista exploratória com profissionais especializados no tema para identificar as empresas alvo deste estudo e qualificar o questionário; b) questionários com perguntas abertas e fechadas; c) investigação documental; d) observação, por um dos pesquisadores que é profissional atuante no tema de pesquisa. Procurou-se garantir que os respondentes ao questionário fossem os profissionais envolvidos em processos de desenvolvimento de software, como gerente de equipes de desenvolvimento, gerente de projeto, gerente de qualidade, analista de sistemas, programador 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 não adotaram modelos como referência em seus processos de qualidade de software. 4.1 CARACTERIZAÇÃO DOS GRUPOS DE EMPRESAS PESQUISADAS Foram investigadas 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. As empresas são classificadas como micro, pequenas, médias ou grandes, englobando uma força de trabalho de 7.235 profissionais, sendo que deste, 1.961 estão envolvidos diretamente com o desenvolvimento de software (ver quadro 1). Quadro 1: Tipo de empresas pesquisadas Classificação Empresas Profissionais (total) Micro 3 10 Pequena 8 183 Media 6 818 Grande 2 1.000 Total 19 1.961 Fonte: Dados da pesquisa 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 (ver Quadro 2). 7/14

Quadro 2: Abrangência de domínio de software por grupos das empresas pesquisadas 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 Fonte: Dados da Pesquisa O ramo de atividade das empresas pesquisadas também é bastante heterogêneo e a maioria das empresas atua em mais de um ramo de atividade de desenvolvimento de software (ver quadro 3). Quadro 3: Grupo de empresas de acordo com 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 Fonte: Dados da Pesquisa 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 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 foi considerada neste estudo. Há um significativo número de empresas que não adotam nenhum desses modelos ou não possui nenhum processo padrão de qualidade software. O CMMI é uma evolução do modelo CMM - Capability Maturity Model também desenvolvido pelo SEI e, para efeitos desta pesquisa não serão considerados distintos (ver quadro 4). Quadro 4: Conjunto de Empresas que adotam modelo de qualidade de software Modelo de qualidade de software Conjunto de Empresas CMM/CMMI 6 MPS.BR 7 ISO 2 8/14

Modelo próprio ou nenhum 9 Fonte: Dados da Pesquisa Observação: algumas empresas utilizam mais de um modelo 5. RESULTADOS E PRINCIPAIS ELEMENTOS ANALISADOS Para a análise geral da pesquisa os resultados foram separados em dois grupos de empresas: a) Empresas que adotam o modelo CMM/CMMI ou o modelo MPS.BR ou a ambos, como referência para a qualidade em seu processo de desenvolvimento (10 empresas pesquisadas e 29 profissionais participantes), e b) Empresas que não adotam algum desses modelos estudados como referência para a qualidade em seu processo de desenvolvimento, e que não aplicam um processo padrão para a qualidade de software (9 empresas pesquisadas e 23 profissionais participantes). 5.1 QUANTO AO LEVAMENTO DOS REQUISITOS Em relação ao levantamento de requisitos observa-se que a forma de contato com o cliente mais utilizada é através de visitas, por ambos grupos de empresas pesquisadas. Quanto à forma de registro do levantamento de requisitos mais utilizada é aquela que segue um padrão da empresa. Porém, percebe-se que nas empresas que não adotam, um significativo número de profissionais assume sua própria metodologia. Mesmo que isto signifique que há o registro, este ocorre de forma não padronizada, o que pode gerar dificuldades de entendimento para outros profissionais não familiarizados com esta metodologia, caso venham a necessitá-lo. [...em um grande projeto com muitas customizações, houve a troca de grande parte da equipe interna por consultores externos que acusaram uma série de não conformidades com os processos e necessidades dos clientes. Tínhamos a documentação completa dos requisitos com o devido aceite dos responsáveis por parte do cliente. Esta documentação permitiu a continuidade da nossa empresa no projeto, justamente por documentar os projetos..] (Fonte :profissional da Empresa A) Quanto ao grau de plenitude dos requisitos também se identificam dificuldades nas empresas que não adotam, na media em que o levantamento é poucas vezes completo. Nas empresas que adotam, a plenitude do levantamento de requisitos apresenta-se completo pela maioria das empresas pesquisadas. [...o levantamento de requisitos e o aceite foram realizados mas não documentados. O projeto foi cancelado com retomada posterior. Tivemos que fazer tudo novamente...] Fonte: Profissional 1 da Empresa B Ambos os grupos caracterizam que o grande motivo da ocorrência da falta da plenitude dos levantamentos é porque o cliente não sabe o que quer. O segundo motivo percebido, com ênfase nas empresas que não adotam, é a falta de metodologia. As dificuldades encontradas no levantamento de requisitos, independente do motivo, fazem com que seja necessário mudar os requisitos em ambos os grupos de empresas. 5.2 QUANTO À TRANSFORMAÇÃO DOS REQUISITOS EM ESPECIALIZAÇÃO A formalização da acolhida dos requisitos junto ao cliente percebe-se que não é uma prática comum nas empresas que não adotam. Enquanto que nas empresas que adotam, evidencia-se este procedimento com alta freqüência, promovendo uma maior padronização de seus processos. 9/14

[...quando a empresa não tinha o processo para a melhoria definido, documentado e utilizado pelas pessoas envolvidas, existia muito retrabalho pois os requisitos não ficavam entendidos por todos. A formalização do aceite dos requisitos prova que estes foram revisados e entendidos por todas as partes envolvidas e assim favorecendo para que se elimine o retrabalho e para que se evite que se trabalhe em algo que não foi acordado. (Fonte: profissional 1 da Empresa C) O registro da transformação dos requisitos em especificação de software ocorre em todas as empresas pesquisadas, de acordo com alguma metodologia padrão da empresa. Porém, para as empresas que não adotam, a maioria dos casos ocorre de acordo com o padrão próprio de cada profissional e não de acordo com um padrão da empresa. Por outro lado, nas empresas que adotam a maioria dos casos ocorre de acordo com o padrão da empresa. Esta diferença também se evidencia desta forma, na análise do tipo de comunicação das especificações à equipe, quando se observa nas empresas que adotam uma formalização mais acentuada. 5.3 QUANTO AO USO DA METODOLOGIA Na análise do cumprimento ao uso de metodologia percebe-se que esta é seguida regularmente em ambos os grupos de empresas, salientando que as empresas que adotam consideram esta atividade como um pressuposto incondicional. [...após termos criado uma metodologia, onde são registrados todos os requisitos e funcionalidades propostas para o cliente, a inconformidade praticamente reduziu a zero..] Fonte: Profissional 2 da Empresa D Quando se investigou situações de não adoção de metodologia, as empresas que não adotam consideram como o maior motivo o trabalho adicional. Destaca-se que os profissionais de ambos os grupos de empresas mencionam a falta de tempo hábil para usá-la, quando por algum motivo não foi aplicada. 5.4 QUANTO À RETENÇÃO DO CONHECIMENTO Na análise da base de conhecimento utilizada para especificação dos projetos, percebe-se uma preponderância para o levantamento de requisitos. A expertise da empresa, o que a empresa sabe, o conhecimento que ela já possui (retém) também é muito valorizado, porém ainda num grau menor que à percepção sobre o conhecimento que está na mente dos analistas. [...Um depoimento que podemos oferecer diz respeito a uma situação extremamente favorável. Foi desenvolvido um projeto de integração entre nosso Sistema e o ERP de uma grande universidade do país. Cada passo foi detalhadamente documentado e validado pelo cliente, desde o levantamento de requisitos até a homologação. Mesmo após a saída das pessoas que participaram do desenvolvimento não houve nenhuma dificuldade em efetuar as implementações...]. (Fonte: Entrevistado 3 da empresa B) Nas empresas que adotam, percebe-se que o conhecimento está totalmente ou parcialmente documentado, enquanto que nas empresas que não adotam, o conhecimento está parcialmente documentado. Nestas últimas, observa-se uma maior ênfase no acesso ao conhecimento na mente dos profissionais, e mais dependente do acesso ao código-fonte. 10/14

Em geral, há uma elevada concordância sobre a contribuição da gerência de requisitos sobre a retenção do conhecimento, enfatizado por 75% dos profissionaisdos entrevistados. Há um consenso em ambos os grupos de empresas pesquisadas que a gerência de requisitos contribui muito para a documentação dos projetos, para o cumprimento do cronograma, para o cumprimento das metas de custo e, finalmente, para a melhoria da qualidade dos projetos de software. A dificuldade principal está na necessidade de mudança cultural e na dificuldade que muitos profissionais de informática têm em aceitar o processo de desenvolvimento como um processo disciplinado e sujeito às regras da engenharia. Os motivos mencionados pela não adoção da metodologia, como a falta de tempo e a falta de hábito, são evidências dessas dificuldades. 6- CONCLUSÕES E CONSIDERAÇÕES FINAIS Este estudo procurou demonstrar como a gerência de requisitos, notadamente aquela baseada em modelos de referência como o CMMI e MPS.BR, pode contribuir para a retenção do conhecimento em empresas que desenvolvem software. Observou-se que o levantamento de requisitos é uma atividade primordial, sendo que a forma de contato com o cliente, o método, e o grau de plenitude pode variar, porém isso não a invalida como atividade fundamental. Na comparação entre os grupos de empresas analisados, observa-se que o grupo que adota um modelo de referência para a qualidade de software realiza essa atividade de uma forma mais padronizada, e com maior grau de plenitude no seu levantamento. A adoção de um padrão de registro e de documentação favorece a utilização posterior do conhecimento nele contido em oposição aos padrões específicos por projeto e aos padrões particulares de cada profissional. Ainda que estes sejam completos, a não padronização pode acarretar em dificuldades de entendimento para aqueles que não estão com ele familiarizados. Além disso, a definição de um padrão de documentação não se limita ao modelo a ser utilizado. A gerência de requisitos requer que os documentos estejam acessíveis a todos que venham deles necessitar. Isso não ocorre quando o profissional cria seus documentos a partir de um modelo particular, para seu próprio uso e, freqüentemente, não os disponibiliza. A aceitação formal dos requisitos representa a concordância de todas as partes envolvidas com o seu conteúdo e, mais do que isso, expressa formalmente o seu pleno entendimento. Como a aceitação formal é realizada sobre um documento, temos aqui uma evidência clara de retenção de conhecimento para as empresas que a adotam. Quando este documento é elaborado segundo um padrão definido pela empresa, sua compreensão para quem não participou de sua elaboração é favorecida na comparação com um modelo particular que, muitas vezes, é somente compreendido plenamente por quem o elaborou. Na análise desta prática observa-se que há um formalismo mais freqüente nas empresas que adotam um modelo de referência, contra práticas mais isoladas nas empresas que não adotam utilizando menos padrões. Nos mecanismos de aceite, há que se observar as citações para o aceite verbal mais freqüente nas empresas que não adotam um modelo de referência. O aceite verbal pressupõe que os requisitos não estão documentados; logo, seu conhecimento está em poder dos profissionais que estão desenvolvendo o projeto, não em poder da empresa. Com o aceite verbal a empresa se predispõe a correr o risco de questionamentos futuros. Aqui cabe lembrar um depoimento que relata que a empresa se habilitou a continuar com um projeto justamente por adotar a prática da documentação detalhada dos requisitos e do aceite formal do cliente quando da sua elaboração. 11/14

A transformação dos requisitos em especificações representa a mudança do o que para o como. Observa-se que documentar as especificações de projeto é uma prática comum a ambos os grupos de empresas. E novamente observa-se que as empresas que adotam um modelo de referência são mais obedientes a um padrão em oposição às empresas do outro grupo, no qual a documentação acontece, de acordo com um padrão por projeto ou com um padrão particular do profissional. O risco da perda de conhecimento por parte da empresa está em esta documentação (elaborada segundo o padrão por projeto ou o padrão individual) não estar disponível ou não ser facilmente compreendida por quem não está com ela familiarizado. A diferença de comportamento entre os dois grupos está evidenciada de forma acentuada na comparação de duas empresas quando analisadas individualmente. Enquanto na empresa do grupo que adota um modelo o padrão da empresa é seguido exclusivamente, na empresa do segundo grupo a forma de documentação não obedece a um padrão único. Considerando a atividade de comunicação como uma das importantes atividades para disseminação de conhecimento, ambos os grupos de empresa estão bem conceituados. A prática mais adotada obedece a um padrão da empresa, mas nesta atividade a forma não importa muito, desde que a base esteja bem documentada. O uso de uma metodologia padrão na execução dos processos requer tempo, dinheiro, determinação e disciplina. As empresas que adotam um modelo seguem com maior cuidado uma metodologia se comparada com as que não adotam. Observa-se que os requisitos são a base de conhecimento mais utilizada para a especificação dos projetos. E para a percepção de muitos investigados, a expertise da empresa, aquele conhecimento que já está retido, também é utilizado. Mas há que se observar que para uma parcela maior, o conhecimento dos analistas ainda é muito utilizado para a especificação. Isto é bom quando esta prática vem consorciada com o registro e com a documentação da especificação - então se estará tornando explícito um conhecimento implícito. Porém ao analisarse o quanto o conhecimento está documentado, observa-se que não é isto que ocorre em vários casos. Percebe-se que a documentação não está totalmente documentada e que é significativa a quantidade de respondentes que validam como prioritário o conhecimento que está na mente dos profissionais ou no código-fonte. Na comparação com os dois grupos observa-se que o grupo de empresas que adota um modelo de referência tem obtido maior sucesso quanto à documentação total, sendo quase que exclusiva deste grupo em oposição ao grupo de empresas que não adotam modelo, o qual salienta que o conhecimento está na mente dos profissionais ou escondido no código-fonte. Com base nesse conjunto de evidências, somados aos casos de sucesso e de insucesso relatados pelos elementos que participaram desta pesquisa, considera-se que a gerência de requisitos influencia de forma positiva e substancial para a retenção do conhecimento das empresas desenvolvedoras de software. A influência se dá através da adoção de metodologias padronizadas para as práticas de levantamento e documentação de requisitos, de aceitação formal desses requisitos e de documentação da especificação funcional dos projetos. Documentação padronizada, facilmente compreendida e disponível é conhecimento explícito. Conhecimento explícito é conhecimento da empresa e não mais exclusividade de alguns profissionais. 12/14

7.REFERÊNCIAS BIBLIOGRÁFICAS ANAIS ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO (SOFTEX), Campinas. Guia Geral do MPS.BR Melhoria de processo do software brasileiro, versão 1.1, 2006. Disponível em http://www.softex.br/mpsbr acessado em novembro de 2006. ALAVI, M.; LEIDNER, D. Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly, Vol. 25, No. 1, pp 107-136, 2001. DRUCKER, P. Managing in a Time of Change. New York: Truman Talley, 1995. DRUCKER, P. Knowledge-Worker Productivity: the biggest challenge. California Management Review, v. 41, n. 2, p. 79 94, Winter, 1999. CARNEGIE MELLON UNIVERSITY/SOFTWARE ENGINEERING INSTITUTE, Pittsburg, Pennsylvania, USA. CMMI for development, version 1.2, 2006. Disponível em http://www.sei.cmu.edu/cmmi,acessado em agosto de 2006. CAVAYE, A.L.M. Case study research: a multi-faceted research approach for IS. Information Systems Journal, v. 6, p. 227 242, 1996. DAVENPORT, Thomas H.; PRUSAK, Laurence. Conhecimento Empresarial. Rio de Janeiro: Editora Campus, 1998. HAMMER, M. A Agenda. Rio de Janeiro: Editora Campus, 2002. HAMEL, G. & PRAHALAD, C.K. Competindo pelo futuro. Rio de Janeiro: Ed. Campus, 1997. KRUGLIANSKAS, I.; TERRA, J. C. C,. Gestão do conhecimento em pequenas e médias empresas. Rio de Janeiro: Editora campus, 2003. LEITE, Júlio C.S.P. Gerenciando a Qualidade de Software com Base em Requisitos. Artigo disponível em http://www.inf.puc-rio.br/~julio. Acessado em abril de 2007 NBR ISO/IEC 12.207. Tecnologia da Informação: processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998. NETO, R. C. As práticas e ferramentas da gestão do conhecimento auxiliam na gestão da interação universidade-empresa? ENANPAD - Anais do 30º encontro da Anpad. Salvador, 2006. NONAKA, I.; TAKEUCHI, H. Criação do Conhecimento na Empresa. Rio de Janeiro: Editora Campus, 1997. NONAKA, I.; KROGH, G.V. & ABEN, M. Making the Most of Your Company s Knowledge: A Strategic Framework. Long Range Planning, v. 34, p. 421 439, 2001. POLANYI, M. The Tacit Dimension. London: Routledge and Kegan Paul, 1966. SOMMERVILLE, I. Engenharia de Software. São Paulo: Addison-Weley, 2005. SPENDER, J-C. AND GRANT, R. Knowledge and the firm: overview. Strategic Management Journal, n. 17, p. 5 9, Winter Special Issue, 1996. SVEIBY, K. E. A Nova Riqueza das Organizações. Rio de Janeiro: Editora Campus, 1998. 13/14

TOBIN, D.R. The Knowledge Enabled Organization. New York: AMACON American Management Association, 1998. TONSIG, S. L. Engenharia de Software. São Paulo: Futura, 2003. WIIG, K.M. Knowledge Management Foundations: - thinking about thinking how people and organizations create, represent and use knowledge. Arlington, Texas: Schema Press, 1993. YIN, R. K. Estudo de Caso: Planejamento e Métodos. Porto Alegre: Bookman, 2001. 14/14