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
5
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.
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.
8
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.
Na década de 1940 surgiram vários organismos ligados à
9
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
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).
14
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
15
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 SWCMM 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
19
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
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)
21
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
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
25
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
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
A
Atributos de processos
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
C
Gerência de Projetos – GPR
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP
(evolução)
3.2, AP 4.1 e AP 4.2
Gerência de Riscos – GRI
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP
Desenvolvimento para Reutilização
3.2
– DRU
Gerência de Decisões – GDE
D
Verificação – VER
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP
Validação – VAL
3.2
Projeto e construção do produto –
PCP
Integração do produto – ITP
Desenvolvimento de requisitos –
DRE
Projeto e construção do produto –
PCP
E
Avaliação e melhoria do processo
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP
organizacional – AMP
3.2
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)
F
Aquisição – AQU
Gerência de Configuração – GCO
AP 1.1, AP 2.1 e AP 2.2
29
Gerência de Portfólio de Projetos –
GPP
Garantia da Qualidade – GQA
Medição – MED
G
Gerência de Requisitos – GRE
AP 1.1 e AP 2.1
Gerência de Projetos – GPR
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
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.
31
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
32
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.
33
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”.
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.
36
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.
37
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
38
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
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.
42
4.2.1.4 Gerenciamento de Custos
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.
43
4.2.1.6 Gerenciamento de Recursos Humanos
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.
44
4.2.1.9 Gerenciamento de Aquisições
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
52
confirmar o escopo do projeto. Informações históricas das
durações de atividades anteriores devem estar disponíveis na forma de
arquivo de projeto. A organização irá manter registros dos projetos de
maneira bastante detalhada para auxiliar o desenvolvimento da estimativa
das atividades (PMBOK, 2004). Como exemplo de arquivo de histórico
retirado do (RUP, 2002), temos o artefato lista de problemas. A Lista de
problemas fornece ao gestor do projeto uma maneira de registrar e
acompanhar problemas, exceções, anormalidades ou outras tarefas
incompletas que necessitam de atenção em termos de gerenciamento do
projeto. Seu formato pode ser livre, porém pode abranger uma descrição
do problema, uma indicação de sua importância, datas que sejam
relevantes ao projeto, impactos no cronograma e nos recursos e possíveis
soluções. Ver apêndice A.
A estimativa dos esforços e custos no GPR4 é influenciada diretamente
pelo uso de histórico. O uso do modelo de histórico referenciado pelo
(RUP, 2002) sugere que a organização utilize-o como plano de métrica.
Nesse plano existe um modelo de histórico para ser implementado. O
modelo de histórico pode ser desenvolvido livremente, mas é interessante
que aborde dados como a descrição do problema, recursos, custos, datas
importantes ao projeto e as possíveis soluções. Ver apêndice B.
Para auxiliar na estimativa pode ser utilizar uma técnica chamada Plannig
Poker. Essa técnica é baseada no consenso de toda equipe, onde é
utilizado um conjunto de cartas com valores específicos que podem
representar pontos relativos ou número de horas. E é praticado no formato
de um jogo. Uma dos integrantes da equipe apresenta a tarefa para o resto
da equipe, e, após uma pequena discussão, cada membro da equipe
escolhe uma carta que é colocada virada para baixo sobre a mesa. Quando
todos da equipe tiverem lançado suas cartas sobre a mesa, as mesmas
são viradas e caso não haja consenso nos valores escolhidos, as
diferenças são discutidas de forma breve, e uma nova rodada acontece até
que haja a convergência.
•
Promover uma interação com todos os participantes do projeto para
encontrar riscos no projeto. Essa interação deve contar com a participação
53
da equipe de projeto, equipe de gerência de risco, especialistas
no tema de outras partes da organização, clientes, usuários, outros
gerentes de projetos, partes envolvidas e especialistas de fora (PMBOK,
2004).
Essa interação pode ter algumas características da metodologia ágil
descrita pelo autor (Schwaber, 2004), como, ser a primeira atividade do dia
e ter duração de no máximo 15 minutos. Realizada sempre no mesmo local
a cada dia de trabalho. Para obter máxima eficiência na reunião deve-se
realizá-la no início do dia, dessa maneira, a primeira coisa que os membros
da equipe irão fazer é pensar no seu dia anterior e o que será planejado
para
o
dia
de
trabalho.
Todos os membros da equipe são obrigados a comparecer. Se por algum
motivo, um membro da equipe não puder comparecer pessoalmente, o
membro ausente ou deve participar por telefone A participação na reunião
deve ser pontual por parte de todos os envolvidos no projeto, caso alguém
se atrase será cobrado uma taxa como punição. A reunião se inicia pelo
responsável e segue o sentindo anti-horário ao redor da sala até que todos
tenham relatado. Cada membro da equipe deve responder a três
perguntas, o que ele fez desde a última reunião, o que irá fazer entre essa
e a próxima reunião e se ele possui algum impedimento em seu trabalho.
Cuidando sempre para não ir além das respostas diretas a essas
perguntas. Somente uma pessoa pode falar por vez, relatando seu
histórico. Se um membro da equipe está com algum problema e precisa da
ajuda dos outros membros, qualquer pessoa da equipe pode chamar a
todos os outros membros da equipe a se reunir para discutir logo após a
reunião diária.
É criada uma documentação para arquivar os riscos. Um bom exemplo é a
utilização do artefato do RUP. A lista de erros. Ver apêndice C. Nessa lista
será armazenada a descrição do problema e sua resolução. Sendo assim,
o grupo de processo GPR6 é atendido.
•
Definir a equipe. O gerente de projeto irá analisar novamente todas as
equipes que tenham mais de sete pessoas, a fim de verificar se existe uma
maneira sensata de dividi-la. As equipes devem ser compostas por, no
54
mínimo, duas pessoas e, no máximo, sete pessoas. Equipes
com mais de sete pessoas geralmente são divididas em sub-equipes, Ao
atribuir o pessoal às equipes, o gerente de projeto deve estar atento à
experiência geral e ao nível de familiaridade da equipe, e deve tentar
formar equipes misturando o 'sangue novo' com o pessoal que já vem
trabalhando no projeto há algum tempo. No início de um projeto, o gerente
de projeto deverá contar com a combinação pessoal experiente/pessoal
novato (RUP, 2004).
O desenvolvimento de um inventário de competências dos recursos
disponíveis na empresa facilitará a descobertas de brechas na atribuição
dos membros da equipe aos papéis Partindo do pressuposto de que o
curso normal de recrutamento de outros membros ou contratação de
recursos externos já foi tentado. Caso exista necessidade, as habilidades
precisarão ser desenvolvidas. A realização de treinamento e a orientações
apropriados devem ser fornecidos a essas pessoas, com antecedência,
mas bem próximo do momento em que elas precisarão revelar suas
habilidades. O treinamento deve ser colocado imediatamente em prática,
pois logo se perderá. Geralmente, a combinação do treinamento formal
seguido de um workshop ministrado pelo mentor para iniciar uma atividade
é particularmente eficaz, uma vez que as novas habilidades entram logo
em ação (RUP, 2004). Considerando essa sugestão o GPR7 estará
saciado.
•
Para complementar o GPR10 pode-se usar algumas atividades do Scrum.
Utilizando o documento de visão e o Product Backlog que representa o
plano em alto-nível do projeto, com os requisitos funcionais e nãofuncionais e o porquê do desenvolvimento do projeto, o Product Backlog irá
existir durante todo o ciclo de vida do projeto. O Team, Scrum Master e
Product Owner revisam os planos e compromissos no início e no final de
cada Sprint, durante as reuniões de planejamento Sprint Planning Meeting
e revisão Sprint Review (Scrum,2004).
O Sprint Planning Meeting é uma reunião em que estão presentes o
Product Owner, o Scrum Master e todo o Team, assim como, qualquer
pessoa que represente as partes envolvidas. Durante o Sprint Planning
55
Meeting, o Product Owner descreve as funcionalidades de
maior prioridade para a equipe. A equipe pode fazer perguntas durante a
reunião afim de que seja quebrada as funcionalidades em tarefas técnicas,
após a reunião. Essas tarefas irão dar origem ao Sprint Backlog. O Product
Owner não precisa descrever todos os itens que estão no Product Backlog.
Dependendo do tamanho do Product Backlog e da velocidade da equipe,
pode-se apenas apresentar os itens de maior prioridade, deixando a
discussão dos itens de menor prioridade para o próximo Sprint Planning
Meeting. Coletivamente, o Scrum Team e o Product Owner definem uma
meta para cada Sprint, que é uma resumido daquilo que se tentará
alcançar no Sprint. O sucesso do Sprint é avaliado no Sprint Review
Meeting em relação ao objetivo traçado para o Sprint. Depois do Sprint
Planning Meeting, a equipe Scrum se encontra separadamente para
discutir sobre o que foi passado a eles e decidir quanto, poderão se
comprometer a fazer no Sprint que será iniciado. Na maioria das vezes,
haverá
negociação
com
o
Product
Owner,
mas
será
sempre
responsabilidade da equipe determinar o quanto ela será capaz de se
comprometer a fazer (Scrum, 2004).
•
A sugestão para o grupo de processos GPR13 é a de utilizar mais
algumas atividades do Scrum. O Product Burndown e as reuniões diárias Daily Meeting. As reuniões podem ser gravadas utilizando um pequeno
aparelho para melhor evidenciar o que foi abordado. Essas atividades
provêem a visibilidade necessária para monitorar o andamento do projeto
e conferir desvios no plano. O Sprint Burndown também contribui para
isso, mostrando diariamente a velocidade do time e se as funcionalidades
que vão ser entregues ao final do período. (Scrum, 2004)
Este gráfico Burndown mede a quantidade de trabalho restante Product
Backlog no eixo vertical e a escala de tempo, pela Sprint no eixo horizontal.
Esse gráfico é estimado a partir da carga de trabalho ao longo do projeto.
No início de cada Sprint é medida a carga de trabalho, que é feita pela
soma de todos os trabalhos abertos Product Backlog estimativas. De Sprint
a Sprint o aumento ou a diminuição dessas cargas podem ser usadas para
analisar o progresso e poder estimar uma data para entrega (SCRUM,
56
2004).
Figura 13 – Burndown chart
Fonte: Schwaber, 2004
4.5.2 Sugestões para processos de gerência de requisitos
É sugerido para adequamento dos processos de gerencia de requisitos ao
MPSBr:
•
Para o grupo de processo GRE3 ser atendido é fundamental que desde o
início do levantamento seja definida a rastreabilidade dos requisitos. A
rastreabilidade é a capacidade de rastrear um elemento do projeto a outros
elementos correspondentes aos requisitos.
Os elementos do projeto
envolvidos em rastreabilidade são chamados de itens de rastreabilidade.
Os itens típicos de rastreabilidade incluem diferentes tipos de requisitos,
elementos de modelo de design e de análise, artefatos de testes e material
de treinamento e documentação de suporte a usuário final (RUP. 2004).
Em vez de documentar os atributos de rastreabilidade em um plano de
requisitos, você deve optar por inserir essas informações diretamente em
57
uma ferramenta de ajuda on-line, em um site da Web ou na
ferramenta utilizada para gerenciar os atributos e a rastreabilidade. Por
exemplo, o Rational RequisitePro essa ferramenta mantém equipes de
projeto
dentro
da
programação,
permitindo
a
criação,
análise
e
gerenciamento dos requisitos de aplicativo e casos de utilização.
•
Sugere-se que revisões para identificar inconsistência no levantamento de
escopo e nas demais partes do projeto. Pode-se utilizar a metodologia
Scrum. Nessa metodologia temos revisões freqüentes realizadas a cada
iteração, ao termino de cada Sprint é feito um Sprint Review Meeting.
Durante esta reunião, o Scrum Team mostra quais objetivos foram
alcançados durante o Sprint. Os participantes do Sprint Review
tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master,
gerência, clientes e engenheiros de outros projetos. Durante o Sprint
Review, o projeto é avaliado levando em consideração o Sprint,
determinados durante o Sprint Planning Meeting. O ideal é que cada um
da equipe que completou um dos itens do Product Backlog trazidos para
fazer parte do Sprint, porém o mais importante é que o objetivo geral do
Sprint seja alcançado.
E a prática de reuniões diárias (Daily Meeting), inclusive com
ajuda de
gráficos (Product Burndown e Sprint Burndown).Dessa forma, O grupo de
processo GRE4 ficará completo.
4.6 ETAPA DE VALIDAÇÃO
A validação das sugestões apresentadas nessa pesquisa foi realizada pelo
coordenador de qualidade da Paradigma. Esse profissional certificado por diversas
metodologias de qualidade, Associação Latino-Americana de Teste de Software
(ALATS), Certificação Foundation - Certified Tester, Foundation Level (ISTQB.
CTFL), SRUM MASTER, Information Technology Infrastructure Library (ITIL), Prova
de Introdução ao MPS.BR (P1-MPS.BR).
A realização dessa validação ocorreu por meio de uma apresentação das
58
sugestões. Na seqüência solicitou-se ao gerente a avaliação critica das
sugestões.
Para esse profissional teoricamente cada sugestão apresentada pode ser
aplicada na organização, a partir da utilização do framework do Scrum a Paradigma
vai atingir todas essas atividades atendendo o nível G.
Porém algumas sugestões fogem um pouco da realidade da empresa, por
exigirem uma pessoa exclusivamente para realizar determinada tarefa ou pelo custo
de sua utilização, por exemplo, o uso da ferramenta da IBM Rational RequisitePro.
59
5 CONCLUSÃO
Em um mercado cada vez mais exigente são necessários produtos de alto
nível para suprir a necessidade organizacional das empresas.
O reflexo dessa grande exigência chegou ao mercado de produção de
software, empresas que não estão preparadas para essa nova realidade acabam por
perder negócios, perdendo fatias do mercado. Esse mercado de software está muito
ligado
a
globalização,
empresas
brasileiras
concorrem
diretamente
com
multinacionais com capital muito poderoso, transformando essa concorrência em
uma luta desleal. Empresas nacionais precisam investir altas somas para estarem
enquadradas em alguma metodologia de qualidade internacional.
Na busca de uma saída a esse alto custo na hora de se adequar a
metodologias de qualidade, foi criado o MPSBR para ajudar empresas nacionais a
ajustarem em um padrão de qualidade competitivo e barato e, com isso, competindo
com empresas estrangeiras.
A sugestão de enquadramento da Paradigma no modelo do MPSBR
ajuda a empresa a aumentar ainda mais sua competitividade e qualidade de seus
produtos, pois percebeu-se que são poucos os pontos que não atendem ao nível de
qualidade e as sugestões apresentadas podem ser implantadas facilmente deixando
a organização habilitada em um modelo de qualidade com ótimo reconhecimento.
Entender os processos da instituição foi fundamental na compreensão de seu
funcionamento e mais importante ainda foi o conhecimento, experiência e a noção
de como funciona o processo inicial para desenvolver um produto. A pesquisa por
métodos e artefatos que atendem as necessidades trouxeram um aperfeiçoamento
técnico e conceitual sobre qualidade e organização para o elborador desta
monografia.
Como trabalhos futuros, sugere-se a avaliação da possibilidade de
implantação das sugestões na empresa.
Outro ponto a ser considerado é a realização de um levantamento
verificando se a empresa possui capacidade de alcançar os próximos níveis do
MPSBR.
60
REFERÊNCIAS
BARTIÉ, Alexandre. Garantia de qualidade de software. Rio de Janeiro: Campus,
2002.
FACHIN, Odília. Fundamentos de metodologia. 3. ed. São Paulo: Saraiva, 2001.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas,
2002.
INTHURN, Cândida. Qualidade & teste de software. Rio de Janeiro: Florianópolis:
Visual Books, 2001.
IBM Disponível em: <http://www-142.ibm.com/software/products/br/pt/reqpro/>
Acesso em: 20 maiO 2010.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Metodologia do trabalho
científico. São Paulo: Atlas, 1995.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software:
aprenda as metodologias e técnicas mais modernas para o desenvolvimento de
softwares. 2. ed. São Paulo: Novatec, 2007.
PLANNING POKER. Disponível em: < http://www.planningpoker.com/> Acesso em:
18 maio 2010
PMBOK guia. 3. ed. Disponível em: <http://www.pmi.org/Pages/default.aspx>
Acesso em: 30 mar. 2010.
PMBOK Disponível em:
<http://www.cin.ufpe.br/~if717/Pmbok2000/pmbok_v2p/wsp_6.1.html> Acesso em:22
maio2010.
RUP v. 2002 Disponível em: <http://www.wthreex.com/rup/portugues/index.htm >
Acesso em: 12 abr. 2010.
61
SOFTEX Guia geral mps.br v1.2, Disponível em:
<http://www.softex.br/mpsbr/_guias/default.asp> Acesso em: 15 ago. 2009.
SCRUM Disponível em:
<http://www.gerenciamentodeprojeto.com/2009/10/mapeamento-do-scrum-para-onivel-g-do.html> Acesso em: 18 maio 2010.
SCHWABER, Ken. Agile Project Management with Scrum. Redmond: Microsoft
Press, 2004.
WEINBERG, Gerald M.. Software com qualidade: pensando e idealizando
sistemas. São Paulo: Markron Books, 1993.
62
APÊNDICES
63
APÊNDICE A - Lista de problemas para sugestão
Paradigma Business Solution
<Nome do Projeto>
Lista de Problemas
Versão <1.0>
Histórico
Data
Versão
Descrição
Autor
1. Lista de problemas
1.1<Identificador— um nome descritivo ou número>
1.1.1 Descrição
[Uma breve descrição do problema.]
1.1.2 Importância
[Uma breve descrição da sua importância .]
1.1.3 Impacto
[Uma descrição sobre os impactos no cronograma e recursos.]
1.1.4 Soluções
[Descreva o que está sendo feito no projeto, para atender para resolver o problema.]
64
APÊNDICE B - Histórico
Paradigma Business Solution
<Nome do Projeto>
Histórico
Versão <1.0>
Histórico
Data
Versão
Descrição
Autor
1. Dados Históricos
1.1 <Identificador— um nome descritivo ou número>
1.1.1 Descrição
[Uma breve descrição do que será feito.]
1.1.2 Recursos
[Liste os recursos do projeto ou produto.]
1.1.3 Custos
[Liste os custos do projeto ou produto.]
1.1.4Soluções
[Descreva o que está sendo feito no projeto, para atender o projeto ou produto.]
65
66
APÊNDICE C - Lista de Erros
Paradigma Business Solution
<Nome do Projeto>
<Área do Projeto Analisada>
Lista de Erros
Versão <1.0>
Histórico
Data
Versão
Descrição
Autor
1 Lista de erros
1.1 <Identificador— um nome descritivo ou número>
1.1.1 Descrição
[Uma breve descrição do problema.]
1.1.2 Soluções
[Descreva o que está sendo feito no projeto, para atender o projeto ou produto.]