UNIVERSIDADE DO SUL DE SANTA CATARINA JAKSON COELHO PEREIRA PROPOSTA PARA IMPLANTAÇÃO DO NÍVEL G DO MODELO MPS.BR: UM ESTUDO DE CASO Palhoça 2010
JAKSON COELHO PEREIRA PROPOSTA PARA IMPLANTAÇÃO DO NÍVEL G DO MODELO MPS.BR: UM ESTUDO DE CASO Trabalho apresentado ao Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina como parte dos requisitos para obtenção do título de Bacharel em Sistemas de Informação. Orientadora: MEng. Vera R. Niedersberg Schuhmacher Palhoça 2010
JAKSON COELHO PEREIRA PROPOSTA PARA IMPLANTAÇÃO DO NÍVEL G DO MODELO MPS.BR: UM ESTUDO DE CASO Este(a) Trabalho de Conclusão de Curso foi julgado(a) adequado(a) à obtenção do título de Bacharel em Sistemas de Informação e aprovado(a) em sua forma final pelo curso de Sistemas de Informação Trabalho apresentado ao Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina, de de 20 Local dia mês ano MEng. Vera R. Niedersberg Schuhmacher Cristina Fogaça, Msc. Profº:
AGRADECIMENTOS Agradeço a professora Vera R. Niedersberg Schuhmacher, como facilitadora, incentivadora desde projeto, atendendo todos os meus questionamentos com muita atenção e comprometimento. Aos meus pais, Anilson e Terezinha, que sempre me apoiaram a buscar todos os meus sonhos sem nunca desistir. Agradeço a todos que involuntariamente ou voluntariamente me ajudaram na conclusão desse trabalho, suportando ou incentivando a produção deste.
RESUMO Este projeto sugere melhorias no modelo de qualidade da organização, com um estudo de caso aumentando não somente a qualidade de seus produtos, mas a competitividade e a produtividade para atender um mercado cada vez mais concorrido e exigente. Para alcançar este objetivo, utilizou-se neste projeto o modelo MPSBR, para atingir o nível G de qualidade, que tem como meta aperfeiçoar a gerência de projetos e a gerência de requisitos. Foram mapeados os processos existentes na empresa relacionados à análise de requisitos e à gerência de projetos. Mapeados os processos de gerência de projeto e gerência de requisito na empresa passou-se a análise de conformidade com o nível G. Reconhecidas as necessidades realizou-se uma etapa de estudos sobre as possíveis sugestões de adequação dos níveis à realidade da empresa. A validação dessas sugestões foi realizada com a orientadora do projeto e com o coordenador de qualidade da empresa que verificou sua viabilidade. Palavras-chaves: MPSBR. Qualidade de processo. Gerencia de projetos. Análise de requisitos.
ABSTRACT This project suggests improvements in the model of quality of the organization, with a case study increasing not only the quality of its products, but the competitiveness and the productivity to assist a market more and more competed and demanding. To reach this objective it was used in this project the model MPSBR, to reach the level quality G, that has as goal improves the management of projects and the management of requirements. The existent processes were mapped in the company related to the analysis of requirements and the management of projects. Mapped the processes of project management and requirement management in the company happened itself the conformity analysis with the level G. Recognized the needs took place a stage of studies on the possible suggestions of adaptation of the levels to the reality of the company. The validation of those suggestions was accomplished with the advisor of the project and with the coordinator of quality of the company that verified its viability. Key-words: MPSBR. Process quality. Project management. Requirements analysis.
LISTA DE SIGLAS ABNT - Associação Brasileira de Normas Técnicas ALATS - Associação Latino-Americana de Teste de Software ANSI American National Stantards Institute AP - Atributos Do Processo ASQC - American Society for Quality Control CMM - Capability Maturity Model CMMI - Capability Maturity Model Integration EAP - Estrutura Analítica de Projetos GPR Gerência de Projetos GRE - Gerência de Requisitos IEC - International Electrotechnical Commission IEEE - Institute of Eletrical and Electronics Engineers IOGE - Instituições Organizadoras de Grupos de Empresas ISO - Internacional Standardization Organization ISTQB. CTFL - Certificação Foundation - Certified Tester, Foundation Level ITIL - Information Technology Infrastructure Library KPAs - Key Process Areas MA-MPS - Método De Avaliação MN-MPS - Modelo De Negócio MPS.BR - Melhoria de Processos do Software Brasileiro MR-MPS - Modelo de referência PMBOK - Project Management Body of Knowledge RAP - Resultados Esperados Dos Atributos Do Processo RUP - Rational Unified Process SEI - Software Engineering Institute SOFTEX - Programa Nacional de Software para Exportação
SUMÁRIO 1 INTRODUÇÃO...5 1.2 OBJETIVO GERAL...6 1.3 OBJETIVOS ESPECÍFICOS...6 1.4 JUSTIFICATIVA...6 1.5 ESTRUTURA DO TRABALHO...7 2 QUALIDADE...8 2.1 ENCONTRANDO A QUALIDADE...10 2.1.1 Atributos da qualidade...11 2.2 A QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE...13 2.2.1 A realidade nos projetos de software...14 2.3 CONHECENDO A MATURIDADE...14 2.3.1 SW-CMM e CMMI...15 2.3.1.1 Os níveis do SW-CMM...16 2.3.1.1.1 Nível 1: inicial...16 2.3.1.1.2 Nível 2: repetitivo...17 2.3.1.1.3 Nível 3: definido...18 2.3.1.1.4 Nível 4: gerenciado...19 2.3.1.1.5 Nível 5: otimizando...19 2.3.1.2 Modelo CMMI...20 2.3.1.2.1 Nível 1: inicial...21 2.3.1.2.2 Nível 2: gerenciado...21 2.3.1.2.3 Nível 3: definido...22 2.3.1.2.4 Nível 4: gerenciado quantitativamente...22 2.3.1.2.5 Nível 5: otimizado...23 2.4 MODELO MPS...23 2.4.1 Descrição MR-MPS...25 2.4.1.1 Processo...26 2.4.1.2 Capacidade do processo...26 2.4.2 Nível de maturidade G...29 2.4.2.1 Parcialmente gerenciado...29
2.4.2.1.1 Gerenciamento de projeto...29 2.4.2.1.2 Gerenciamento de requisitos...31 3 METODOLOGIAS...33 3.1 TIPOS DE PESQUISA...33 3.2 DELIMITAÇÕES...34 3.3 ARQUITETURA DE SOLUÇÃO...34 3.4 METODOLOGIA DE DESENVOLVIMENTO DO PROJETO...35 3.4.1 Etapa de contextualização...36 3.4.2 Etapa de Identificação...36 3.4.3 Etapa de Análise...36 3.4.4 Etapa de desenvolvimento...36 3.4.5 Etapa de validação...37 4 DESENVOLVIMENTO DO ESTUDO...38 4.1 CONTEXTUALIZAÇÃO DO ESTUDO DE CASO...38 4.2 UTILIZAÇÃO DO PMBOK...39 4.2.1 Áreas do Conhecimento...40 4.2.1.1 Gerenciamento de Integração...40 4.2.1.2 Gerenciamento de Escopo...41 4.2.1.3 Gerenciamento de Tempo...41 4.2.1.4 Gerenciamento de Custos...42 4.2.1.5 Gerenciamento de Qualidade...42 4.2.1.6 Gerenciamento de Recursos Humanos...43 4.2.1.7 Gerenciamento de Comunicação...43 4.2.1.8 Gerenciamento de Riscos...43 4.2.1.9 Gerenciamento de Aquisições...44 4.3 ÁREAS DE ESTUDO...44 4.3.1 Gerência de integração aplicada a empresa...45 4.3.2 Gerencia de escopo aplicada a empresa...47 4.4 APROXIMAÇÃO DO NÍVEL G A REALIDADE DA EMPRESA...49 4.5 GRUPOS DE PROCESSOS NA PARADIGMA...50 4.5.1 Sugestões para processos de gerência de projetos...51 4.5.2 Sugestões para processos de gerência de requisitos...56 4.6 ETAPA DE VALIDAÇÃO...57
5 CONCLUSÃO...59 REFERÊNCIAS...60 APÊNDICES...62 APÊNDICE A - LISTA DE PROBLEMAS PARA SUGESTÃO...63 APÊNDICE B - HISTÓRICO...64 APÊNDICE C - LISTA DE ERROS...66
1 INTRODUÇÃO 5 No Brasil, desenvolvimento de software está entre os maiores do mundo e a cada dia, aumenta o grau de exigência dos clientes, que cada vez mais estão buscando qualidade, rapidez e produtos feitos sob medida para atender suas necessidades. Com isso, fica claro que a empresa que não buscar formas de estabelecer uma grande maturidade nos processos de desenvolvimento de software, para atender esse novo perfil de mercado, estará correndo na direção contraria e com isso perdendo grandes oportunidades de negócio vitais para a sobrevivência de uma empresa, pois a permanência no mercado esta ligada diretamente a qualidade. Mas certificar uma empresa em algumas das normas mais importantes e conceituadas no mercado pode não ser algo muito acessível, uma certificação pode ter alto custo para empresa, esse custo para uma empresa de grande porte pode passar despercebido, mas para uma empresa que está iniciando no mercado é completamente inviável. A partir deste cenário que. o MPS.BR é um programa para melhoria de processo do software brasileiro coordenado pela associação para promoção da excelência do software brasileiro (SOFTEX o detalhamento do guia envolve a definição dos níveis de maturidade, seus processos e capacidade, além dos resultados esperados provendo uma estrutura de trabalho para uma instituição que deseje implementar o MR-MPS. ( GUIA GERAL MPS.BR V1.2, 2007, p. 4) No Brasil, uma das principais vantagens desse modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. Ligada a essa premissa de que esse modelo atende as necessidades das empresas brasileiras de pequeno porte, implementando nesse mercado um nível de satisfação que atende um vasto mercado onde cada vez mais se espera que atenda níveis de qualidade internacionais. O nível de maturidade G é responsável pelos processos de gerência de projeto e pelo levantamento de requisitos. No processo de gerência de projeto estabelecemos e mantemos planos que definem as atividades, recursos e responsabilidades do projeto.
6 A etapa de levantamento de requisitos, gerencia o levantamento de requisitos do produto e dos seus componentes e as inconsistências entre os requisitos. Dessa forma será alinhado o desenvolvimento inicial de um produto de maneira que os resultados obtidos atendam as necessidades do cliente colocando a empresa dentro de uma metodologia que tem grande aceitação no mercado nacional. 1.2 OBJETIVO GERAL O objetivo deste projeto é a análise dos processos da empresa estudo de caso. A sugestão para sua conformidade ao nível G do MPSBR. 1.3 OBJETIVOS ESPECÍFICOS A vontade de expandir para novos mercados que exigem ainda mais qualidade faz surgir a necessidade de implementar padrões de qualidade. O aumento da maturidade auxilia no desenvolvimento de um produto competitivo, trabalhando sob a necessidade da empresa em controlar seus processos no momento em que é feito o levantamento de requisitos até o momento em que são definidas as atividades para controlar o andamento do projeto. O uso do modelo MSBR como modelo de referência exige disciplina e estudo por parte das empresas, que a partir de estudos apurados sobre seus processos devem posteriormente inferir possíveis melhorias para sua adequação. 1.4 JUSTIFICATIVA
7 Este projeto se justifica pela garantia de um processo de qualidade satisfatório nos processos que serão trabalhados dentro do modelo proposto. O impacto que o MPSBR terá sobre esse desenvolvimento abrange as etapas de gerência de projetos e gerência de requisitos. Por si só o projeto se justifica, pois jogará luz aos processos e as possíveis pendências para que seja possível o alcance da maturidade no nível G. Conforme modelo SOFTEX (2007) a fase de gerência de projeto visa, definir estratégias para as atividades, recursos e responsabilidades do projeto, documentação sobre o desenvolvimento do projeto, auxiliar na realização de correção quando necessário e a realização de manobras para melhorar o desempenho do projeto. A medida que a organização amadurece esse processo também evolui. O nível G de maturidade MPS.BR propõe a gerência de levantamento de requisitos referente ao projeto que será desenvolvido, seus produtos e componentes. A proposta do nível G permite o reconhecimento de inconsistências entre os requisitos, planos do projeto e a definição do produto 1.5 ESTRUTURA DO TRABALHO A monografia foi estruturada da seguinte forma: no primeiro capítulo foi abordada a apresentação do problema a ser resolvido na presente monografia, a justificativa do trabalho, os objetivos gerais e específicos que esperam ser atingidos. Abordando os principais tópicos o capítulo 2 da fundamentação teórica ao trabalho: qualidade, MPS.BR. No capítulo 3 é apresentada a metodologia de desenvolvimento deste projeto. O capítulo 4 apresenta o processo de desenvolvimento deste trabalho e aplicação da metodologia proposta no capítulo 3. As considerações finais desta monografia estam no capítulo 5.
2 QUALIDADE 8 Embora o controle relacionado a qualidade de software tenha um foco maior nas últimas décadas, historicamente a busca por qualidade é muito antiga. Um registro de mais de 4 mil anos relata que os egípcios haviam criado uma forma de parametrizar a medida utilizada em suas construções. O cúbico medida criada a partir do comprimento do braço do faraó reinante. Todas as construções deveriam seguir esse padrão se não atendida a essa especificações a penalidade poderia chegar a morte do responsável que para evitar essa penalidade comparava periodicamente a fidelidade da medida Juran e Gryna,(1988 apud KOSCIANSKI; SOARES, 2007). Assim como os egípcios é possível encontrar inúmeros trabalhos realizados com resultados extraordinários por outros povos: os grandes templos construídos na Grécia e Roma antiga, os feitos de navegação no século XV, as catedrais medievais. Em todas essas realizações não se dispunha de instrumentos de precisão nem técnicas sofisticadas Vincent (2004 apud KOSCIANSKI; SOARES, 2007). Em geral, espera-se que para obter um aumento na qualidade no desenvolvimento sejam necessários mais recursos ou mais tecnologias. Um grande marco na história da qualidade foi, com certeza, a revolução industrial. Esse período também é associado a profundas mudanças econômicas e sociais, como o início da automação e o surgimento do consumo de massa. A criação de diversas indústrias levou rapidamente à concorrência entre elas, o que, por sua vez, desencadeou um processo de melhoria contínua que perdura até hoje. O aumento da eficiência tornou-se uma condição imprescindível para garantir a sobrevivência. (KOSCIANSKI; SOARES, 2007, p. 18.) Um exemplo claro sobre isso foi o fechamento de diversas indústrias de diferentes segmentos, por não atenderem o mercado com a qualidade necessária. Alguns dos grandes organismos de qualidade nasceram na segunda metade do século XX. Na década de 1940 surgiram vários organismos ligados à
qualidade; por exemplo, a American Society for Quality Control (ASQC), a Associação Brasileira de Normas Técnicas (ABNT) e, ainda, a Internacional Standardization Organization (ISO). A Segunda Guerra Mundial também contribuiu com o processo, Quando as técnicas de manufatura foram aprimoradas para fabricação de material bélico (KOSCIANSKI; SOARES, 2007, p. 19). 9 O Japão neste período começa a se destacar como um importante pólo de qualidade contribuindo com novos métodos como o método de Taguchi, a metodologia 5S e os diagramas de causa e efeito de Ishikawa, também conhecido como espinha de peixe. Figura 1 - Diagrama de Ishikawa Fonte: Koscianski e Soares (2007, p.18) A figura 1 apresenta um diagrama de Ishikawa típico. Esse modelo foi desenvolvido para auxiliar a identificar as causas de problemas e, de preferência, utilizado em uma reunião em que todos os envolvidos discutam livremente sobre o problema em questão. Esse problema é representado no eixo central do diagrama. Após a representação do problema, apresentam-se os elementos que irão compor o cenário em linhas diagonais. Esses elementos são chamados de categorias Koscianski e Soares (2007 p18). Segundo Koscianski e Soares (2007 p 20) para cada categoria identifica fatores (causas) que possam contribuir para aumentar ou reduzir o problema
10 (efeito)[...] Seguindo os anos do pós guerra, os computadores ainda tinham seu uso restrito a universidades e para áreas militares, mas alguns anos mais tarde quando os computadores tornaram-se mais acessíveis e um número maior de usuários começou a surgir gerando o aumento da demanda por softwares fazendo com que a qualidade ocupasse um lugar de destaque Segundo Koscianski e Soares (2007 p 20). 2.1 ENCONTRANDO A QUALIDADE Deparamo-nos com um mundo globalizado que todos os dias nos obriga a enfrentar esses impactos causados por esse fenômeno. Neste contexto nos deparamos com a informática um dos elementos que mais impactam. A grande evolução tecnológica nos permite hoje, transmitir dados, informações e conhecimento para todos os continentes. (INTHURN, 2001, p. 3) As tecnologias de informações quebraram as barreiras da comunicação, mostrando um novo mundo e modificando a própria estrutura da indústria e do consumo. (INTHURN, 2001, p. 3) A preocupação da indústria deixou de ser apenas com o produto e as fases de desenvolvimento do seu produto e posterior a venda dele. O capital intelectual passou a ser uma preocupação, pois a qualidade está ligada diretamente a esse fator que de acordo com Autora Inthurn (2001), a qualidade é um fator de competitividade que se mostra cada vez mais presente no plano estratégico das organizações. (INTHURN, 2001, p. 3) Essa nova postura no cenário socioeconômico, sócio mundial, está voltada cada vez mais para a qualidade. Isto tem forçado as organizações a adotarem políticas frente ao consumidor, empregado e à sociedade em geral. Uma compreensão mais adequada do conceito de qualidade é muito mais importante do que a palavra ou frase a ser utilizada como rótulo ou jargão, pois não importa como e quais palavras sejam utilizadas, desde que se entenda o conceito com clareza. (INTHURN, 2001, p. 6)
11 O mais relevante é o fato de se estar educado para a qualidade. É conhecer seus princípios e compreender, com clareza, os mecanismos que a compõem. Desta forma, a qualidade deve ser conceituada e explicada da maneira mais simples e clara possível, não utilizando frases prontas, mas fazendo as pessoas entenderem realmente o processo, como e porque ele acontece. Neste processo de entendimento do conceito de qualidade, é importante perceber que sempre estarão envolvidos dois personagens principais. O produtor da qualidade: responsável por gerar produtos ou serviços e, o consumidor da qualidade: responsável por utilizar estes produtos e serviços. (INTHURN, 2001 p.6) Figura 2 - Produtor e Consumidor Fonte: Inthurn (2001 p.6) O mecanismo da qualidade só se completará quando houver uma perfeita sincronização entre o produtor que ofertará o produto ou serviço, associada à satisfação do consumidor que utilizará este produto ou serviço. Quando uma dessas partes não estiver interagindo satisfatoriamente, é muito provável que a qualidade não existirá, ou estará comprometida ou prejudicada (INTHURN, 2001 p.6). 2.1.1 Atributos da qualidade Segundo Inthurn (2001), aumentar a produtividade significa produzir cada vez mais e/ou melhor, com cada vez menos.
12 Figura 3 - Produtividade = Qualidade / Custos Fonte: Inthurn (2001 p.7) Assim, para aumentar a produtividade de uma empresa, é necessário que o produto atenda às necessidades do cliente, tendo um baixo custo e boa qualidade. Figura 4 - Produtividade = Valor Reduzido/Valor Consumido Fonte: Inthurn (2001 p.7) Para Deming (apud INTHURN, 2001, p. 7), a produtividade é aumentada pela melhoria da qualidade, mas este fato é conhecido por uma seleta minoria de pessoas. A produtividade tem relação direta com os resultados obtidos e os recursos utilizados durante o processo. Figura 5 - Produtividade = Resultados Obtidos / Recursos disponíveis consumidos Fonte: Inthurn (2001 p.7)
13 De acordo com Inthurn (2001) ter maior produtividade entre todos os seus concorrentes significa ser competitivo. Com isso, o que garante a sobrevivência da empresa é a própria competitividade. Garantir que uma empresa permaneça no mercado está diretamente ligado a uma equipe de pessoas que saiba montar e operar um sistema, que seja capaz de projetar um produto/serviço que consiste a preferência do consumidor a um custo inferior ao de seus concorrentes (INTHURN,2001, p8). Assim pode-se afirmar que sem qualidade não ocorre produtividade e vice-versa. Quando se discute o monitoramento da qualidade na produção de software, deve-se levar em consideração que o controle de todo ciclo de produção de um software deve extrair ao máximo a produtividade buscando uma constante evolução do processo de desenvolvimento de um software. 2.2 A QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE No início dos anos 80, surgiram os primeiros conceitos sobre qualidade de software. Isto teve início no trabalho de desenvolvedores e testadores. Cada fase da atividade passava por uma conferência, com isso, garantindo que cada etapa estivesse completa e bem sucedida. (BARTIÉ, 2002, p.4). [...] muitas organizações foram formadas e muitos dos padrões que utilizamos hoje nasceram nessa época, como os padrões americanos formados pelo IEEE (Institute of Eletrical and Electronics Engineers) e ANSI (American National Stantards Institute) e os internacionais como ISO (International Stantards Organization). No entanto, foi o modelo CMM (Capability Maturity Model), elaborado pelo Software Engineering Institute, que ganhou maior dimensão e importância para as organizações de software, tornando-se um modelo de avaliação mas reconhecido internacionalmente (BARTIÉ, 2002, p.4).
2.2.1 A realidade nos projetos de software 14 Grande parte das organizações tem consciência de que a tecnologia da informação tem um grande valor estratégico para viabilizar o aprimoramento e a inovação de seus produtos e serviços. Segundo Bartié (2002,p. 6) o que permanentemente vemos é um festival de amadorismo e ineficiência ao nos depararmos com o processo de desenvolvimento de um software ou mesmo uma necessidade de mudanças para adaptação as novas necessidades do mercado. Segundo Bartié (2002), as indústrias não estão preparadas para atender as rápidas necessidades dos mercados simplesmente porque não investiram no aperfeiçoamento de seus processos internos. Boa parte das empresas que fornecem softwares a organizações podem ser consideradas amadoras, ou seja, desconhecem ou não aplicam da forma correta um processo de engenharia de software. O resultado disso, é que não existe qualquer garantia de que o software será entregue no prazo correto e a custos negociados. E ainda existe um alto risco de que esse projeto venha a se perder no meio do caminho virando um grande problema. 2.3 CONHECENDO A MATURIDADE Um dos objetivos de se implantar um processo de qualidade de software é garantir o gerenciamento do nível de qualidade do produto. Muitas empresas já descobriram da pior maneira que softwares não adequados, além de garantir uma péssima imagem da empresa, pode também elevar em muito os custos da produção desse produto, causando prejuízo (BARTIÉ 2002, p. 8). A grande maioria dos problemas de desenvolvimento está relacionado à falta de controle do processo de desenvolvimento, e as grandes indústrias de software já perceberam isso. A cada ano que passa, segundo (BARTIÉ, 2002, p.8), informações, técnicas, metodologias, ferramentas e empresas especializam-se em
assuntos cada vez mais voltados a como aprimorar o processo de engenharia de software [...]. Um dos mais importantes modelos de avaliação da maturidade organizacional que está no mercado foi idealizado pelo Software Engineering Institute (SEI) como explica Bartié (2002, p. 8): 15 um centro de desenvolvimento e pesquisa patrocinada pelo departamento de Defesa dos Estados Unidos e Filiado à Universidade Carnegie Mellon. Sua missão foi produzir um trabalho que possibilitasse às organizações aperfeiçoar a qualidade final de seus produtos finais [...]. Como resultado desse trabalho criou-se o modelo Capability Maturity Model (CMM), que tem como foco o processo de software na proposta de melhoria contínua, buscando disciplina e um controle mais adequado ao processo de desenvolvimento e manutenção do software. Esses seriam os pilares para se obter um produto com excelente qualidade. (BARTIÉ, 2002, p.8) 2.3.1 SW-CMM e CMMI O Capability Maturity Model (CMM), definido pelo Software Engineering Institute (SEI), que segundo (BARTIÉ, 2002 p. 9) descreve uma estrutura de trabalho que possui todos os elementos necessários para tornar um processo de desenvolvimento de software mais eficiente e controlado. O CMM tem sua base num modelo evolutivo. Dois dos principais modelos criados pelo SEI (Software Engineering Institute) para melhoria de processos são o SW- CMM e o CMMI. Criado no final da década de 1980 apenas para software, o SW-CMM obteve grande sucesso ao gerar novos padrões para engenharia de sistemas. Posteriormente, como uma evolução dos vários CMMs existentes foi criado o modelo CMMI (KOSCIANSKI; SOARES, 2007 p. 95). Por ser específico à área de software, não contempla as áreas de grande importância da empresa, como Recursos Humanos e Finanças. Mas mesmo assim sua aplicação não garante o sucesso da empresa, embora possa ser um grande
16 diferencial na melhora da eficácia e da competitividade. O grande foco do SW-CMM são os processos, fator com maior potencial de melhoria em curto prazo. (KOSCIANSKI; SOARES, 2007 p. 95) 2.3.1.1 Os níveis do SW-CMM O CMM está dividido em cinco níveis que servem como um avaliador do processo de maturidade da empresa. O objetivo principal do SW-CMM é que as organizações conheçam e melhorem seus processos de desenvolvimento de software com a implementação de práticas definidas. A melhoria de um processo é baseada em vários pequenos passos, não em grandes revoluções. O SW-CMM organiza os passos evolucionários em cinco níveis, que definem uma escala para avaliar a maturidade do processo dentro da empresa. (KOSCIANSKI E SOARES, 2007 p. 96) Cada nível do SW-CMM com exceção do primeiro é composto por diversas Áreas-chave de Processo (Key Process Areas [KPAs]). Cada uma delas identifica um grupo de atividades que estão relacionadas, realizando um conjunto de metas. Além disso, são cumulativas, ou seja, para uma empresa que atinja o nível 5 é necessário satisfazer todas as chaves dos níveis 2 a 5. Os cinco níveis de maturidade do SW-CMM são o Inicial, Repetitivo, Definido, Gerenciado e Otimizado. A seguir iremos descrever um pouco sobre cada nível. 2.3.1.1.1 Nível 1: inicial Nesse nível poucos processos são definidos e o sucesso depende muitas vezes do individualismo. Organizações nesse nível, muitas vezes são até bemsucedidas, mas isso em geral se restringe ao desenvolvimento de produtos com os quais já estiveram envolvidas anteriormente (WEINBERG, 1994 apud KOSCIANSKI;
17 SOARES, 2007, p.96). As organizações que estão no nível 1 apresentam diversas falhas no planejamento que acaba gerando diversos problemas ocasionando dificuldades quando são realizados previsões, pois quando são feitas contêm erros. Geralmente os cronogramas e planos são irrealistas e acabam passando por alterações durante o desenvolvimento do produto. Nesse ambiente os imprevistos são comuns e, para serem resolvidos, a capacidade individual terá que ser existir. E também a falta de credibilidade no planejamento leva a um desenvolvimento confuso, já que, todos estão acostumados à idéia de que previsões e planos não funcionam. E é muito comum ver que o desenvolvimento segue a partir dos requisitos, com ausência total de qualquer de documentação, essa que só é levada a sério por profissionais que compreendem sua importância. (KOSCIANSKI; SOARES, 2007 p.97) E como Koscianski e Soares (2007, p.97) descrevem Para que um gerente possa administrar uma equipe nessas condições, é preciso iniciar realizando uma mudança cultural. Dificilmente a equipe acreditará nos benefícios de processos bem organizados [...] 2.3.1.1.2 Nível 2: repetitivo Uma organização que possui maior probabilidade de cumprir compromissos de requisitos, prazos, mas desde que sejam semelhantes a projetos já realizados anteriormente. Como exemplo o autor sugere o seguinte: organizações especializadas em desenvolvimento de softwares baseados em Web, já possuem conhecimento nessa área, portanto desenvolver outro projeto nessa área se torna mais simplificado. Já um projeto para uma área desconhecida para essa organização corre o risco de não obter o mesmo sucesso. (KOSCIANSKI; SOARES, 2007 p. 97) Existe a preocupação com a gerência do projeto. Práticas de realizar, reuniões semanais e de acompanhar o cronograma constantemente definas pelos gerentes e seguidas pela equipe. Dessa forma os gerentes conseguem identificar problemas. Uma empresa que está no nível 2 está apta a realizar seus próprios
18 projetos, porém sofre com a mudança. Podendo ficar desorientada com facilidade ao prever o resultado da utilização de novas ferramentas e métodos. Acontecendo o mesmo para o desenvolvimento de novos produtos. (KOSCIANSKI; SOARES 2007, p. 97) Segundo Koscianski e Soares (2007, p. 97) as áreas chaves compreendem: Gestão dos requisitos, Planejamento de projetos, Supervisão e acompanhamento de projetos, Gestão da subcontratação, Grupo de garantia de qualidade e Gestão de configurações. 2.3.1.1.3 Nível 3: definido Nesse nível a empresa não fica presa apenas a repetir os sucessos do passado, mas estabelece uma estrutura de processos que permitem com que ela encare novos projetos e mudanças. A organização consegue manter-se dentro do processo mesmo em períodos de crise. As ferramentas passam a ser aplicadas de forma sistemática, padronizada e coerente (KOSCIANSKI; SOARES 2007 p. 98). Desenvolver o software já passa a contemplar a criação de uma documentação sólida, o que ajuda o gerente e a equipe a terem melhor controle. Conhecendo bem o seu papel a equipe tem a exata noção do que pode impactar eventuais falhas na qualidade do projeto. Para que cada membro da equipe desenvolva seu trabalho da melhor forma, há preocupação de que todos tenham os conhecimentos e habilidades necessárias. Como o processo é bem definido, caso um desenvolvedor abandone o projeto antes do seu término, o impacto é relativamente menor que nos níveis anteriores (KOSCIANSKI; SOARES 2007, p. 98) Segundo Koscianski e Soares (2007, p. 98) as áreas-chave do nível 3 são a implantação do grupo de engenharia de processos de software, o processo-padrão de software no âmbito da organização, implantação de programas de treinamento a
gestão integrada de projetos e a coordenação entre os grupos que participam de projetos de sistemas. 19 2.3.1.1.4 Nível 4: gerenciado Nesse nível, de acordo com os autores Koscianski e Soares (2007 p. 99), a administração de processos e produtos evolui para um tratamento quantitativo. Isso não implica que apenas agora devam ser coletadas métricas de processo [...] Uma base de dados de processo de software é utilizada para coletar informações e analisar dados disponíveis a partir dos processos de software definidos. São definidas métricas quantitativas para avaliar os processos e os produtos de software. Os riscos envolvidos no aprendizado para desenvolvimento em um novo domínio de aplicações são cuidadosamente gerenciados. Como resultado desse maior controle, coleta de dados e gerenciamento de riscos, os produtos de software tendem a apresentar maior qualidade. (KOSCIANSKI; SOARES, 2007 p. 99) Conforme Koscianski e Soares (2007, p. 97) as áreas-chave do nível 4 são a gestão quantitativa dos processos e gestão da qualidade de software. 2.3.1.1.5 Nível 5: otimizando Segundo Koscianski e Soares (2007, p. 98) Neste nível os processos estão em melhoria contínua, sendo otimizados para as necessidades de cada momento. Os gerentes identificam pontos fracos de cada processo e agem de forma pró-ativa para que estes sejam melhorados. Os resultados obtidos servem de análise para obter custo benefício de novas tecnologias. A busca de novas tecnologias e processos é buscada pela equipe afim de que poderia tornar a forma de trabalho ainda mais produtiva. Os defeitos são identificados e resolvidos, e suas
20 causas são estudadas, para evitar que sejam repetidos. A experiência é sempre utilizada (KOSCIANSKI; SOARES, 2007, p. 98). Para Koscianski e Soares (2007, p. 98) as áreas-chave do nível 5 são a prevenção dos defeitos, gestão da evolução tecnológica e gestão de mudanças de processos. 2.3.1.2 Modelo CMMI O sucesso causado pelo SW-CMM fez com que outros modelos fossem criados, áreas como gestão de recursos humanos (P-CMM), de aquisição de software (SA-CMM) e de engenharia de sistemas (SE-CMM) foram contempladas por modelos complementares. Porém todos esses padrões que foram criados apresentam estruturas, formatos e termos diferentes, causando muita confusão quando necessário o uso de mais de um deles simultaneamente. Visando uma integração desses diversos modelos deu-se uma evolução do CMM e foi criado o CMMI. O modelo Capability Maturity Model Integration (CMMI), foi projetado prevendo a possibilidade de integração com outros modelos. Todos os textos desenvolvidos são consistentes e compatíveis com a ISO/IEC TR 15504. O objetivo do CMMI assim como o SW-CMM é auxiliar na função de guia para que a melhoria de processos na organização e também da habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços. Com isso, espera-se que a organização atenda os prazos, tornando a organização mais eficiente e construindo softwares com menos erros (KOSCIANSKI; SOARES, 2007 p. 102). os níveis do CMMI são designados pelos números de 1 a 5: inicial, gerenciado, definido, gerenciado quantitativamente e otimizado. Os níveis de maturidade consistem em um conjunto predefinido de áreas do processo. É importante salientar que quando uma organização atinge as práticas necessárias para estar em um nível, isto significa que pratica todos os requisitos necessários dos níveis imediatamente anteriores.[...] (KOSCIANSKI; SOARES, 2007 p. 106)
2.3.1.2.1 Nível 1: inicial 21 No primeiro nível do CMMI os processos estão bagunçados. Não possui um ambiente estável para desenvolvimento de software, não existem padrões e se existem não são seguidos. Problemas nos prazos e custos persistem e também o cumprimento dos requisitos. E a organização ainda depende do talento individual (KOSCIANSKI; SOARES, 2007 p. 106). O fato de que uma organização contemple o nível 1 e tenha problemas com o processo de desenvolvimento segundo (KOSCIANSKI; SOARES, 2007 p. 106). [...] não significa necessariamente que seus produtos finais são ruins. É possível, até mesmo, que bons produtos sejam entregues. Entretanto isso se deve ao trabalho dos heróis que fazem muitas horas extras para compensar planejamentos mal feitos. Pode ocorrer também de os produtos serem entregues, mas a um custo mais alto ou com prazo excessivo. Algumas particularidades em muitas organizações em que processos estão desorganizados é que dificilmente será possível repetir sucessos anteriores, levando em consideração o fato de que esse sucesso foi determinado por habilidade individual e não da organização. Para Koscianski e Soares, (2007) A ausência de um técnico-chave nos projetos seguintes significa que sucessos serão difíceis de alcançar, pois um dos seus principais responsáveis não está mais presente. 2.3.1.2.2 Nível 2: gerenciado De acordo com Koscianski e Soares, (2007) os projetos da organização possuem requisitos gerenciados e processos planejados, medidos e controlados. As práticas possibilitam que a organização cumpra os planos no desenvolvimento dos projetos. Com grande preocupação em seguir o cronograma de atividades os processos e serviços são gerenciados. Realizando um monitoramento constante das
22 atividades, com isso, a previsão de problemas é realizada com antecedência influenciando diretamente nas atividades corretivas. Datas para entregas de pequenas partes dos produtos são estabelecidas entre um acordo com os stakeholders e revisadas, com os produtos, sempre que necessário. O monitoramento feito pelos gerentes aumenta consideravelmente as chances de que os prazos serão cumpridos (KOSCIANSKI; SOARES, 2007, p.107). 2.3.1.2.3 Nível 3: definido Como explica Koscianski e Soares, (2007) os processos são bem caracterizados e entendidos. A padronização de processos possibilita maior consistência nos produtos gerados pela organização. Na descrição dos processos são usados padrões, procedimentos, ferramentas e métodos bem definidos. Esses fatores diferenciam o nível 3 do nível 2. Organizações no nível 2 podem variar padrões, descrições de processo e procedimentos a cada projeto. No nível 3, isso não ocorre mais: os procedimentos são padronizados e devem prever a aplicação em projetos diferentes. Outra distinção em relação ao nível anterior é o maior nível de detalhe e rigor na descrição dos processos (KOSCIANSKI; SOARES, 2007 p. 107). 2.3.1.2.4 Nível 4: gerenciado quantitativamente De acordo com Koscianski e Soares, (2007), os processos são selecionados para contribuir com o desempenho geral dos demais processos. São controlados usando métodos estatísticos e outras técnicas quantitativas. Nesse nível dados são coletados e analisados estatisticamente, auxiliando no desempenho da empresa. E para Koscianski e Soares, (2007) Eventuais problemas específicos que ocasionem variações nas medidas são corrigidos para prevenir futuras ocorrências. As medidas de qualidade e de desempenho do processo são armazenadas em um repositório [...].
23 O nível 4 tem um grande diferencial com relação ao anterior. Aumento da previsibilidade do desempenho de processos, graças ai controle quantitativo (KOSCIANSKI; SOARES, 2007, 108). 2.3.1.2.5 Nível 5: otimizado Os processos estão em constante processo de melhora, levando em consideração o entendimento qualitativo. Essa melhora se da com o uso de inovações e novas tecnologias. Que segundo Koscianski e Soares (2007, p.108). Objetivos quantitativos de melhoria de processos são estabelecidos, continuamente revisados de acordo com os negócios da organização e usados como critério no gerenciamento. Os efeitos da implantação da melhoria de processos são medidos e avaliados. A evolução dos processos é responsabilidades de todos não apenas uma ordem específica dos níveis hierárquicos mais altos. Desta forma, é possível que seja criado um ciclo de melhoria contínua dos processos, evitando-se acomodação e, eventualmente, uma volta a níveis inferiores do CMMI (KOSCIANSKI; SOARES, 2007, p. 108). 2.4 MODELO MPS Para SOFTEX (2009) o modelo MPS está fundamentado nos conceitos de maturidade e capacidade de processos para avaliação e melhoria da qualidade no desenvolvimento de software e serviços relacionados. Uma das metas do programa MPS.BR é definir e aprimorar um modelo de melhoria e avaliação de processo de software, visando preferencialmente às micro, pequenas e médias empresas, 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 modelo MPS estabelece um modelo de processos de software e um processo e um método de avaliação de processos. Esta
24 estrutura fornece sustentação e garante que o modelo MPS esteja sendo empregado de forma coerente com as suas definições. O modelo MPS estabelece também um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software (SOFTEX, 2009, p.12). A construção desse modelo, assim como, modelo de melhoria e avaliação, possui fundamento nas seguintes normas técnicas ISO/IEC 12207:2008 [ISO/IEC 2008a] e ISO/IEC 15504-2 [ISO/IEC, 2003] adaptando as organizações de seu interesse (SOFTEX, 2009 p.12). O MPS está dividido em 3 componentes como mostra SOFTEX (2009) Modelo de referência (MR-MPS), método de avaliação (MA-MPS) e modelo de negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo MPS. O Modelo de Referência MR-MPS possui os requisitos que os processos das organizações precisam atingir para estar dentro do padrão MR-MPS. Ele contém as definições dos níveis de maturidade, processos e atributos do processo, [...] com os requisitos de modelos de referência de processo da Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003] (SOFTEX, 2009, p.13). [...]o guia de avaliação contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). O processo e o método de avaliação MA-MPS estão em conformidade com a Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003] (ISO/IEC, 2003 apud SOFTEX, 2009 p. 13). O modelo de negócio MN-MPS especifica as regras de negocio para como deve-se implementar o MR-MPS. [...]pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de empresas pelas Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio de cursos, provas
e workshops[...] (SOFTEX, 2009, p.13). 25 Além das normas internacionais como. International Organization for Standardization (ISO) e International Electrotechnical Commission (IEC) que servem como base técnica para o MPS. 2.4.1 Descrição MR-MPS O MR-MPS Está dividido em níveis de maturidade o modelo MR-MPS, formando por uma combinação de processos e, possui a seguinte definição para dos processos: A definição dos processos segue os requisitos para um modelo de referência de processo apresentados na ISO/IEC 15504-2, declarando o propósito e os resultados esperados de sua execução. Isso permite avaliar e atribuir graus de efetividade na execução dos processos. [...] estando relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade (SOFTEX, 2009, P.16). Os níveis de maturidade são os parâmetros para a evolução da organização, representando melhoria na implementação de processos na organização. E graças a identificação do nível de maturidade que é possível tomar perceber qual desempenho futuro ao executar um ou mais processos. De acordo com SOFTEX (2009, p.16) os níveis são: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A progressão durante os níveis de maturidade acontece a partir do nível G e segue até o nível A. E para SOFTEX (2009) [...] cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. E para se atingir um dos níveis de qualidade é necessário que os resultados esperados em cada processo sejam alcançando com sucesso. Essa divisão dos níveis de maturidade em sete estágios visa contemplar às micros e
26 pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos (SOFETX, 2009, p.16) 2.4.1.1 Processo Os processos no modelo MR-MPS expostos a medida que seus propósitos e resultados são detalhados. Os propósitos são os objetivos que se pretende atingir com a utilização do processo. E os resultados são frutos do desenvolvimento eficaz do processo. Esse resultado pode ser visualizado por um produto finalizado ou por uma mudança significativa na forma como se executa esse processo (SOFTEX, 2009, p.16). 2.4.1.2 Capacidade do processo Para SOFTEX (2009) a capacidade do processo é representada por um grupo de atributos de processos em termos de resultados esperados. A capacidade está diretamente ligada ao grau de aprimoramento em que processo está sendo desempenhado pela organização. A medida que a organização evolui para um nível de maturidade, a forma como o processo será executa passará a ter que atender um novo padrão. (SOFTEX, 2009, p.16) O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G
27 para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido neste nível superior (SOFTEX, 2009, p.17). Existem 9 níveis de capacidade dos processos e são descritos por atributos de processos(ap). E como cada atributo será explorado utilizando os respectivos resultados esperados de atributos de processo (SOFTEX, 2009, p.17). Existem nove atributos de processo que são: O processo sendo executado. Esse atributo mostra quanto se atingiu de seu propósito; O processo é gerenciado. Esse atributo demonstra quando da execução desse projeto foi gerenciado; Atributo responsável pelo gerenciamento dos produtos de trabalho do processo. Esse atributo é responsável pela evolução do produto, uma medida da sua produção; O processo é definido. Esse atributo é responsável por monitorar o quanto um processo padrão é mantido para apoiar a implementação do processo definido; O processo é medido. Atributo relacionado a resultados de medição usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e auxilia no alcance dos objetivos de negócio definidos; O processo é controlado. Atributo que controla de forma estatística para produzir um processo estável, capaz e previsível dentro de limites estabelecidos; O processo é objeto de melhorias e inovações. Monitorando mudanças no processo. Identificá-las a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo; O processo é otimizado continuamente; Controle sobre as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos importantes na..
28 Nível Processos Atributos de processos A AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 B Gerência de Projetos GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2, AP 4.1 e AP 4.2 C D Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Verificação VER Validação VAL Projeto e construção do produto PCP Integração do produto ITP Desenvolvimento de requisitos DRE Projeto e construção do produto PCP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 E F Avaliação e melhoria do processo organizacional AMP Definição do processo organizacional DFP Gerência de recursos humanos GRH Gerência de reutilização GRU Gerência de projetos GPR (evolução) Aquisição AQU Gerência de Configuração GCO AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1 e AP 2.2
Gerência de Portfólio de Projetos GPP Garantia da Qualidade GQA Medição MED 29 G Gerência de Requisitos GRE Gerência de Projetos GPR AP 1.1 e AP 2.1 Quadro 1 - Níveis de maturidade, processos e os atributos de processo correspondentes Fonte: PROGRAMA NACIONAL DE SOFTWARE PARA EXPORTAÇÃO, 2009, p. 21 Segundo o autor SOFTEX (2009) Os atributos de processo AP 4.1, AP 4.2, AP 5.1 e AP 5.2 somente devem ser implementados para os processos críticos da organização/unidade organizacional, selecionados para análise de desempenho. 2.4.2 Nível de maturidade G 2.4.2.1 Parcialmente gerenciado Esse nível é composto pelos processos gerência de projetos e gerência de requisitos (SOFTEX, 2009, p.25). 2.4.2.1.1 Gerenciamento de projeto autor é: O propósito do gerenciamento de projetos nesse nível de acordo com o De acordo com o SOFTEX, (2009) a finalidade do processo Gerência de Projetos é formar e sustentar planos que definem as atividades, recursos
30 e responsabilidades do projeto, bem como fornecer informações sobre o andamento do projeto que aceitem a realização de correções quando houver problemas com o andamento do projeto. A intenção desse processo evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são adicionados, de forma que a gerência de projetos passe a ser realizada com fundamento no processo decidido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter uma ênfase quantitativa, mostrando a alta maturidade que se espera da organização. A partir desse propósito são esperados a partir do nível G os seguintes resultados como é descrito pelo SOFTEX (2009): O alvo do trabalho para o projeto é definido; As atividades e os produtos projeto são definidas utilizando métodos apropriados; O modelo e as atividades do período de desenvolvimento são definidos; O orçamento e o cronograma do projeto, e a definição de pontos de controle, são estabelecidos e mantidos; A identificação de riscos e quais os seus impactos, são estabelecidos e documentados; Os desenvolvedores para o projeto são planejados levando em consideração o conhecimento e o perfil necessário para executá-lo; Os recursos e o ambiente de trabalho; Os dados importantes do projeto são identificados e planejados com forme a maneira de coleta, armazenamento e distribuição. Uma maneira de acessá-los é definida,questões de privacidade e segurança; Um plano geral para a execução do projeto é definido com um conjunto de planos específicos; A viabilidade projeto, considerando as restrições e os recursos disponíveis. Caso necessário, ajustes são realizados; Revisão do plano do projeto é realizada com todos os envolvidos; O projeto é gerenciado seguindo o plano projeto e outros planos que afetam o projeto e a documentação é realizada; O gerenciamento das partes interessadas pelo projeto; De acordo com o planejamento, revisões são realizadas em pontos definidos no projeto; Apontamentos de problemas identificados e o resultado da análise de questões relacionadas, incluindo dependências críticas, são estabelecidos e recebem a devida atenção das pessoas envolvidas. Planos para corrigir possíveis falhas com relação ao planejado e para evitar a repetição dos problemas são identificados, implementados e acompanhados até a sua conclusão.
2.4.2.1.2 Gerenciamento de requisitos 31 O propósito do gerenciamento de requisitos nesse nível segundo o autor SOFTEX (2009) gerenciar os requisitos do produto e das partes do produto a ser desenvolvido com esse projeto e identificar possíveis inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto Os resultados esperados com o gerenciamento de requisitos descrito pelo autor SOFTEX (2009) são os seguintes: Os requisitos são entendidos, avaliados e, de acordo com o cliente são aceitos; a equipe deve seguir com os requisitos aprovados; Após definidos os caminhos a serem seguidos entre os requisitos e os produtos de trabalho é mantida; Revisões em no projeto são realizadas buscando encontrar inconsistência em relação aos requisitos; As mudanças nos requisitos devem ser monitoradas ao longo do projeto. 2.4.3 Sobre os outros níveis O nível g é a apenas o primeiro deles, ainda temos outros que possui um grau de importância igual, porém a cada novo nível que é atingido a maturidade da empresa se torna maior. E uma grande parte de seus níveis funciona de forma acumulativa com relação ao nível anterior, agregando a atividade ou usando de forma mais detalhada. Nível F que é composto pelo nível anterior somando aos processos aquisição, garantia da qualidade, gerência de configuração, gerência de portfólio de projetos e medição (SOFTEX, 2009, p.29). Nível E que segue a mesma lógica, sendo formado pelos processos anteriores incrementados com os seguintes processos: avaliação e melhoria do processo organizacional, definição do processo organizacional, gerência de recursos humanos e gerência de reutilização. o processo gerência de projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no processo definido para o
projeto e nos planos integrados (SOFTEX, 2009, p.34). 32 Nível D composto pelos processos anteriores e mais os processos desenvolvimento de requisitos, integração do produto, projeto e construção do produto, validação, e verificação (SOFTEX, 2009, p.38). Nível C formado pelos níveis anteriores acrescidos dos processos desenvolvimento para reutilização, gerência de decisões e gerência de riscos (SOFTEX, 2009, p.43). Nível B é o acúmulo dos níveis anteriores mais novos resultados para atender aos objetivos de gerenciamento quantitativo (SOFTEX, 2009, p.46). Nível A (SOFTEX, 2009) formado por todos os níveis anteriores e especializando cada processo de cada nível a fim de atingir o maior grau de maturidade.
3 METODOLOGIAS 33 O capítulo 3 descreve os procedimentos metodológicos utilizados no desenvolvimento da monografia. 3.1 TIPOS DE PESQUISA Segundo Gil (2002), uma pesquisa, tendo em vista seus objetivos, pode ser classificada como pesquisa exploratória. Esta pesquisa tem como objetivo proporcionar maior familiaridade com o problema, com vistas a torná-lo mais explícito. Pode envolver levantamento bibliográfico, entrevistas com pessoas experientes no problema pesquisado. Geralmente, assume a forma de pesquisa bibliográfica e estudo de caso. Segundo Gil (2002), uma pesquisa, quanto aos seus procedimentos técnicos, pode ser classificada da seguinte forma: Pesquisa bibliográfica: desenvolvida a partir de material já elaborado, constituído principalmente de livros e artigos científicos. Não é aconselhável que textos retirados da Internet constituam a estrutura teórica do trabalho monográfico. Estudo de caso: consiste no estudo profundo de um ou poucos objetos, de maneira que permita seu amplo e detalhado conhecimento. [...]É levada em consideração, principalmente, a compreensão, como um todo, do assunto investigado. Todos os aspectos do caso são investigados. Quando o estudo é intensivo podem até aparecer relações que de outra forma não seriam descobertas (FACHIN, 2001, p. 42). 151) é O método de procedimento monográfico. Para Lakatos e Marconi (1996, p. [...] um estudo sobre um tema específico ou particular de suficiente valor representativo e que obedece a rigorosa metodologia. Investiga determinado assunto não só em profundidade, mas em todos os seus ângulos e aspectos, dependendo dos fins a que se destina.
34 Nesse trabalho segundo sua natureza é aplicada as seguintes formas de metodologia. Utilizando uma pesquisa exploratória para ter maior conhecimento do problema, podendo valer de um levantamento bibliográfico para isso. Constituído por livros e artigos. Também é um estudo de caso pois consiste num estudo um pouco mais aprofundado do tema em questão. 3.2 DELIMITAÇÕES O escopo desse projeto está limitado apenas a abordar o nível G do MPS.BR desenvolvendo apenas as atividades relacionadas a este processo. Trabalhando com a gerência de projeto e levantamento de requisitos. O projeto não pretende de forma alguma alterar a estrutura da organização e nem de seus recursos. A sugestão ocorre de forma a atingir apenas uma parte pré determinada e somente aquelas que se mostrarem inadequadas ou inexistentes. 3.3 ARQUITETURA DE SOLUÇÃO Desenvolver um novo produto é tarefa relativamente complicada. A partir do momento que é feita a solicitação por um cliente é desencadeado uma seqüência de atividades. Levantamento de requisitos e gerência de projetos.
35 Figura 6 Diagrama da arquitetura de solução. Fonte: Elaborada pelo autor, 2009 Desencadeado o processo para definição do projeto, partimos para o desenvolvimento do levantamento de requisitos, que utilizando o modelo proposto para realização dessa tarefa tem como objetivo; identificar possíveis inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Um melhor entendimento é obtido e seguindo essa especificação a equipe desenvolve uma atividade mais eficiente e se for necessário alguma mudança nos requisitos, essa mudança será monitorada ao decorrer de todo o projeto. Partindo para a gerência do projeto o grupo envolvido irá criar planos que garantem a definição das atividades, recursos e responsabilidades do projeto, além de estar sempre acompanhando o andamento do projeto que tem um papel fundamental para que o prazo seja cumprindo. Assim o uso do modelo de referencia MPSBR na empresa, é possível melhorar e garantir a qualidade das etapas envolvidas no processo estudado. 3.4 METODOLOGIA DE DESENVOLVIMENTO DO PROJETO Este projeto apresenta uma metodologia dividida em etapas, a contextualização, identificação, análise, desenvolvimento e validação.
3.4.1 Etapa de contextualização 36 Na etapa de contextualização é apresentada a empresa estudo de caso, o MPSBR e a identificação de uso do PMBOK na empresa. 3.4.2 Etapa de Identificação A partir de uma análise detalhada do fluxo de processos envolvidos no nível G, gerencia de projetos e análise de requisitos, da empresa desenvolveu-se o modelo de processos, identificando-se entradas, saídas e comportamentos. 3.4.3 Etapa de Análise Na etapa de análise foi realizada a comparação das necessidades e atividades do nível G com o processo identificado dentro da empresa. A partir desta análise foi possível definir os possíveis gargalos relacionados as discrepâncias com o nível G do MPSBR. 3.4.4 Etapa de desenvolvimento A partir da análise passou-se ao desenvolvimento das sugestões de adequação. Esta etapa exigiu maiores pesquisas procurando na literatura possibilidades de melhorias e artefatos que pudessem apoiar a completude do processo da empresa em relação ao nível G.
3.4.5 Etapa de validação 37 Na etapa de validação apresentou-se os resultados do desenvolvimento, na forma de sugestões para o gerente de qualidade da empresa. Suas considerações encontram-se relatadas no capitulo 4 item 4.6
4 DESENVOLVIMENTO DO ESTUDO 38 Neste capítulo é apresentado o desenvolvimento do projeto a partir da metodologia apresentada no capítulo 3. 4.1 CONTEXTUALIZAÇÃO DO ESTUDO DE CASO A análise dos processos foi realizada em uma empresa catarinense. A Paradigma. A empresa está situada na região da grande Florianópolis que tem como missão disponibilizar soluções de tecnologia aplicadas a negócios que trazem resultados que adicionam uma vantagem competitiva e melhores resultados para as organizações. Com uma bagagem com mais de dez anos de atuação, atuando no mercado nacional e internacional. Contando com uma equipe com mais de 50 colaboradores capacitados e experientes e com a maturidade de uma plataforma robusta. Possuindo um conjunto de aplicativos que compreende quatorze modalidades de negociação, tendo como objetivo a busca contínua de inovação tecnológica e a diferenciação de soluções, adotar a simplicidade como estado da arte, agregar valor e competitividade às empresas e excelência em produtos e serviços. O gerenciamento de projetos é composto dos conhecimentos intrínsecos à profissão de gerenciamento de projetos. Como em outras profissões como advocacia, medicina e contabilidade, os conhecimentos pertencem aos profissionais e acadêmicos que o aplicam e o desenvolvem. O conjunto de conhecimentos em gerenciamento de projetos completo inclui práticas tradicionais comprovadas amplamente aplicadas, além de novas metodologias que estão surgindo na profissão, inclusive materiais publicados e não publicados. Como resultado disso, os conhecimentos em gerenciamento de projetos está em constante evolução. O principal objetivo do Project Management Body of Knowledge (PMBOK) é identificar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que é largamente reconhecido como boa prática. Identificar significa
39 fornecer uma visão macro, e não uma descrição detalhada. Amplamente reconhecido significa que o conhecimento e as práticas descritas poderão ser aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um acordo geral em relação ao seu valor e sua utilidade. Boa prática significa que existe acordo geral de que a implementação dessas habilidades está correta, ferramentas e técnicas podem ajudar a garantir chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito tem que ser implementado à risca em todos os projetos; a equipe de gerenciamento de projetos é responsável por avaliar o que é de fato necessário em um projeto específico. (PMBOK, 2004 p.3) O PMBOK é composto por nove áreas de conhecimento, são as seguintes; Gerenciamento da Integração do Projeto; Gerenciamento do Escopo do Projeto; Gerenciamento do Prazo do Projeto; Gerenciamento do Custo do Projeto; Gerenciamento da Qualidade do Projeto; Gerenciamento dos Recursos Humanos do Projeto; Gerenciamento da Comunicação do Projeto; Gerenciamento dos Riscos do Projeto; Gerenciamento das Aquisições do Projeto. 4.2 UTILIZAÇÃO DO PMBOK A partir da análise dos resultados do processo de aquisição da informação observou-se que os processos da empresa encontram-se hierarquizados a partir dos processos de gerência do PMBOK. Observou-se que a organização utiliza todas as nove áreas de conhecimento do guia, conforme a figura abaixo.
40 Figura 7 - Áreas conhecimento PMBOK Fonte: Elaborada pelo autor, 2010 4.2.1 Áreas do Conhecimento As áreas de conhecimento de gerenciamento de projetos que são aplicadas durante o processo de gestão e implementação do projeto são determinadas de acordo com a necessidade exigida para cada demanda. 4.2.1.1 Gerenciamento de Integração A Gerência de Integração do Projeto coordena todos os aspectos do Plano de Projeto e é altamente interativa. O planejamento do projeto, execução do projeto e controle de mudanças ocorre através de todo o projeto e é continuamente repetido enquanto o projeto é executado.
41 O controle de integração do projeto mantém a integridade das linhas de base das medidas de performance e garantem que mudanças no escopo do produto sejam refletidas na definição do escopo do projeto. Para isso verifica-se como as mudanças afetam o projeto como um todo e gerencia-se os impactos em todas as áreas. Após executar as mudanças é necessário refleti-las em todos os artefatos, o uso de linhas de base para manter a consistência entre as versões, utilizando ferramenta de controle de versão que controlam as mudanças, registra-se as mudanças, controla-se as versões gerandose os relatórios sobre as mudanças nos artefatos e produtos. 4.2.1.2 Gerenciamento de Escopo A definição dos requisitos feita em conjunto com o gerenciamento de escopo é a rota segura a ser seguida. Gerenciado através da verificação do software final produzido (compreendendo por software final um módulo ou funcionalidade), a partir da existência dos vínculos entre os requisitos funcionais e não funcionais com os artefatos utilizando-os para a implementação das funcionalidades ou customizações ou até mesmo novas criações. É gerenciado o escopo e também as mudanças que possam impactar ou não o cronograma de trabalho, sendo avaliado pela equipe em cada caso, também em conjunto com o cliente, para garantir o resultado final dentro do prazo e custos esperados. 4.2.1.3 Gerenciamento de Tempo Realizam-se reuniões de trabalho com interação entre a equipe, tendo sempre em vista os riscos envolvidos e a forma de como ocorrem as possíveis correções de percurso a tempo procurando não prejudicar o bom andamento do trabalho.
4.2.1.4 Gerenciamento de Custos 42 Existe uma gerência de custo do projeto executada pelo gerente do projeto. Dentre suas atribuições destaca-se a estimativa de custos, recursos alocados e manutenção do controle sobre os custos, garantindo que o projeto permaneça dentro do orçamento aprovado. O controle de custos preocupa-se com que todos estejam de acordo com os fatores que influenciam a linha de base dos custos, gerenciando as demandas por mudanças sugeridas pelo cliente. Quando ocorre alguma mudança o controle de custos deve: monitorar a desempenho do custo para detectar e entender variações no plano; garantir que todas as mudanças apropriadas sejam registradas na linha de case dos custos; prevenir que mudanças incorretas, inapropriadas ou não autorizadas sejam incluídas na linha de base dos custos; informar aos envolvidos no projeto as mudanças autorizadas. As mudanças no custo e orçamento do projeto são gerenciadas com a ajuda de um sistema de acompanhamento e controle de custos. Todas as mudanças nos custos e orçamentos são documentadas para avaliação dos responsáveis na equipe de desenvolvimento. 4.2.1.5 Gerenciamento de Qualidade A área de qualidade interage mutuamente com os processos de outras áreas do conhecimento. Cada processo pode envolver os esforços de um ou mais indivíduos ou grupos de indivíduos, dependendo das necessidades do projeto. Cada processo ocorre, geralmente, pelo menos uma vez em cada fase do projeto. A gerência da qualidade do projeto é direcionada tanto para a gerência do projeto quanto para o produto do projeto. O fracasso no cumprimento dos requisitos de qualidade em qualquer das dimensões, traz conseqüências negativas sérias para uma ou até mesmo para todas as partes envolvidas no projeto, por isso, sua importância no processo de gerenciamento.
4.2.1.6 Gerenciamento de Recursos Humanos 43 O gerenciamento de recursos preocupa-se com o uso efetivo das pessoas envolvidas no projeto, incluído todos os stakeholders. Envolve planejamento organizacional, definição da equipe e desenvolvimento da mesma quando necessário. 4.2.1.7 Gerenciamento de Comunicação Os processos de comunicação do projeto estão relacionados com as habilidades gerais de comunicação. Os processos de comunicação garantem que todas as informações do projeto, incluindo planos do projeto, avaliações de risco, notas de reuniões e outras mais sejam coletadas e documentadas. Estes processos também garantem que as informações sejam distribuídas e compartilhadas pelos envolvidos no projeto nos relatórios de performance do mesmo. Na finalização do projeto, as informações são arquivadas e usadas como referência em projetos futuros. 4.2.1.8 Gerenciamento de Riscos O gerenciamento de riscos é utilizado em todas as etapas do projeto, um monitoramento constante é realizado para prevenir, identificar, analisar, planejar, acompanhar ou rastrear e controlar cada fase e atividade, minimizando e isolando os pontos vulneráveis.
4.2.1.9 Gerenciamento de Aquisições 44 O gerenciamento de aquisições inclui os processos necessários a obtenção de bens e serviços de terceiros, para atingir o resultado final caso exista a necessidade. 4.3 ÁREAS DE ESTUDO Para realizar o estudo de caso na organização serão abordadas as áreas de conhecimento que mais se enquadram com o modelo proposto pelo estudo. Portanto, a gerência de integração e a gerência de escopo. Figura 8 Áreas de conhecimento do objeto de estudo Fonte: Elaborada pelo autor, 2010 Dentro de cada uma das gerências existem papéis e responsabilidades desempenhados por seus funcionários. O esclarecimento sobre o que é cada papel dentro das atividades relacionadas e de sua representação na organização é fundamental na compreensão do processo.
45 De acordo com Rational Unified Process (RUP) o papel é uma definição abstrata de um grupo de atividades realizadas e dos artefatos gerados. Normalmente esse papel é desempenhado por uma pessoa ou uma equipe, um membro da equipe pode ter vários papéis distintos. Os papéis não são pessoas, pelo contrário, eles descrevem como as pessoas se comportam no negócio e quais as responsabilidades que elas têm. Apesar de maioria dos papéis serem desempenhados dentro da organização, as pessoas fora da organização têm um papel importante. Para o RUP papéis são um grupo de atividades coerentes por eles executadas e as atividades estão fortemente relacionadas aos artefatos. Figura 9 Papéis RUP Fonte: Rational Unified Process 4.3.1 Gerência de integração aplicada a empresa A gerência de integração desenvolve-se na empresa durante todo o ciclo de vida do projeto, do início do projeto e segue executando o mesmo processo até o encerramento. Nessa etapa, surge o papel do gerente de projetos, responsável por alocar recursos; ajustar as prioridades, coordenar interações com o cliente e usuário e geralmente manter a equipe do projeto concentrada na meta certa. O gerente do projeto também estabelece um conjunto de práticas que garantem a integridade e a qualidade dos artefatos do projeto (RUP, 2002). Abaixo temos a descrição do cenário atual dentro da organização
46 estudada. O cliente entra em contato com a área comercial da empresa e apresenta a sua necessidade. O comercial por sua vez aciona a gerência com uma préproposta em mãos. A gerência cria uma proposta comercial em conjunto com a área comercial e encaminha o documento para análise do cliente com cronograma macro. Caso não aconteça aprovação da proposta pode ocorrer uma nova negociação. Sendo positiva a aprovação da proposta, o gerente monta a equipe, iniciando processo de desenvolvimento do projeto. Figura 10 Gerencia de integração fase inicial Fonte: Elaborada pelo autor, 2010 Durante o ciclo de vida do projeto, a gerência de integração está monitorando e identificando mudanças, prazos, inconsistências e riscos, fazendo controle do projeto A mudança pode ser identificada pelo cliente. O cliente solicita uma alteração. A equipe pode informar a necessidade de uma mudança ou até a própria organização solicita essa mudança. A partir dessas requisições a gerência avalia e identifica se a mudança solicitada, independente de quem a solicitou vai gerar algum risco, mudança de cronograma ou alteração no escopo envolvendo custos. Havendo riscos no projeto é criado uma documentação e um e-mail é encaminhado para a área comercial o
47 mesmo acontece para alterações de impacto de cronograma. Porém quando a alteração envolve custos, é necessário que uma nova negociação seja realizada com o cliente, caso contrário o gerente tem autonomia para solicitar a que a tarefa seja executada. Figura 11 Gerencia de integração durante o clico do projeto Fonte: Elaborada pelo autor, 2010 4.3.2 Gerencia de escopo aplicada a empresa Gerência de escopo é a etapa do projeto que interpreta as necessidades do cliente transformando em guia para o desenvolvimento do projeto. Na gerência de escopo sobressaem dois novos papeis: o analista de sistema e o desenvolvedor. O analista de sistemas tem por responsabilidade liderar e coordenar a identificação de requisitos e a modelagem de casos de uso, delimitando o sistema e
48 sua funcionalidade. O desenvolvedor tem como responsabilidade desenvolver e testar componentes de acordo com os padrões adotados para o projeto, para fins de integração com subsistemas maiores. Produzir todo software necessário para instalação e desinstalação rápida, fácil e segura do produto (RUP, 2002). Nessa etapa, o cliente envia dois documentos. Um contendo a proposta comercial e outro contendo a descrição de sua necessidade. O gerente de projeto recebe esses documentos e planeja o escopo em parceria com o analista coordenador. O analista faz um detalhamento do escopo e encaminha a documentação para o cliente. O cliente realiza aprovação que no caso de positiva retorna para o analista e o gerente de projeto. É realizado um detalhamento de cronograma e então é encaminhado novamente ao cliente. Após essa aprovação retorna ao coordenador analista para que ele levante os requisitos, monte as funcionalidades e finalmente parta para o desenvolvimento. Figura 12 Gerencia de escopo Fonte: Elaborado pelo autor, 2010
49 4.4 APROXIMAÇÃO DO NÍVEL G A REALIDADE DA EMPRESA O levantamento dos processos foi realizado e com isso a realização da especificação de quais grupos de resultados a empresa está abrangendo, ou seja, é possível identificar quais os pontos de deficiência da organização que necessitam de orientação para atingir o nível G. Dentro do nível G de maturidade, existem grupos de resultados que a organização deve contemplar para atingir esse nível de maturidade. De acordo com a especificação fornecida pelo (SOFTEX, 2009) os grupos se apresentam por áreas de gerência. Quadro 2 Processos da gerência de projetos. Fonte: Elaborado pelo autor, 2010
50 Quadro 3 Processos de gerência de requisitos. Fonte: Elaborado pelo autor, 2010 4.5 GRUPOS DE PROCESSOS NA PARADIGMA Após ter avaliado os processos da organização foi possível saber quais os grupos de resultados estão sendo aplicados, sendo parcialmente aplicados e não aplicados. Processos aplicados: são processos onde a empresa desempenha todas as atividades sugeridas pelo nível G do MPSBR. Processos aplicados parcialmente: para alguns grupos de processos a empresa desenvolve apenas parcialmente as atividades sugeridas pelo nível G do MPSBR. Processos não aplicados: neste caso a empresa não cumpre com as atividades sugeridas pelo nível G do MPSBr. Os quadros 4 e 5 apresentam a análise da aplicação dos processo na empresa.
51 Quadro 4 Processos de gerência de projetos na Paradigma. Fonte: Elaborado pelo autor, 2010 Quadro 5 Processos de gerência de requisitos na Paradigma. Fonte: Elaborado pelo autor, 2010 4.5.1 Sugestões para processos de gerência de projetos Nesse momento serão apresentadas as sugestões de adequação consideradas pertinentes no processo de gerência de projetos a luz do nível G do MPSBr. sugere-se: Para complementar o GPR2 o uso de uma Estrutura Analítica de Projetos (EAP) juntamente com dados históricos. Uma EAP é um agrupamento orientado ao subproduto dos elementos do projeto que organiza e define o escopo total do projeto. O trabalho que não está na EAP está fora do escopo do projeto. A EAP é freqüentemente usada para elaborar ou