O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software

O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software Maria Angela Coser (UTFPR/CEFETES) macoser@cefetes.br Helio Gomes de Carvalho (UTFPR) helio@utfpr.edu.br Resumo: A indústria de software passa hoje por um choque de qualidade. No processo de desenvolvimento de software existem conflitos entre clientes e fornecedores como: atraso na entrega, produtos de baixa qualidade, custos acima do esperado e conflitos em relação aos requsitos do produto. O crescimento da indústria de software depende da excelência de seu processo de produção que requer profissionalização, automatização e aprimoramento constante dos processos. Este artigo apresenta um estudo do processo de especificação de requisitos de software, aplicado a um processo genérico. O gerenciamento de projeto estudado, é baseado no PMBoK (Project Management Body of Knowledge), e nos modelos de qualidade em processos de software: CMMI (Capability Maturity Model Integration), modelo de padrão international, e MPS.BR (Melhoria de Processos de Software Brasileiro), modelo brasileiro equivalente ao internacional. A gerência de projetos de desenvolvimento de software vem centrar sua atividade objetivando a qualidade, produtividade, maturidade, competitividade e redução de riscos através do planejamento, execução e controle do desenvolvimento do produto. Palavras-chave: Gerência de projetos; Padrões de qualidade de software; Processo de especificação de requisitos de software. 1. Introdução O mercado de software brasileiro passa por um choque de qualidade. Embora muitas empresas do setor abram suas portas todo dia, é da excelência de seu processo de produção que depende o sucesso dessa tecnologia, a garantia de mercado interno, e a capacidade de se inserir no mercado externo. A indústria de software encontra-se no centro do processo de transformação econômica que muitos autores identificam como sendo a construção de uma economia baseada na informação ou no conhecimento. O mercado de software está relacionado à tendência geral de inserção tecnológica nos mais diversos setores da economia. O crescimento dessa indústria passa pela profissionalização, automatização e aprimoramento de seus processos. A produção de software tem de estar em conformidade com as normas internacionais para atingir patamares de competitividade no mercado externo. Então, o desafio do software brasileiro hoje, é a certificação (VANZOLINI, 2006; ROSELINO, 2003). No processo de desenvolvimento de software, a existência de conflitos gerados entre usuários, clientes e desenvolvedores por divergências e ambigüidades nos termos do projeto, é constante. A ausência de planejamento e métodos justifica grande parte do fracasso de vários projetos, de nada adianta fazer alto investimento em tecnologia, se existem falhas no levantamento e especificação de requisitos, na comunicação da equipe, se acontecem riscos não calculados, cronograma e custos imprevisíveis. Por outro lado, as empresas precisam estar constantemente atualizadas e aptas a acompanhar as mudanças constantes, de alteração em escopo de projetos, evolução tecnológica, ambiental e organizacional. Metodologicamente, este artigo elabora uma revisão teórica dos conceitos de gerência de projetos, padrões de qualidade de software e engenharia de requisitos e apresenta dados de pesquisas e experiências relatadas para mostrar a importância da implementação desses 1

conceitos no processo de produção de software. 2. Fundamentação teórica 2.1 Gerência de projetos Apesar das potencialidades dos softwares muitos projetos são começados e não finalizados, fracassados por não atender as expectativas geradas com a implantação, rejeitados por apresentar dificuldade para os usuários. Segundo Pressman (2002, p.5), a falta de adoção de métodos, ferramentas e procedimentos no desenvolvimento de software e a difícil relação e entendimento entre o usuário com o desenvolvedor são apontados como os possíveis fatores causadores desses problemas. Esse fracasso fica explicitado nos dados das pesquisas realizadas pelo instituto The Standish Group International que analisa a situação dos projetos de tecnologia da informação (TI) nos EUA, a partir de 1994. A pesquisa realizada no ano 2000 registra que 28% dos projetos foram bem sucedidos, enquanto 72% falharam ou apresentaram problemas de custo, prazo, ou escopo estimados (TAIMOUR, 2005). Os problemas dos projetos de TI explicitados nessas pesquisas mostraram que as falhas estão relacionadas, principalmente, com o apoio da organização ao projeto, o envolvimento dos usuários, a definição clara dos requisitos do projeto e também com a experiência do gerente de projetos (GAVA et al., 2004). Para amenizar os problemas levantados nessas pesquisas, padrões, guias e metodologias foram criados por instituições reconhecidas mundialmente instituindo o gerenciamento de projetos e a profissão de gerente de projetos. Segundo Vaz (2005) uma empresa que não se dedica a administrar seus empreendimentos segundo uma visão metodológica da gerência de projetos, provavelmente, terá dificuldades durante a execução, e em consequência pode querer parar o projeto e já gastou muito. Enquanto uma organização que utiliza a metodologia adequada tomará decisões mais acertadas quanto à continuidade de seu empreendimento. Segundo PMBoK (2000), a gerência de projetos é o uso do conhecimento, das habilidades, ferramentas e técnicas com a finalidade de suprir as necessidades e expectativas da organização com relação a um projeto. Essa metodologia prevê que um projeto é acompanhado através de cinco grupos de processos, muitas vezes iterativos, representado na figura 1, que são: iniciação, planejamento, execução, controle e encerramento. FIGURA 1 Representação da iteração entre os grupos de processos em cada fase. Fonte: Adaptado de PMBoK (2000, p.31). Esses processos cobrem todo o ciclo de vida do projeto, seja do ponto de partida do empreendimento, a criação de programas e cronogramas a serem seguidos, a realização propriamente dita que simultaneamente dispara o teste e controle do produto até a entrega ao cliente (PMBoK, 2000; VAZ, 2005). Os grupos de processos se ligam pelos resultados que produzem. Essas conexões não são separadas ou descontínuas ou acontecem uma única vez. Elas são formadas por atividades que se sobrepõem, ocorrendo em intensidades diferentes ao longo de cada fase do projeto. 2

A metodologia do PMBoK (2000) faz uso de conhecimentos, habilidades, ferramentas e técnicas com intuito de receber entradas e gerar saídas para os processos. Ela descreve o gerenciamento de projetos em nove áreas de conhecimento, quais sejam: integração, escopo, tempo, custo, qualidade, recursos humanos, comunicação, riscos e aquisição, todas integradas entre si e muitas vezes concorrentes como escopo, tempo, risco e qualidade. O agrupamento dos processos em áreas de conhecimento leva em conta a natureza e as características de cada processo. A gerência de projetos é um processo interativo, uma ação, ou a falta de ação numa área, interfere no resultado de outras áreas. Os projetos são, na maioria das vezes, criados para desempenhar funções estratégicas das organizações, neste sentido a equipe de projeto deve conhecer o contexto onde o projeto se insere, deve identificar as partes envolvidas, conhecer suas necessidades e expectativas, a estrutura e a maturidade da organização em relação a sistemas de gerenciamento de projetos. A qualidade dos produtos e serviços gerados num projeto é hoje um dos principais diferenciais competitivos, e como garantí-la passou para o topo da pauta de discussão dentro das empresas desenvolvedoras de software. 2.2 Padrões de qualidade de software A qualidade é determinante na produção de software. Para um software ter qualidade, a combinação de atributos necessária para o desempenho adequado de suas funções deve ser claramente definida. O Programa Brasileiro da Qualidade e Produtividade em Software (PBQP Software) existe desde 1993, passou por diversas alterações, mas manteve o objetivo principal para o qual foi criado: atingir padrões internacionais de Qualidade e Produtividade no Setor de Software no Brasil. O compromisso com a qualidade de software e serviços tem como finalidade elevar o software brasileiro a patamares internacionais de competitividade (WEBER et al., 2006). Pressman (2002, p.724-725) define qualidade de software como: conformidade a requisitos funcionais e de desempenho explicitamente declarados a padrões de desenvolvimento claramente documentados e a características implícitas que são esperados de todo software profissionalmente desenvolvidos. E ainda enfatiza que os requisitos são a base a partir da qual a qualidade é medida. A falta de conformidade aos requisitos explícitos e implícitos, como o desejo de uma boa manutenibilidade, significa falta de qualidade. Entre as várias abordagens para a melhoria do processo de desenvolvimento de software, destacam-se modelos de qualidade, como o CMM (Capability Maturity Model) e o CMMI (Capability Maturity Model Integration). São modelos desenvolvidos pelo instituto de pesquisa da universidade de Carnegie-Mellon, Software Engineering Institute SEI, para avaliação dos processos de software de uma organização e para identificação das palavraschave que são requeridas para aumentar a maturidade desses processos (WEBER et al., 2006). São modelos bastante utilizados por empresas em todo o mundo e se inserem no contexto de melhoria do processo de produção de software. A maioria das empresas que querem melhorar processos, que pretendem exportar software ou serviços e, receber reconhecimento internacional busca o CMMI. O CMMI incorpora as necessidades de melhorias identificadas pelo uso do CMM no mundo, é compatível com a norma ISO/IEC 15504, alinhado ao PMBoK e possui um direcionamento claro e objetivo para as práticas de desenvolvimento de sistemas. O modelo CMMI tem cinco níveis de maturidade: chamamos o nível 1 de caótico, é o caso de qualquer empresa imatura de software, que não possui um ambiente estável. Os níveis consecutivos, 2 a 5, são níveis mais amadurecidos. O nível 5 pode ser chamado de nível de melhoria contínua. No Brasil, a empresa EDS atingiu o nível 5, mas até pouco tempo atrás, só havia empresas nível 2, o que já era considerado um avanço para a maioria. O fator custo e tempo de 3

implantação do CMMI são determinantes para muitas empresas, elas não querem mais levar dez anos para chegar ao nível 5 (SPINOLA, 2005). A qualidade da produção de software brasileira vem sendo medida a cada dois anos desde 1993, com pesquisas amostrais diretas, conduzidas pelo Ministério da Ciência e Tecnologia (MCT), por intermédio da Secretaria de Política de Informática (SEPIN), no âmbito do PBQP Software. A pesquisa mais recente apurou ganhos significativos das empresas quanto ao conhecimento de modelos e normas relacionadas a qualidade de software como mostra o gráfico 1. 90 80 70 60 50 40 30 20 10 0 Modelo CMM / CMMI Capability Maturity Model Integration Norma NBR ISO / IEC 12207 Processos do Ciclo de Vida de Software Norma ISO / IEC 15504 Avaliação de Processo 1995. 1997. 1999. 2001. 2005. GRÁFICO 1 Percentuais de conhecimento de modelos e normas relacionados à qualidade dos processos de software Brasil, 1995-2005. Fonte: Adaptado de WEBER et al. (2006). Esse ganho de informação sobre modelos e normas internacionais de qualidade de software coincide com o lançamento do Projeto MPS.BR (Melhoria de Processos de Software Brasileiro), coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), em dezembro de 2003. O modelo para melhoria do processo de software brasileiro, MPS.BR, equivalente nacional ao CMMI, com a mesma excelência técnica porém de custo mais baixo, acelerou a busca das empresas por padrões de qualidade, produtividade e competitividade em seu processo. Uma questão-chave hoje é a inserção da produção brasileira de software no mercado internacional. Para Spínola (2005) o Brasil tem oportunidade de participar ativamente desse mercado, pois tem boas universidades e boa formação de pessoas. Dentro desse objetivo, esse autor tem defendido três pontos fundamentais a trabalhar: o primeiro é qualidade de nossos produtos e processos; o segundo é a produtividade produzir mais gastando menos e no prazo definido; e o terceiro é a fábrica de software. A criação do modelo brasileiro, MPS.BR, contribuiu para acelerar que a produção de software seja sistematizada, controlada e medida para poder atingir os outros objetivos de qualidade, competitividade e produtividade. Assim surgiu o conceito de maturidade em gestão de projetos, que vem sendo tratado com uma escala evolutiva pela qual as empresas devem passar para progredir (LAURINDO; MORAES, 2006). À medida que as empresas crescem, precisam aperfeiçoar a capacidade de gerenciar projetos, elas formalizam a experiência que vão adquirindo, desenvolvendo competências na área. O aumento da qualidade no processo de produção de software depende muito menos do uso de novas tecnologias do que do emprego efetivo de práticas gerenciais adequadas e 4

sistematizadas. Portanto, há uma necessidade de compreensão dos problemas envolvidos no processo de desenvolvimento de software. 2.3 Engenharia de requisitos O processo de desenvolvimento de software tem por objetivo definir e exercitar processos - humanos que atuam como máquinas -; métodos, ou seja, planos de processos; ferramentas e ambientes, que são formados de máquinas apoiando processos e métodos, para a construção de software que satisfaça necessidades de cliente e usuário dentro de prazos e custos programados (FERNANDES, 2003). Esse processo pode ser visto como um conjunto de atividades, métodos, práticas e transformações que guiam pessoas envolvidas na produção de software. A engenharia de software é estruturada em áreas de conhecimento que fornece uma interpretação estabelecida na relação cliente-usuário-desenvolvedor que se inicia na definição de requisitos de software. Para ser eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas, os procedimentos necessários e a habilidade, e ainda, o treinamento e a motivação do pessoal envolvido. O desenvolvimento de um software começa pelo entendimento de como ele será usado, isto é: estabelecer o que o software deve fazer e definir as restrições sobre sua operação e implementação. A engenharia de requisitos é uma disciplina que engloba todas as atividades necessárias para criar e manter a documentação de requisitos do software. Essa fase, segundo dados do instituto Standish Group, responde por 56% dos erros encontrados depois do produto final ter sido entregue ao cliente (TAIMOUR, 2005). O entendimento dos requisitos do software é essencial para o sucesso de um processo de desenvolvimento de software. A atividade de especificação de requisitos é um processo de descoberta, relacionamento, refinamento e especificação. A engenharia de requisitos são atividades para aumentar a precisão e controlar a variação da linguagem de interação entre o resultado desejado e o usuário (SWEBOK, 2004). Requisitos são classificados como funcionais, que são declarações de funções que o software deve fornecer, reagir ou se comportar em determinadas situações; não funcionais, que são restrições sobre os serviços ou funções que o software oferece; e, requisitos de domínio, que são derivados do domínio da aplicação e refletem as características do domínio do problema. São informações que descrevem o contexto no qual o software terá que ser desenvolvido e operado, o ambiente, objetivos, todas as fontes de informações, patrocinadores e influenciadores do produto (SOMMERVILLE, 2003). O processo de engenharia de requisitos é descrito por Sommerville (2003) e Pfleeger (2004) em quatro passos como representado na figura 2: estudo de viabilidade, elicitação e análise de requisitos, especificação de requisitos e validação da documentação dos requisitos. O processo inicia com o estudo de viabilidade, a partir de uma descrição geral do sistema, restrições do projeto e de como será utilizado dentro da organização. Este estudo deve apresentar um relatório, sob o ponto de vista tecnológico e organizacional, se este projeto é ou não viável e se deve prosseguir com a elicitação e análise dos requisitos, tornando mais claras as restrições do projeto. A etapa seguinte, de elicitação de requisitos é realizada com a participação de usuários, gerentes e desenvolvedores envolvidos no processo e todas as pessoas da organização que venha a ser por ele influenciado. A partir de entrevistas, observações e reuniões, são apresentados os objetivos do projeto, o fluxo de trabalho, documentação, legislação, planilhas e sistemas relacionados ao projeto de software. A meta é reconhecer os elementos básicos do problema segundo a perspectiva do usuário e, portanto, compreender o domínio no qual o projeto e a organização se inserem, identificar as partes interessadas, capturar dos usuários os requisitos funcionais e não funcionais pretendidos e identificar os 5

problemas, conflitos e propostas de soluções em conjunto com as partes interessadas (SOMMERVILLE, 2003; PFLEEGER, 2004). FIGURA 2 Processo de Engenharia de Requisitos. Fonte: SOMMERVILLE (2003, p.103). Uma vez elicitados os requisitos, estes devem ser documentados. A fase de especificação de requisitos produz documentos que contemple que o escopo do software definido no planejamento do projeto é detalhado, as funções e o desempenho do software são especificados, as interfaces com outros sistemas são identificadas e as restrições que o software deve atender são estabelecidas. Os documentos gerados neste processo são avaliados junto aos usuários e gerentes segundo os critérios descritos a seguir por Sommerville (2003) e Pfleeger (2004): validade, os requisitos devem atender a toda comunidade de usuários; consistência, não devem existir restrições contraditórias ou descrições diferentes para uma mesma função nos requisitos; completeza, os requisitos devem definir todas as funções e restrições exigidas pelos usuários; realismo, para assegurar que os requisitos podem ser implementados; e verificação, para reduzir divergências entre usuários e desenvolvedores. Uma incorreta elicitação e validação de requisitos podem levar ao desenvolvimento de um produto que não atende aos objetivos para o qual foi planejado, sendo total ou parcialmente desperdiçado. A validação de requisitos se ocupa de apresentar o documento de requisitos aceito pelo cliente. Ela tem de mostrar os requisitos que realmente definem o sistema que o cliente deseja (SOMMERVILLE, 2003; PFLEEGER, 2004). O processo de especificação de requisitos é um processo iterativo com feedback contínuo que deve ser gerenciado para acompanhar a compreensão do que se quer desse produto, sua evolução e no relacionamento que ele provoca entre as pessoas. 2.3.1 Gestão de requisitos de software O processo de especificação de requisitos de software depende da experiência e comprometimento das pessoas envolvidas, além da adoção de métodos, práticas e transformações que guiam os clientes e desenvolvedores na construção de um produto de qualidade. Muitos projetos de software são começados e não finalizados, fracassados por falta 6

de gerenciamento ou por gerenciamento ineficaz. Da concepção a implantação de um software, muitos dos requisitos podem sofrer alteração, serem substituídos, ampliados, excluídos. Isso é muito comum, pois as necessidades dos usuários e das organizações são mutáveis. Estes documentos devem ser recuperados, reavaliados, revisados e alterados durante a validação de cada etapa do processo de desenvolvimento de software subseqüente. Para acompanhar a atualização dinâmica dos requisitos é necessário identificar ferramentas que proporcionem que os requisitos possam ter vida própria e ser permanentemente atualizados. O gerenciamento de requisitos é o processo de gerenciar e controlar essas mudanças. A gestão de requisitos inclui o planejamento desse gerenciamento, onde são especificados os procedimentos e as políticas para a gestão de requisitos, e ainda o gerenciamento de mudanças, em que as mudanças são analisadas e seu impacto é avaliado (SOMMERVILLE, 2003). O planejamento é essencial ao processo de gerenciamento de requisitos, que envolve altos custos. Sommerville (2003) propõe que no planejamento se estabeleça o detalhamento necessário para a gestão de requisitos e se inclua os seguintes aspectos: Identificação de requisitos: identifica cada requisito de modo único, para permitir a referência cruzada entre requisitos e facilita seu rastreamento. Processo de gestão de mudanças: estabelece um conjunto de atividades que avalia o impacto e o custo das alterações. Política de rastreamento: define políticas de rastreamento que estabelece as relações entre os requisitos e estes com o projeto do sistema, e ainda como manter esses registros atualizados. Suporte de apoio de ferramentas: a gestão de requisitos precisa de apoio de ferramentas para armazenamento de requisitos que seja segura, gerenciada e acessível por todos os envolvidos, para o gerenciamento de mudanças, que acompanha a solicitação até a implementação da mudança, que permita facilidade de rastreamento, para encontrar a qualquer hora, os requisitos relacionados. A qualidade do produto final depende da sistematização do processo de desenvolvimento do software, enquanto a ausência de planejamento e métodos justifica grande parte dos fracassos de vários projetos. 3. O impacto da adoção de normas e modelos de referência na produção de software Os fatores críticos ao sucesso dos projetos de TI explicitados nas pesquisas do instituto Standish Group mostraram que as falhas estão relacionadas, principalmente, com pessoas e não com a tecnologia. Mais especificamente, essas falhas ocorrem por falta de envolvimento dos usuários, a definição clara dos requisitos do projeto ou requisitos incompletos, mudanças de requisitos no decorrer do projeto e também com a experiência e habilidade do gerente de projeto (TAIMOUR, 2005). As principais causas de fracassos de projetos de software também foram avaliadas pelo European Software Process Improvement Traninig Initiative (ESPITI) em uma pesquisa realizada em 3.800 projetos, onde foi constatado que (MIRANDA, 2003): 50% dos principais problemas de projetos de software se originam na fase de especificação de requisitos; 13% das principais causas de fracassos nesses projetos são oriundos da falta de participação dos usuários; 12% das principais causas de fracassos nesses projetos se relacionam aos requisitos 7

incompletos; e ainda 12% das principais causas de fracassos nesses projetos ocorrem por mudanças nos requisitos. Gava et al. (2004) identifica que os problemas relacionados ao levantamento e ao gerenciamento de requisitos caracterizam os principais fatores responsáveis pela falta de qualidade dos projetos de software. À medida que as empresas vão precisando aperfeiçoar a capacidade de gerenciar projetos, elas tendem a formalizar a experiência que vão adquirindo nos processos relacionados a essa atividade (LAURINDO; MORAES, 2006, p.7). Este assunto é particularmente importante para a gerência de projetos de desenvolvimento de software, e tem sido um fator relevante para a competitividade de empresas de pequeno, médio ou grande porte e sua inserção no mercado internacional. A empresa UNITECH Tecnologia de Informação constata que a adoção de normas, métodos, técnicas e ferramentas da qualidade no desenvolvimento de software, promove a melhoria dos processos e produtos e aumenta a produtividade, maturidade e competitividade da empresa. Traçou objetivos para viabilizar estratégia de crescimento com qualidade, produtividade e rentabilidade, de forma a contruir diferenciais competitivos, esta empresa desenvolveu um programa integrado de melhoria de processos de desenvolvimento de software, que passa pela adoção de padrões internacionais, com normas e modelos de processos implementados desde 1998, representado na tabela 1, de forma a reduzir o esforço necessário para realizar um trabalho e aumentar a qualidade e consistência dos resultados (PASSOS, 2006). TABELA 1 Cronograma de implementação / certificação de padrões de qualidade na UNITECH. Norma / Modelo Implementação Certificação ISO 9001:1994 Desde 1998 Agosto/1999 ISO 9001:2000 Desde 2002 Julho/2003 SW - CMM 2 Desde 2003 Janeiro/2005 ISO 14001:2004 Desde 2005 Dezembro/2005 OHSAS 18001:1999 CMMI 3 Desde 2005 Abril/2006 CMMI 5 Desde 2006 Setembro/2007 Fonte: PASSOS (2006). Como resultado deste projeto houve redução de 60% em defeitos de software desde 2003, maior envolvimento, comprometimento e responsabilidade das pessoas atigindo um nível de comprometimento de 90,34% em dezembro/2004 com a implantação do CMMI 2 e 90% em maio/2005 com o CMMI 3. Os resultados também foram identificados no aumento do índice de satisfação do cliente que passou de 75%, em 2003, para 92,5% em 2005, que permitiu a conquista de novos clientes e crescimento do faturamento da empresa que passou de 51 milhões de reais em 2003 para 85,5 milhões de reais em 2005 (PASSOS, 2006). A institucionalização das normas e modelos de referência permitiu uma reflexão sobre as práticas adotadas na empresa, provocou mudanças positivas sobre a natureza do trabalho e contribuiu para o redirecionamento criativo de tarefas e comportamentos. A qualidade dos produtos e serviços gerados a partir deste projeto é hoje um dos principais diferenciais competitivos da empresa UNITECH. 4. Considerações Finais A gerência de projetos em processo de especificação de requisitos de software se 8

caracteriza por ser um conjunto estruturado de atividades para derivar, validar e manter vivos os documentos de requisitos de um software durante o processo de desenvolvimento de forma a permitir a qualidade do produto. A incorreta definição de escopo de um projeto, e mais ainda da elicitação de requisitos de software podem levar ao desenvolvimento de um produto que não atende aos objetivos para o qual o projeto e o produto de software foram planejados. A estruturação da gestão de requisitos seguindo o modelo de gerenciamento de projetos e padrões de qualidade internacional proporciona um maior formalismo que facilita a tomada de decisões pelos envolvidos. Compreender como as empresas podem progredir na gestão de projetos e qual é a real natureza da questão da maturidade nesta gestão, é importante para que os gerentes de projetos entendam as particularidades do contexto para identificar a forma pela qual a maturidade deve ser buscada, quais dimensões são mais relevantes, e dessa forma dimensionar esforços para melhoria desse processo. Em projetos de software usar a metodologia de gerência de projetos e implementar normas e modelos de referência na gestão de requisitos pode criar um detalhamento que proporcione um mecanismo eficaz para a comunicação entre as partes envolvidas, obtendo requisitos claros, completos e consensuais, necessários e fundamentais ao desenvolvimento de software com qualidade. Este trabalho mostrou que estudar a gerência de projetos de um processo genérico, o PMBoK, aplicado à produção de software, e mais especificamente ao processo de especificação de requisitos de software, e ainda, conhecer e implementar os normas e modelos de qualidade em processos de software, de padrões internacionais, o CMMI e MPS.BR, tornase importante, pois permite ampliar a produtividade, maturidade e competitividade das empresas de desenvolvimento de software e ainda acompanhar a evolução do processo de desenvolvimento de software, que abrange práticas de planejamento, engenharia e gestão visando a excelência desse processo. Referências FERNANDES, J.H.C. Qual a Prática do Desenvolvimento de Software. In: Ciência e Cultura, Brasil, v.55, n.2, p. 29-33, 2003. Disponível em: <http://cienciaecultura.bvs.br/pdf/cic/v55n2/15526.pdf>. Acesso em: 14 nov. 2006. GAVA, V. L.; ALMEIDA, P. A.; SPÍNOLA, M. M. Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais. In: Encontro Nacional de Engenharia de Produção, 24., 2004, Florianópolis. Anais... Florianópolis: ENEGEP, 2004. 1CD. IEEE COMPUTER SOCIETY. Guide to the Software Engineering Body of Knowledge, SWEBOK 2004. Los Alamitos, Califórnia: IEEE, 2004. Disponível em: <www.swebok.org >. Acesso em: 10 out. 2006. LAURINDO, F. J. B; MORAES, R. O. Gestão de projetos de TI. Vanzolini em foco, São Paulo, ano 14, n. 62, mai./jun. 2006. Disponível em: <http://www.vanzolini.org.br>. Acesso em: 07 out. 2006. MIRANDA, M. Requisitos de Software: o processo, CMM e o Unified Process, 2003. Disponível em: < http://www.innovative.inf.br/imagens/imgpalestras/requisitos-processo_cmm_rup-infonordeste2003.pdf>. Acesso em: 27 jul. 2007. PASSOS, C. Programa Integrado de Melhoria de Processos de Desenvolvimento de Software. In: Encontro da Qualidade e Produtividade em Software, 2006, Fortaleza. Disponível em: < http://www.mct.gov.br/upd_blob/0009/9509.pdf >. Acesso em 27 jul. 2007. PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2ª ed. São Paulo: Prentice Hall, 2004, 537p. PRESSMAN, R. S. Engenharia de Software. 5ª ed. Rio de Janeiro: McGraw-Hill, 2002, 843p. PROJECT MANAGEMENT INSTITUTE. Project Management Body of Knowledge, PMBoK 2000. Tradução livre, versão 1.0, Capítulo de Minas Gerais, disponibilizado em jan. 2002, 159p. Disponível em: <www.pmimg.org.br>. Acesso em fev. 2002. ROSELINO, J. E. Relatório Setorial Preliminar Setor: Software. Brasília: FINEP, 2003. Disponível em: 9

<http://www.finep.gov.br/portaldpp/relatorio_setorial/impressao_relatorio.asp?lst_setor=17>. Acesso em: 07 out. 2006. SOMMERVILLE, I. Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003, 592p. SPINOLA, M. M. Opinião. In: Vanzoline em foco, São Paulo, 2005. Edição Especial. Disponível em: <http://www.vanzolini.org.br>. Acesso em: 07 out. 2006. TAIMOUR, A. N. Why IT Projects Fail, 2005. Disponível em: < http://www.projectperfect.com.au/info_it_projects_fail.php>. Acesso em: 10 out. 2006. FUNDAÇÃO VANZOLINI. Destaque: Questão de Qualidade. Vanzolini em foco, São Paulo, ano 14, n. 61, mar./abr. 2006. Disponível em: <http://www.vanzolini.org.br>. Acesso em: 07 out. 2006. VAZ, J.C. Questão de método. Vanzolini em foco, São Paulo, ano 13, n. 58, set./out. 2005. Disponível em: <http://www.vanzolini.org.br>. Acesso em: 07 out. 2006. WEBER, K. C.; NASCIMENTO, C. J.; MARINHO, D. S. Programa Brasileiro da Qualidade e Produtividade em Software: treze anos acompanhando e disseminando a cultura da qualidade. In: Revista ProQualiti, Lavras, v.2, n.1, 2006. Disponível em: <www.mct.gov.br/upd_blob/6446.pdf>. Acesso em: 19 out. 2006. 1 0