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.
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
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
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
1 INTRODUÇÃO
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.
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.
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.
2 QUALIDADE
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.
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).
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
(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)
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.
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
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
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):
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 SW-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
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é bem-sucedidas, mas isso em geral se restringe ao desenvolvimento de produtos com os quais já estiveram envolvidas anteriormente (WEINBERG, 1994 apud KOSCIANSKI;
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
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 .
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
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
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
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 [...].”
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
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).
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
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
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.
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 Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
D 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
E 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)
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
F Aquisição – AQU
Gerência de Configuração – GCO
Gerência de Portfólio de Projetos – GPP
Garantia da Qualidade – GQA Medição – MED
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
O propósito do gerenciamento de projetos nesse nível de acordo com o autor é:
De acordo com o SOFTEX, (2009) a finalidade do processo Gerência de Projetos é formar e sustentar planos que definem as atividades, recursos
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
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).
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
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).
O método de procedimento monográfico. Para Lakatos e Marconi (1996, p. 151) é
[...] 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”.
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.
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
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
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
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
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.
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.
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 gerando-se 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.
