UNIVERSIDADE DE SO PAULO

ESCOLA DE ENGENHARIA DE SO CARLOS

DEPARTAMENTO DE ENGENHARIA DE PRODUO








ALFREDO COLENCI NETO






Proposta de um modelo de referncia para desenvolvimento de
software com foco na certificao do MPS.Br














So Carlos
2008

ALFREDO COLENCI NETO











Proposta de um modelo de referncia para desenvolvimento de software
com foco na certificao do MPS.Br















ORIENTADOR: Prof. Dr. Edson Walmir Cazarini








So Carlos
2008



Tese de doutorado apresentada
Escola de Engenharia de So Carlos,
como parte dos requisitos para
obteno do ttulo de doutor em
Engenharia de Produo.























































Dedicado a minha esposa
Ana Vivian, e minhas
filhas Laura e Maria
Luiza.

Agradecimentos





Deus pela minha vida.

Agradecimento especial ao meu orientador, Prof. Dr. Edson Walmir Cazarini, pelos
vrios anos de convivncia e ensinamentos transmitidos nesta jornada.

Aos meus pais Alfredo e Ana Maria por me darem a vida e me ensinarem a vive-la com
dignidade, sem nunca ter medido esforos na minha educao. Vocs so os melhores !

Aos meus irmos Pedro Luciano, Ana Teresa e meu cunhado Wilder pelos momentos de
descontrao e incentivo.

Aos professores e funcionrios do Departamento de Engenharia de Produo da Escola
de Engenharia de So Carlos em especial ao Prof. Dr. Daniel Capaldo do Amaral e Jos
Luis Chiaretto.

A todos colaboradores da COSS Consulting em especial ao Dr. Fredy Joo Valente, Sr.
Antonio Rigo e Sr. Luis Carlo Colella Ferro.

Aos amigos Janaina e Anderson pela colaborao nos momentos finais.

IV
Resumo

COLENCI NETO. A. (2008). Proposta de um modelo de referncia para desenvolvimento
de software com foco na certificao do MPS.Br. Tese (doutorado) - Escola de Engenharia
de So Carlos, Universidade de So Paulo, So Carlos, 2008.

Esta tese prope um modelo de referncia aplicvel s pequenas empresas produtoras de
softwares, para dar suporte ao seu processo de desenvolvimento de produtos (PDP).
Utilizando uma reviso bibliogrfica que permitiu a contextualizao terica, ao estado da
arte, e tendo por base o modelo de qualidade MPS.Br, so apresentados e discutidos os
conceitos de qualidade e de produtividade com abordagem voltada para as pequenas
empresas. A seguir, procede-se a uma avaliao contextualizada, com base no mtodo de
avaliao MARES, em algumas empresas do setor, para se obter uma constatao da efetiva
situao das mesmas quanto as suas prticas no desenvolvimento de sistemas informatizados.
Da anlise dos resultados e baseado no referencial terico, objetiva-se, como contribuio ao
melhor domnio do tema, disponibilizar-se um modelo de referncia capaz de harmonizar o
atingimento de qualidade assegurada e produtividade elevada com atuao rpida e eficaz,
de modo a garantir competitividade s pequenas empresas produtoras de software no Brasil.

Palavras Chave: Desenvolvimento de Produto, Desenvolvimento de Software, Modelo de
Referncia.




V
Abstract

COLENCI NETO. A. (2008). Proposal of a referencial model for software development
with focus on MPS.Br. Tese (doutorado) - Escola de Engenharia de So Carlos,
Universidade de So Paulo, So Carlos, 2008.



This thesis proposes a product development process (PDP) reference model for software
companies. The PDP reference model was developed based on the MPS.Br existing model
and an extensive bibliography revision which allowed for a state of the art context analysis.
This work also presents the main quality and productivity concepts targeted at small software
development companies. Following that path, a context evaluation based on the evaluation
method MARES was applied to a group of small software companies in order to produce a
present stage concerning their software development practices, per company. By analyzing
and comparing the evaluation results and the theoretical material surveyed, a new PDP
reference model was proposed aiming to ease the introduction of quality and productivity
practices for small software development companies. It is expected that the adoption of the
proposed reference model can help small companies leverage their competitive advantage in
Brasil.

Keywords: Product Development, Software Development, Referencial Model.



VI
Lista de Ilustraes

Figura 1. Seqncia das atividades da pesquisa. ................................................................... 24
Figura 2. Processos relacionados com desenvolvimento de produtos. ROZENFELD et al.
(2006). ......................................................................................................................... 27
Figura 3. Modelo cascata. SOMERVILLE (2003). ............................................................... 33
Figura 4. Modelo espiral resumido de Boehm. Adaptado de Pressman (2005). ....................... 35
Figura 5. Modelo Incremental. PRESSMAN (2005)............................................................. 36
Figura 6. Rational Unifield Process. KRUCHTEN (2003). ................................................... 38
Figura 7. O processo Extreme Programming. PRESSMAN (2005)....................................... 44
Figura 8. Fluxo de desenvolvimento Scrum. Adaptado de COCHANGO (2006). ................ 47
Figura 9. Nveis de maturidade do CMMi. CMMI-DEV (2006). .......................................... 49
Figura 10. Diagrama da relao entre processos. Adaptado de MOPROSOFT (2005). ........ 56
Figura 11. Estrutura do MR-MPS. MPS (2006). ................................................................... 57
Figura 12. Classes de Processos do MPS.Br. MPS (2006). ................................................... 61
Figura 13: Nveis de Maturidade: CMMI x MR-MPS. Adaptado de PINTO (2006).............. 63
Figura 14. O modelo MPS.Br. WEBER (2005). ................................................................... 77
Figura 15. Etapas do processo de avaliao. ......................................................................... 82
Figura 16. Modelo de referncia. ROZENFELD et al, (2006)............................................... 94
Figura 17. Viso geral do modelo de referncia para desenvolvimento de software. ........... 108
Figura 18. Fluxo de atividades da gerncia de requisitos .................................................... 117
Figura 19. Fluxo de atividades para gerncia de projetos. ................................................... 125
Figura 20. Fluxo de trabalho na implantao do processo. .................................................. 139
Figura 21. Tela do Share-Point. .......................................................................................... 144
Figura 22. Arquitetura da soluo WELCOSS.................................................................... 146
Figura 23. Fluxo de kanbans na empresa. ........................................................................... 148
Figura 24. Arquitetura do sistema DVR. ............................................................................ 149


VII
Lista de Tabelas

Tabela 1 - reas de Processo do CMMi. .............................................................................. 51
Tabela 2 - Organizaes com certificao CMM/CMMi no Brasil ....................................... 53
Tabela 3 - Classificao das empresas segundo o porte ........................................................ 66
Tabela 4 - Resultado da aderncia das atividades do modelo de referncia ao MPS.Br
Gerncia de Projeto. ................................................................................................... 104
Tabela 5 - Resultado da aderncia das atividades do modelo de referncia ao modelo MPS.Br
Gerncia de Requisitos ............................................................................................ 106














VIII
Lista de Quadros



Quadro 1. Representao da classificao metodolgica da pesquisa.................................... 22
Quadro 2. Caractersticas de cada nvel do CMMi. ............................................................... 50
Quadro 3. Nveis de maturidade do MPS.Br......................................................................... 58
Quadro 4. Quadro resumo da empresa A. ............................................................................. 84
Quadro 5. Quadro resumo da empresa B. ............................................................................. 85
Quadro 6. Quadro resumo da empresa C. ............................................................................. 86
Quadro 7. Quadro resumo da empresa D. ............................................................................. 87
Quadro 8. Quadro resumo da empresa E. ............................................................................. 88
Quadro 9: Resumo dos projetos analisados......................................................................... 150








IX
Lista de Abreviaturas e Siglas

ABES Associao Brasileira de Empresas de Software
BID Banco Interamericano de Desenvolvimento Econmico e Social
BNDES Banco Nacional de Desenvolvimento
CMM Capability Maturity Model
CMMi Capability Maturity Model Integrated
CRM Customer Relationship Management
EAP Estrutura Analtica de Processos
ERP Enterprise Resource Planning
FINEP Financiadora de Estudos e Projetos
GCQ Grupo de Controle da Qualidade
ISO International Organization for Standardization
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
IPT Instituto de Pesquisas Tecnolgicas do Estado de SP
MA-MPS Modelo de Avaliao - Melhoria do Processo de Software Brasileiro
MCT Ministrio da Cincia e Tecnologia
MSF Microsoft Solution Framework
MR-MPS Modelo de Referncia - Melhoria do Processo de Software Brasileiro
MPS.Br Melhoria do Processo de Software Brasileiro
O.O. Orientao a Objetos
PDS Processo de Desenvolvimento de Software
PDP Processo de Desenvolvimento de Produto
PMBOK Project Manager Body of Knowledgement
PMI Project Manager Institute
RFID Radio Frequency Identification
RUP Rational Unified Process
SEI Software Engineering Institute
SPICE Software Process Improvement and Capability dEtermination
SVN Subversion
TI Tecnologia da Informao
UNAM Universidad Nacional Autnoma del Mxico
UML Unified Modeling Language
XP eXtreme Programming






X
Sumrio
RESUMO___________________________________________________________ 1
ABSTRACT_________________________________________________________ 1
LISTA DE ILUSTRAES_____________________________________________ 1
LISTA DE TABELAS _________________________________________________ 1
LISTA DE QUADROS_________________________________________________ 1
LISTA DE ABREVIATURAS E SIGLAS __________________________________ 1
1. INTRODUO ___________________________________________________ 13
1.1 Objetivos _____________________________________________________________ 17
1.2 Hiptese ______________________________________________________________ 18
1.3 Justificativa ___________________________________________________________ 19
1.4 A Escolha do Mtodo de Pesquisa_________________________________________ 20
1.4.1 Aspectos Conceituais da Pesquisa _______________________________________ 20
1.4.2 Atividades da Pesquisa ________________________________________________ 23
1.5 Estrutura do Trabalho __________________________________________________ 25
2. REVISO TERICA_______________________________________________ 26
2.1 Desenvolvimento de Produto _____________________________________________ 26
2.2 Processo de desenvolvimento de produto ___________________________________ 28
2.3 Processo de desenvolvimento de software __________________________________ 29
2.4 Modelos de Processo de software _________________________________________ 32
2.4.1 Modelo Cascata _____________________________________________________ 33
2.4.2 Modelo Espiral _____________________________________________________ 34
2.4.3 Modelo Incremental__________________________________________________ 35
2.4.4 Rational Unified Process (RUP)________________________________________ 37
2.5 Metodologias geis _____________________________________________________ 39
2.5.1 eXtreme Programming _______________________________________________ 41
2.5.2 SCRUM___________________________________________________________ 45
2.6 Qualidade no Processo de Software _______________________________________ 47
XI
2.6.1 CMMi ____________________________________________________________ 48
2.6.2 ISO/IEC 12207 _____________________________________________________ 54
2.6.3 MoProSoft _________________________________________________________ 55
2.6.4 MPS.Br ___________________________________________________________ 56
2.6.5 Comparativo CMMi e MPS.Br _________________________________________ 61
3. CARACTERSTICAS DA INDSTRIA DE SOFTWARE___________________ 64
3.1 Setor de Software no Brasil ______________________________________________ 64
3.1.1 Anlise das Condies de Atuao ______________________________________ 67
3.2 Avaliao do processo de desenvolvimento de software _______________________ 71
3.2.1 Procedimentos de avaliao____________________________________________ 73
3.2.2 Consideraes Gerais ________________________________________________ 74
3.2.3 Mtodos de Avaliao ________________________________________________ 74
3.3 Procedimento de avaliao de processo ____________________________________ 80
3.3.1 Processo de avaliao ________________________________________________ 81
3.4 Resultados da pesquisa__________________________________________________ 83
3.4.1 Sobre as empresas ___________________________________________________ 83
3.4.2 Anlise____________________________________________________________ 88
4. PROPOSTA DE UM MODELO DE REFERNCIA _______________________ 91
4.1 Modelos de referncia __________________________________________________ 91
4.2 O modelo de desenvolvimento de produto __________________________________ 93
4.2.1 Macro-Fases________________________________________________________ 94
4.3 Detalhamento do nvel G do MPS.Br ______________________________________ 96
4.3.1 Gerncia de Projetos _________________________________________________ 96
4.3.2 Gerncia de Requisitos ______________________________________________ 101
4.4 Pontos comuns entre MPS.br e o modelo de referncia ______________________ 103
4.5 Proposta do Modelo ___________________________________________________ 106
4.5.1 Processo Padro de Gerncia de Requisitos ______________________________ 114
4.5.2 Processo Padro de Gerncia de Projetos ________________________________ 123
5. APLICAO DO MODELO: UMA PESQUISA-AO ___________________ 136
5.1 A empresa ___________________________________________________________ 136
5.2 Estruturao da metodologia de trabalho na empresa_______________________ 138
5.2.1 Implantao do Processo de Gerncia de Requisitos _______________________ 139
5.2.2 Implantao do Processo de Gerncia de Projetos _________________________ 141
5.5 Disponibilizao do modelo de processo na empresa ________________________ 143
XII
5.6 O modelo em aplicao: a mensurao dos resultados _______________________ 145
5.7 Mensurao das melhorias _____________________________________________ 150
5.7.1 Resultados ________________________________________________________ 151
6. CONCLUSO___________________________________________________ 161
REFERNCIAS BIBLIOGRFICAS ___________________________________ 165
ANEXO I _________________________________________________________ 170
ANEXO II _________________________________________________________ 178





13
1. INTRODUO

A Tecnologia da Informao (TI) representa um conjunto de conhecimentos que
permite o tratamento integrado e sistmico das informaes, proporcionando o rpido
crescimento do conhecimento em todas as atividades humanas. Drucker (1968) afirma que
atravs da TI, o conhecimento se comporta como no princpio dos vasos comunicantes, da
Fsica, promovendo desenvolvimentos em direo a seqentes crescimentos em todas as reas
e avanado gradualmente. O software, entendido como um sistema integrador e sistematizador
das informaes, representa o principal meio para a gesto do conhecimento e para sua
operacionalizao. Deste modo, a atividade de produo de software ganha importncia
fundamental para o sucesso da gesto das tecnologias de informao e tem merecido a ateno
de inmeros pesquisadores em todo o mundo.
Examinando-se o formalismo processual no desenvolvimento de software e sua
constatao com a prtica vigente nas pequenas empresas, sediadas no mercado brasileiro,
percebe-se claramente um distanciamento das prticas adotadas frente aos procedimentos
recomendados. De fato, podem ser constatadas certas dificuldades advindas de falhas desse
processo, que, via de regra, peca pela ao no disciplinada capaz de bem sistematizar seu
desenvolvimento e aplicao, o que lhe acarreta os efeitos da no qualidade do sistema,
nocivos aos usurios e a prpria organizao.
As pesquisas dos ltimos anos em projeto de produto e da prpria engenharia de
software mostraram que a qualidade de um produto final conseqncia de um processo de
desenvolvimento bem disciplinado, capaz de levar em conta no apenas requisitos
previamente estruturados mas tambm aqueles a serem percebidos como exigncias
14
correlacionadas s reais condies de demanda, ou seja, os semi-estruturados e os no
estruturados.
Historicamente, a produo de software chega a se mostrar um procedimento catico.
Isso de deve principalmente aos poucos anos de experincia dessa rea que possui no mais
que seis dcadas. Desta forma, muitos mtodos, tcnicas e ferramentas esto ainda sendo
criados e implantados, no sentido de se melhorar a qualidade do produto.
Na dcada de 90 surgiram modelos de qualidade cujo propsito era ser um guia para
que empresas pudessem amadurecer o prprio processo de forma gradual. Modelos como
Capability Maturity Model Integrated (CMMi) e a prpria norma ISO so referncias nesse
sentido.
O CMMi um modelo de maturidade para o desenvolvimento e manuteno de
software e dos servios que abrangem o ciclo de vida do produto, desde sua concepo,
entrega e manuteno. O modelo enfatiza s disciplinas de engenharia de sistemas e tambm
engenharia de software e integrao necessria para se construir e manter os produtos de
forma abrangente. O CMMi oferece um conjunto de boas prticas agrupadas de acordo com
reas de atividades correlatas e nveis de maturidade. Os nveis correspondem a etapas
progressivas de eficcia gerencial e se apresentam como um caminho evolucionrio para
qualquer organizao que pretenda melhorar seus processos de desenvolvimento e
manuteno de software. CHRISSIS; KONRAD; SHRUM, (2003).
Desde que as empresas comearam a orientar a adaptao dos processos de
desenvolvimento a esses modelos e normas, muitos relatos de insucesso foram apresentados
em todo o mundo, principalmente no segmento de pequenas empresas.
15
O desafio das empresas atuais atingir um grau de qualidade em seu processo sem que
se perca produtividade. Esse fato marcado principalmente porque essas empresas dependem
de nveis satisfatrios de produtividade para concorrer e prosperar neste mercado competitivo.
Ocorre que, em algumas empresas, a busca pela produtividade acaba se tornando um
empecilho na garantia da qualidade, em conseqncia do mal uso dos recursos na medida e no
tempo adequado.
Com foco voltado para o mercado nacional, no qual mais de 70% das empresas so
pequenas segundo a ABES (2007) e a SOFTEX (2005), foi criado em 2003 o modelo
brasileiro de qualidade de software chamado de MPS.Br Melhoria do Processo de Software
Brasileiro que conta com o apoio do Ministrio da Cincia e Tecnologia (MCT) e de centros
de pesquisa como a SOFTEX e a RIOSOFT. Este modelo foi baseado nos modelos CMM,
ISO 12207 e ISO 15504 para que empresas nacionais pudessem amadurecer seu processo com
impacto reduzido, ou seja produtivamente.
O programa apresenta um modelo de referncia para melhoria (MR-MPS) e tambm
para avaliao de processo (MA-MPS). Atualmente existem 104 empresas que j se
certificaram em algum dos 7 nveis de maturidade, que so uma combinao entre processos e
capacidade de processos. MPS (2007).
Mesmo com esse modelo bem definido, ainda se encontram no mercado empresas que
no possuem formas de alcanar as metas propostas para garantir qualidade e isto se d devido
falta de uma estrutura j definida dos processos, ferramentas, documentos, papis que
auxiliariam no curso correto a ser seguido, ou seja, carecem ainda de um tratamento sistmico.
Sabe-se que um processo de desenvolvimento compreende atividades associadas
seguidas de forma ordenada que tenha incio e fim bem definidos, que ao trmino tenha-se um
produto que cumpra com seus requisitos pr-estabelecidos, ABNT (2000).
16
No desenvolvimento de software, pode-se definir um procedimento de forma similar
ao de qualquer outro produto. Um processo de software maduro e consolidado de extrema
importncia pois garante que o que foi desenvolvido permite obter, no mnimo, realmente o
que foi planejado. Muito esforo j foi despendido, ao longo dos anos, na busca de
metodologias de desenvolvimento que pudessem nortear equipes na construo de sistemas.
Entre essas metodologias se destacam: o modelo clssico, espiral, incremental, prototipagem.
Todos esses, entretanto, apresentam limitaes e problemas que os afastam de situaes reais.
PFLEEGER (2004).
De forma mais atualizada e garantindo uma eficcia maior, surgiram metodologias
chamadas geis, que deixam de lado os aspectos burocrticos do desenvolvimento para
valorizar produtividade. Entre elas se destacam: Extreme Programming e SCRUM. O efeito
sentido do sacrifcio da parte burocrtica do processo para o prestgio da agilidade de resposta
a perda da garantia da qualidade, tantas vezes percebida e reclamada pelos clientes.
Esta investigao prope o desenvolvimento de metodologia prpria e consolidada,
capaz de eliminar o aparente antagonismo de objetivos que se estabelece ao se minimizar o
protocolo e a burocracia e se prestigiar a reduo de tempo de processamento do projeto.
Assegurar qualidade e reduzir tempo so objetivos a serem perseguidos harmonicamente, se o
processo de projeto se d com o adequado tratamento sistmico.
Nesse sentido, este trabalho apresenta uma pesquisa de campo com cinco empresas
desenvolvedoras de software para levantamento da real situao em que as mesmas se
encontram com relao ao processo de desenvolvimento, em confronto com a teoria j
disponvel.
A partir desses dados e confrontando com dados nacionais que mostram a evoluo da
indstria de software brasileira, pode-se ter uma real situao de como estas organizaes
17
desenvolvem seus produtos e mediante dificuldades e problemas apresentados prope-se um
modelo de desenvolvimento otimizado para esse segmento, voltado principalmente para
cumprir com os propsitos do modelo de qualidade MPS.Br.
Tem-se como base para a criao de um modelo adequado para desenvolvimento de
software, o modelo de referncia de desenvolvimento de produto criado em ao conjunta de
grupos de trs universidades brasileiras: NUMA (EESC-USP), GEPEQ (DP-USFCAR) e
GEPP (UFSC). Segundo Rozenfeld et al (2006), essa ao, teve como resultado um modelo
de referncia que contm os conceitos e as melhores prticas em desenvolvimento de produtos
(DP) com a misso de se tornar referncia para a derivao de outros modelos, adequados a
um setor ou tipo especfico de produto. A justificativa para uso desse modelo que o mesmo
j foi utilizado em outras pesquisas com resultados satisfatrios.
Para se validar o modelo proposto, faz-se uma aplicao dos processos de gerncia de
projetos e de gerncia de requisitos, em dois projetos distintos, em uma pequena empresa
localizada na cidade de So Carlos SP. Aps a aplicao que levou 15 meses, props-se uma
avaliao qualitativa junto aos membros participantes do projeto para mensurao dos
resultados.

1.1 Objetivos
O objetivo principal deste trabalho propor um modelo de referncia para
desenvolvimento de software, aplicvel a pequenas empresas, de modo a permitir o alcance de
elevados padres de qualidade e produtividade na produo de software, em conformidade
com o modelo MPS.Br .
Para atingir o objetivo principal, so propostos os seguintes objetivos especficos:
18
Realizar uma investigao sobre os processos de desenvolvimento de software atuais,
presentes na literatura e utilizados nas empresas, tanto grandes quanto pequenas;
Realizar uma pesquisa bibliogrfica sobre mtodos de avaliao de processos de
desenvolvimento de software;
Realizar uma pesquisa de campo contextualizando a atual situao de cinco empresas
que desenvolvem software e os procedimentos adotados atualmente quanto ao
processo de desenvolvimento;
Acompanhar e avaliar em uma empresa desenvolvedora de software a aplicao do
modelo proposto em um projeto real;
Analisar possveis discrepncias de procedimentos e propor uma metodologia prpria
capaz de garantir a competitividade.

1.2 Hiptese
Para atingir os objetivos propostos, a seguinte hiptese de pesquisa ser examinada
atravs de reviso bibliogrfica e anlise qualitativa:
Hiptese 1: A garantia da qualidade e o alcance de elevados padres de produtividade sero
atendidos efetivamente, com uso adequado do modelo proposto.







19
1.3 Justificativa
Conforme dados do ABES (2007), 94% das empresas desenvolvedoras de software no
Brasil so pequenas, em um total aproximado de 1.894. Sabe-se que tais empresas enfrentam
barreiras para amadurecer seu processo de desenvolvimento em decorrncia das presses do
mercado e mesmo, da pouca integrao de suas equipes, o que, se superados, lhes garantir
alcanar melhores resultados em qualidade, produtividade e tempo de atendimento, na
qualidade de seus produtos. No dominando perfeitamente o gerenciamento do processo,
essas empresas passam a viver situaes complexas, com perda de clientes e de rentabilidade
chegando rapidamente ao insucesso.
Estendendo a abordagem ao mercado globalizado, pode-se perceber estar ocorrendo
um intenso processo de terceirizao no desenvolvimento de software, conhecido como off
shore, onde empresas americanas e europias vivendo um estgio mais intensivo em
tecnologia, buscam parceiros para desenvolverem sistemas capazes e com custos mais
competitivos.
Neste cenrio macroambiental, pases como ndia e China tm tido vantagens
principalmente por possurem certificaes de qualidade no processo de desenvolvimento.
Cabe as empresas desenvolvedoras de software no Brasil, neste momento, criar meios para
competir nesse mercado bastante promissor.
Uma das maneiras de se criar essa possibilidade no cenrio brasileiro justamente
fortalecendo e melhorando a forma pela qual as empresas criam seus produtos. Existe,
atualmente, um nmero considervel de processos para desenvolver sistemas
computadorizados, com srias restries ao uso em pequenas empresas, conforme ser
apresentado neste estudo. Entre esses processos se destacam modelos tradicionais como
espiral, incremental, cascata e mais modernamente as metodologias geis Extreme
20
Programming e Scrum como tambm o RUP (Rational Unified Process) que sofrem crticas
quanto garantia da qualidade final dos produtos.
Quanto a qualidade do processo de desenvolvimento, tem-se modelos como a norma
ISO 12207 e o CMMi, mundialmente conhecidos, mas que apresentam restries a adoo por
pequenas empresas. Surge como alternativa, para esse segmento grande de mercado, o modelo
brasileiro chamado de MPS.Br. Todos esses modelos indicam o que deve ser cumprido em
termos de metas para se garantir qualidade, porm fica na incumbncia das organizaes
proverem meios para atingir os objetivos necessrios. Na literatura existem poucos relatos de
uma estrutura que possa ser utilizada como referncia nas pequenas empresas.
Justifica-se ento a elaborao de um modelo de referncia, com o objetivo de ser
justamente, um guia a pequenas empresas na melhoria do seu processo de desenvolvimento de
software em conformidade com o modelo MPS.Br.

1.4 A Escolha do Mtodo de Pesquisa
Nesta seo apresentam-se consideraes sobre a metodologia da pesquisa empregadas
no trabalho, sua classificao e as atividades seguidas, bem como a exposio de motivos que
justifiquem a sua escolha.

1.4.1 Aspectos Conceituais da Pesquisa
A escolha da metodologia da pesquisa permitiu estabelecer uma reviso bibliogrfica
do contexto terico a partir do qual procedeu-se a escolha de procedimento melhor aplicvel
ao caso em investigao. De incio, estabeleceu-se uma classificao metodolgica que, para
21
melhor compreenso, destacando-se quatro aspectos: natureza, objetivos, forma da abordagem
do problema e procedimentos tcnicos adotados.
o Quanto natureza: Para Gil (2001) e Silva (2001), pode-se classificar
uma pesquisa quanto a sua natureza entre bsica e aplicada. Neste caso, em se
tratando de uma pesquisa onde a hiptese aplicada para se comprovar sua
veracidade, este trabalho caracterizado como uma pesquisa aplicada, pois
gera conhecimento prtico dirigido soluo de um problema especfico,
envolvendo verdades e interesses locais.
o Forma de abordagem do problema: Quanto abordagem do problema
que caracterizado por considerar a idia de que pequenas empresas no
possuem um modelo de referncia, adequado sua realidade, para o
desenvolvimento de software, esta pesquisa considera que existe uma relao
entre o mundo real e o sujeito que no traduzido em nmeros e que segundo
Silva (2001), reflete ao fato de que os dados e resultados devem ser, na sua
maioria, indutivamente analisados, no traduzindo em nmeros opinies e
informaes para classific-los e analis-los, caracterizando a pesquisa como
qualitativa. Sendo assim, no se faz uso de mtodos e tcnicas estatsticas.
o Quanto aos objetivos: Para Gil (2001) e Demo (1994) uma pesquisa pode
ser classificada de trs formas quanto aos seus objetivos: pesquisas
exploratrias, pesquisas descritivas e pesquisas explicativas. Em se tratando de
um estudo para familiaridade com o problema com vista a torn-lo explcito e
construir hipteses, este trabalho melhor caracterizado como pesquisa
exploratria, pois envolve levantamento bibliogrfico; entrevistas e visitas com
empresas que possuem o problema pesquisado.
22
o Procedimentos tcnicos adotados: Para Gil (2001), divide-se a
classificao quanto aos procedimentos tcnicos adotados nos seguintes itens:
pesquisa bibliogrfica, pesquisa documental, pesquisa experimental, pesquisa
ex-pos-facto, levantamento, estudo de caso, pesquisa-ao e pesquisa
participante. Neste aspecto, esta pesquisa tem caractersticas comuns a mais de
uma classificao. Por compreender um levantamento terico do assunto ao
estado da arte, pode ser classificada como pesquisa bibliogrfica. Tambm
caracterizado como uma pesquisa-ao, pois o escopo da pesquisa foi aplicado
e demonstrado em uma organizao de forma colaborativa entre o pesquisador
e seus colaboradores. A pesquisa-ao ou pesquisa participante se mostra
bastante enriquecedora pois ultrapassa a simples obteno de dados para,
atravs das possibilidades de comunicao biunvoca entre entrevistador e
entrevistado, colher opinies e mesmo, esclarecer o entrevistado sobre suas
condies de atuao, segundo Brando (1985) e Thiollent (1988).
O quadro 1, apresenta uma classificao da pesquisa, de forma geral para uma melhor
visualizao, destacando, em negrito, aquelas que foram adotadas neste trabalho.

Quadro 1. Representao da classificao metodolgica da pesquisa.

23
1.4.2 Atividades da Pesquisa
Escolhido o procedimento metodolgico a ser adotado, estabeleceu-se a seqncia de
atividades a serem desenvolvidas na sua realizao, conforme se apresenta na figura 1, a
seguir.
Durante a reviso da literatura buscou-se estabelecer o contexto terico, ao estado da
arte, de modo a oferecer subsdios para a identificao dos temas que cuja relevncia
pudessem contribuir para o melhor entendimento do assunto.
Com a justificativa traada foram propostos os problemas da pesquisa que serviram
para definir a hiptese e objetivos apresentados na seo 1.1 deste trabalho.
Para a hiptese estabelecida, procedeu-se a uma pesquisa de campo, entre empresas
representativas. Buscou-se entre as empresas desenvolvedoras de software aquelas que
pudessem oferecer contribuio efetiva. A seguir foram realizados os procedimentos para o
processo de avaliao composto das atividades de identificao das empresas pesquisadas,
aplicao do mtodo, anlise dos resultados, conforme ser apresentado no captulo 4.
24

Figura 1. Seqncia das atividades da pesquisa.

Complementarmente, com a anlise desses dados, pode-se confrontar os resultados
com estudos do Ministrio da Cincia e Tecnologia (MCT), para assim propor o modelo
desejado e posteriormente aplic-lo em projetos reais de uma empresa como forma de
comprovao da hiptese e mensurao dos resultados.






25
1.5 Estrutura do Trabalho
O presente trabalho est dividido em seis captulos, cujo contedo descrito a seguir:
O Captulo 1, que este, faz a introduo do assunto, apresenta os objetivos, as
justificativas, metodologia e hipteses para a realizao do trabalho, ou seja, apresenta como o
trabalho est estruturado.
O Captulo 2, atravs de reviso bibliogrfica, discorre os conceitos de
desenvolvimento de produto, desenvolvimento de software e qualidade.
O Captulo 3 realiza uma avaliao baseada no mtodo MARES com empresas de
pequeno porte, para traar a real situao destas quanto ao seu procedimento de
desenvolvimento. Faz-se tambm um levantamento amplo acerca dos vrios mtodos de
avaliao existentes.
O Captulo 4, com base nos dados levantados na pesquisa de campo, apresenta a
proposta do trabalho baseada no modelo de referncia proposto por Rozenfeld et al (2006)
para desenvolvimento de produto. Neste captulo contextualizam-se tambm conceitos e
definies acerca do que vem a ser um modelo de referncia.
O Captulo 5 demonstra os resultados da aplicao do modelo em uma empresa.
O Captulo 6, finalmente, aponta as consideraes finais do trabalho e discusso a
respeito de possibilidade de novas investigaes, a partir da pesquisa realizada.





26
2. REVISO TERICA

Este captulo aborda tpicos que se relacionam temtica de pesquisa e que sustentam
os processo de investigao, so eles: desenvolvimento de produto, processo de
desenvolvimento de produto, processo de desenvolvimento de software, metodologias para
desenvolvimento de software e modelos de qualidade aplicados ao processo de
desenvolvimento de software.

2.1 Desenvolvimento de Produto
Desenvolver produtos consiste em um conjunto de atividades por meio da qual busca-
se, a partir da necessidade do mercado e das possibilidades tecnolgicas chegar as
especificaes de projeto de um produto e sua posterior construo.
Ao longo dos anos, tem-se a percepo clara de que empresas que desenvolvem seus
produtos de forma a propiciar uma inovao, tem tido destaque frente ao mercado
competitivo. Essa inovao se faz possvel devido a um processo de desenvolvimento bem
estruturado.
O desenvolvimento de produtos gerenciado de forma eficaz e eficiente tem se
mostrado um diferencial competitivo para as organizaes. Atravs de um processo bem
definido e gerenciado, as organizaes de qualquer segmento so capazes de se manterem no
mercado de forma competitiva.
Mais do que desenvolver o produto, busca-se procedimentos capazes de promover
inovaes produtivas com eficcia. Sendo assim, o processo do projeto tem que ser
administrado em virtude do envolvimento de recursos financeiros, fsicos e humanos.
27
Neste sentido, Kaminski (2005) cita que o desenvolvimento de produtos uma tarefa
complexa, envolvendo diversos interesses e habilidades, tanto pelo lado do consumidor
quanto do desenvolvedor, equipe de vendas, distribuio e suporte, tornando assim o
desenvolvimento de novos produtos uma soluo de compromissos.
Entende-se que a atividade de desenvolver produtos deve se integrar com outras reas
funcionais para garantir um produto que realmente atenda ao que foi planejado. As reas so:
processo de vendas, suporte, suprimentos, produo, distribuio, pesquisa e
desenvolvimento, planejamento estratgico, atendimento ao cliente, monitoria do mercado. A
Figura 2 ilustra essa integrao entre os processos.


Figura 2. Processos relacionados com desenvolvimento de produtos. ROZENFELD et al. (2006)

Pela importncia que o desenvolvimento de produtos representa para as organizaes,
este captulo faz uma explanao sobre o PDP (processo de desenvolvimento de produto) e o
PDS (processo de desenvolvimento de software).
28
2.2 Processo de desenvolvimento de produto
O processo de desenvolvimento de um produto, segundo Pugh (1990), uma atividade
sistemtica, da identificao de necessidades de mercado/usurios at a venda do produto que
atenda com xito aquela necessidade, ou seja, uma atividade que envolve produto, processos,
pessoas e organizao, de modo a caracterizar os requisitos do projeto.
O PDP considerado como um processo pelo qual uma organizao transforma dados
sobre oportunidades de mercado e possibilidades tcnicas em informaes de valor para o
produto final, segundo Clark e Fujimoto (1991).
Adicionalmente, Cooper (1993) idealizador do chamado stage-gate, define o PDP
como um modelo formal, mapa, template ou processo pensado para orientar um projeto de um
novo produto do estgio de idias at depois do seu lanamento. Avanando em suas
contribuies Rozenfeld et al. (2006) defendem que o processo de desenvolvimento de
produtos operacionalizado atravs de projetos separados. Sendo assim, propem um modelo
de referncia genrico que adotado neste trabalho e que ser melhor discutido no captulo 5.
Uma forma de se caracterizar o processo de desenvolvimento de produto por meio
das seguintes dimenses, as quais esto presentes no modelo de referncia desenvolvido pelo
Grupo de Engenharia Integrada: ROZENFELD et al. (2006)
atividades/fases: H muitas formas de se classificar as fases e atividades do processo
de desenvolvimento de produto. Na Abordagem do Grupo EI e no modelo de
referncia so identificadas sete fases: Conceber Produto, Conceituar Produto,
Projetar Produto e Processo, Homologar Produto, Homologar Processo e Ensinar
Empresa. O modelo de referncia apresenta as atividades dispostas em cada uma
destas etapas;
29
recursos: compe-se de todos conceitos/filosofias, mtodos/tcnicas e
ferramentas/sistemas que podem ser aplicados no processo de desenvolvimento de
produto;
organizao: refere-se a no s a estrutura organizacional responsvel e executora
das atividades de desenvolvimento de produto como tambm os elementos como
cultura, qualificao profissional, formas de comunicao entre os indivduos, etc... ,
ligados aos aspectos de organizao do trabalho;
informao: dimenso que representa o fluxo de informao existente neste processo:
os dados, sua estrutura e o formato como estes circulam (relatrios, fichas, telas de
computador, etc...).
2.3 Processo de desenvolvimento de software
O Processo de desenvolvimento de software (PDS) se baseia no conceito generalizado
de processo, que pode ser definido como uma seqncia de estados de um sistema que se
transforma. SPINOLA (1999).
Entende-se ento que o conceito de PDS segue a mesma definio utilizada para
outros processos, sendo um conjunto de atividades inter-relacionadas que quando executadas
produzem um bem ou servio, que neste caso o software.
Apesar de possuir conceitos similares para definio de processos, Humphrey (1989),
define que a gesto de software se diferencia da gesto de um processo tpico de manufatura,
em virtude dos seguintes aspectos:
software geralmente mais complexo do que outros produtos manufaturados;
em virtude de a engenharia de software ser relativamente nova, no h muitos
gerentes e profissionais que tenham condies de avaliar um processo efetivo;
30
em outros campos da engenharia, a entrega para manufatura segue uma
disciplina natural que no encontrada no processo de software;
a disciplina de software no uma cincia natural. No se baseia em fundaes
naturais estveis da cincia, como a Fsica;
software a parte mais visvel de um sistema para os usurios; portanto,objeto
de constantes mudanas e reclamaes;
custos insignificantes de se reproduzir software faz com que a descoberta de
problemas ocorra muito tarde no ciclo de vida.
Sommerville (2003) cita que o processo de software definido como um conjunto de
atividades e resultados associados que produzem um produto de software. Pressman (2005)
apresenta a definio de um processo de software como um framework para as tarefas que so
necessrias para a construo de um software de alta qualidade.
O Software Engineering Institute (SEI) da Carnegie Melon University, prope o
seguinte:
Um processo uma seqncia de passos realizados para um dado
propsito. Colocado de maneira mais simples, processo aquilo que
voc faz. Processo aquilo que as pessoas fazem, usando
procedimentos, mtodos, ferramentas, e equipamentos, para
transformar matria prima (entradas) em produto (sada) que tenha
valor para o cliente. PAULK (1995).

Em meados dos anos 70, Schwartz j apontava as fases principais do processo de
produo de um sistema de software:
1. Especificao de Requisitos: traduo da necessidade ou requisito operacional para
uma descrio da funcionalidade a ser executada.
2. Projeto de Sistema: traduo destes requisitos em uma descrio de todos os
componentes necessrios para codificar o sistema.
31
3. Programao: (Codificao): produo do cdigo que controla o sistema e realiza a
computao e lgica envolvida.
4. Verificao e Integrao: (Check-out): verificao da satisfao dos requisitos
iniciais pelo produto produzido.

A definio mais atual oferecida por Sommerville (2003) similar; e divide as
atividades como especificao, desenvolvimento, validao e evoluo.
Um processo de desenvolvimento de software tem, segundo Booch, et al. (2005),
quatro objetivos fundamentais:
1) Providenciar orientao sobre a seqncia de realizao das atividades envolvidas.
2) Especificar os modelos descritivos do sistema que devem ser desenvolvidos.
3) Dirigir as tarefas dos participantes e da equipe como um todo.
4) Providenciar critrios para a monitorao e avaliao dos modelos e atividades do
projeto.

O no cumprimento eficiente dessas tarefas por parte de alguns projetistas se deve a
diversos fatores, inclusive os de carter histrico e justificado pela dificuldade que esses
projetistas enfrentam em definir um processo realstico para um produto que
predominantemente lgico e no exatamente, fsico.
Dessa forma, empresas que definirem seus processos, de forma eficiente, garantiro
sua sobrevivncia e destaque em um mercado globalmente concorrido, tendo estimativas,
custos, prazos e o cumprimento dos requisitos fielmente garantidos, ou seja eficincia no
processo e eficcia no produto. Inclusive com reais condies de comprovarem a maturidade
de seu processo, conquistando em funo disto, uma certificao de qualidade correspondente.
32
Entre os mais conhecidos se destacam o CMMi (Capablity Maturity Model Integrated), a
norma ISO 12207 e o MPS.Br (Melhoria do processo de software brasileiro).
Desde a dcada de 60 tem-se procurado estabelecer procedimentos sistematizados de
desenvolvimento que pudessem garantir um produto de qualidade. Desde que os primeiros
sistemas computacionais comearam a ser criados surgiram metodologias que tinham como
intuito servirem de guia para a criao de software. Entre eles se destacam, o Modelo Clssico
(Cascata), Espiral, Incremental, Prototipagem e mais recentemente as metodologias chamadas
de geis, como o Extreme Programming (XP) e o SCRUM.
Estas metodologias sofrem crticas quanto a sua eficcia de aplicao, dando margem
para que adaptaes sejam implementadas. O que se tem ainda, de fato um panorama
desfavorvel quanto a oferta de algum modelo eficaz que garanta produtividade e qualidade,
principalmente voltado para as pequenas empresas. Esforos neste sentido continuam a serem
despendidos.
A partir da definio das fases bsicas de um processo de desenvolvimento, muitos
pesquisadores idealizaram novos modelos na tentativa de padronizar e facilitar a criao de
um software. Alguns desses modelos sero descritos a seguir.

2.4 Modelos de Processo de software
Muitas vezes identificados como paradigmas, os modelos de desenvolvimento de
software foram surgindo desde meados dos anos 60 para reverter o que pode ser chamado de
forma catica de criao de sistemas. medida que novas tecnologias, bem como
necessidades foram aparecendo, esses modelos tentavam suprir a carncia por um processo
disciplinado de desenvolvimento.
Faz-se a seguir uma descrio dos modelos mais difundidos.
33
2.4.1 Modelo Cascata
Tambm conhecido como modelo clssico, foi criado por Royce (1970). Este modelo
tem como principal caracterstica o fato das atividades estarem distribudas de forma linear e
seqencial, como mostra a figura 3.


Figura 3. Modelo cascata. SOMERVILLE (2003).

Apesar da proposta inicial ter como caracterstica a retro-alimentao, o que tornava o
modelo menos linear, a prtica deturpou essa idia e o modelo passou a ser seqencial, o que
significa que cada etapa deve ser completada na sua totalidade para desencadear a prxima
fase. Isso demanda um tratamento ordenado e sistemtico ao desenvolvimento do software e
exige maior tempo de desenvolvimento. PFLEEGER (2004).
Apesar de ser considerado um modelo bastante didtico e fcil de ser compreendido,
muitas so as crticas a este paradigma. Uma das crticas se deve ao fato de que o modelo
sendo linear e seqencial, tem um custo muito elevado na manuteno j que o retorno para
uma das fases anteriores difcil.
Para Teles (2004), o modelo assume que todo o sistema construdo de uma nica
vez. Isso implica que para poder testar todo o sistema preciso que todas as fases anteriores,
34
desde o levantamento dos requisitos at a implementao, estejam concludas e integradas em
um todo. Na prtica, os erros ocorrem em todas as etapas do desenvolvimento e deixar os
testes para depois da implementao algo altamente ineficiente. Sabe-se que para sistemas
complexos onde no se tem todos os requisitos definidos, as dificuldades na utilizao desses
modelos o torna inoperante.

2.4.2 Modelo Espiral
O pesquisador Boehm (1988) sugeriu um modelo evolucionrio, isto , a medida que o
desenvolvimento ocorre, o produto evolui. O processo delimitado em uma seqncia de
fases que resultam verses incrementais do software. Na forma de espiral, cada volta na
espiral representa novos incrementos.
So definidas quatro importantes atividades conforme se apresenta na figura 4, a
seguir, que so:
(1) Planejamento: determinao dos objetivos, alternativas e restries.
(2) Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos.
(3) Engenharia: desenvolvimento do produto no nvel seguinte.
(4) Atualizao feita pelo cliente: avaliao dos resultados da engenharia.
Um ciclo se inicia com a fase de planejamento (primeira atividade) onde ocorre o
comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os
objetivos. Na segunda atividade, faz-se uma anlise de riscos. Usando a prototipao como
ferramenta. Uma vez que o risco for tido como inaceitvel, pode-se no continuar com o
35
projeto. Na terceira atividade ocorre o desenvolvimento do produto. Na quarta atividade o
produto avaliado e se prepara para iniciar um novo ciclo.


Figura 4. Modelo espiral resumido de Boehm. Adaptado de PRESSMAN (2005).

Em geral, modelos evolucionrios tm o propsito de lidar melhor com um conjunto
de requisitos que sofrem mudanas constantes ou que so incertos.

2.4.3 Modelo Incremental
Na viso de Pfleeger (2004), assim como o modelo espiral, o modelo incremental
tambm evolucionrio. Parte-se do princpio de que em um produto final no precisa
necessariamente ser entregue como um pacote, ao todo. Vrias partes, chamadas de
incremento, podem ser desenvolvidas separadamente conforme a prioridade.
Tem-se assim um ganho na confiabilidade do produto, j que o incremento entregue
antes, ser usado e testado de forma antecipada. A figura 5 mostra de forma simplificada este
modelo.
36
A desvantagem que para muitos usurios receber um produto em partes pode no ser
confortvel e a integrao entre os incrementos pode ser um fator de alto risco se no for bem
controlada.
Um processo de desenvolvimento segundo esse modelo divide o desenvolvimento de
software em iteraes. Em cada iterao, so realizadas as atividades de anlise, projeto,
implementao e testes para uma parte do sistema. Esta caracterstica contrasta com o modelo
em cascata, no qual as fases de anlise, projeto, implementao e testes so realizadas uma
nica vez para o sistema como um todo. PRESSMAN (2005).
Uma vez alocados os requisitos a uma iterao de desenvolvimento, estes requisitos
so analisados, projetados, implementados, testados e implantados. Na iterao subseqente,
um outro subconjunto de requisitos considerado para ser desenvolvido, o que produz uma
nova verso (ou incremento) do sistema que contm extenses e refinamentos sobre a verso
anterior. Desta forma, o desenvolvimento evolui em verses, atravs da construo
incremental e iterativa de novas funcionalidades at que o sistema completo esteja construdo.


Figura 5. Modelo Incremental. PRESSMAN (2005).

37
Mesmo com vrios modelos criados para disciplinar o processo de desenvolvimento,
durante todos esses anos, a indstria de software no conseguiu ter ndices de produtividade
aceitveis. Foi ento que na ltima dcada, alguns pesquisadores criaram o conceito de
desenvolvimento gil idealizando metodologias que poderiam quebrar os paradigmas at
ento estudados.

2.4.4 Rational Unified Process (RUP)
Este framework proprietrio foi criado em 1998 pela Rational Software Corporation
baseado-se nas melhores prticas de vrios outros processos que antecederam sua criao.
Tem como finalidade ser um guia para equipes de desenvolvimento na criao de produtos de
software. Segundo Booch et al. (2005), o processo unificado consiste em uma abordagem do
ciclo de vida de um processo, especialmente adequada UML (Unified Modeling Language).
Kruchten (2003) define o RUP como um processo bem estruturado para desenvolver
software com alta qualidade de modo repetvel e previsvel.
Uma caracterstica do RUP o fato de apresentar a modelagem de negcios durante o
incio do ciclo de desenvolvimento do produto, que torna o entendimento das necessidades
mais claras. A figura 6 apresenta o modelo de forma grfica para uma melhor compreenso.


38


Figura 6. Rational Unifield Process. KRUCHTEN (2003).

Nesta figura esto representados, nas linhas, as chamadas disciplinas, que indica o que
ser feito durante o desenvolvimento. J nas colunas, esto as fases do desenvolvimento. Na
interseco entre as linhas e colunas esto representadas as quantidades de esforo a ser
realizado por disciplina durante cada uma das fases.
O RUP composto por 4 fases, que so: concepo, elaborao, construo e
transio, cada uma com objetivos especficos, ou seja:
o Fase de concepo: estabelecer o escopo e a viabilidade econmica do projeto.
o Fase de elaborao: elimina os principais riscos e estabelece uma arquitetura
estvel a partir da qual o sistema poder evoluir.
o Fase de construo: um produto completo desenvolvido de maneira iterativa
at que esteja pronto para ser passado aos usurios, o que ocorre na fase de
transio, onde uma verso beta do sistema disponibilizada.
39
o Fase de transio: inicia-se um novo ciclo de desenvolvimento para a evoluo
do produto, o que envolveria todas as fases novamente. Em todas as fases
identifica-se no seu final um marco (milestone) de verificao de quais
objetivos da fase foram alcanados.
As disciplinas definem o que deve ser feito pelos responsveis em termos de atividades
e artefatos. Uma facilidade que o RUP apresenta fornecer modelos (templates) para cada
artefato e roteiros (guidelines) para cumprimento das atividades. Por estas prticas o RUP
considerado como sendo um processo de desenvolvimento iterativo e incremental, com
enfoque orientado a objetos (OO).
Apesar dessa abordagem ter surgido como uma soluo para empresas
desenvolvedoras, algumas crticas e limitaes devem ser consideradas. A principal delas est
relacionada ao fato do modelo ter sido criado por uma empresa comercial que vincula a cada
fase e disciplina produtos e ferramentas comerciais proprietrios. Outra crtica est
relacionada ao alto volume de documentos exigidos em cada atividade o que dificulta a
implementao por pequenas empresas que no possuem recursos para criar e gerenciar a
documentao.
Diante destas crticas, so poucos os relatos de pequenas empresas que conseguiram
implantar o framework com sucesso. Este fato remete s organizaes a criar derivaes e
adapt-lo s suas realidades, sendo que a derivao mais conhecida se chama openUP.

2.5 Metodologias geis
As chamadas metodologias geis para desenvolvimento de software, so uma resposta
s chamadas metodologias pesadas ou tradicionais. Fowler (2006) coloca as metodologias
40
modernas de desenvolvimento como uma reao aos modelos tradicionais e extremamente
conceituais, chamada por ele de monumentais que existem h muito tempo e que nunca
ficaram conhecidas por serem particularmente de sucesso. A crtica mais freqente a elas
que so burocrticas, ou seja, existe documentao excessiva.
Como uma reao a estas metodologias, um novo grupo apareceu na dcada de 90,
com maior flexibilidade de procedimentos que tentam estabelecer um compromisso til entre
nenhum processo e um processo excessivo, provendo apenas o processo necessrio e
suficiente para fornecer uma vantagem razovel.
A primeira impresso de que as metodologias geis de desenvolvimento se opem as
metodologias mais tradicionais, simplesmente porque geram menos documentos, no toca a
essncia dos mtodos geis. Duas das principais idias por trs dos mtodos geis, as quais os
diferenciam das demais metodologias, segundo Fowler (2006), so:
1. Mtodos geis so mais adaptativos do que previdentes. Mtodos tradicionais
procuram planejar em detalhes longos perodos, desta forma, da sua natureza a resistncia
mudana, uma vez que o planejamento esteja estabelecido. Mtodos geis, por sua vez,
acolhem a mudana a qualquer momento, a ponto de adaptar a prpria metodologia para
serem bem sucedidos.
2. Mtodos geis baseiam-se mais nas pessoas do que nos processos. Enquanto os
mtodos tradicionais procuram definir processos que vo funcionar com qualquer um que os
execute, os mtodos geis asseguram que nenhum processo pode superar as habilidades de
uma equipe. Desta forma, o papel do processo dar suporte equipe de desenvolvimento em
seu trabalho.
A discusso que se promove neste aspecto, est relacionada ao desenvolvimento de
software como um processo definido ou um processo emprico no sentido de no se
41
conhecerem todas as caractersticas do produto nas fases iniciais de desenvolvimento. As
metodologias geis partem do princpio de que o processo de software emprico.
Processos empricos baseiam-se na visibilidade dos aspectos e resultados do processo e
em prover maneiras de inspecionar e corrigir o processo e o produto. Dessa forma, processos
empricos aceitam as falhas como conseqncia natural da produo e tentam torn-las
visveis e passveis de correo o mais cedo possvel. Assim, argumenta Schwaber et al
(2002), a abordagem emprica ideal para o ambiente de desenvolvimento de software, onde
funcionalidades consideradas terminadas muitas vezes no esto suficientemente testadas e
aceitas pelo cliente, onde os passos a serem seguidos na criao de um produto s podem ser
descritos em alto-nvel (como elicitar requisitos) e onde correes, seguindo um processo
definido, tm um custo inaceitvel (modificar os documentos de requisitos, arquitetura e
testes alm do cdigo-fonte).
Existem diversos processos e metodologias que so consideradas geis, sendo Extreme
Programming, Scrum, Crystal e Microsoft Solution Framework (MSF), apenas alguns
exemplos.
Das metodologias geis existentes no mercado, a Scrum tem se destacado nos ltimos
anos por concentrar-se nas prticas e atividades de gerenciamento de projetos, reunindo aes
de monitoramento e feedback que visam identificar e corrigir deficincias e/ou impedimentos
no processo de desenvolvimento. A seguir so detalhadas as duas mais conhecidas.

2.5.1 eXtreme Programming
eXtreme Programming (XP) teve como idealizador o americano Kent Beck que em
1999 props uma forma de desenvolvimento que pudesse valorizar a programao ignorando
42
as atividades, que na viso do autor so demasiadas, como documentao, anlise e projeto
muito extensos. Sendo assim, esta abordagem voltada explicitamente para prticas de
codificao.
A metodologia est voltada para projetos cujos requisitos so alterados constantemente
com equipes pequenas (aproximadamente 12 desenvolvedores) e com desenvolvimento
iterativo.
De acordo com Beck (2004) uma empresa interessada em utilizar o XP deve-se basear
nos quatro valores defendidos pela metodologia, que so:
Feedback: o cliente estando disponvel gera constante retorno a equipe de
desenvolvimento;
Comunicao: uma boa comunicao essencial para agilizar o retorno do cliente a
equipe;
Simplicidade: deve-se implementar o necessrio para atender a necessidade do cliente;
Coragem: para se conseguir colocar em prtica todos os valores e prticas do XP.
Para Jeffries (2001), XP uma disciplina de desenvolvimento de software baseada em
valores que funciona unindo todo o time atravs de prticas simples, tais como oferecer
feedback suficiente para todos saberem onde esto posicionados em relao a um projeto e
como devem ajustar as prticas para esta situao nica.
Alm dos valores, tm-se algumas prticas que garantem o bom andamento dos
projetos, so elas: cliente presente, planejamento do jogo, stand up meeting, programao em
par, desenvolvimento guiado pelos testes, refatorao, cdigo coletivo, cdigo padronizado,
design simples, metfora, ritmo sustentvel, integrao contnua e releases curtos.
Essas prticas estabelecias por Jeffries (2001), so detalhadas a seguir.
43
Time: todos os envolvidos fazem parte do projeto e possuem contribuies;
Planejamento do jogo: atividade para definir estimativas, prioridades e
funcionalidades juntamente com o cliente;
Desenvolvimento orientado a testes: os testes so planejados antecipadamente ao
desenvolvimento;
Verses intermedirias: entrega de pequenas verses do software ao cliente que
poder acompanhar o desenvolvimento, diminuindo riscos e dando opinies sobre o
produto;
Programao em par: sempre dois programadores executam a funo em conjunto;
Projeto simples: evita-se complexidade desnecessria que poderia comprometer
desempenho e manutenibilidade;
Refatorao: consiste na melhoria da legibilidade do cdigo a fim de facilitar seu
entendimento e manuteno;
Padronizao do cdigo: todos seguem um padro de cdigo definido;
Metfora: a comunicao deve ser facilitada utilizando metforas;
Todos so donos de tudo: todo o cdigo pertence equipe e qualquer membro pode
melhorar o que for necessrio;
40 horas semanais: todo cronograma e estimativa so feitos para se trabalhar 40 horas
semanais. Se um membro necessitar trabalhar alm desse tempo significa que algo est
errado.
44

Figura 7. O processo Extreme Programming. PRESSMAN (2005).

As crticas a esta abordagem apontam que o XP no permite reproduzir resultados em
outros projetos, j que a documentao e o controle no so tratados de forma adequada e que
ela seria impraticvel em projetos complexos. Alm disso, existem barreiras como a
comprovao para o cliente de que um processo nessas condies ser eficaz. A
disponibilidade do cliente sendo necessria pode se tornar tambm um empecilho, uma vez
que nem todos projetos contaro com essa possibilidade e grandes empresas impem
burocracias para a tomada de decises e mudar isso extremamente complexo.
Apesar dessas barreiras e crticas, a metodologia mostra uma tendncia por solues
no sentido de se agilizar o desenvolvimento. Dentre as boas prticas, algumas como a
refatorao, a programao orientada a testes, a democratizao do cdigo fonte e
padronizao do cdigo, so extremamente vlidas e devem ser levadas em considerao.
45
2.5.2 SCRUM
Assim como Extreme Programming, a SCRUM outra metodologia gil que apresenta
uma comunidade grande de adeptos em todo o mundo. Idealizada por Ken Schwaber na
dcada de 90, Schwaber (2002), possui como objetivo fornecer um processo conveniente para
a gerncia de projeto e desenvolvimento orientado a objeto. Scrum se destaca das demais por
dar mais enfoque a rea de gerenciamento.
Trata-se de fato, de um processo de desenvolvimento iterativo e incremental que pode
ser aplicado a qualquer produto, no somente em software, ou no gerenciamento de qualquer
atividade complexa.
Segundo Schwaber et al. (2002), a Scrum apresenta uma abordagem emprica que
aplica algumas idias da teoria de controle de processos industriais para o desenvolvimento de
softwares, re-introduzindo as idias de flexibilidade, adaptabilidade e produtividade. O foco
da metodologia encontrar uma forma de trabalho dos membros da equipe para produzir o
software de forma flexvel e em um ambiente em constante mudana.
O fato da Scrum ser baseado em conceitos de processos industriais mostra que outras
engenharias podem contribuir e muito com a engenharia de software.
O mtodo baseia-se ainda, conforme Schwaber et al (2002), em princpios como:
equipes pequenas (mximas sete pessoas); requisitos que so pouco estveis ou
desconhecidos; e iteraes curtas. Divide o desenvolvimento em intervalos de tempos de, no
mximo 30 dias, tambm chamadas de Sprints.
Este mtodo no requer ou fornece qualquer tcnica ou mtodo especfico para a fase
de desenvolvimento de software, apenas estabelece conjuntos de regras e prticas gerenciais
que devem ser adotadas para o sucesso de um projeto. As prticas gerenciais do Scrum so:
46
Tarefas do Produto: define tudo o que necessrio no produto final. Contm uma
lista priorizada e constantemente atualizada dos requisitos do sistema que est sendo
construdo ou otimizado;
Estimativa de esforo: como a Scrum representa um processo iterativo, a estimativa
de esforo para executar as tarefas deve ser realizada freqentemente;
Sprint: procedimento de adaptao s mudanas de variveis de ambiente, como
requisitos, tempo, recursos ou tecnologia. Sprints so intervalos fixos de tempo, em
que todo o trabalho realizado. Na Scrum, um sprint tem durao de trinta dias.
Durante um sprint a equipe Scrum se organiza para produzir um incremento do
produto. Reunies Scrum dirias (Daily Scrum Meetings), de aproximadamente quinze
minutos realizadas para verificar o progresso do projeto;
Reunio de Reviso de Sprint: Apresentao dos resultados no ltimo dia do sprint.

As pequenas equipes so formadas de: projetistas, programadores, tecnlogos,
engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades
definidas no incio de cada sprint e so responsveis pelo desenvolvimento destas funes.
A figura 8, a seguir, representa o fluxo de desenvolvimento da metodologia Scrum.

47

Figura 8. Fluxo de desenvolvimento Scrum. Adaptado de COCHANGO (2006).

Como j foi dito, cabe reforar um aspecto positivo desta metodologia que o
procedimento de trabalho das equipes que estabelece reunies dirias e quinzenais.
Diariamente se realiza uma reunio de quinze minutos, onde o time apresenta gerncia o que
ser feito no dia seguinte, e nestas reunies os gerentes podem levantar os fatores de
impedimento e avaliar e o progresso geral do desenvolvimento.
Um dos fatores de destaque a possibilidade de fornecer um mecanismo de
informao de status, atualizado continuamente, e a redefinio pela responsabilidade de
tarefas a serem divididas dentro da equipe, de forma explcita.
Nas reunies quinzenais, a equipe se dedica a proceder a revises das etapas e do todo,
e sendo o caso, efetuar retroaes (feedback) para corrigir e otimizar o processo de projeto.
2.6 Qualidade no Processo de Software
A norma ISO/NBR 8402 (1994) define qualidade como a totalidade de caractersticas
de uma entidade que lhe confere a capacidade de satisfazer as necessidades implcitas e
48
explcitas. Necessidades explcitas so aquelas expressas na definio dos requisitos propostos
pelo produtor e necessidades implcitas, aquelas que embora no documentadas nas
exigncias do produtor, so necessrias ao usurio.
Segundo Machado (2001), para muitos projetistas de sistemas, a qualidade do processo
de software to importante quanto a qualidade do produto. A partir da dcada de 90 houve
uma crescente preocupao com a modelagem e melhoria do processo de software.
Abordagens importantes como as normas ISO 15504 e a ISO 12207, o modelo CMMi
(Capability Maturity Model Integrated) sugerem que melhorando o processo de software se
obtm a melhoria da qualidade dos produtos.
Para melhor caracterizao dos esforos, so apresentados, a seguir, os diversos
modelos criados ao longo do tempo, que estabelecem uma correlao construtiva, entre a
melhoria da qualidade do processo e a conseqente melhoria da qualidade do produto.

2.6.1 CMMi
O Capability Matururity Model Integrated o mais reconhecido modelo de qualidade
para processo de desenvolvimento de software no mundo. Idealizado pelo Instituto de
Engenharia de Software (SEI) da Universidade Carnegie Mellon - USA, teve sua primeira
verso lanada em 1991, com limitao somente voltada s prticas de engenharia de
software. Com a evoluo do modelo e sua aceitao mundial, vrios verses foram surgindo.
Como exemplo, tem-se: aquisio de software, gesto de times e desenvolvimento integrado
de produto e processo e engenharia de sistemas. O CMMi surgiu para unificar essas verses.
Humphrey (1989), principal idealizador do CMM, descreve que o modelo possui
estgios de maturidade pelos quais as organizaes passam enquanto evoluem o seu ciclo de
desenvolvimento, atravs de avaliao contnua, identificao de problemas e aes corretivas
49
dentro de uma estratgia de melhoria dos processos. Este caminho de melhoria definido por
cinco nveis de maturidade, conforme apresentado na Figura 9.


Figura 9. Nveis de maturidade do CMMi. CMMI-DEV (2006).

O CMMi possui duas representaes: "contnua" ou "por estgios". Estas
representaes permitem a organizao utilizar diferentes caminhos para a melhoria de acordo
com a necessidade:
o Contnua: possibilita a organizao utilizar a ordem de melhoria que melhor
atende os objetivos de negcio da empresa. composto por nveis de
capacidade.
o Por estgios: disponibiliza uma seqncia pr-determinada para melhoria
baseada em estgios que no deve ser desconsiderada, pois cada estgio serve
de base para o prximo, sendo composto por nveis de maturidade.
O quadro 2 apresenta de forma resumida, as caractersticas de cada nvel estabelecido
pelo CMMi:

50
Quadro 2. Caractersticas de cada nvel do CMMi.
1 Inicial No nvel 1 os processos so informais e caticos. Existe uma completa falta de
planejamento e controle dos processos. Os funcionrios esto focados
basicamente em atividades corretivas que surgem a todo instante.
2 Gerenciado Os processos bsicos de gerenciamento de projetos para planejar e acompanhar
custos, prazos e funcionalidades so estabelecidos. Compromissos so firmados
e gerenciados. A disciplina de processo permite repetir sucessos de projetos
anteriores em aplicaes similares. Tipicamente, possui gerenciamento de
projetos estabelecido; alguns procedimentos tcnicos escritos;
acompanhamento de qualidade; gerncia de configurao inicial; atividades
bsicas de medio e anlise. O sucesso depende basicamente do
gerenciamento do projeto.
3 - Definido Atividades de gerenciamento bsico e de Engenharia de Software so
documentadas, padronizadas e integradas em processos-padro. Todos os
projetos de desenvolvimento ou manuteno de softwares utilizam uma verso
de um desses processos adaptada s caractersticas especificas de cada projeto.
Possui processos gerenciais e tcnicos bem definidos, possibilidade de avaliao
do processo; ferramentas e metodologias padronizadas; medies iniciais de
desempenho; inspees e auditorias rotineiras; testes padronizados; gerncia
de configurao; evoluo controlada dos processos tcnicos e gerenciais.
4 Gerenciado
Quantitativamente
Mtricas detalhadas do processo de software e da qualidade do produto so
coletadas. Tanto o processo como o produto de software so
quantitativamente compreendidos, avaliados e controlados. Relatrios
estatsticos so gerados. Tipicamente, encontra-se estabelecido e em uso
rotineiro um programa de medies. A qualidade planejada por um grupo
dedicado, sendo rotineiramente avaliada e aprimorada
5 - Otimizado A melhoria contnua do processo estabelecida por meio de sua avaliao
quantitativa e da implantao planejada e controlada de tecnologias e idias
inovadoras. Projetos-piloto so realizados para a absoro e internalizao de
novas tecnologias. Tipicamente, um alto nvel de qualidade e de satisfao dos
clientes alcanado rotineiramente, com grande foco na melhoria contnua.
Fonte: FIORINI (1998).
Estruturado em 5 nveis de maturidade, o CMMi abrange 22 reas de processo que
segundo o CMMI-DEV (2006), so um conjunto de prticas interrelacionadas, que, quando
implementadas coletivamente, satisfazem os objetivos considerados importantes para obter
melhoramentos numa determinada rea. Essas reas de processos, por sua vez, so divididas
em 4 categorias:
Gerenciamento de projetos;
Gerenciamento de processos;
Engenharia;
Suporte.
51
A Tabela 1, a seguir, representa as 22 reas de processo do CMMi, sua categoria e
nvel de maturidade;
Tabela 1 - reas de Processo do CMMi.

Tabela 1































Fonte: CMMI-DEV (2006).

rea de Processo Categoria Nvel de
Maturidade
Anlise e Resoluo de Causas Suporte 5
Gerenciamento de Configurao Suporte 2
Anlise de Deciso e Resoluo Suporte 3
Gerncia de Integrao do Projeto Gerenciamento de
projetos
3
Medio e Anlise Suporte 2
Inovao e Implantao Organizacional Gerenciamento de
processos
5
Definio do Processo Organizational Gerenciamento de
processos
3
Foco no Processo Organizacional Gerenciamento de
processos
3
Desempenho do Processo Organizacional Gerenciamento de
processos
4
Treinamento Organizacional Gerenciamento de
processos
3
Integrao do Produto Engenharia 3
Monitorao e Controle de Projeto Gerenciamento de
projetos
2
Planejamento de Projeto Gerenciamento de
projetos
2
Garantia da Qualidade do Processo e do
Produto
Suporte 2
Gerncia Qualitativa do Projeto Gerenciamento de
projetos
4
Desenvolvimento de Requisitos Engenharia 3
Gerncia de Requisitos Engenharia 2
Gerncia de Risco Gerenciamento de
projetos
3
Gerncia de Acordo com Fornecedor Gerenciamento de
projetos
2
Soluo Tcnica Engenharia 3
Validao Engenharia 3
Verificao Engenharia 3
52
Apesar de toda notoriedade que o CMMi apresenta perante o mercado mundial, existe
uma discusso acerca de sua real aplicabilidade pelas pequenas empresas e pela adoo de
metodologias geis. Paulk (1998) apresenta uma viso sobre a utilizao do modelo em
pequenas empresas, defendendo que o modelo em si, somente diz o que deve ser cumprido em
termos de processos, deixando a cargo das pequenas empresas a forma de trabalho, tendo
ento que se buscar meios para isso.
Com relao a adoo de metodologias geis, Paulk (2001), em um estudo sobre o uso
do XP e CMMi ressalta que:
XP foca no trabalho tcnico e o CMMi nas questes de gerenciamento;
XP no aborda questes relacionadas institucionalizao das prticas em uma
organizao, o que considerado crucial para o CMM;
XP aborda, at um determinado limite, questes de gerenciamento e acompanhamento
de projetos.
Pode-se entender ento que, de acordo com estes relatos, o uso de algumas prticas,
seja de XP ou Scrum, podem ser utilizadas para auxiliar empresas, independentemente do
porte a cumprir com as metas do CMMi.
Modelos de qualidade e metodologias geis no so antagnicas e talvez possam
coexistir na mesma organizao. O CMMi pode servir como orientao para dizer quais
processos e prticas de gerencia de projetos devem estar presentes e Scrum para dizer como
esses processos devem ser executados.
Todavia, so poucos os relatos reais de implantao do CMMi em pequenas empresas
ou de adoo de metodologias geis. Segundo MCT (2006), apenas 70 empresas no Brasil tm
certificao CMM ou CMMi sendo que apenas seis esto no nvel 5, das quais, todas so
53
mdias ou grandes empresas. A tabela 2 apresenta uma cronologia da uso do CMM e do
CMMi , no Brasil e sua adoo por organizaes produtoras de software.

Tabela 2 - Organizaes com certificao CMM/CMMi no Brasil
Nvel Atual No
ano
At o
ano
Desde
2 3 4 5
CMM CMMi CMM CMMi CMM CMMi CMM CMMi
1997 1997 1997 1997
1 1 1
1998 1998 1998 1998
1 1 2
1999 1999 1999 1999
2
2000 2000 2000 2000
2
2001 2001 2001 2001
4 4 6
2002 2002 2002 2002
3 3 9
2003 2003 2003 2003
16 1 1 18 27
2004 2004 2004 2004
6 2 1 9 36
2005 2005 2005 2005
14 11 1 2 2 30 66
2006 2006 2006 2006
1 3 4 70
Total 40 11 8 4 1 6 70
Fonte: MCT (2006).

54
Diante dessa constatao e das dificuldades encontradas pelas pequenas empresas,
algumas aes colocam-se como alternativa ao CMMi. Entre eles pode-se destacar o
MOPROSOFT no Mxico e o MPS.Br no Brasil, ressaltando-se que ambos so fortemente
baseados nas diretrizes da norma ISO/IEC 12207 apresentada a seguir.

2.6.2 ISO/IEC 12207
A Norma ISO/IEC 12207 foi criada pela International Organization for
Standardization (ISO) e o International Electrotechnical Commission (IEC).
Esta norma estabelece os processos, atividades e tarefas a serem aplicados durante a
aquisio, fornecimento, desenvolvimento, operao e manuteno de software. Definindo de
forma ampla os processos que guiam a adaptao da sua utilizao nos projetos de software
em uma empresa.
Como objetivo, passa a contar com o auxlio dos envolvidos na produo de software,
de modo a melhor definir suas funes, por meio de processos bem estabelecidos, e assim,
proporcionar s empresas que a utilizam um entendimento melhor das atividades a serem
seguidas nas operaes correlacionadas.
A verso brasileira da norma, publicada em 1998, tem o mesmo nome que da norma
internacional, acrescida das iniciais NBR.
Para Nogueira (2003), a adoo da norma ISO/IEC 12207 pelo desenvolvedor de
software, estabelece os procedimentos de como estruturar e gerenciar o ciclo de
desenvolvimento, proporcionando a possibilidade de acompanhamento de todo o processo e,
permitindo que o software venha representar mais fielmente, a realidade da empresa
modelada, para gerao de um sistema customizado, atendendo assim de modo adequado os
requisitos e necessidades demandados por essa empresa.
55

2.6.3 MoProSoft

Este um modelo para a melhoria e manuteno de processo de desenvolvimento para
a indstria de software mexicana. Desenvolvido pela Associao Mexicana para a qualidade
em engenharia de software, atravs da Faculdade de Cincias da Universidade Nacional
Autnoma do Mxico (UNAM) e da Secretaria de Economia com a finalidade de se
estabelecer uma norma mexicana que fosse apropriada s caractersticas de tamanho da
grande maioria das empresas daquele pas que so pequenas uma vez que elas representam
92% das empresas. MOPROSOFT (2006).
O modelo proposto, assim como os outros apresentados a seguir, neste trabalho, est
focado em processos e considera trs nveis bsicos estruturais de uma organizao: alta
direo, gerencial e operacional.
A alta direo engloba os processos de Gesto de Negcios. O nvel gerencial engloba
Gesto de Processos, Gesto de Projetos e Gesto de Recursos. Este ltimo est constitudo
pelos sub-processos: recursos humanos e ambiente de trabalho, bens, servios e infraestrutura
e conhecimento da organizao. O nvel operacional integrado pelos processos de
administrao de projetos especficos e de desenvolvimento e manuteno de software.
Em cada processo esto definidos os responsveis pela execuo das prticas. As
regras so direcionadas s pessoas da organizao, de acordo com suas habilidades e
capacitao para desenvolve-la.
A figura 10, representa as relaes de processos e sub-processos, estabelecidos pelo
MOPROSOFT (2005) e seus nveis de responsabilidade intrnseca.
56

Figura 10. Diagrama da relao entre processos. Adaptado de MOPROSOFT (2005).

2.6.4 MPS.Br
O MPS.Br um programa para Melhoria de Processo do Software Brasileiro,
coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX),
contando com apoio do Ministrio da Cincia e Tecnologia (MCT), da Financiadora de
Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).
Conforme descrito em MPS (2007), esse programa tem como propsito definir e
aprimorar um modelo de melhoria e avaliao de processo de software, em atendimento
preferencialmente s pequenas e mdias empresas, de forma a satisfazer as suas necessidades
de negcio e ser reconhecido nacional e internacionalmente como um modelo aplicvel
indstria de software.
O MPS.Br tambm estabelece um processo e um mtodo de avaliao, que oferece
sustentao e permite verificar que o mesmo esteja sendo empregado de forma coerente com
as definies. Pode-se dizer que esta nova possibilidade representa uma sensvel melhoria e
contribuio ao domnio do tema.
57
Tomou-se como base para a construo deste modelo de melhoria e avaliao de
processo de software, as normas NBR ISO/IEC 12207, a norma internacional ISO/IEC 12207
e a ISO/IEC 15504, o que permite considerar, portanto, que o modelo est em conformidade
com estas normas. Este modelo tambm garante o contedo do CMMI-SE/SW, atravs da
incluso de processos e de resultados, segundo WEBER (2005).
O modelo de referncia MR-MPS define Nveis de Maturidade, que so uma
combinao entre processos e capacidade de processos, conforme a estrutura apresentada na
figura 11.

Figura 11. Estrutura do MR-MPS. MPS (2006).

A definio dos processos neste caso segue a forma apresentada na ISO/IEC 12207,
declarando o propsito e os resultados de sua execuo. Isso permite avaliar e atribuir graus
de efetividade na execuo dos processos. As atividades e tarefas necessrias para atender ao
propsito e aos resultados so definidas pelos usurios do MR-MPS.
2.6.4.1 Nveis de maturidade
De fato, os nveis de maturidade estabelecem patamares de evoluo de processos,
caracterizando estgios de melhoria de implementao de processos na organizao. O nvel
58
de maturidade em que se encontra uma determinada organizao permite prever seu
desempenho futuro em uma ou mais disciplinas. O MR-MPS define sete nveis de maturidade:
A (Em Otimizao); B (Gerenciado Quantitativamente); C (Definido); D (Largamente
Definido); E (Parcialmente Definido); F (Gerenciado) e G (Parcialmente Gerenciado). A
escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um destes sete
nveis de maturidade foi atribudo um perfil de processos e de capacidade de processos que
indicam por exemplo, onde a organizao tem que colocar esforo para melhoria de forma a
atender os objetivos do negcio, ou destaca seus pontos fortes.
O Quadro 3 apresenta os nveis de maturidade do modelo, seus processos e as
capacidades necessrias para cada nvel.
Quadro 3. Nveis de maturidade do MPS.Br
Nvel Processo Capacidade
A Inovao e Implementao na Organizao
Anlise e Resoluo de Causas
AP1.1, AP2.1, AP2.2, AP3.1 e AP3.2
B Desempenho do Processo Organizacional
Gerncia Quantitativa do Projeto
AP1.1, AP2.1, AP2.2, AP3.1 e AP3.2
C Anlise de Deciso e Resoluo
Gerncia de Risco
AP1.1, AP2.1, AP2.2, AP3.1 e AP3.2
D Desenvolvimento de Requisitos
Soluo Tcnica
Integrao do Produto
Instalao do Produto
Liberao do Produto
Verificao
Validao
AP1.1, AP2.1, AP2.2, AP3.1 e AP3.2
E Treinamento
Avaliao e Melhoria do Processo
Organizacional
Definio do Processo Organizacional
Adaptao do Processo para Gerncia de
Projeto
AP1.1, AP2.1, AP2.2, AP3.1 e AP3.2
F Medio
Gerncia de Configurao
Aquisio
Garantia da Qualidade
AP1.1, AP2.1 e AP2.2
G Gerncia de Requisitos
Gerncia de Projetos
AP1.1 e AP2.1
Fonte: MPS (2007).
59
O progresso e o alcance do nvel de maturidade so obtidos, quando so atendidos
todos os resultados e propsitos do processo, e tambm os atributos do processo relacionados
quele nvel e aos anteriores.
A diviso em estgios, tendo como referncia os nveis de maturidade do CMMi tem
uma escala diferenciada, com o propsito de almejar uma implementao e avaliao mais
gradual e adequada s pequenas e mdias empresas. A possibilidade de se realizarem
avaliaes considerando maior detalhamento e um maior nmero de nveis, permite ao
gerenciador uma maior visibilidade dos resultados de melhoria dos processos o que acarretar
maior confiabilidade e menores custos ou tempo de execuo.

2.6.4.2 Capacidade do Processo
A capacidade do processo um conjunto de atributos descrito em termos de resultados
os quais proporcionam o cumprimento dos atributos de processo. A capacidade estabelece o
grau de refinamento e institucionalizao com que o processo executado na organizao.
Cabe destacar que medida que se evolui nos nveis, um maior ganho de capacidade para
desempenhar o processo exigido pela organizao.
Para melhor entendimento, a capacidade do processo se caracteriza segundo cinco
atributos de processos (AP) que so:
AP 1.1 O processo executado;
AP 2.1 O processo gerenciado;
AP 2.2 Os produtos de trabalho do processo so gerenciados;
AP 3.1 O processo definido, e;
AP 3.2 O processo implementado.

60
2.6.4.3 Processos
Por processos entende-se o conjunto de operaes realizadas segundo mtodos
prprios, desenvolvidos para o entendimento de necessidades estabelecidas ou implcitas.
Responde ao como fazer.
Os processos, de acordo com MPS (2006), so descritos em termos de:
o Propsito: descreve o principal objetivo a ser atingido durante a execuo
do processo e os provveis resultados obtidos com a efetiva implementao
do mesmo;
o Resultados do processo: podem ser evidenciados por um artefato
produzido, uma mudana significativa de estado e um atendimento s
especificaes;
o Informaes adicionais: so referncias que podem ajudar na definio do
processo pela organizao.

Os processos so agrupados, por uma questo de sistematizao, de acordo com o seu
objetivo principal no ciclo de vida de software. Esse agrupamento caracteriza em trs
diferentes classes de processos, que so, segundo MPS (2007):
Fundamental: atendem o incio e a execuo do desenvolvimento, operao ou
manuteno dos produtos de software e servios correlatos durante o ciclo de vida de
software;
De Apoio: auxiliam um outro processo e contribuem para o sucesso e qualidade do
projeto de software;
Organizacional: uma organizao pode empregar estes processos em nvel corporativo
para estabelecer, implementar e melhorar um processo do ciclo de vida.
61
A figura 12 apresenta as classes de processos fundamentais, organizacionais e de apoio do
MPS.BR, destacando os pontos fundamentais a serem considerados no desenvolvimento de
software.


Figura 12. Classes de Processos do MPS.Br. MPS (2006).

2.6.5 Comparativo CMMi e MPS.Br
Feitas as apresentaes individuais dos diferentes modelos de processo destacando
suas caractersticas e especificidades, cabe explicitar comparativamente suas vantagens e
limitaes.
62
O MPS.Br possui uma srie de diferenciais (ou vantagens) se relacionado com outros
modelos de processo. Segundo Couto (2007) alguns desses diferenciais so:
Os sete nveis de maturidade do MPS.Br permitem uma implementao mais
gradual, adequada micro, pequena e mdia empresa, alm de aumentar a
visibilidade do processo de melhoria;
O MPS.Br possui compatibilidade com CMMI e SPICE (Software Process
Inprovement and Capability dEtermination), que so modelos reconhecidos
internacionalmente;
O modelo MPS.Br foi criado pensando na realidade da empresa brasileira, com
foco na micro, pequena e mdia empresa de software;
Permite sua aplicao a custos acessveis (em R$) adequados a realidade brasileira.
A qualificao da empresa que o aplica mantida por avaliaes peridicas (de
dois em dois anos).

A comparao do MPS.Br com o CMMi tambm interessante, pois o CMMi um
dos modelos de maturidade mais importantes, reconhecido internacionalmente. Fica evidente
que o MPS.Br no tem como objetivo a criao de algo novo no que se refere s normas e
modelos de maturidade, mas sim uma adaptao inovadora dos modelos existentes para a
realidade das empresas brasileiras. Com isso, pode-se dizer que a adequao da empresa s
normas de maturidade descritas no MR-MPS pode ser vista, em alguns casos, como uma
preparao para uma avaliao posterior do CMMi.
Cabe lembrar que o CMMi possui cinco nveis de maturidade designados pelos
nmeros de 1 a 5, diferente do MR-MPS que possui sete nveis designados pelas letras de A a
G. Os nveis de maturidade do CMMi possuem uma relao com os nveis de maturidade do
MR-MPS, conforme apresentado na figura 13, a seguir:
63


Figura 13: Nveis de Maturidade: CMMI x MR-MPS. Adaptado de PINTO (2006).


Pode-se dizer que no MR-MPS a diviso dos nveis de maturidade permite uma
implementao mais gradual e adequada s micros, pequenas e mdias empresas brasileiras. A
possibilidade de se realizarem avaliaes, considerando um nmero maior de nveis permite
uma visibilidade dos resultados de melhoria de processo, na empresa e no pas, com prazos
mais curtos, COUTO (2007).
Como se observa, no h critrios conflitantes nos diferentes modelos, apenas
adaptaes estabelecidas por fora das especificidades do mercado brasileiro.



64
3. CARACTERSTICAS DA INDSTRIA DE SOFTWARE

Este captulo tem a finalidade de avaliar pequenas empresas desenvolvedoras de
software, com o objetivo de possibilitar melhor entendimento das efetivas condies pelas
quais essas empresas, de forma geral, realizam os processos de produo de software. Para
tanto, procedeu-se uma reviso bibliogrfica sobre as caractersticas da indstria de software
no Brasil e sua evoluo e tendncias, de modo a permitir a compreenso do macro e do
microambiente que circunstanciam a atuao do setor.
Para a realizao desta avaliao, procedeu-se a um levantamento amplo dos mais
destacados critrios de avaliao, de modo a se identificarem suas efetivas condies
materiais e intelectuais de produo, seu ambiente de atuao e suas prticas, diante de suas
potencialidades e limitaes. Para se ter um balizador nacional, foi realizada uma comparao
com os resultados de pesquisas do MCT, estabelecido como um referencial macro, de modo a
permitir comparao de pontos comuns ou discrepantes, sobre a efetividade de atuao da
amostra considerada. Fez-se tambm um estudo da evoluo do setor de software no pas,
com o intuito de melhor compreender as caractersticas das empresas no Brasil.

3.1 Setor de Software no Brasil

O Brasil possui 7.818 empresas de software, dedicadas ao desenvolvimento, produo
e distribuio de software e prestao de servios. Daquelas que atuam no desenvolvimento e
produo de software, 94% das empresas so classificadas como micro e pequenas, em um
total de 1.894. ABES (2007).
65
Os grficos 1 e 2, apresentam um panorama da diviso das empresas por porte e por
tipo de atividade respectivamente:







Grfico 1: Diviso por porte da empresa. ABES (2007).







Grfico 2: Diviso das empresas por tipo de atividade. ABES (2007).

A caracterizao do tamanho da empresa estabelecida pelo Servio Brasileiro de
Apoio s Micro e Pequenas Empresas (SEBRAE) e pelo Instituto Brasileiro de Geografia e
Estatstica (IBGE), segundo critrios diferentes. So consideradas micro e pequenas empresas
aquelas que, de acordo com o SEBRAE (1998) apresentam:
faturamento menor que R$ 1,2 milhes por ano.
possui menos que 50 empregados.

53.60%
22%
24.20%
Distribuio
Servio
Produo
36.80%
57%
5.10%
0.80%
Micro
Pequena
Mdia
Grande
66
O BNDES (Banco Nacional de Desenvolvimento Econmico e Social) apresenta
definio diferente para classificar as micro e pequenas empresas, baseando-se na receita
operacional bruta anual. Sendo:
at R$ 1,2 milho - micro empresa.
superior a R$ 1,2 milho e inferior ou igual a R$ 10,5 milhes - pequenas empresa.

O SEBRAE utiliza como critrio de classificao, o faturamento a partir da
comercializao bruta anual das empresas, o que, neste caso, inclui valores provenientes da
comercializao de software e de outros produtos e servios de informtica ou no, de acordo
com a faixa de valores a que pertencem, considerao que pode mascarar o quantitativo
especfico da produo de softwares, com outras atividades.
A tabela abaixo apresenta uma comparao entre os valores definidos pelo Sebrae e
pelo BNDES quanto a classificao por faturamento.
Tabela 3 - Classificao das empresas segundo o porte
Porte
Agncia Micro Empresa Pequena
Empresa
Mdia Empresa Grande empresa
SEBRAE
At 19
empregados.
Faturamento
anual de R$ 244
mil
At 99
empregados.
Faturamento
anual de at R$
1,2 milho

BNDES
Receita
operacional bruta
anual ou
anualizada de
at R$ 1,2
milho
Receita
operacional bruta
anual ou
anualizada
superior a R$ 1,2
milho e inferior
ou igual a R$
10,5 milhes
Receita
operacional bruta
anual ou
anualizada
superior a R$
10,5 milhes e
inferior ou igual a
R$ 60 milhes
Receita
operacional bruta
anual ou
anualizada
superior a R$ 60
milhes.
MCT
de 1 a 9
pessoas.
de 10 a 49
pessoas.
de 50 a 99
pessoas.
100 ou mais
pessoas.
67
A classificao por faturamento transparece algumas inadequaes quando aplicadas
s empresas de software, visto que existem casos de empresas com um nmero reduzido de
colaboradores mas que apresentam faturamento alto. Este fato, pode significar o alto grau de
inovatividade contida nos softwares, o que lhe agrega valor.
Sendo assim, utilizada neste trabalho, a classificao definida pela MCT (2005) que
considera a fora de trabalho, quer seja efetiva (scios, dirigentes e empregados efetivos)
quanto total (efetivos mais terceiros prestadores de servio, bolsistas e estagirios) e
adotando-se como critrio:
- microempresas (de 1 a 9 pessoas),
- pequenas (de 10 a 49 pessoas),
- mdias (de 50 a 99 pessoas) e
- grandes (100 ou mais pessoas).


3.1.1 Anlise das Condies de Atuao

Entender as condies de atuao da empresa de software um dos mais importantes
pontos para se compreender as contingncias de execuo do processo de produo de
software, pois representa a maturidade gerencial e o profissionalismo de atuao.
Um aspecto interessante desta anlise compreender que as pequenas empresas
representam em seu conjunto, uma significativa porcentagem do faturamento do setor e
empregam um nmero elevado da mo de obra, MCT (2005), mas que possuem como
caracterstica marcante o fato de no apresentarem um processo de desenvolvimento de
software maduro. Essa dificuldade em amadurecer o processo de desenvolvimento, tem
conseqncias no faturamento, na sua prpria competitividade, na qualidade dos produtos
68
gerados, entre outros fatores. Pode-se dizer que h um interrelacionamento entre os fatores:
competncia, incorporao tecnolgica, nvel de solues oferecidas e faturamento.

3.1.1.1 Caractersticas gerais de atuao

Estudos qualitativos de carter exploratrio destacam que, as caractersticas marcantes
das pequenas empresas desenvolvedoras de software no Brasil so derivados de um processo
de software imaturo e inconcluso. Entre essas caractersticas se destacam, segundo
FERNADES (2004):
Informalidade: no existem processos previamente definidos e adotadas pela empresa.
A produo de software fortemente dependente de prtica individual, baseada na
formao e capacidade dos desenvolvedores;
No h ambiente estvel de desenvolvimento: nada novo projeto demanda o emprego
de toda a ateno e competncia no seu tratamento, desde as etapas de definio de
requisitos at a entrega do produto. Assim, sucessos anteriores no se repetem, de
forma sistematizada;
O sucesso se deve competncia: o processo fortemente marcado pelo esforo dos
desenvolvedores, em atos que beiram ao herosmo, pelos esforos despendidos;
Dependncia de pessoas especficas: o que resulta em queda acentuada de
produtividade ou mesmo incapacidade de realizar alguma tarefa quando certas pessoas
deixam a empresa, pois grande parte do conhecimento pode ser no estruturado, vai
com quem o detm.
Incapacidade de controle do processo: o que ocasiona na constante verificao de
problemas nos cronogramas ou oramentos estabelecidos, resultando em atrasos no
desenvolvimento ou na sobrecarga das pessoas para evitar provveis atrasos;
69
Falta de Comprometimento com Qualidade: existe a preocupao com prticas
voltadas garantia de qualidade dos produtos, porm, freqentemente ocorre o
abandono dessas prticas em momentos de presso e stress.
Em questes relacionadas ao tratamento dos requisitos de software, tem-se:
Definio de requisitos de software de maneira informal, apenas por meio de contatos
pessoais (reunies), as vezes sem registro, gerando futuras discrdias entre
desenvolvedores e clientes;
Desconhecimento ou no aplicao de tcnicas de Engenharia de Requisitos;
Procedimentos informais de validao dos requisitos sem um comprometimento
formal do cliente;
Alteraes dos requisitos de uma maneira informal, s vezes at atravs de contatos
telefnicos, sem avaliao de efeito sobre custos ou cronograma;
Alteraes efetuadas por pessoas no qualificadas ou autorizadas a faz-lo;
Falta de ateno aos requisitos ao longo do desenvolvimento, levando frustraes do
cliente com requisitos no considerados ou mal interpretados;

Tais condicionantes oneram qualitativa e quantitativamente as empresas por afetarem
sua imagem de competncia, s vezes de maneira irrecupervel.
Nos processos de Gerenciamento do Desenvolvimento, ficam evidentes os seguintes
pontos, conseqncia direta da falta de controle sobre as operaes:
Falta de abordagens metodolgicas bem como de dados histricos para estimativas de
custo e esforo;
Cronograma e oramento com elevado nvel de incerteza;
Falta de argumentos objetivos (nmeros) para respaldar uma negociao de
cronograma e oramento de clientes;
70
Execuo e planejamento, sem a correspondente medio peridica ao longo do
desenvolvimento, resultando em perda do controle do estado do desenvolvimento;
Falta de capacidade de acompanhar o progresso de um desenvolvimento de forma
objetiva (quantitativa);
Falta de controle de responsabilidades mtuas, levando a empresa a arcar com atrasos
que no so seus, como por exemplo, quando um cliente atrasa uma avaliao prevista
no cronograma;
Falta de preocupao com gerenciamento de riscos, que so percebidos apenas quando
se materializam em forma de problemas reais;
Falta de capacidade de antecipao de possveis atrasos, levando a constatao do
problema s vsperas do encerramento de prazos, quando mudanas de planejamento
so inviveis;
No aplicao de aes corretivas no momento adequado, quando o planejado no se
efetiva.
Impossibilidade de se estabelecer landmakers, ou indicadores de desempenho para
verificao de progresso ao longo dos prazos estabelecidos.

No aspecto preservao de dados, constata-se forte disperso causada por:

Perda de verses anteriores de um software;
Armazenamento dos produtos (verso anteriores, inclusive) dependente de disciplina
individual;
Alteraes bem intencionadas e no discutidas levando ao caos;
Indefinio de quem pode alterar documentos e produtos e de como as alteraes so
definidas e avaliadas;
Falta de controle de mudanas;
71
Dificuldade para desfazer uma mudana aps contatar resultado insatisfatrio.

Assim sendo, as experincias e os resultados anteriores, no sendo sistematicamente
documentados, no permitem criar um histrico e um referencial de aprendizagem, contido
numa base de dados produtiva.
A observao desta circunstncia de atuao das empresas e a experincia
desenvolvida ao longo do tempo, ensejaram um aprofundamento no tema, merecendo esta
pesquisa.
Com o intuito de entender com maior preciso as caractersticas e problemas
enfrentados pelas empresas, foi realizada uma pesquisa de campo em cinco empresas, todas
localizadas no interior do estado de So Paulo, com o objetivo de avaliar a real condio sob
as quais elas desenvolvem seus produtos.
A seguir, se apresentam as consideraes sobre a pesquisa de campo, assim como o
processo e mtodo de avaliao escolhido, buscando-se correlacionar o contexto terico com a
prtica reinante e suas circunstncias.

3.2 Avaliao do processo de desenvolvimento de software
De incio cabe destacar que qualquer processo de desenvolvimento de software
apresenta um significativo grau de dificuldade, principalmente por se tratar da concepo e
materializao de uma soluo de alto contedo abstrato e no fsico, onde questes subjetivas
e no estruturadas tm forte participao. Mesmo assim, uma aproximao com as prticas de
organizao sistmica e de planejamento estratgico podem representar uma significativa
contribuio melhoria dos procedimentos de gesto neste tipo de atuao. Como exemplo,
72
pode-se recorrer ao planejamento estratgico de Porter (2004), para anlise dos pontos fortes,
pontos fracos, ameaas e oportunidades (PFOA); ou ao Balanced Scorecard BSC de Kaplan
e Norton (1997) que permite estabelecer o planejamento estratgico, de incio, sob quatro
perspectivas: a econmica (gerao de renda e reduo de custos); a do cliente (na pr-venda,
venda e ps-venda); a dos processos internos que do suporte atividade principal da
empresa, no caso, a produo e desenvolvimento de software e a aprendizagem e inovao.
O entendimento do que uma empresa faz e como ela faz um passo importante para
traar uma tentativa de gerenciamento, planejamento ou melhoria das atividades.
Segundo Wangenheim (2005), as anlises so feitas por meio de uma avaliao de
processo, que um exame disciplinado das atividades usadas por uma organizao, baseada
em um modelo de referncia com o objetivo de determinar a capacidade destes processos e a
maturidade da organizao.
Tanto o CMMi, o MPS.Br e a ISO/IEC 12207, possuem mtodos prprios e normas
para avaliao de processo de software, porm apresentam limitaes para uma avaliao de
contextualizao.
No processo de melhoria como um todo, existem basicamente trs tipos de avaliaes,
que podem ser usadas para avaliar o processo, motivar equipes, direcionar estratgias e
determinar um estado em comparao a um modelo ou norma, ou formar uma linha base para
acompanhar a melhoria. SALVIANO (2004).
Os principais tipos de avaliao incluem:
Avaliaes de contextualizao: ponto inicial no processo de melhoria onde
gera-se um entendimento da sua situao atual considerando os principais
pontos fortes e fracos.
73
Avaliaes detalhadas: so realizadas para avaliar em mais detalhes os
processos importantes e crticos.
Avaliaes contnuas: podem ser integradas com programas de medio
existentes para monitorar os processos selecionados durante e depois da
implantao das aes de melhoria.

3.2.1 Procedimentos de avaliao
Os procedimentos de avaliao encontram dificuldades em sua realizao ocasionadas
entre outras, pela rapidez da inovao, pela especificidade de cada projeto e por decorrncia
das mudanas estruturais da prpria empresa.
Comparando-se por exemplo, com a indstria metal-mecnica, que atua sob
encomenda, na execuo de produtos unitrios, repetem-se as dificuldades semelhantes:
o Prazos dilatados de concepo e desenvolvimento;
o Necessidade de se contar com equipes com conhecimento intensivo e
competncias de planejamento, concepo, desenvolvimento, testes e
consolidao de procedimentos;
o Grande possibilidade de migrao da empresa desenvolvimentista do software
para a empresa aplicadora (Spin off de profissionais);
o Dificuldade de se estabelecer ganhos de escala, advindos da padronizao, da
repetitividade ou por analogia na aprendizagem do processo, com casos
semelhantes, anteriormente tratados;
o Dificuldade de se estabelecerem padres de produo e portanto, controles de
produo efetivos, o que se agrava, pela imaterialidade e subjetividade na
criao de solues.
74
Um ponto importante a ser destacado neste caso, refere-se ao fato das dificuldades em
se realizar tais avaliaes. Principalmente por se tratar de um produto tecnolgico que sofre
mudanas rpidas, alm da especificidade de cada projeto e do aspecto gerencial onde
mudanas contnuas e rpidas na estrutura da empresa afetam o processo de desenvolvimento.

3.2.2 Consideraes Gerais
Feitas estas consideraes, nascidas da anlise das circunstncias de atuao das
empresas, fortalece-se a idia de se aprofundar no estudo do assunto. Sendo o objetivo deste
trabalho identificar a situao atual de algumas empresas com relao ao processo de
desenvolvimento, a avaliao de contextualizao foi usada no primeiro momento, por
permitir um rpido diagnstico das condies de atuao da organizao.

3.2.3 Mtodos de Avaliao
Mtodo de avaliao de processo de desenvolvimento de software um exame
disciplinado dos processos usados por uma organizao baseado em um modelo de referncia
com o objetivo de determinar a capacidade destes processos e/ou maturidade de uma
organizao, segundo Wangenheim (2005).
Paulk et al. (1995) salientam que um mtodo de avaliao fornece a estrutura bsica
para a investigao do processo e permite um rpido e consistente desenvolvimento das
constataes que apontam os pontos fortes e fracos da organizao.
A elaborao de mtodos de avaliao no algo recente, tendo seu incio em meados
da dcada de 70 quando pesquisadores da IBM, preocupados com atrasos nos cronogramas,
falta de controle de verses entre outros problemas criaram mecanismos para avaliar o
75
processo e futuramente melhor-los. Desde ento, dezenas de mtodos foram criados, cada
qual com suas especificaes e caracterstica.
Apresenta-se a seguir, de maneira sucinta, alguns mtodos aplicados mundialmente e
que foram adotados como referncia nesta pesquisa.

3.2.3.1 QuickLocus
Criado em 2003 por pesquisadores do Instituto de Pesquisas Tecnolgicas do Estado
de So Paulo IPT, trata-se de um mtodo de avaliao voltado para pequenas e mdias
empresas.
Segundo Kohan (2003), destina-se s organizaes de software com at cinqenta
pessoas, utilizando um tempo reduzido de aplicao e cujo resultado fornece a base para um
plano de melhoria do processo de desenvolvimento. A aplicao do QuickLocus consome, em
geral, apenas um dia de trabalho na organizao, quando avaliado um escopo reduzido do
modelo de referncia.
Este mtodo permite estabelecer a escolha do modelo de avaliao que ser utilizado,
como o CMMi ou a ISO/IEC 15504.

3.2.3.2 RAPID
Criado na Austrlia o mtodo RAPID - Rapid Assessment for Process Improvement for
Software Development teve como motivao atender as pequenas e mdias organizaes que
no possuiam recursos para custear as avaliaes mais detalhadas que duravam cerca de
quatro dias.
76
Assim como os demais, o mtodo compatvel com a ISO/IEC 15504, tornando
possvel que o resultado de suas avaliaes possam ser comparados com o resultado de outras
organizaes que o utilizam.
Tem como caracterstica a necessidade de avaliadores qualificados para sua aplicao,
sendo considerado um bom mtodo por fornecer subsdios para melhoria de processo.

3.2.3.3 MARES
Mtodo criado por pesquisadores do Laboratrio de Qualidade e Produtividade de
Software da UNIVALI (Universidade do Vale do Itaja), com objetivo de desenvolver um
modelo e mtodo de avaliao de processo de software integrando o CMMi-SW e a norma
ISO/IEC 15504 em uma forma adaptada s caractersticas das micros e pequenas empresas
brasileiras de software visando posterior melhoria de processo.
De acordo com Anacleto (2004), este mtodo se diferencia dos demais,
principalmente, pela definio de uma estrutura que auxilia na caracterizao da organizao e
seleo dos processos relevantes, passveis de serem melhorados no contexto especfico.
Este mtodo encontra-se disponvel publicamente, incluindo uma descrio detalhada
de todas as atividades da avaliao com guias para sua adaptao a contextos especficos.
Outra caracterstica positiva que o mtodo no exige conhecimento especfico dos
representantes das empresas participantes sobre avaliao de processos e sobre o modelo de
referncia utilizado, o que facilita sua aplicao.
Segundo Wangenheim (2006) este mtodo se destaca justamente por ser voltado a
pequenas empresas que possuem vrios fatores limitantes quanto a utilizao de outros
mtodos.
77
3.2.3.4 MA-MPS

Este mtodo permite a realizao de avaliaes em empresas seguindo o modelo
MPS.Br (melhoria do processo de software brasileiro). A figura 14, a seguir, destaca o mtodo
de avaliao do MPS.Br dentro do modelo.


Figura 14. O modelo MPS.Br. WEBER (2005).

Os requisitos do MA-MPS so baseados nos requisitos dos mtodos de avaliao
definidos na norma ISO/IEC 15504, os requisitos definidos no CMMi e os prprios requisitos
definidos pelo MPS.Br.
Conforme apresentado em MA-MPS (2007) um mtodo avaliativo voltado para
pequenas e mdias empresas e se destaca por possuir facilitadores que garantem seu uso de
forma acessvel a essas organizaes.
A avaliao utilizando este mtodo exige um lder e membros da equipe com
certificao do modelo.




78
3.2.3.5 FAME
Este um mtodo de avaliao unificado, desenvolvido na Alemanha e que
infelizmente oferece pouca referncia disponvel. Seu foco no exclusivamente voltado s
pequenas empresas, podendo ser aplicvel nas demais. Suporta avaliaes tanto com o
objetivo de melhoria, quanto determinao da capacidade. O mtodo auxilia determinar os
pontos fortes e fracos dos processos de software atuais e auxilia na tomada de decises para a
melhoria de processo. Este mtodo utiliza o modelo de avaliao padro da ISO/IEC TR
15504.

3.2.3.6 TOPS
O projeto TOPS (Toward Organised Process em SMEs small and medium
enterprises) foi formado pela Comunidade Europia com o propsito de difundir as melhores
prticas de software e, particularmente, propor caminhos de melhoria para empresas regionais
da Itlia.
Desde o incio do projeto foi identificado que a melhor maneira de incentivar
programas de melhoria contatar diretamente a empresa e executar uma avaliao rpida de
processo de software para identificar e planejar aes especficas. O projeto desenvolveu um
mtodo de avaliao rpida, adaptando o SPICE (ISO/IEC TR 15504) e oferecendo a
avaliao, sem custos, para as empresas que se integrassem a ele. O programa de avaliaes
teve como objetivos, estimular interesse em avaliaes de processo de software e suas
melhorias, contribuir na definio de planos de melhoria, coletar dados e estatsticas sobre
melhorias de processo de software, enfim estabelecer uma referncia para a contnua
otimizao.
79

3.2.3.7 ISO/IEC 15504
A ISO, em 1992, destacou a necessidade de se elaborar uma norma que fosse aplicvel
melhoria de processos e determinao da capacidade. Este padro deveria considerar os
mtodos e normas j existentes (como por exemplo, o SW-CMM e a ISO 9001), abranger
todos os processos de software e ser construdo pelos especialistas que j desenvolviam e
trabalhavam com os mtodos e normas existentes. Como resultado desse primeiro trabalho, a
ISO iniciou em janeiro de 1993, o projeto SPICE (Software Process Improvement and
Capability dEtermination) com o objetivo de produzir inicialmente um relatrio tcnico que
fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais especfico
que a norma ISO 9001 originando assim a norma ISO/IEC 15504.
Esta norma se presta realizao de avaliaes de processos de software com dois
objetivos:
o melhoria de processos;
o determinao da capacidade de processos de uma unidade organizacional.
Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma
avaliao com o objetivo de gerar um perfil dos processos que ser usado para a elaborao de
um plano de melhorias. A anlise dos resultados identifica os pontos fortes, os pontos fracos e
os riscos inerentes aos processos. No segundo caso, a organizao tem como meta avaliar um
fornecedor, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao comprador
estimar o risco associado contratao daquele fornecedor para auxiliar na tomada de deciso
de contrat-lo ou no. Esta anlise de risco permite alimentar o processo de deciso de se
contratar ou no determinada empresa. Cabe lembrar que o insucesso na aquisio de um
80
software extrapola os custos de aquisio em si e repercute em perdas s vezes irreparveis,
decorrentes da no disponibilidade no tempo certo, de uma ferramenta estratgica.

3.3 Procedimento de avaliao de processo
A avaliao do processo de desenvolvimento em uma organizao pode variar de
acordo com o mtodo escolhido. Normalmente, so escolhidos avaliadores capacitados, um
modelo de avaliao compatvel e um processo de avaliao.
Para a realizao da pesquisa de campo deste trabalho foi escolhido o mtodo
MARES. O fator principal que justifica a escolha deste mtodo o fato do mtodo apresentar
uma avaliao de contextualizao facilmente aplicvel e que apresenta resultados
satisfatrios, sendo que o mesmo j foi aplicado em centenas de empresas brasileiras. Os
outros mtodos destacados nesta pesquisa esto voltados para avaliaes detalhadas ou
avaliaes contnuas e na maioria dos casos exige pessoal certificado para aplicar a pesquisa.
Outros fatores que justificam a escolha desse mtodo de avaliao so:
Baixo custo;
Rapidez na aplicao;
Obteno de resultados confiveis;
Casos relatados de aplicaes bem sucedidas j realizadas com o mtodo;
Dados obtidos servem de base para o processo de melhoria;
Fcil acesso aos questionrios e material.


81
3.3.1 Processo de avaliao
Uma avaliao deve ser conduzida de acordo com um processo documentado, capaz de
atender aos propsitos previamente estabelecidos. O processo documentado de avaliao tem
que conter as atividades de planejamento, coleta de dados, validao dos dados e a
apresentao dos resultados. Segue-se o detalhamento de cada um destes requisitos:
Planejamento: o planejamento do procedimento de avaliao deve ser desenvolvido
em funo da empresa em estudo e deve estar contido num plano, devidamente documentado,
de modo a incluir os seguintes elementos: entradas requeridas, atividades a serem executadas,
recursos e cronograma, identidade e as responsabilidades definidas dos participantes da
avaliao, critrios de ponderao dos fatores quanto a sua importncia relativa, descrio dos
resultados esperados e consideraes relevantes;
Coleta de Dados: os dados requeridos para a avaliao dos processos dentro do escopo
da avaliao e informaes adicionais devem ser coletados de forma sistemtica,
considerando-se no mnimo, um estudo prvio sobre estratgia e tcnica para a seleo, coleta,
anlise e justificativa para atribuio de notas; estabelecimento de correspondncia entre os
processos das unidades organizacionais e os elementos do modelo de avaliao de processo.
Validao dos Dados: os dados coletados necessitam ser validados para confirmar se
as evidncias coletadas so objetivas, para garantir que as mesmas so suficientes e
representativas para cobrir o escopo e o propsito da avaliao e para garantir que os dados
coletados, como um todo, sejam consistentes.
Apresentao dos Resultados: os resultados da avaliao, incluindo no mnimo as
sadas especificadas, tm que ser documentados e comunicados ao patrocinador da avaliao
ou ao seu representante. Os resultados devem conter no mnimo, os seguintes elementos: data
da avaliao, as entradas da avaliao, a identificao das evidncias objetivas utilizadas, a
82
abordagem utilizada para a avaliao, a identificao do processo documentado de avaliao e
o conjunto de perfis de processo resultante da avaliao, sendo um perfil de processo para
cada processo avaliado. A figura 15, detalha as etapas do processo de avaliao.


Figura 15. Etapas do processo de avaliao.

Para este trabalho foi primeiramente idealizada, a elaborao de um mtodo de
avaliao prprio, porm com o avano dos estudos, pde-se constatar a existncia de
mtodos j consagrados que atenderiam aos objetivos previamente estabelecidos. O mtodo
MARES foi escolhido, por comparao entre alternativas.
Escolhido o mtodo, iniciou-se a etapa de planejamento, com o contato com empresas
conhecidas, seis foram selecionadas. Esse contato aconteceu inicialmente por telefone e por
email. Cabe destacar que uma das empresas teve seus resultados posteriormente
desconsiderados por apresentar dados no relevantes e, por ter encerrado suas atividades.
Nesta etapa buscou-se fazer um levantamento prvio da empresa atravs do site, para um
rpido entendimento das suas atividades.
A etapa de coleta de dados durou 3 meses, entre as entrevistas e as visitas. Cada
entrevista teve durao de 1 dia. As dificuldades dessa etapa ficaram relacionadas ao
83
agendamento das entrevistas com representantes da empresa, e a busca por dados entendidos
como confidenciais que foi solucionada com a assinatura de um acordo de confidencialidade.
Com os questionrios preenchidos, iniciou-se a anlise dos dados. Esta etapa levou 16
dias para ser concluda e teve como objetivo, identificar as prticas de cada empresa com
relao aos processos de desenvolvimento, seus pontos fortes e fracos, seguindo o modelo de
Porter (2004).
A etapa de validao foi realizada em conjunto com as empresas para garantir os dados
coletados e a posterior anlise. Aproveitou-se nesta etapa para, como forma de contribuio
empresa, realizar uma apresentao aos colaboradores mostrando os pontos fortes e fracos
levantados na pesquisa e discutindo-se melhorias aplicveis, ocorrendo uma interao
amigvel entre entrevistador e entrevistados.
Os resultados da anlise dessa pesquisa de campo so apresentados a seguir.

3.4 Resultados da pesquisa
3.4.1 Sobre as empresas
o EMPRESA A
Trata-se de uma empresa com sete anos no mercado que iniciou suas atividades
desenvolvendo portais corporativos, sendo ganhadora inclusive de prmios nacionais pelos
trabalhos realizados. Passou a desenvolver sistemas sob-encomenda e atualmente tem um foco
em desenvolvimento de software web para o setor de logstica. Em 2005 realizou a exportao
de seus produtos para pases da Amrica do Sul, fato que exigiu mudanas no processo de
desenvolvimento, de modo a atender aos padres de qualidade exigidos pelo cliente.
84
Quanto ao desenvolvimento de software a empresa apresentava algumas prticas
positivas como mtricas para estimativas e outras boas prticas de gesto de projetos e
codificao, porm, no de maneira institucionalizada. Revelou falhas nas atividades de
levantamento de requisitos e testes, j que essas tarefas no possuem padro de documentao
e o gerenciamento de documentao, quando feito, falho. Cada projeto segue um processo
diferenciado perdendo-se boas prticas j realizadas em projetos anteriores e os
correspondentes ganhos de aprendizagem.
A empresa conta com o apoio de uma consultoria para criar o planejamento estratgico
da organizao, evidenciando o interesse pela melhoria de seus processos visando crescimento
nas exportaes.

Ramo Portais Corporativos e Logstica
Nmero de colaboradores 7
Localizao Jundia - SP
Ano da Fundao 2000
Entrevistado (Cargo) Proprietrio / Gerente de Projeto
Quadro 4. Quadro resumo da empresa A.


o EMPRESA B
Empresa familiar com foco em desenvolvimento de software para instituies
educacionais, tem entre seu produto-chave um ERP (Enterprise Resource Planning) para
gesto escolar. O ponto chave da organizao o grau de conhecimento dos scios quanto a
tecnologias de informao e suas correlaes.
85
No existe em sua atuao, processo definido de desenvolvimento e apresenta poucas
prticas de gesto de projetos, o que acarreta problemas principalmente em gerenciar
requisitos. Pelo pequeno nmero de colaboradores existe uma sobreposio de funes e certa
negligncia em atividades-chave.
A empresa possui dezenas de clientes e o foco maior est na customizao e
manuteno de produtos, porm no existe um processo padro definido o que acarreta,
inclusive a dificuldade de reutilizao de cdigo-fonte.
Apresenta necessidade de formalizar seu processo de desenvolvimento em todos os
aspectos.

Ramo Software Gesto Educacional
Nmero de colaboradores 3
Localizao Tamba SP
Ano da Fundao 2004
Entrevistado (Cargo) Scio da Empresa
Quadro 5. Quadro resumo da empresa B.


o EMPRESA C
Como foco voltado para projetos agropecurios, a empresa se destaca por desenvolver
software com alto grau de inovao e pioneirismo, a partir de financiamento de rgos de
fomento pesquisa.
A organizao possui um organograma bem definido, porm em momentos crticos, as
atribuies so deixadas de lado para cumprimento de metas e prazos prementes. Existe
portanto um conflito entre a estrutura formal, contida no organograma e a efetividade dos
86
nveis decisrios, que diante de situaes-problema, so centralizados em uma ou duas
pessoas. Existe um processo de desenvolvimento definido e documentado, todavia sem muito
detalhamento e com falta de padres de documentao. O padro de codificao existe, porm
no ocorre um processo de verificao de seu cumprimento. O processo definido pela empresa
necessita ser adaptado a uma realidade mais voltada ao mercado, com ganhos de
produtividade.
A durao dos projetos de aproximadamente 6 meses, sem muito controle do
cronograma e de estimativas, e o gerenciamento correto depende direta e fortemente da
experincia dos gerentes.








Quadro 6. Quadro resumo da empresa C.


o EMPRESA D
Empresa pioneira em algumas tecnologias, possui significativos projetos com clientes
de grande porte, no setor de automao tendo foco no desenvolvimento de hardware. Como
ponto favorvel tem-se a gerncia de projetos bem definida com uso de softwares e mtodos
declarados, bem como na padronizao de cdigo-fonte, seguida por todos. Por ter uma forte
propenso ao uso de software livre em seus produtos, a empresa se utiliza tambm para
Ramo Software Agropecurio
Nmero de colaboradores 16
Localizao So Carlos - SP
Ano da Fundao 2003
Entrevistado (Cargo) Gerncia de Projeto
87
atividades internas, de vrias ferramentas de cdigo aberto, o que agrega valor e facilita o
cumprimento de tarefas, como trabalho colaborativo, controle de verso, entre outros.
Esta empresas, no apresenta um programa definido de qualidade e vrias atividades
so dependentes de esforo individual de colaboradores que na maioria dos projetos
desempenham papis no previamente definidos. A documentao dos projetos falha, o que
fica evidente na falta de padro dos documentos gerados. No existe atualmente um processo
declarado de desenvolvimento de software.

Ramo Automao e software livre
Nmero de colaboradores 13
Localizao So Carlos - SP
Data da Fundao 2003
Entrevistado (Cargo) Diretor de Tecnologia
Quadro 7. Quadro resumo da empresa D.


o EMPRESA E
Empresa voltada para sistemas de automao comercial e industrial, possuindo 14
produtos em seu portflio. Apresenta a maioria dos funcionrios lotados nos processo de
suporte, que no so padronizados, ocasionando problemas na manuteno.
Nenhum documento tcnico gerado durante o projeto, apenas documentos
contratuais. Esse fato remete a empresa a problemas srios de rastreabilidade de requisitos e
de configurao de software toda vez que novas funcionalidades so exigidas.
88
Outro ponto negativo detectado foi o fato de no existir qualquer tipo de controle de
verso ou gerncia de configurao.
Como ponto positivo se destaca o fato da empresa atuar em um mercado competitivo
dominar o mercado em um raio de 130 km, de sua sede.

Ramo Automao Comercial e Industrial
Nmero de colaboradores 12
Localizao Porto Ferreira - SP
Data da Fundao 2000
Entrevistado (Cargo) Proprietrio / Gerente de Projetos
Quadro 8. Quadro resumo da empresa E.

3.4.2 Anlise
De acordo com a pesquisa de campo realizada, pode-se constatar que todas as cinco
empresas analisadas so caracterizadas como pequena empresa, uma vez que possuem menos
de 49 colaboradores. Elas apresentam algum tipo de processo de desenvolvimento, porm no
formalizado e documentado, o que acarreta deseconomias e perdas de produtividade em
termos de cumprimento das metas e de uma definio de documentos e padres a serem
seguidos. Outro fator que, no operando como processos institucionalizados, em momentos
de crise tende-se a abandonar o planejado, como recorrncia compensatria.
Em quase todas as organizaes pesquisadas existe algum tipo de preocupao com
qualidade como, por exemplo na documentao de especificaes, na padronizao de cdigo
e de testes, entretanto, a falta de um modelo, acarreta nestas empresas a impossibilidade de
repetir boas prticas j adquiridas em outros projetos e de se beneficiar com os ganhos da
89
aprendizagem, ou seja, no se verificarem crescimentos ao longo das curvas de aprendizagem
decorrentes dos processos.
Outra caracterstica marcante detectada na pesquisa foi a constatao de que todas as
empresas j enfrentaram problemas pela no formalizao de documentos, como plano de
projeto ou documento de requisitos, inclusive com descontrole de verses de ativos (softwares
e documentos). Nas fases inicias estes procedimentos informais levam a validao dos
requisitos sem um comprometimento do cliente, dificultando inclusive as alteraes dos
requisitos, pois no h meios de rastre-los
A falta de abordagens metodolgicas bem como de dados histricos para estimativas
de custo e esforo torna cada novo projeto a um elevado nvel de incerteza quanto a
cronograma e oramento;
Faz-se a seguir uma descrio de outros problemas constatados:
Desconhecimento e conseqente falta de uso de mtodos para anlise de riscos.
Inexistncia de um ambiente estvel de desenvolvimento.
Dependncia marcante de colaboradores chave.
Execuo e planejamento, sem a correspondente medio peridica ao longo do
desenvolvimento, resultando em perda do controle do estado do desenvolvimento.
Falta de capacidade de acompanhar o progresso do desenvolvimento de forma objetiva
(quantitativa);
Falta de planejamento estratgico definido para alinhamento e direcionamento dos
projetos a serem iniciados.
Falta de capacidade de antecipao de possveis atrasos,
Alteraes bem intencionadas e no discutidas levando ao caos;
90
Diante deste diagnstico, constata-se, uma forte necessidade de se estabelecer um
modelo de desenvolvimento de software aplicvel s pequenas empresas com caractersticas
semelhantes, de modo a melhorar seu processo e conseqentemente manter-se
competitivamente no mercado.










































91
4. PROPOSTA DE UM MODELO DE REFERNCIA

Pelas razes j apresentadas, a disponibilizao de um modelo de referncia para o
desenvolvimento de softwares aplicvel a pequenas empresas, no caso brasileiro representar
uma significativa contribuio do entendimento e domnio do tema. Neste sentido,
apresentam-se a seguir alguns conceitos.


4.1 Modelos de referncia

Modelos de referncia podem ser entendidos como uma representao dos processos
de negcio, descrevendo suas atividades, informaes, recursos e organizao. Tem como
intuito ser uma referncia no sentido de auxiliar empresas e profissionais a planejar, controlar
e gerenciar o desenvolvimento de produto.
Barbalho e Rozenfeld (2004) apresentam uma definio bastante completa acerca do
que caracteriza um modelo:
Um modelo uma representao externa e explcita de parte da realidade
vista pela pessoa que desejar us-lo para apoiar a execuo de tarefas
relacionadas com aquela parte da realidade, sejam operacionais ou
gerenciais, sendo expresso em termos de algum formalismo (linguagem)
definido por construtos de modelagem.

Segundo Vernadat (1996) modelos de referncia so modelos parciais que podem ser
usados como base para o desenvolvimento ou a avaliao de modelos particulares. Modelos
so chamados de parciais quando eles no so totalmente instanciados, ou seja, no atendem
92
ao processo existente em uma realidade em particular. So genricos, normalmente
direcionados a um determinado setor da economia. Eles so, portanto, templates que podem
ser adaptados a condies especficas de uma empresa.
Um modelo de referncia deve permitir uma viso de como o processo ser realizado,
explicitando as atividades e responsabilidades de cada participante. O objetivo do modelo de
referncia prover a empresa com uma soluo inicial para seus processos de negcios, para
que, atravs dessa, seja especificado e detalhado o modelo particular da empresa.
Curtis et al. (1992) descrevem quatro aspectos bsicos necessrios e pertinentes aos
modelos:
o Aspectos de informao: descreve os dados que sero utilizados e produzidos e as
relaes entre eles;
o Aspectos lgicos e seqenciais: descreve o comportamento, referindo-se ao como e ao
quando;
o Aspectos organizacionais: os aspectos organizacionais descrevem quem sero os
responsveis;
o Aspectos funcionais: descreve o que deve ser feito.
De acordo com essas vises entende-se que um modelo de referncia pode servir para
desenvolvimento de produto nas mais variadas reas, como alimentcia, de manufatura, de
software, entre tantas outras. Segundo Vernadat (1996), as vantagens em se adotar modelos de
referncia consistem em:
reduo de tempo e custo no desenvolvimento do modelo particular;
comparao das atividades da empresa com as atividades propostas no modelo
(exemplo: melhores prticas);
melhor suporte na implantao de sistemas de gesto empresarial integrado (ERP).
93
4.2 O modelo de desenvolvimento de produto
Esta pesquisa teve emprego do modelo de referncia de desenvolvimento de produto
criado pelo esforo conjunto de grupos de pesquisa de trs universidades brasileiras:
o Grupo de Engenharia Integrada do Ncleo de Manufatura Integrada (NUMA) do
Departamento de Engenharia de Produo da Escola de Engenharia de So Carlos,
Universidade de So Paulo;
o Grupo de Estudos e Pesquisa em Qualidade (Gepeq), do Departamento de Engenharia
de Produo da Universidade Federal de So Carlos (UFSCar).
o Departamento de Engenharia Mecnica da Universidade Federal de Santa Catarina, o
Grupo de Engenharia do Produto e Processo (Gepp).

Essa ao, iniciada em 2001, teve como resultado um modelo de referncia que
contm os conceitos e as melhores prticas em desenvolvimento de produtos (DP) com a
misso de se tornar referncia para a derivao de outros modelos, adequados a um setor ou
tipo especfico de produto.
Neste sentido, este modelo j serviu de base para outros trabalhos. Romano (2003)
definiu um modelo de referncia voltado ao processo de desenvolvimento de mquinas
agrcolas. As atividades propostas limitam-se ao processo interno, executadas pelas equipes de
vrios departamentos internos. O modelo inclui trs macro-fases: planejamento, projeo e
implementao. A primeira consiste das fases de planejamento do projeto, a macro-fase de
projeo constituda das fases de elaborao dos projetos: informacional, conceitual,
preliminar e detalhado do produto e, por fim, processo de manufatura. E, finalmente, a macro-
fase de implementao formada pela fase de produo, lanamento do produto no mercado,
validao do produto e encerramento do projeto..
94
Barbalho (2006), adaptou este modelo para o desenvolvimento de produtos mecatrnicos
com aplicao em um caso real. Penso (2003), desenvolveu um trabalho em cima do modelo
de referncia aplicado a indstria de alimentos.
A figura 16 ilustra uma viso macro do modelo de referncia de forma grfica.

Figura 16. Modelo de referncia. ROZENFELD et al, (2006).

Pode-se visualizar a existncia de fases e sub-fases bem definidas, na qual papis e
fluxo de atividades so declarados. Alm disso a passagem das fases caracterizada por
pontos de controle, chamados de Gates. Faz-se a seguir uma anlise resumida das 3 Macro-
Fases do modelo.

4.2.1 Macro-Fases

o Pr Desenvolvimento: esta macro-fase responsvel por alinhar o desenvolvimento
de software com o planejamento estratgico da empresa, evitando que projetos fora de
contexto sejam levados adiante. Desta forma, o pr-desenvolvimento deve garantir que
o direcionamento estratgico, definido pela empresa no seu planejamento estratgico,
as idias de todos os autores internos e externos envolvidos com os produtos e as
oportunidades e restries sejam sistematicamente mapeados e transformados em um
conjunto de projetos bem definidos, isto , o portflio dos projetos que devero ser
95
desenvolvidos. Compreendem esta macro-fase as fases de Planejamento Estratgico e
Planejamento do Projeto.

o Desenvolvimento: aps a definio do portflio de produtos e o planejamento dos
projetos, inicia-se o desenvolvimento propriamente dito. No modelo, esta fase
integrada s macro-fases de pr e ps-desenvolvimento. Esta tem incio a partir das
informaes geradas pelo pr-desenvolvimento e documentadas no plano de projeto.
Divide-se esta fase em quatro outras que se iniciam com o levantamento de requisitos
dos interessados e termina com o lanamento do produto no mercado. Utilizam-se
tcnicas, mtodos e ferramentas para o cumprimento das atividades, como por
exemplo, tcnicas para estimativas, ferramentas de modelagem, modelos para analise
de riscos, entre outros. Apesar de aparecerem seqencialmente, as atividades desta
fase no seguem uma linearidade. Tm-se sobreposio de atividades, paralelismo e
chegando a ocorrer em algumas vezes atividades cclicas. As fases que compem esta
macro-fase so: Projeto Informacional, Projeto Conceitual, Projeto Detalhado e
Lanamento do Produto. Esta possibilidade oferecida de se avanar e retroceder, de ir
e vir, representa uma efetiva oportunidade de se enriquecer o projeto, pela sua
otimizao.

o Ps-Desenvolvimento: aps o desenvolvimento do produto, diferentemente do que
acreditam alguns, o projeto ainda no est finalizado. O acompanhamento desse
produto, deve ser feito, medindo seu desempenho. Esta macro-fase compreende ainda
a retirada do produto do mercado e, finalmente, uma avaliao de todo o ciclo do
produto, para que as experincias contrapostas ao que foi planejado anteriormente
sirvam de referncia a desenvolvimentos futuros, permitindo o feedback. Neste
96
estgio, as fases so: Analisar Satisfao do Cliente, Monitorar Desempenho do
Produto, Realizar Auditoria Ps-Projeto e Descontinuar Produto do Mercado. Cabe
lembrar que a retirada do produto no deve ser motivo de insatisfao para o cliente,
que ser atendido por solues mais avanadas.

4.3 Detalhamento do nvel G do MPS.Br

4.3.1 Gerncia de Projetos

O processo de gerncia de projetos a primeira camada do processo de engenharia de
software que abrange todo o processo de desenvolvimento, do comeo ao fim. A gerncia de
projetos oferece uma compreenso do escopo do trabalho a ser feito, dos riscos, dos recursos
exigidos, das tarefas a serem executadas, dos marcos de referncia a serem acompanhados, do
custo e da programao a ser seguida. PRESSMAN, (2005).
O MPS.Br destaca o processo de gerncia de projetos com o objetivo de estabelecer e
manter planos que definam as atividades, recursos e responsabilidades do projeto, bem como
prover informaes sobre o seu andamento que permitam a realizao de correes quando
houver desvios significativos no seu desempenho. MPS (2007).

4.3.1.1 Resultados Esperados

Os resultados esperados pela correta implantao do processo de gerncia de projetos,
representados pela sigla GPRn, atribudo ao nvel G do MPS.Br so apresentados a seguir:
MPS (2007).
97
GPR1 - O escopo do trabalho para o projeto definido, apresentando todo o
trabalho necessrio para entregar um produto e/ou servio que satisfaa as
necessidades, caractersticas e funes especficas para o projeto, de forma a
conclu-lo com sucesso;
GPR2 - As tarefas e os produtos de trabalho do projeto so dimensionados
utilizando mtodos apropriados. Todo o trabalho deve ser decomposto em
componentes menores, a fim de facilitar seu gerenciamento. A estrutura de
decomposio fornece uma referncia para atribuio de tamanho, esforo,
cronograma e responsabilidades, e utilizada como uma estrutura subjacente para
planejar, organizar e controlar o trabalho executado no projeto;
GPR3 - O modelo e as fases do ciclo de vida do projeto so definidos, permitindo
planejar o projeto, incluindo marcos importantes para o controle e revises. No
ciclo de vida so definidas as fases e as atividades do projeto, de acordo com o
escopo dos requisitos, as estimativas para os recursos e sua natureza. A
determinao das fases do ciclo de vida do projeto possibilita perodos planejados
de avaliao e de tomada de decises, nos quais compromissos significativos so
realizados com relao aos recursos, abordagem tcnica, reavaliao de escopo e
custo do projeto;
GPR4 - O esforo e o custo para a execuo das tarefas e dos produtos de trabalho
so estimados com base em dados histricos ou referncias tcnicas, incluindo os
dados de custo, esforo e tempo de projetos executados anteriormente, alm de
dados apropriados de escala para equilibrar as diferenas de tamanho e
complexidade;
GPR5 - O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de
controle, so estabelecidos e mantidos. So identificadas as tarefas do projeto e
98
potenciais gargalos, que so resolvidos quando possvel, e o cronograma das
atividades estabelecido, com incio, durao e trmino. Com base no cronograma
e na estimativa de custos, refletida pelos recursos requeridos, estabelecido o
oramento do projeto. Este resultado importante porque o cronograma e o
oramento so instrumentos fundamentais para o acompanhamento do dia-a-dia do
projeto. Desta forma, sempre que necessrio, devem ser revistos e atualizados;
GPR6 - Os riscos do projeto so identificados e o seu impacto, probabilidade de
ocorrncia e prioridade de tratamento so determinados e documentados. Para
facilitar a identificao dos riscos, interessante elaborar-se uma lista de riscos
mais comuns, que deve ser examinada pelo gerente do projeto e/ou equipe do
projeto para identificar quais destes so potenciais riscos para o projeto em
questo. Os riscos identificados devem ser registrados, bem como o
acompanhamento dos seus estados e aes tomadas. No nvel G, os riscos so
acompanhados para verificar como afetam o projeto e para se tomar as medidas,
aplicveis mesmo que ainda sem um gerenciamento completo;
GPR7 - Os recursos humanos para o projeto so planejados considerando-se o
perfil e o conhecimento necessrio para execut-lo, determinando-se as funes,
responsabilidades e relaes hierrquicas do projeto. As funes do projeto podem
ser designadas para pessoas ou grupos, os quais podem ser internos ou externos
organizao;
GPR8 - As tarefas, os recursos e o ambiente de trabalho necessrios para executar
o projeto so planejados, devendo ser especificadas as tarefas e previstos os
recursos e o ambiente necessrio, incluindo, por exemplo, equipamentos,
ferramentas, servios, componentes, viagens e requisitos de processo. Este
planejamento importante, pois recursos especiais precisam de suporte
99
oramentrio, o que pode se tornar crtico em alguns projetos, se no forem
previstos;
GPR9 - Os dados relevantes do projeto so identificados e planejados quanto
forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para
acess-los, incluindo, se pertinente, questes de privacidade e segurana. O motivo
de se coletar cada dado tambm deve ser evidenciado, pois colet-lo, armazen-lo,
distribu-lo de forma controlada e mant-lo atualizado, implica em custo. A
questo da confidencialidade, mesmo quando no declarada pelo cliente, deve ser
tratada com extremo cuidado;
GPR10 - Planos para a execuo do projeto so estabelecidos e reunidos no Plano
do Projeto. Todas as informaes definidas e coletadas para o projeto devem ser
organizadas de forma a possibilitar um gerenciamento adequado do projeto. A
reunio desses documentos conhecida como sendo o Plano do Projeto;
GPR11 - A viabilidade de atingir as metas do projeto, considerando-se as
restries e os recursos disponveis, avaliada. Se necessrio, ajustes so
realizados. O estudo da viabilidade considera o escopo do projeto e examina
aspectos tcnicos, financeiros e humanos. Deve-se considerar tambm os objetivos
de negcio da organizao. Muitas vezes prefervel no iniciar ou parar um
projeto do que prosseguir com um projeto invivel, o que pode levar a perdas
maiores, tanto para o fornecedor como para o cliente;
GPR12 - O Plano do Projeto revisado com todos os interessados e o
compromisso com ele obtido. Negociaes devem ser realizadas quando existem
conflitos entre as diversas variveis do projeto, como requisitos, custos e prazos. A
soluo dos conflitos e estabelecimento de compromissos fundamental para que
100
o projeto possa efetivamente contar com recursos planejados, para atingir as metas
definidas;
GPR13 - O progresso do projeto monitorado com relao ao estabelecido no
Plano do Projeto e os resultados so documentados. O acompanhamento pode ser
realizado utilizando-se ferramentas de planejamento, em que se pode examinar o
previsto contra o realizado, usando-se indicadores de progresso e cumprimento de
marcos, entre outros. Pode tambm ser feito por meio de reunies e comunicao
pessoal;
GPR14 - O envolvimento das partes interessadas no projeto gerenciado, podendo
incluir o cliente e o usurio, a direo da organizao e os membros da equipe do
projeto. Este resultado importante porque o distanciamento da gerncia do
projeto em relao aos interessados pode acarretar desvios em relao s reais
necessidades que o projeto dever atender;
GPR15 - Revises so realizadas em marcos do projeto e conforme estabelecido no
planejamento. Os marcos do projeto precisam ser previamente definidos ao se
realizar o planejamento do projeto. As revises em marcos podem ter um carter
formal, com participao de gerncias superiores, representantes do cliente e outras
partes interessadas no projeto. Este resultado importante, porque as revises em
marcos so oportunidades para verificar, de forma ampla, o andamento de todo o
projeto, independente do acompanhamento do dia-a-dia;
GPR16 - Registros de problemas identificados e o resultado da anlise de questes
pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as
partes interessadas. Todos os problemas encontrados com os resultados anteriores
devem ser registrados e gerenciados at a sua correo;
101
GPR17 - Aes para corrigir desvios em relao ao planejamento e para prevenir a
repetio dos problemas identificados so estabelecidas, implementadas e
acompanhadas at a sua concluso. Como resultado dos acompanhamentos citados
anteriormente, problemas so identificados, analisados e registrados. Aes
corretivas devem ser estabelecidas para resolver problemas que possam impedir o
projeto de atingir seus objetivos. O controle dos problemas levantados, as aes
tomadas, os responsveis pelas aes e os resultados devem ser registrados.

4.3.2 Gerncia de Requisitos
Os problemas que os projetistas de software tm para solucionar so, muitas vezes,
muito complexos. Compreender a natureza desses problemas pode ser muito difcil,
especialmente se o sistema novo. Conseqentemente, difcil estabelecer o que o sistema
deve fazer. As descries das funes e das restries so os requisitos do sistema, e o
processo de descobrir, analisar e documentar essas funes e restries chamado de
engenharia de requisitos. SOMMERVILLE (2003).
O propsito desse processo no Nvel G do MPS.Br gerenciar os requisitos dos
produtos e componentes do produto do projeto e identifica. MPS (2007).
Algumas das atribuies do processo de requisitos so: reviso dos requisitos
recebidos de um fornecedor de requisitos e prevenir seu mal entendimento; documentar as
mudanas nos requisitos e suas justificativas; manter a rastreabilidade bidirecional entre os
requisitos e produtos de trabalho em geral; identificar inconsistncias entre os requisitos, os
planos do projeto e os produtos de trabalho do projeto; entre outras. MPS (2007).


102
4.3.2.1 Resultados Esperados

Segundo MPS (2007), os resultados esperados pela correta implantao do processo de
gerncia de requisitos, representados pela sigla GREn, atribudo ao nvel G do MPS.Br so:
GRE1 - O entendimento dos requisitos obtido junto aos fornecedores de
requisitos, com a finalidade de garantir que os requisitos estejam claramente
definidos. Para que isso ocorra, deve-se rever com o fornecedor de requisitos se as
necessidades e expectativas esto sendo atendidas com os requisitos propostos e,
com essa confirmao, criar um documento de requisitos. Todas as comunicaes
com o fornecedor de requisitos devem ser registradas em atas, e-mails, ferramentas
de comunicao ou outros meios, sendo necessrio uma comprovao de que os
interessados esto de acordo com o contedo registrado;
GRE2 - Os requisitos de software so aprovados utilizando-se critrios objetivos,
envolvendo a equipe tcnica da organizao e o cliente. Esses critrios devem ser
estabelecidos previamente, tais como: possuir identificao nica; estar claro e
apropriadamente declarado; ser relevante; ser completo; estar consistente com os
demais requisitos; ser implementvel, testvel e rastrevel. Deve ter muita cautela
ao aprovar novos requisitos, pois uma mudana nos requisitos de um projeto pode
impactar significativamente em termos de escopo e estimativas de cronograma e
esforo;
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho
estabelecida e mantida, permitindo rastrear a dependncia existente entre eles.
Com isso, facilita-se a avaliao do impacto das mudanas de requisitos que
possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho
ou nas tarefas do projeto;
103
GRE4 - Revises em planos e produtos de trabalho do projeto so realizadas
visando identificar e corrigir inconsistncias em relao aos requisitos. Ao
identificar alguma inconsistncia entre os requisitos e os demais elementos do
projeto, estas devem ser registradas e cabendo executar aes corretivas a fim de
resolv-las. Se houver mudanas nos requisitos, deve-se executar essa reviso para
identificar se todos os artefatos do projeto esto consistentes;
GRE5 - Mudanas nos requisitos so gerenciadas ao longo do projeto atravs de
documentao das mudanas e de manuteno do histrico das decises tomadas
acerca dessas mudanas. Estas decises so tomadas por meio da realizao de
anlises de impacto da mudana no projeto e podem incluir aspectos como:
influncia em outros requisitos, expectativa dos interessados, cronograma, riscos e
custo.

4.4 Pontos comuns entre MPS.br e o modelo de referncia
Uma das caractersticas marcantes existentes nos modelos de qualidade aplicados ao
PDS, como o CMMi e o MPS.Br, se diz ao fato de no existir uma explcita indicao de
como atingir os objetivos, limitando-se apenas a apresentar o que deve ser cumprido, cabendo
aos responsveis pela melhoria do processo criar ou adaptar meios para que os nveis de
maturidade possam ser efetivamente atingidos.
No caso do MPS.Br, em todos os nveis de maturidade, encontram-se processos que
so identificados no modelo de referncia para desenvolvimento de produto. No Nvel G,
encontram-se os processos de gerncia de requisitos e gerncia de projetos claramente
definidos nas etapas de pr-desenvolvimento e incio da etapa de desenvolvimento.
104
Por outro lado, existem processos como planejar processo de fabricao e montagem
ou a fase de preparao da produo do produto que no so aplicveis ao PDS devendo ser
ento eliminados do modelo proposto.
Para uma melhor compreenso dos pontos comuns, faz-se nesta seo, uma anlise da
aderncia sobre o processo de desenvolvimento de produto com o MPS.Br, onde, por meio de
uma tabela comparativa, demonstra-se o que cada atividade implementada no decorrer das
fases do modelo de referncia ficaria representado no resultado esperado do MPS.Br
especificamente no processo de gerncia de projeto e gerncia de requisitos.
As tabelas 4 e 5 esto estruturadas da seguinte maneira: a primeira coluna representa
as fases do processo de planejamento de projeto proposto no modelo de referncia, a segunda
coluna representa cada atividade desenvolvida na fase relacionada, e a terceira coluna
representa os resultados esperados no MPS.Br aderentes a cada atividade correlata no modelo
de referncia. A tabela 4 refere-se Gerncia de Projetos enquanto que a tabela 5, refere-se
Gerncia de Requisitos.
Tabela 4 - Resultado da aderncia das atividades do modelo de referncia ao MPS.Br Gerncia de
Projeto.
Fase Atividade Resultado Esperado
Definir interessados do
projeto
GPR 7. Os recursos humanos para o projeto so
planejados considerando o perfil e o conhecimento
necessrios para execut-lo;

GPR 14. O envolvimento dos interessados no projeto
gerenciado;
Definir escopo do
produto
GPR 2. As tarefas e os produtos de trabalho e as tarefas
do projeto so dimensionados utilizando mtodos
apropriados;

Definir escopo do
projeto
GPR 1. O escopo do trabalho para o projeto definido;
Planejamento
de Projeto
Detalhar escopo do
projeto
GPR 8. As tarefas, os recursos e o ambiente de trabalho
necessrios para executar o projeto so planejados.

GPR 2. As tarefas e os produtos de trabalho e as tarefas
do projeto so dimensionados utilizando mtodos
apropriados;
105
Definir atividades e
seqncia
GPR 2. As tarefas e os produtos de trabalho e as tarefas
do projeto so dimensionados utilizando mtodos
apropriados;

GPR 3. O modelo e as fases do ciclo de vida do projeto
so definidas;

Preparar cronograma GPR4. O esforo e o custo para a execuo das tarefas
e dos produtos de trabalho so estimados com base em
dados histricos ou referncias tcnicas.

GPR 5. O cronograma e o oramento do projeto,
incluindo marcos e/ou pontos de controle, so
estabelecidos e mantidos;
Detalhar ciclo de vida
do produto
GPR 3. O modelo e as fases do ciclo de vida do projeto
so definidas;
Avaliar riscos GPR 6. Os riscos do projeto so identificados e o seu
impacto, probabilidade de ocorrncia e prioridades de
tratamento so determinados e documentados;
Preparar oramento do
projeto
GPR 5. O cronograma e o oramento do projeto,
incluindo marcos e/ou pontos de controle, so
estabelecidos e mantidos;
Analisar a viabilidade
econmica do projeto
GPR 11. A viabilidade de atingir as metas do projeto,
considerando as restries e os recursos disponveis,
avaliada. Se necessrio ajustes so realizados;
Definir indicadores de
desempenho
GPR 15. Revises so realizadas em marcos do projeto
e conforme estabelecidos no planejamento.

GPR 16. Registros de problemas identificados e o
resultado da anlise de questes pertinentes, incluindo
dependncias crticas, so estabelecidas e tratados com
as partes interessadas.
Definir plano de
comunicao
GPR 9. Os dados relevantes do projeto so identificados
e planejados quanto a forma de coleta, armazenamento
e distribudos. Um mecanismo estabelecido para
acess-los, incluindo, se pertinente, questes de
privacidade e segurana;
Planejar e preparar
aquisies
GPR 8. As tarefas, os recursos e o ambiente de trabalho
necessrios para completar o trabalho so planejados
Preparar Plano de
Projeto
GPR 10. Planos para execuo do projeto so
estabelecidos e reunidos no Plano de Projeto.
Discusso e redao do
Plano de Projeto
GPR 12. O plano do projeto revisado com todos os
interessados e seu respectivo compromisso com ele
obtido.

Avaliar e aprovar Fase GPR 16. Registros de problemas identificados e o
resultado da anlise de questes pertinentes, incluindo
dependncias crticas, so estabelecidas e tratados com
as partes interessadas.

GPR 17. Aes para corrigir desvios em relao ao
planejado e para prevenir a repetio dos problemas
identificados so estabelecidas, implementadas e
acompanhadas at sua concluso.

106
Tabela 5 - Resultado da aderncia das atividades do modelo de referncia ao modelo MPS.Br Gerncia
de Requisitos
Fase Atividade Resultado Esperado
Definir requisitos do
produto

GR1 O entendimento dos requisitos obtido junto aos
fornecedores de requisitos.
Definir especificaes
meta do produto

GR2 Os requisitos de software so aprovados
utilizando critrios objetivos.
Gerenciar Mudanas de
Engenharia

GR5 Mudanas nos requisitos so gerenciadas ao
longo do projeto.
Propor mudana


GR1 O entendimento dos requisitos obtido junto aos
fornecedores de requisitos.
Alterar informaes do
produto


GR3 A rastreabilidade bidirecional entre os requisitos e
os produtos de trabalho estabelecida e mantida.

Projeto
Informacional
Acompanhar Produto e
Processo


GR4 Revises em planos e produtos de trabalho do
projeto so realizadas visando identificar e corrigir
inconsistncias em relao aos requisitos.

Essa relao, para os dois processos iniciais do MPS.Br, ser adotada por ser
imprescindvel, como base para a proposta de um modelo de referncia voltado ao
desenvolvimento de software, conforme ser justificado a seguir.


4.5 Proposta do Modelo

Com base no modelo de referncia para desenvolvimento de produtos e seus pontos de
conformidade com a norma MPS.Br se prope um modelo de referncia, chamado de BASE,
que serve de guia para as empresas de desenvolvimento de software criarem seus produtos de
forma a garantir qualidade dos produtos finais.
Nesta proposta tem-se a definio do modelo representado e estruturado com base em
quatro elementos bsicos, que representam quem faz, o qu, como e quando:
107
Papis e Responsabilidades (quem) - Um papel define o comportamento e
responsabilidades de um profissional ou grupo de profissionais que participam do
desenvolvimento do projeto. O comportamento representado atravs das atividades
que cada papel deve desempenhar ao longo do projeto. As responsabilidades
normalmente esto associadas aos artefatos que cada papel deve produzir e manter ao
longo das atividades que realiza. Na prtica, um mesmo papel pode ser desempenhado
por mais de uma pessoa, assim como uma mesma pessoa pode assumir vrios papis
ao longo do projeto.
Artefatos (o qu) - Em sentido amplo, o termo artefato representa um produto
concreto produzido, modificado ou utilizado pelas atividades de um processo.
Os artefatos representados no PDS no incluem todos os artefatos de um projeto de
desenvolvimento, mas todos estes devem ser elaborados ao longo do projeto.
O PDS disponibiliza modelos (templates) para a maioria de seus artefatos, com o
objetivo de orientar e facilitar a sua elaborao.
Atividades (como) - Uma atividade no PDS representa um conjunto de passos e
tarefas que um profissional, que desempenha o papel responsvel por aquela atividade,
deve executar para gerar algum resultado. As atividades envolvem a produo e
modificao de artefatos do projeto.
Fluxo de Atividades (quando) - O fluxo de atividades do PDS apresenta a seqncia
e a dependncia entre as atividades do projeto ao longo do tempo.
As atividades no fluxo so divididas em fases do ciclo de vida do projeto e nos papis
responsveis pela execuo de cada uma.
A figura 17 apresenta uma viso geral do modelo de referncia proposto.
108

Figura 17. Viso geral do modelo de referncia para desenvolvimento de software.

O processo se inicia com uma solicitao por parte do cliente, podendo ser um cliente
interno ou externo. Automaticamente este pedido tratado na fase de planejamento
estratgico, onde se analisa o projeto confrontando com as metas da empresa, evitando que
projetos fora do contexto estratgico de atuao da empresa sejam levados adiante. Esta fase
tem como marco o escopo preliminar. Na fase de planejamento, tem-se como intuito o
detalhamento do escopo com o planejamento de recursos necessrios e como marco final o
Plano de Projeto aprovado. J na etapa de construo se encontram as fases de Elaborao
para elicitao de requisitos junto ao cliente, de construo e testes do produto, alm das fases
de homologao e implantao. Cabe destacar que apesar de parecer seqencial e linear, as
fases de Elaborao, Construo e Testes apresentam iteraes cclicas. Na fase de Ps-
Desenvolvimento esto inclusos os processos de suporte ao produto e a descontinuidade do
109
mesmo. Paralelamente a todos essas fases, faz-se um controle de qualidade para acompanhar o
processo e o produto, tomando aes efetivas quando desvios so detectados.
Cada rea dentro do modelo decomposto em processos que contm sub-processos
com atividades, funes e artefatos associados a seu propsito. Em cada processo existem
marcos, tambm chamados de Gates que definem pontos de verificao e validao.
Abaixo segue uma descrio mais detalhada de cada rea com seus propsitos.

Planejamento Estratgico. Representa a primeira etapa no processo de desenvolvimento do
produto e tem o objetivo de se obter ao final um plano que contenha o portflio de produtos
da empresa a partir de seu planejamento estratgico. A importncia desta etapa se d pela
filtragem que existir na seleo de produtos que devero ser iniciados e aqueles que devero
ser abandonados sempre seguindo a estratgia quanto dinmica da tecnologia e dinmica
do mercado, pblico alvo, lucratividade, entre outros. Trata-se de uma etapa de gerenciamento
macro e de posicionamento da empresa, com relao a sua vocao na produo de projetos
para determinadas demandas do mercado.

Planejamento. Esta fase se desenvolve aps a filtragem, j na relao direta com o cliente. O
objetivo do planejamento o estabelecimento de um acordo formal, entre a equipe de
desenvolvimento e usurios do projeto, quanto ao escopo do produto a ser desenvolvido. A
viabilizao do projeto pela empresa, sob orientao do planejamento estratgico, marca o
incio do projeto. A partir do escopo preliminar, a equipe do projeto d incio ao detalhamento
do escopo do produto. O escopo detalhado deve ser registrado no Documento de Escopo e
posteriormente no Plano de Projeto e aprovado formalmente pelos usurios. O Plano de
Projeto resultante desta fase, contm ainda um cronograma do projeto, os recursos a serem
110
utilizados, o plano de comunicaes, a anlise de riscos, entre outros pontos importantes, que
sero acordados pelo fornecedor e pelo cliente.

Elaborao. Esta fase envolve uma anlise detalhada sobre as necessidades e problemas
gerais do projeto e a definio de como o sistema ser desenvolvido em termos tecnolgicos,
considerando os requisitos, limitaes e restries identificados durante a fase de
Planejamento.
O objetivo da fase de Elaborao o estabelecimento e validao de uma arquitetura
de hardware e software que suporte de forma adequada os requisitos funcionais e no-
funcionais do sistema.
Durante esta fase os analistas de sistema da equipe do projeto devem identificar os
requisitos detalhados do produto a partir de reunies e entrevistas de levantamento junto aos
usurios. Estes requisitos devero ser descritos detalhadamente no Documento de Requisitos
do projeto e atravs de um Diagrama de Casos de Uso, representando a viso funcional e as
fronteiras do sistema. Esta fase importante porque focaliza os limites de aplicao do
software e elimina um grande nmero de outras alternativas.
Os casos de uso identificados devero ser descritos detalhadamente no Modelo de
Casos de Uso que, alm do diagrama de casos de uso elaborado durante o levantamento de
requisitos, inclui tambm as Especificaes de Casos de Uso. Em paralelo, a equipe de
analistas de sistema define a arquitetura de hardware e software do sistema, que dever ser
documentada no Documento de Arquitetura. Este documento formalmente aprovado pelas
partes envolvidas.

Construo. Esta fase compreende o desenvolvimento propriamente dito do sistema, em
termos de cdigos-fonte e componentes de software.
111
O objetivo desta fase o desenvolvimento de uma verso operacional do sistema,
estvel o suficiente para ser disponibilizada para testes e posterior homologao por seus
usurios finais, no menor tempo possvel, considerando os critrios de qualidade estabelecidos
pelo projeto.
Os analistas de sistema da equipe estaro envolvidos no projeto detalhado do sistema -
Diagramas de Classes e outros diagramas considerados relevantes para a representao do
projeto do sistema, enquanto os projetistas de banco de dados estaro envolvidos na
modelagem da verso completa do banco de dados. Com base nestas informaes, no Modelo
de Casos de Uso, o Documento de Requisitos e no Documento de Arquitetura, os
programadores estaro focados na implementao do sistema e de seus componentes, atravs
de atividades de codificao, realizao de testes unitrios e na integrao e compilao de
verses intermedirias.
Em paralelo ao desenvolvimento do sistema, os manuais de usurio, guias rpidos,
manuais de instalao e administrao, release notes, entre outros documentos, sero
desenvolvidos, e formalmente registrados.
A fase de Construo dever ser dividida em iteraes de acordo com a necessidade
identificada pelo gerente do sistema.
A cada iterao ser gerada e testada uma nova compilao do sistema, contendo os
cenrios de casos de uso implementados at o momento.

Teste. Esta fase envolve as atividades necessrias para que o sistema desenvolvido seja
adequadamente disponibilizado a seus usurios com a menor presena de erros possveis. O
objetivo principal desse processo portanto encontrar falhas no sistema durante todo o
processo de desenvolvimento, uma vez que os testes so divididos em testes unitrios e teste
de sistema. Os teste unitrios ocorrem cotidianamente e so planejados de forma previa ao
112
desenvolvimento de um cdigo, sua execuo se d logo aps ao trmino da compilao de
uma parte do cdigo. Falhas so documentadas e prontamente corrigidas. Ao trmino da
implementao de todo o sistema so realizados os testes do sistema com todas as
funcionalidades integradas.

Homologao. A fase de homologao representa a fase de aceitao do usurio, que quando
bem direcionada e com o desenvolvimento do sistema bem instrumentado sempre ser
encerrada com o documento de avaliao formal sinalizando sucesso. Esta etapa na maioria
dos sistemas pode ter uma curta durao, ou at mesmo ser unificada etapa de teste, porm,
processos de homologao mais extensos so suportados.
Estando o sistema homologado junto a seus usurios, ele estar disponvel para
implantao em ambiente de produo.
Apesar desta fase estar baseada principalmente em atividades externas ao PDS,
considera-se importante relacion-las no ciclo de vida do projeto, uma vez que so
consideradas etapas do processo de desenvolvimento como um todo. Entende-se que a
passagem do produto para o ambiente de produo (deployment) deve ser preocupao
constante da equipe de desenvolvimento, e todas as atividades relacionadas devem ser
planejadas desde o incio do projeto. Todo o PDS tem como objetivo final a disponibilizao
para os usurios de um produto desenvolvido em conformidade com suas especificaes,
dentro dos critrios de qualidade previstos para o projeto, e que possa ser prontamente
utilizado por seus usurios.

Implantao. Esta etapa representa a entrega e instalao do sistema para uso. Tambm
chamada em outros modelos de Deployment ou Produo. Compreende esta etapa uma
estratgia para implantao do sistema que caracterizado pelo desenvolvimento de um
diagrama UML chamado de diagrama de implantao (deployment). Trata-se de um diagrama
113
usado para se obter uma viso esttica da implantao, assim se pode definir onde e como
determinados componentes ou sistemas e subsistemas sero instalados/empacotados. Refere-
se tambm a disponibilizao do produto e ao acesso, com a praticidade adequada de uma
aplicao eficiente e eficaz.

Manuteno/Suporte. Aps a instalao, inicia-se a etapa de acompanhamento do sistema
que representa uma importante fase, pois, garante o funcionamento do sistema e eventuais
reparos e suporte. Esta fase caracterizada pelas atividades de suporte e de manuteno. Toda
solicitao de suporte formalmente requisitada, seja por email ou por documento prprio,
mesmo as solicitadas por telefone so imediatamente documentadas.

Descontinuidade do Produto. Esta fase representada pelo fim do suporte ao produto, na
qual a empresa e o cliente/usurio formalmente estabelecem a descontinuidade manuteno
do sistema. Dada a velocidade da inovao que afeta a dinmica da tecnologia e a dinmica do
mercado, conforme Drucker (1968), h que se prever a obsolescncia tcnica ou esgotamento
das demandas especficas ou, a possibilidade de revigorar do produto, com a considerao de
sua otimizao, o que demandar novo contrato.

Controle do Projeto. Esta fase est relacionada ao acompanhamento do projeto durante todo
o ciclo de vida, desde as fases preliminares, com o intuito de monitorar, controlar e registrar o
andamento do projeto como um todo, identificando mudanas e possibilitando ajustes. Nesta
fase se encontram os processos de gerncia de projetos, gerncia de requisitos e gerncia da
qualidade, explicados abaixo com mais detalhes:
Gerncia de Requisitos. A gerncia de requisitos tem como intuito garantir que
mudanas solicitadas e efetuadas durante o desenvolvimento sejam controladas, de forma a
114
criar um mecanismo que possa atualizar as documentaes do produto, negociar as mudanas,
analisar o impacto dessas mudanas e reformular o cronograma.
Controle de Projetos. Esta fase dedicada a todo controle do projeto, previamente
planejado. Leva-se em considerao os conceitos do PMI (Project Manager Institute) e da
metodologia gil Scrum.
Gerenciamento da Qualidade. Esta fase realizada durante todo o PDS, sendo de
extrema importncia para a garantia da qualidade nos padres estabelecidos pela empresa.
Visa o gerenciamento da qualidade no processo e conseqentemente do produto de software.
Esse gerenciamento est alinhado com as diretrizes estabelecidas pelo MPS.Br e deve estar
descrita nos planos da empresa.
Esta etapa est sob responsabilidade da equipe de qualidade (GQA) que acompanha
cotidianamente o processo, seus artefatos e o produto final, registrando ocorrncias e
designando os relatrios aos responsveis para que medidas possam ser tomadas na soluo
de desvios.

Com foco em aprofundar esse modelo, foram selecionadas os processos inicias de
Gerncia de Requisitos e Gerncia de Projetos. A justificativa para escolha desses dois
processos se deve ao fato de serem os pontos iniciais para um programa de melhoria tanto no
CMMi como principalmente no MPS.Br.

4.5.1 Processo Padro de Gerncia de Requisitos
A gerncia de requisitos compreende uma etapa fundamental do desenvolvimento,
pois garante que as mudanas solicitadas aps a finalizao do projeto ou durante o
andamento do projeto sero consideradas e tero um tratamento adequado. Pode-se definir a
115
gerncia de requisitos como um processo sistemtico para elicitar, documentar, organizar e
rastrear os requisitos variveis de um sistema.
Tem que se levar em considerao que qualquer mudana deve ser implementada de
forma adequada, caso seja aprovada, sem afetar a qualidade final do produto,
independentemente de quem solicita e quanto tempo ter para realizar a mudana.
Entre os principais fatores que ocasionam a no gerncia efetiva de requisitos por parte
de pequenas empresas, pode-se destacar o fato dessas empresas no terem um processo padro
para usar como base. Isso ocasiona problemas como descontrole do cronograma, escopo do
projeto maior do que o previamente estipulado e cobrado financeiramente, percepo do
cliente de que toda solicitao dever ser alterada a qualquer tempo, da forma que ele deseja,
entre outros.
No intuito de se gerar um processo padro para a gerncia de requisitos, faz-se a
seguir um detalhamento das atividades, do fluxo de atividades, dos artefatos necessrios e dos
papis a serem desempenhados, em conformidade com a norma MPS.Br.

4.5.1.1 Definio dos fluxos de atividades

O fluxo de atividades do processo de Gerncia de Requisitos foi definido com base na
literatura atual disponvel, ao estado da arte e tendo como objetivo principal atender aos
resultados esperados pelo processo de Gerncia de Requisitos do MR-MPS, alm da
influncia do modelo de referncia para desenvolvimento de produto utilizado neste trabalho.
Atravs do fluxo de atividades o processo de Gerncia de Requisitos sistematizado
de modo que sejam desempenhadas as atividades da forma como apresentado no fluxograma
da figura 18.
116
O processo se inicia com uma requisio, que pode ser externa, solicitada por um
cliente ou internamente identificada por um colaborador. De qualquer modo, esta requisio
precisa ser formalizada na forma de documento padro ou email. A partir dessa formalizao,
faz-se um levantamento mais detalhado para elicitar esse pedido, levantando informaes do
que o cliente deseja. Constatada a real necessidade de mudana, traa-se uma anlise do
impacto no projeto como um todo, passando pelo cronograma, necessidade de recursos, etc,
para isso, usa-se uma matriz de rastreabilidade dos requisitos. Com essa primeira anlise feita,
inicia-se uma etapa de negociao na qual as prioridades, custos e o tempo de
desenvolvimento da solicitao so acertados, considerando-se que para esta atividade se faz
utilizar-se de critrios previamente estabelecidos. Caso no tenha sido aprovada, a solicitao
de mudana, o cliente comunicado dos motivos. Em caso positivo, as mudanas so
incorporadas no projeto e a rastreabilidade estabelecida com a atualizao dos documentos
de requisitos e plano de projeto.

117

Figura 18. Fluxo de atividades da gerncia de requisitos

Deve-se destacar que todas essas aes so definidos em um Plano de Gerncia de
Requisitos. Os itens abaixo fazem uma breve descrio de cada uma das atividades do fluxo:

4.5.1.2 Atividades

Nome Formalizar Solicitao
Descrio Significa receber a solicitao do cliente obtida por um dos meios oficiais
declarados na Poltica Organizacional (PO), registrar solicitao do cliente,
agendar obteno de requisitos e fazer levantamento de informaes sobre
o cliente (quando externo).
Responsvel(is) Suporte
118

Participantes Suporte
Cliente
Produtos
Requeridos
Email ou formulrio de solicitao de mudana
Produtos
Gerados
Formulrio de Solicitao de mudana preenchido

Nome Elicitar e Analisar Requisitos
Descrio Atividade destinada ao levantamento e entendimento das necessidades de
forma clara e documentada no padro esabelecido.
Responsvel(is) Analista de sistemas

Participantes Analista de sistemas
Cliente
Produtos
Requeridos
Solicitao de Mudana
Produtos
Gerados
Requisitos Especificados

Nome Analisar impacto da mudana
Descrio Dever ser realizada uma anlise para entender o impacto que essa
mudana ir desencadear no projeto como um todo, em termos de
cronograma e da demanda de recursos
Responsvel(is) Gerente do Projeto

Participantes Analista de Sistemas
Gerente de Projeto
Produtos
Requeridos
Requisito Especificado.
Matriz de Rastreabilidade
Produtos
Gerados
Anlise do Impacto

Nome Analisar e Negociar os Requisitos
Descrio Nesta atividade ser analisada a viabilidade de tempo e financeira da
mudana e a negociao junto ao cliente.
Responsvel(is) Gerente de Projeto
Participantes Analista de Sistema
Gerente de Projeto
Cliente
Produtos
Requeridos
Requisitos Especficos
Produtos
Gerados
Viabilidade da mudana

Nome Incorporar alteraes apropriadas
Descrio Com a aprovao da mudana, ser executada as mudanas no sistema de
forma a atender a necessidade do cliente.
Responsvel(is) Gerente de Projeto
Participantes Gerente de Projeto
Desenvolvedor
119
Equipe de Qualidade
Produtos
Requeridos
Requisito Especificado
Produtos
Gerados
Sistema atualizado

Nome Manter rastreabilidade bidirecional dos requisitos
Descrio Com a mudana j executada, deve-se registrar e atualizar os documentos
que sofreram alteraes.
Responsvel(is) Analista de sistema
Participantes Equipe de Qualidade
Analista de sistema
Produtos
Requeridos
Documento de requisitos / Matriz de rastreabilidade / Plano de Projeto
Produtos
Gerados
Documentos atualizados.

Nome Comunicar o Cliente
Descrio A comunicao com o cliente em caso de inviabilidade deve ser feita de
maneira formal explicitando claramente os motivos.
Responsvel(is) Gerente do projeto

Participantes Gerente do projeto
Cliente
Produtos
Requeridos
Anlise de viabilidade
Produtos
Gerados
Email

4.5.1.3 Artefatos

Formulrio de Solicitao de Mudana: Documento que registra o pedido de
mudana feito pelo cliente interno ou externo, cada formulrio gera um nmero
identificando o responsvel pela solicitao, descrio e motivo da mudana. Esse
formulrio pode ser eletrnico ou fsico.
Documento de Requisitos: O documento de requisitos registra todos os requisitos do
sistema levantados junto aos usurios gestores e finais. Aconselha-se padronizar este
documento seguindo o padro internacional definido pela IEEE 820. Este artefato deve
estar sob rgido controle de mudanas uma vez que as alteraes em suas informaes
podem ter impacto por todo o sistema.
120
Documento de Arquitetura: Descreve as principais decises de projeto tomadas pela
equipe de desenvolvimento e os critrios considerados durante a tomada destas
decises. Suas informaes incluem desde a especificao da infra-estrutura de
hardware e software do sistema, at descries detalhadas dos diversos mecanismos de
arquitetura de software adotados.
Matriz de Requisitos: A Matriz de Requisitos registra todos os requisitos e as regras
de negcios do sistema levantados junto aos usurios gestores e finais. Este artefato
deve estar sob rgido controle de mudanas uma vez que as alteraes em suas
informaes podem ter impacto por todo o sistema.
Plano de Gerncia de Requisitos: Descreve a documentao de requisitos, os tipos
de requisitos e seus respectivos atributos de requisitos, especificando as informaes e
os mecanismos de controle que devem ser coletados e usados para avaliar, relatar e
controlar mudanas nos requisitos do produto.
Laudos das revises realizadas: Formulrio padro no qual a Equipe de Qualidade
periodicamente registra todas os desvios encontrados entre os produtos gerados e a
descrio do planejado, enviando aos responsveis para que medidas sejam tomadas.

4.5.1.4 Papis e Responsabilidades

Analista de Sistemas: responsvel pelas atividades de anlise e projeto do sistema,
incluindo o levantamento dos requisitos junto aos stakeholders, a especificao dos
requisitos em documento apropriado, a modelagem do sistema atravs de diagramas
UML, o projeto da arquitetura do sistema de forma detalhada, alm do controle das
mudanas nos requisitos e no escopo do projeto.

Gerente de Projeto: O gerente de projeto responsvel por todas as atividades
referentes ao gerenciamento e planejamento do projeto, entre os quais se incluem:
121
Alocar recursos
Estabelecer prioridades;
Coordenar as negociaes e acordos com usurios e demais reas da empresa;
Definir para cada membro da sua equipe, seus respectivos papis e as permisses que
so atribudas a cada papel;
Instituir o uso de uma ferramenta de controle de verso para garantir, de maneira
automatizada, que somente alteraes autorizadas sejam implementadas no sistema e
em todos os itens de configurao. E assim, poder averiguar as mudanas entre o
sistema e uma verso futura;
Autorizar a atualizao de uma verso de produo do sistema por uma nova verso;
estabelecida pelo Gerente de Configurao. Qualquer mudana em verses de
produo deve ser autorizada pelo Gerente do Sistema
O gerente de projeto o responsvel por garantir o planejamento, execuo e controle
do Processo de Desenvolvimento de Software durante todo o ciclo de vida do projeto.

Quality Assurrance: responsvel pela garantia da qualidade no projeto. Suas aes
esto relacionadas ao monitoramento tanto do processo quanto dos produtos gerados com
a finalidade de identificar desvios ao planejado devendo relatar ao responsvel para que
aes corretivas sejam tomadas. Suas atividades so, portanto: investigar os documentos
gerados, analisar o cdigo do sistema e registrar as ocorrncias.
Suporte: responsvel pelo suporte ao sistema junto ao cliente, podendo ser um suporte
remoto ou estar alocado no prprio cliente. Tem como responsabilidade receber as
solicitaes de manuteno e mudanas registrando de forma correta para gerar tickets
para cada chamado. Trata-se do elemento de ligao entre o fornecedor e o cliente, o que
lhe exige habilidades especficas de relacionamentos.
122
4.5.1.5 Atendimento aos Resultados Esperados

Como forma de elucidar o cumprimento dos resultados esperado pelo modelo, segue
abaixo, um panorama, considerando-se para cada Resultado de Processo o que se espera, o
que deve ser feito e como o modelo proposto cumpre esse resultado.

Resultado Esperado GR1 O entendimento dos requisitos obtido junto aos
fornecedores de requisitos.
O que fazer ? Verificar se os requisitos foram entendidos da mesma forma pelos
desenvolvedores e cliente, a partir de documentos prvios ou elaborados
com fornecedores de requisitos.
O que o modelo
proporciona
- Define um mecanismo de comunicao contnua com os fornecedores,
tais como: reunies, atas, reviso conjunta.

- Identifica os fornecedores de requisitos.

- Gera um documento que representa o entendimento dos requisitos.


Resultado Esperado GR2 Os requisitos de software so aprovados utilizando
critrios objetivos.
O que fazer ? Com base em critrios pr-definidos deve-se aprovar ou no os requisitos
levantados, tanto em termos tecnolgicos, financeiros, de tempo, de
recursos, entre outros.

O que o modelo
proporciona
- Define um conjunto de critrios objetivos.

- Realiza avaliao e aceitao dos requisitos baseados nos critrios.

Resultado Esperado GR3 A rastreabilidade bidirecional entre os requisitos e os
produtos de trabalho estabelecida e mantida.
O que fazer ? Deve-se manter, ao longo do projeto, um mecanismo que possibilite a
rastreabilidade bidirecional entre os requisitos e demais produtos do
projeto.
O que o modelo
proporciona
- Criao de uma matriz de rastreabilidade.

Resultado Esperado GR4 Revises em planos e produtos de trabalho do projeto
so realizadas visando identificar e corrigir inconsistncias
em relao aos requisitos.
O que fazer ? Garante que inconsistncias sejam identificadas com base nos requisitos e
que sejam realizadas aes para corrigi-las.
O que o modelo - Monitoramento peridico da Equipe de Qualidade (QA) para identificar
123
proporciona inconsistncias e registrar em Laudos as revises realizadas.


Resultado Esperado GR5 Mudanas nos requisitos so gerenciadas ao longo
do projeto.
O que fazer ? Durante todo o projeto, deve-se registrar os pedidos de mudanas nos
requisitos e analisa o impacto da mudana. Essas aes devem estar
registradas em um plano de gerncia de requisitos.
O que o modelo
proporciona
- Formalizao das mudanas atravs de email e/ou formulrios de
solicitao.
- Cria um plano de gerncia de requisitos.


4.5.2 Processo Padro de Gerncia de Projetos

Existe um consenso, entre os pesquisadores da rea de engenharia de software, de que
a gesto eficiente de projetos imperativa na busca pela qualidade de resultados.
MAGALHES (2005).
Esse conceito reflete bem a realidade mundial que apresenta alguns dados
preocupantes. O Chaos Research, principal fonte de dados sobre gerncia de projetos mostra
que somente 33% dos projetos de software iniciados so de sucesso. STANDISH (2004).
Para o bom entendimento sobre gerncia de projetos interessante destacar o conceito
de projeto. Segundo a ABNT (2001), projeto Processo nico, consistido de um grupo de
atividades, controladas com datas para incio e trmino, empreendido para alcance de um
objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos.
J para o Project Management Institute, um projeto pode ser definido, em termos de
suas caractersticas distintivas Um empreendimento temporrio, planejado, executado e
controlado, com objetivo de criar um produto ou servio nico. PMBOK (2000).
124
Essas definies apresentadas por instituies que padronizam os conceitos
relacionados a projetos seguem uma mesma linha da definio de projeto de software, que
para Pressman (2005), um projeto de software para ser bem sucedido, necessrio que alguns
parmetros sejam corretamente analisados, como por exemplo, o escopo do software, as
tarefas a serem realizadas, os riscos envolvidos, os recursos necessrios, os indicadores a
serem estabelecidos e cumpridos, os esforos e custos aplicados e a sistemtica a ser seguida.
O controle destes parmetros caracteriza a funo tpica do gerenciamento de projetos a qual,
de forma geral, se inicia antes do trabalho tcnico e prossegue medida que a entrega do
software vai se concretizando.
Percebe-se ento a importncia da gerncia de projetos, que de acordo com o PMBOK
(2000), a aplicao de conhecimentos, habilidades, ferramentas e tcnicas nas atividades do
projeto a fim de atender os requisitos do projeto. Pode ser mais bem compreendido atravs
dos processos que o compem, que podem ser reunidos em cinco grupos de processos:
Iniciao, Planejamento, Execuo, Controle e Encerramento. E tambm, em nove reas de
conhecimento: Gerenciamento da Integrao do Projeto, Gerenciamento do Escopo do
Projeto, Gerenciamento do Tempo do Projeto, Gerenciamento dos Custos do Projeto,
Gerenciamento da Qualidade do Projeto, Gerenciamento dos Recursos Humanos do Projetos,
Gerenciamento da Comunicao do Projeto, Gerenciamento dos Riscos do Projeto e
Gerenciamento dos Fornecimentos de Bens e Servios do Projeto.






125
4.5.2.1 Fluxo das Atividades


Figura 19. Fluxo de atividades para gerncia de projetos.

O processo se inicia com a abertura do projeto que gera um escopo preliminar, j na
fase de planejamento esse escopo detalhado dando subsdio para que se crie uma estrutura
analtica de processos (EAP), desencadeando na seqncia outras atividades como
126
planejamento de esforos, definio de estimativa de tempo e recursos, o que resulta em um
cronograma. Esse cronograma juntamente com o planejamento de recursos humanos,
planejamento de riscos, planejamento do ambiente de execuo do projeto e planejamento das
comunicaes gera o Plano do Projeto que dever estar de comum acordo com a equipe de
desenvolvimento e com o cliente. A partir da aceitao do cliente so desencadeadas as tarefas
de execuo na formao e treinamento do time alm da montagem do ambiente e divulgao
de informaes e tarefas. Aps o planejamento e execuo, iniciada a fase de controle, na
qual o gerente do projeto monitora constantemente riscos, custos, cronograma e a equipe,
identificado divergncias e tomando decises para solucionar problemas. O fim do projeto
marcado pela assinatura do termo de aceite e o ato de encerramento do contrato.
Para esse processo padro, algumas atividades so destacadas, conforme apresentado a
seguir:

4.5.2.2 Atividades

Nome Definir Escopo
Descrio Esta atividade recebe o escopo preliminar e detalha em um documento
oficial contendo descrio dos objetivos, metas e justificativa do projeto
como um todo.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
Recursos Humanos
Produtos
Requeridos
Escopo preliminar
Produtos
Gerados
Escopo Detalhado

Nome Criar EAP
Descrio Cria-se uma estrutura analtica de processos, atravs de um Brainstorm.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
Equipe de Desenvolvimento
Produtos
Requeridos
Escopo
Produtos
Gerados
EAP Estrutura Analtica de Processos

Nome Planejar Recursos Humanos
127
Descrio Faz-se um levantamento das necessidades de recursos humanos para o
projeto. Deve-se estabelecer o perfil, habilidades e conhecimentos
necessrios, fazendo uma anlise se a empresa possui este recurso ou
dever contratar.
Responsvel(is) Gerente de projeto
Participantes Gerente de Projeto
Recurso Humano
Produtos
Requeridos
EAP Estrutura Analtica de Processos
Produtos
Gerados
Planilha de alocao de pessoal

Nome Planejar comunicaes
Descrio Deve-se estabelecer a forma de comunicao entre os membros do projeto
e entre o cliente, de forma a estabelecer um caminho para registro de
solicitaes, pedidos de maneira rpida.
Responsvel(is) Gerente do Projeto
Participantes Cliente
Gerente do Projeto
Produtos
Requeridos
Escopo detalhado
Produtos
Gerados
Plano de comunicao

Nome Planejar Ambiente
Descrio Identificar e descrever os recursos necessrios para execuo do projeto.
Deve-se levar em considerao hardware, software, rede, servidores, entre
outros.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
Equipe de Infra-Estrutura
Produtos
Requeridos
Escopo detalhado
Produtos
Gerados
Planilha de necessidades de Recursos

Nome Identificar Riscos
Descrio Atravs do mtodo de Moynihan, pretende-se identificar os principais
riscos inerentes ao projeto e a probabilidade destes vierem a ocorrer.
Responsvel(is) Gerente de Projeto
Participantes Gerente de Projeto
Produtos
Requeridos
Escopo detalhado
EAP
Produtos
Gerados
Planilha de Riscos com anlise de impacto.

Nome Definir Atividades, Durao e Seqncia
Descrio Com a EAP definida, faz-se uma estruturao das atividades de forma
seqencial atribuindo datas e responsabilidades.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
128
Produtos
Requeridos
EAP
Produtos
Gerados
Atividades seqenciadas

Nome Gerar Cronograma
Descrio Faz-se uma anlise das atividades, seus relacionamentos e durao,
gerando assim um cronograma do projeto como um todo.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
Produtos
Requeridos
EAP
Produtos
Gerados
Cronograma

Nome Revisar/Finalizar Plano do Projeto
Descrio O plano do projeto compreende a unificao de todos os outros planos (RH,
Riscos, Ambiente, cronograma, comunicao) de forma a estabelecer
formalmente o planejamento do projeto.
Responsvel(is) Gerente do Projeto
Participantes Gerente do Projeto
Cliente
Equipe
Produtos
Requeridos
Escopo, Plano de RH, Plano de Risco, Plano de Comunicao, Plano de
Ambiente e Cronograma.
Produtos
Gerados
Plano de Projeto

Nome Analisar Viabilidade
Descrio Nesta etapa fundamental para o projeto dever ser realizado o estudo de
viabilidade do projeto, de forma a identificar se a empresa possui tempo
para o projeto, se possui recursos, se existe domnio da tecnologia para
concluir o projeto.
Responsvel(is) Diretor de Tecnologia
Participantes Diretor de Tecnologia
Gerente de projeto
Produtos
Requeridos
Plano de Projeto
Produtos
Gerados
Estudo de Viabilidade (Planilha).


4.5.2.3 Papis

Analista de Sistemas: responsvel pelas atividades de anlise e projeto do sistema,
incluindo o levantamento dos requisitos junto aos stakeholders, a especificao dos
requisitos em documento apropriado, a modelagem do sistema atravs de diagramas
129
UML, o projeto da arquitetura do sistema de forma detalhada, alm do controle das
mudanas nos requisitos e no escopo do projeto.
Gerente de Projeto: O gerente de projeto responsvel por todas as atividades
referentes ao gerenciamento e planejamento do projeto, incluindo:
o Alocar recursos
o Estabelecer prioridades
o Coordenar as negociaes e acordos com usurios e demais reas da empresa
o Definir para cada membro da sua equipe, seus respectivos papis e as
permisses que so atribudas a cada papel
o Instituir o uso de uma ferramenta de controle de verso para garantir, de
maneira automatizada, que somente alteraes autorizadas sejam
implementadas no sistema e em todos os itens de configurao. E assim, poder
averiguar as mudanas entre o sistema e uma verso futura
o Autorizar a atualizao de uma verso de produo do sistema por uma nova
verso estabelecida pelo Gerente de Configurao. Qualquer mudana em
verses de produo deve ser autorizada pelo Gerente do Sistema
O gerente de projeto o responsvel por garantir o planejamento, execuo e controle
do Processo de Desenvolvimento de Software durante todo o ciclo de vida do projeto.

Quality Assurrance: responsvel pela garantia da qualidade no projeto. Suas aes
esto relacionadas ao monitoramento tanto do processo quanto dos produtos gerados
com a finalidade de identificar desvios ao planejado devendo relatar ao responsvel
para que aes corretivas sejam tomadas. Suas atividades so, portanto: Investigar
documentos gerados, analisar cdigo do sistema e registrar ocorrncias.
Recursos Humanos: Profissional com a responsabilidade de apresentar ao gerente do
projeto os colaboradores atuais da empresa, seus perfis habilidades e disponibilidade.
130
Infra-Estrutura: Pessoa ou grupo de pessoas que tem como responsabilidade planejar
e montar a infra-estrutura para execuo do projeto. Compreende esta atividade a
instalao de mquinas, softwares, rede, e outros dispositivos necessrios. Deve
tambm monitorar cotidianamente o funcionamento desses dispositivos para manter o
bom funcionamento.

4.5.2.4 Artefatos

Plano de Projeto: O documento de Plano de Projeto estabelece as principais
funcionalidades e fronteiras do sistema e registra informaes que delimitam o
projeto de desenvolvimento como um todo. Este artefato tem a funo de um
contrato entre os diferentes interessados no sistema (usurio gestor, usurio final,
etc.), registrando aquilo que ser desenvolvido ao longo do projeto. Deve ser
formalmente aprovado pelas partes envolvidas.
Escopo: Esse documento tem por objetivo descrever uma viso inicial para o
projeto, definindo os interessados, objetivos, justificativa e uma descrio do que o
sistema ir fazer. Recomenda-se que seja um documento curto de 3 a 5 pginas.
Cronogama: O cronograma a disposio grfica do tempo que ser gasto na
realizao de um trabalho ou projeto, de acordo com as atividades a serem
cumpridas. Serve para auxiliar no gerenciamento e controle deste trabalho,
permitindo de forma rpida a visualizao de seu andamento.
Plano de Recurso Humano: Todos as necessidades de recursos humanos devem
ser identificadas atravs de habilidades e perfil desejveis, alm de uma analise se
a empresa j possui esses recursos ou se ter que contratar ou treinar.
131
Plano de Risco: Documento que contempla uma anlise de todos os riscos que um
projeto de TI (Tecnologia da Informao) pode enfrentar. Nesse documento, deve
existir para cada risco, a probabilidade e a importncia, alm de medidas a serem
tomadas em caso de ocorrncia.
Laudos das revises realizadas: Formulrio padro no qual a Equipe de que
Qualidade periodicamente registra todas os desvios encontrados entre os produtos
gerados e a descrio do planejado, enviando aos responsveis para que medidas
sejam tomadas.

4.5.2.5 Atendimento aos Resultados Esperados

Como forma de elucidar o cumprimento dos resultados esperado, segue um panorama
apresentando o resultado que o MR-MPS espera, o que deve ser feito e como o modelo
proposto cumpre esse resultado.

Resultado Esperado GPR1: O escopo do trabalho para o projeto definido
O que fazer ? Deve-se criar um documento de escopo seguindo uma padro previamente
definido.
O que o modelo
proporciona
- Define um escopo do projeto com a visualizao do trabalho a ser
realizado.



Resultado Esperado GPR2: As tarefas e os produtos de trabalho do projeto so
dimensionados utilizando mtodos apropriados;
O que fazer ? Estimar o esforo atravs de um mtodo definido pela empresa.

O que o modelo
proporciona
- O modelo proporciona a utilizao de bases histricas ou mtodos como
COCOMO ou Pontos de funo baseados em uma EAP (Estrutura Analitica
de Projeto).


132
Resultado Esperado GPR3: O modelo e as fases do ciclo de vida do projeto so
definidas;
O que fazer ?
Definir um ciclo de vida apropriado para o projeto em questo com a
descrio das atividades.

O que o modelo
proporciona ?

- Define o ciclo de vida do projeto, indicando suas fases, as relaes de
seqncia, a interdependncia entre as fases e os marcos e pontos de
controle do projeto.


Resultado Esperado GPR4: O esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados
histricos ou referncias tcnicas;
O que fazer ? Realiza estimativas de custo e esforo para tarefas e produtos de trabalho
com base em dados histricos ou mtodos de estimativas .

O que o modelo
proporciona ?
- Criao de um plano de custos (financeiro ou em horas)

- Criao de um cronograma planejado com horas de trabalho


Resultado Esperado GPR5: O oramento e o cronograma do projeto, incluindo
marcos e/ou pontos de controle, so estabelecidos e
mantidos;
O que fazer ? Definir o cronograma com dependncia entre tarefas e o oramento.


O que o modelo
proporciona ?
- Criao de um cronograma contendo caminho crtico e dependncia entre
as tarefas.

- Reviso do cronograma e oramento, conforme a necessidade ao longo
do desenvolvimento.


Resultado Esperado GPR6: Os riscos do projeto so identificados e o seu
impacto, probabilidade de ocorrncia e prioridade de
tratamento so determinados e documentados;
O que fazer ? Utilizar um check-list ou mtodo para identificao dos riscos inerentes a
um projeto de tecnologia.

O que o modelo
proporciona ?
- Utilizao de uma lista dos riscos para o projeto, caracterizando seu
impacto.

- Analisa riscos, determina o grau de importncia, probabilidade e
prioridade de cada risco.


133
Resultado Esperado GPR7: Os recursos humanos para o projeto so planejados
considerando o perfil e o conhecimento necessrios para
execut-lo;
O que fazer ? Criar um plano de recursos humanos


O que o modelo
proporciona
- Selecionar Recursos humanos a partir das competncias requeridas para
realizar as atividades do projeto.



Resultado Esperado GPR8: As tarefas, os recursos e o ambiente de trabalho
necessrios para executar o projeto so planejados
O que fazer ? Criar um plano de infra-estrutura necessria para o projeto, identificando
recursos.

O que o modelo
proporciona
- Planejar a quantidade de recursos e a infra-estrutura necessria para
cada tarefa a parir da EAP.

Resultado Esperado GPR9: Os dados relevantes do projeto so identificados e
planejados quanto forma de coleta, armazenamento e
distribuio. Um mecanismo estabelecido para acess-los,
incluindo, se pertinente, questes de privacidade e
segurana;
O que fazer ? Deve-se definir um plano de gerncia de dados listando todos os
documentos gerados no projeto, sua distribuio e mdia para
armazenamento, proteo (segurana e sigilo) e recuperao desses
dados.

O que o modelo
proporciona
- Criao de um plano de documentao. Tanto para documentos
eletrnicos ou no.



Resultado Esperado GPR10: Planos para a execuo do projeto so
estabelecidos e reunidos no Plano do Projeto
O que fazer ? Compor o plano de projeto com base nas informaes de planejamento do
projeto organizadas e relacionadas.

O que o modelo
proporciona
- Criao de um Plano de Projeto



134
Resultado Esperado GPR11: A viabilidade de atingir as metas do projeto,
considerando as restries e os recursos disponveis,
avaliada. Se necessrio, ajustes so realizados
O que fazer ? Avaliar a viabilidade do projeto, a partir da viso geral dos objetivos e
caractersticas dos resultados pretendidos, dos recursos financeiros,
tcnicos, humanos, bem como restries impostas pelo cliente, ambiente
externo e interno e condies de desenvolvimento.

O que o modelo
proporciona
- Documento de avaliao da viabilidade com critrios estabelecidos.



Resultado Esperado GPR12: O Plano do Projeto revisado com todos os
interessados e o compromisso com ele obtido
O que fazer ? Garantir que todos os interessados tomaram conhecimento e se
comprometeram com o planejamneto do projeto.

O que o modelo
proporciona
- Registro do comprometimento com o plano de projeto atavs de
assinatura das partes envolvidas.



Resultado Esperado GPR13: O progresso do projeto monitorado com relao
ao estabelecido no Plano do Projeto e os resultados so
documentados
O que fazer ? Monitorar o projeto, comparando o planejado com o realizado.

O que o modelo
proporciona
- Relatrio de monitorao do projeto.



Resultado Esperado GPR14: O envolvimento das partes interessadas no projeto
gerenciado
O que fazer ? Planejar o tipo de envolvimento dos interessados no projeto registrando as
atividades e evidenciando o envolvimento


O que o modelo
proporciona
- Reunio com os envolvidos para definio dos papis e obteno de
assinatura na Ata de reunio.


Resultado Esperado GPR15: Revises so realizadas em marcos do projeto e
conforme estabelecido no planejamento
O que fazer ? Realizar revises do projeto em marcos previamente estabelecidos


O que o modelo
proporciona
Gerao de laudos das revises realizadas.


135

Resultado Esperado GPR16: Registros de problemas identificados e o resultado
da anlise de questes pertinentes, incluindo dependncias
crticas, so estabelecidos e tratados com as partes
interessadas
O que fazer ? Identificar e analisar problemas das monitoraes.


O que o modelo
proporciona
- Lista de problemas identificados.



Resultado Esperado GPR17: Aes para corrigir desvios em relao ao planejado
e para prevenir a repetio dos problemas identificados so
estabelecidas, implementadas e acompanhadas at a sua
concluso
O que fazer ? Definir aes corretivas e acompanhar essas aea at sua concluso


O que o modelo
proporciona
- Plano de ao corretiva com informaes de acompanhamento da
execuo das aes.















136
5. APLICAO DO MODELO: UMA PESQUISA-AO

Aps a idealizao de um adequado modelo de referncia, procedeu-se a uma
aplicao em um projeto real para validar o modelo e mensurar os ganhos com sua
implantao em uma empresa de pequeno porte.
A escolha da empresa se justifica pelos seguintes fatores:
Acessibilidade, isto , a empresa possui inteno de melhorar seus processos e para
tanto, disponibilizou recursos para esse projeto;
Resultados rpidos;
O fato de a empresa possuir projetos de diferentes tamanhos em diferentes reas de
atuao, como parte do seu posicionamento junto ao mercado.

5.1 A empresa
A COSS Solues e Tecnologia Ltda uma empresa brasileira, fundada em 2005 com
sua sede instalada no Plo de Alta Tecnologia de So Carlos/SP e um escritrio em So
Paulo/SP. A empresa possui trs scios e conta atualmente com 23 colaboradores sendo 17
deles diretamente ligados a desenvolvimento de software.
Est voltada para atuar na criao, desenvolvimento e implementao de produtos e
servios de alto valor agregado na rea de Gesto & Tecnologia da Informao. Atua junto a
empresas nacionais e multinacionais do segmento de indstria, servios e comrcio. Trabalha
com tecnologias e solues de classe mundial para entregar o maior valor aos seus clientes e
parceiros de negcios, globalmente, como: SAP, Oracle, Microsoft, Java, JBoss, embedded C,
137
C++, .NET, SAP Netweaver, em ambientes computacionais heterogneos incluindo
dispositivos mveis.
Em 2006, iniciou suas atividades com a prtica de implementao de solues SAP
CRM (Customer Relationship Management) visando aprofundar o conhecimento dos
processos de negcios centrados no cliente. Nessa linha, desenvolveu servios e metodologias
com recursos prprios, implementando de forma objetiva e pragmtica esta soluo.
Construiu relaes empresariais, desenvolveu parcerias de negcios com empresas globais e
trabalhos colaborativos, treinou profissionais, executivos e empresrios, e conquistou
financiamento FAPESP para desenvolvimento de plataforma de integrao baseado em
tecnologia RFID (WELCOSS) com o objetivo de desenvolver solues prprias e prover ao
mercado produtos e servios de alto valor agregado, nesta rea. Esta soluo est preparada
para atender empresas de diferentes segmentos de mercado como: Automotiva, Qumica, Bens
de Consumo, Varejo, Hospitalar, Governo, Alta-Tecnologia, Aeronutica, Papel & Celulose,
Energia e Manufatura em geral, entre outras.
Possui trabalhos em diversas regies do Brasil e Amrica Latina. Em 2007, a empresa
consolidou a prtica de CRM e constituiu o ID SMART Center (lanado em 14/02/2007),
trata-se de um centro de competncia em tecnologia RFID, preparando mo-de-obra para
trabalhar com os mais diferentes dispositivos tecnolgicos e solues de mercado existente
nesta rea.
A necessidade de poder contar com um modelo de referncia estruturado de
desenvolvimento de software se d pela exigncia de qualidade por alguns clientes nacionais e
internacionais e que fez, de incio, com que a empresa adotasse o MPS.Br como estratgia
para futuramente implantar o modelo CMMi.

138
5.2 Estruturao da metodologia de trabalho na empresa
O trabalho de implantao de melhoria de processos na empresa teve incio em maio
de 2007, com apio irrestrito da alta administrao. Foi formado um grupo chamado de Grupo
de Controle da Qualidade (GCQ), constitudo por 2 membros, sendo que 1 deles teria
dedicao exclusiva a essa atividade durante 15 meses.
A estruturao da metodologia de trabalho na empresa resultou na elaborao de
alguns documentos importantes como a Poltica Organizacional que disserta sobre as questes
que se relacionam aos processos de software e que definem a forma de implantao dos dois
processos do nvel G do MR-MPS: Processo de Gerncia de Requisitos e Processo de
Gerncia do Projeto.
Tambm foram organizados documentos que padronizam a codificao nas linguagens
de programao dos softwares produzidos pela empresa, templates de ata de reunio, modelos
de documentos para registro de ocorrncias, planilha para controle de horas de
desenvolvimento, plano de documentao, entre outros.
O fluxo de atividades a seguir, apontado na figura 20, representa os passos para
implantao dos dois processos na empresa ao longo desse perodo.
139

Figura 20. Fluxo de trabalho na implantao do processo.
Faz-se abaixo algumas consideraes sobre a implantao dos dois processos do nvel
G do MPS.Br

5.2.1 Implantao do Processo de Gerncia de Requisitos
O processo de Gerncia de Requisitos foi o primeiro processo a ser implantado e teve
como embasamento essencial a elaborao da documentao e o estabelecimento das
140
definies resultantes do momento inicial da implantao do nvel G e da estruturao da
metodologia de trabalho da empresa. A implantao desse processo levou 5 meses.
Todas as aes realizadas para a implantao desse processo foram voltadas ao
atendimento de cada um dos resultados esperados na Guia Geral do MPS.Br.
valido destacar que a empresa j possua atividades relacionadas a elicitao de
requisitos, porm no formalmente. No existia um documento padro nem uma forma
adequada para selecionar um mtodo de coleta de requisitos, inclusive em alguns projetos no
existia evidncias de aceitao dos requisitos por parte do cliente, as solicitaes eram muitas
vezes por telefone, de maneira verbal. Os critrios para aprovao dos requisitos eram
tomados pela presso que o cliente exercia.
A implantao do processo de Gerncia de Requisitos seguiu uma metodologia
gradual que consistiu em: entender os fluxos de atividades proposto pelo modelo de
referncia, adaptar os fluxos, elaborao dos documentos e modelos-padro, instalao e
adaptao das ferramentas de apoio para disseminao do processo, treinamento da equipe e
acompanhamento da execuo nos projetos estudados.
Entre as ferramentas instaladas destacam-se as ferramentas: TRAC System para
rastreabilidade de ativos e controle de atividades, o Subversion (SVN) para controle de verso
de cdigo fonte e documentao e o MS-SharePoint para disseminao de documentao e
informaes. Outro ponto de destaque esteve relacionado a padronizao dos documentos,
sendo declarados no Plano de Documentao da empresa.
As dificuldades encontradas durante essa adaptao esteve relacionada ao fato do
processo de gerncia de requisitos estar integrado e depender de outros processos, como por
exemplo, o processo de suporte, o processo de desenvolvimento de requisitos, entre outros.
Sendo assim, entende-se que para melhorar o processo de gerncia de requisitos outros
141
processos do MR-MPS, principalmente do nvel F e E foram parcialmente implementados, o
que ajudar futuramente no programa de melhoria contnua.

5.2.2 Implantao do Processo de Gerncia de Projetos
Com o processo de gerncia de requisitos j em andamento, teve incio a
implementao do processo de gerncia de projetos.
Esta nova fase j dispunha de diversos pontos favorveis, adquiridos nas etapas
preparatrias e ao longo da implantao da fase de gerncia de requisitos, ou seja, j se
percebia uma predisposio e um comprometimento da equipe para avanar em sua atuao.
Entretanto, mesmo assim, esta segunda fase levou 6 meses e envolveu mais diretamente a
equipe de qualidade que baseada no modelo proposto, adaptou-a para as necessidades
demandadas pela organizao. Cabe destacar que a empresa no dispunha de nenhum gerente
formado em cursos especficos de gerenciamento de projetos, o que exigiu, como parte
indispensvel, investimentos na capacitao de dois de seus gerentes, em curso especfico de
35 horas de durao.
Assim como o processo de gerncia de requisitos, todas as aes realizadas para a
implantao do processo foram voltadas ao atendimento de cada um dos resultados esperados
no guia geral do MPS.Br, conforme proposto no modelo. Neste aspecto cabe destacar a
influncia marcante do PMI e mais especificamente do PMBok (Project Manager Body of
Knowledgement), como prticas j assimiladas pela equipe.
A melhoria do processo seguiu uma metodologia semelhante a do processo de gerncia
de requisitos, na qual buscou-se um entendimento dos fluxos de atividades proposto pelo
modelo. Alm disso procedeu-se a adaptao desses fluxos, a elaborao dos documentos e a
criao de templates. Adicionalmente, foi feito uso e adaptao das ferramentas de apoio,
142
como o MS-Project e o Trac System j instaladas na empresa, e o treinamento da equipe
atravs de curso de gerncia de projetos. Para os desenvolvedores, foi realizado o treinamento
atravs de workshop interno e finalmente, a etapa de acompanhamento da execuo das
atividades ocorreu, monitorando-se e tomando aes corretivas quando desvios aconteciam.
Com relao ao processo de gerncia de projetos, percebeu-se que a empresa possua
boas prticas de planejamento e controle de projetos, porm essas aes eram mnimas e no
atendiam s exigncias do modelo. Como exemplo, cabe citar o uso do MS-Excel para
definio de cronograma, o que ocasionava perda de tempo e dificuldade de
acompanhamento. No existia controle de verso dos documentos gerados, uma vez que os
documentos eram feitos para cada projeto, de uma determinada forma e ficava armazenado no
computador do gerente, sem a preocupao de se estabelecer sistematizao.
Algumas iniciativas foram primordiais para que se pudessem alcanar as metas
propostas no modelo de referncia. O uso da tcnica de anlise de risco chamada de
MOYNIHAN foi de significativa contribuio. O modelo Moynihan avalia o risco de um
projeto de TI pela estimativa da intensidade de 23 fatores de risco sobre 4 fatores de sucesso.
SCHMITZ (2007).
Outro ponto a ser destacado foi o fato de que aps a aprovao do Plano do Projeto, a
equipe se reunia para esclarecimentos dos papis de cada membro. Dessa reunio gerada
uma Ata na qual todos assinam, concordando com sua funo e responsabilidade individuais,
o que formaliza seus compromissos.
Os planos de Recursos Humanos, Comunicao e de Infra-Estrutura so facilitados em
sua divulgao com o uso de planilhas pr-definidas, nas quais os responsveis apenas
preenchem suas necessidades, que sero analisadas sob uma tica realstica.
143
Entre as dificuldades verificadas cabe destacar a necessidade de se atuar sob a tenso
gerada pelas imposies de prazo impostas pelos clientes e pela j aceita, fora do mercado.
Essa presso, muitas vezes percebida como normal, repercute no ambiente interno da
empresa e passa a justificar uma srie de comportamentos que levam a decises
intempestivas, justificadas pela pressa. Esse comportamento encobre falhas maiores como a
no previsibilidade, a atuao em tempo e por antecipao, o que diminuiria riscos e
reduziria custos, e pior, a urgncia passa se justificar decises, muitas delas, inadequadas ou
descabidas. O pior efeito entretanto a formao de um comportamento que passa a justificar
o negligenciamento de atividades primordiais de planejamento, criando uma cultura de
improvisao. No caso em estudo, essa dificuldade foi superada por fora do treinamento e da
difuso da importncia do planejamento, e pelo indispensvel apoio da alta gerncia e isso
transpareceu diretamente nos resultados que passaram a ser percebidos.
A disponibilizao das informaes para toda a equipe durante o desenrolar do
processo foi um ponto importante para que todos entendessem sua participao e importncia.
Cabe lembrar que esta uma das prticas bem sucedidas e amplamente conhecida do sistema
Toyota de Produo, sem dvida, uma importante referncia na produo enxuta e gil. A
seguir ser apresentado o procedimento de disponibilizao adotado.

5.5 Disponibilizao do modelo de processo na empresa
Por meio da utilizao do software MS-SharePoint, foi disponibilizado o processo
consensualmente definido e tambm, o documento oficial que define o Plano de Processo de
Desenvolvimento de Software. Sendo assim, todos os colaboradores envolvidos, direta ou
indiretamente no desenvolvimento passam a ter acesso a essa documentao. Como
ferramenta de visualizao foi adotado o MS-SharePoint, que um meio de comunicao e de
144
colaborao para aplicaes intranet, no qual so gerenciados contedos de forma rpida e
segura. A figura 21, ilustra a tela do sistema na qual o processo disponibilizado.


Figura 21. Tela do Share-Point.

Escolhido o meio de comunicao, foi necessrio que os membros da empresa fossem
treinados para seu uso. O treinamento ocorreu em dois momentos. Primeiramente, atravs de
um workshop de 3 horas para mostrar uma viso geral do processo e seu uso dentro do
SharePoint. Posteriormente foi realizado um treinamento de 4 horas, especificamente voltado
para uso da ferramenta. Uma etapa simples, de baixo custo e de pouca durao mas
indispensvel.
Como resultado do esforo para institucionalizar o modelo de referncia, a partir da
implantao de dois processos: gerenciamento do projeto e gerenciamento de requisitos,
partes significativas e representativas de sua aplicabilidade, foram selecionados dois projetos
145
desenvolvidos na empresa e que puderam posteriormente mostrar os resultados alcanados.
Durante as duas aplicaes foram identificadas melhorias, que imediatamente foram
adaptadas no processo. Os dois projetos selecionados so descritos a seguir.

5.6 O modelo em aplicao: a mensurao dos resultados
Como se estabelecem nesta pesquisa, para corroborar a efetividade do modelo
proposto, foram escolhidos dois projetos reais em uma pequena empresa produtora de
software, executados nos anos 2007/2008. A escolha desses projetos se justifica,
principalmente, pelos fatores: tempo de projeto relativamente curto para retorno dos dados,
por terem sido os primeiros projetos da empresa depois da institucionalizao do programa de
melhoria e tambm por terem sido projetos externos, onde a exigncia por qualidade maior
se comparado a projetos internos. Como metodologia de validao foi adotada a pesquisa-
ao, descrita por Thiollent (1988), pelas razes j apresentadas neste trabalho.

5.6.1 Sistema iKanban
O software iKanban faz parte de um sistema de informao voltado a rea de Logstica
e Produo para Planejamento e Controle da Produo (PCP). Trata-se de um software que
controla a produo de forma automatizada utilizando a tecnologia de Identificao por Rdio
Freqncia (RFID).
O projeto, encomendado por um cliente, teve um tempo aproximado de 7 meses de
durao e envolveu o esforo de 9 colaboradores, entre gerentes, desenvolvedores e suporte.
146
O Cliente utiliza o sistema Kanban como forma de controlar seu fluxo de mercadoria e
reposio de estoque, porm, quebras de cartes, perdas e falta de viso ampla do processo
geravam ruptura constante no abastecimento da linha de produo.
Implantou-se ento um sistema chamado WELCOSS iKanban que compreendia no uso
de Tags RFID de 915Mhz, padro Gen 2, acopladas aos 2.200 Kanbans da produo e
antenas estrategicamente localizadas na planta da empresa. Com esse sistema pode-se rastrear
e gerenciar as movimentaes de material, desde o recebimento de matrias primas e
componentes at a sada, para seu uso na linha de produo e conseqentemente, visualizar a
localizao de cada item, em tempo real. O sistema possui interface Web, disponvel na
intranet da empresa e integrao com o ERP (Enterprise Resource Planning) atualmente
utilizado. A comunicao entre o ERP e o iKanban pode ser feita atravs da tecnologia de
Web Service, troca de arquivos, entre outras.
A figura 22 ilustra a arquitetura da soluo desenvolvida.


Figura 22. Arquitetura da soluo WELCOSS.
147
Conforme relatado por COLELLA (2008), o funcionamento do sistema se d pelo
acoplamento de todos os kanbans uma Tag de RFID. O processo se inicia quando uma
mercadoria chega na empresa juntamente com a nota fiscal. No instante em que a nota fiscal
cadastrada no sistema de gesto (ERP), o Portal de RFID do recebimento imediatamente
avisado das mercadorias que iro chegar. Quando a empilhadeira passa com essas mercadorias
pelo portal de recebimento, automaticamente o sistema realiza a conferncia dos volumes
enviando o resultado da conferncia para o ERP, contendo todas as informaes sobre os
produtos realmente recebidos e os produtos faltantes. Quando esse produto deixa a rea de
recebimento para ser consumido na linha de produo a movimentao dos kanbans tambm
lida pelo Portal RFID, que automaticamente atualiza as informaes no Banco de Dados do
sistema. O mesmo ocorre quando o carto (kanban) levado para o quadro kanban aps o
item ter sido consumido na linha. Sendo assim, um usurio do sistema pode, a partir do
computador remoto, visualizar de forma rpida e fcil a localizao de cada item dentro da
empresa e no fornecedor.
O projeto teve um cronograma aproximado de 7 meses e logo nos primeiros dias de
funcionamento os benefcios foram percebidos com a imediata deteco de itens faltantes,
conferncia de divergncias entre o que era comprado e o que de fato era recebido,
antecipao do abastecimento da linha de montagem antes da parada, visualizao remota do
quadro kanban para todos os interessados. A partir dos dados gerados pelo sistema, torna-se
possvel estimar melhor a quantidade pedida de cada item, visando reduzir os estoques e
minimizando o risco de rupturas na linha de produo, pela antecipao de informaes
proporcionada pelo sistema.
A figura 23 apresenta o fluxo de kanbans na empresa.


148

Figura 23. Fluxo de kanbans na empresa.

Os desafios do projeto estavam direcionados ao pioneirismo do uso da tecnologia de
RFID no Brasil o que elevou os riscos do projeto como um todo, pois no havia referncia do
seu bom uso.
Por ter sido o primeiro projeto da empresa utilizando o modelo de referncia alguns
pontos foram marcantes, entre eles a dificuldade da equipe em seguir com disciplina, os
modelos de documentos previamente estabelecidos, o que foi sendo solucionado com um
acompanhamento intenso da equipe de qualidade e pela vontade manifesta da alta direo.



149
5.5.2 Sistema DVR
Este o segundo caso, no qual o modelo de referncia pode ser testado. Trata-se de um
sistema para armazenamento de textos em gravaes de vdeos. O projeto teve durao de 3
meses, sendo iniciado em junho e seu trmino em outubro de 2008. Ao todo envolveu 6
colaboradores.
O escopo do sistema envolvia a transferncia de dados entre pontos de vendas (POS) e
um sistema de gravao de vdeo digital (DVR), de forma que ao efetuar uma compra em um
caixa de supermercado por exemplo, o sistema iria associar a informao da compra (texto)
com a imagem capturada por uma cmera. Esse sistema est voltado para segurana e visa
detectar furtos nos quais o prprio colaborador responsvel pela venda efetua fraudes. Pode,
adicionalmente ser ampliado para estudos de comportamento do consumidor no ato da
compra.


Figura 24. Arquitetura do sistema DVR.

Como caracterstica favorvel deste projeto, pode-se destacar o escopo fechado no
qual o cliente conhecia exatamente as necessidades do sistema. Por outro lado a complexidade
e a necessidade de desenvolvimento de cdigo fonte em baixo nvel dificultaram as
150
estimativas e execuo do projeto. Foram desenvolvidos cdigos em diversas linguagens de
programao, entre elas: C#, C, C++ Builder, VB, Delphi e Kylix, tanto para rodar em
plataforma Linux (Kernel 2.4) quanto Windows (2000, XP e Vista).
O quadro 9, a seguir apresenta um resumo dos projetos considerados e analisados para
essa aplicao especfica, bem como o tempo despedido na anlise.

Quadro 9: Resumo dos projetos analisados
PROJETO 1 PROJETO 2
Tempo 7 meses 3 meses
Pessoas Envolvidas 9 6
rea de Aplicao Logstica e Produo Segurana
Complexidade Alta Mdia
Linguagens de
Programao Utilizadas
Java, C C#, C, Delphi, Kylix, VB,
C++ Builder.
Dificuldade em implantar
o modelo de referncia
Alta Baixa


5.7 Mensurao das melhorias
Descritos os dois casos escolhidos para a aplicao do modelo de referncia proposto e
feita sua aplicao efetiva, conforme descrito, a etapa seguinte foi a de se mensurar os
resultados decorrentes, que poderiam ter aspectos positivos ou negativos e qualitativos e
quantitativos. Neste sentido, prosseguiu a pesquisa atravs da aplicao de um questionrio
junto aos colaboradores envolvidos no desenvolvimento dos dois projetos. Alguns
colaboradores atuaram nos dois projetos, outros s em um deles, entretanto, no se percebeu
diferenas significativas em sua manifestao.
O questionrio foi elaborado especificamente para este propsito e se encontra no
anexo B deste trabalho. So 15 questes relacionadas a qualidade e produtividade do processo
151
com respostas na escala Likert, que varia de 1 a 5, sendo: 1 discordo totalmente, 2 -
discordo, 3 indiferente, 4 - concordo e 5 - concordo totalmente.
Foram coletados dados de 9 colaboradores da empresa e o tempo de durao dessa
fase da pesquisa foi de 1 dia, somando um total aproximado de 6 horas. Para a tabulao dos
resultados utilizou-se do software MS-Excel e para gerao dos grficos utilizou-se do
software MS-PowerPoint.

5.7.1 Resultados
De acordo com os dados levantados nesta pesquisa junto aos membros participantes
dos dois projetos, pode-se perceber uma alto grau de satisfao relacionado aos processos
implementados.
No incio do formulrio foi solicitado ao colaborador que escrevesse duas palavras que
representassem o programa de melhoria como um todo. Esta foi a maneira encontrada para
compreender o sentimento de cada membro participante quanto ao programa. As palavras
descritas foram:






Definio Produtividade
Qualidade Qualidade


Qualidade Satisfao
Integrao Perfeio



Excelncia Melhoria

Confiabilidade Documentao


Comunicao Pioneirismo
Colaborao Administrao
152
` Pode-se entender que todos os membros responderam palavras relacionadas a
melhoria, satisfao, entre outras, o que nos d uma compreenso de algo positivo.
Essa satisfao comprovada na anlise das respostas das 15 questes, visto que 86%
concordaram totalmente quando perguntando se houve melhoras na execuo do projeto.
Outro ponto a ser destacado se relaciona a mudana na forma de trabalho, na qual 57% se
mostraram satisfeitos com a melhora na documentao, 100% disseram que houve agilidade
nos produtos gerados e 86% acreditam que a qualidade do produto final foi melhor se
comparada com outros projetos.
Abaixo faz-se uma anlise mais detalhada de cada umas das 15 perguntas feitas aos
membros das equipes.


Questo 1. Houve melhoria na execuo do projeto aps a implantao dos processos ?
Para esta questo 13% responderam que concordam totalmente que o modelo de
referncia proposto proporcionou melhoria no desenvolvimento dos projetos e 87%
concordam que o projeto teve melhora se comparado a outros projetos da empresa antes da
implantao dos processos. Constata-se ento uma concordncia de 100% dos membros para a
percepo de que houve melhoria, ou seja, o modelo de referncia proposto foi percebido
como aplicvel e representa melhoria.





Grfico 3. Resultados da questo 1.
0% 0% 0%
87%
13%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
153
Questo 2. Houve agilidade no tempo de produo de software ?
Quanto a questo relacionada a agilidade para se construir o produto 25% disseram
concordar e 75% concordar totalmente que houve ganhos em termos de agilidade na
construo do produto. Essa questo particularmente interessante pois declara que apesar do
controle sobre os processos a produtividade no se mostrou prejudicada.





Grfico 4. Resultados da questo 2.


Questo 3. A documentao gerada auxiliou no seu trabalho ?
Uma das preocupaes com relao a melhoria do processo se deve ao fato do excesso
de documentao. Nessa questo, assim como na questo 13, percebe-se que a documentao
no afetou negativamente no trabalho da equipe. 87% concordaram que a documentao
gerada auxilio no trabalho, apenas 13% acreditam ser indiferente.






Grfico 5. Resultados da questo 3.

0% 0%
13%
49%
38%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0% 0%
75%
25%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
154
Questo 4. A comunicao da equipe foi mais intensa e eficiente ?
Como ponto chave de qualquer projeto, a comunicao deve ser avaliada e em um
programa de melhoria deve ser levada em considerao. Para essa questo, 62% concordam
totalmente para o fato da comunicao da equipe ter sido eficiente. Isso se deve ao fato do
modelo de referncia proporcionar reunies dirias, rpidas e objetivas.






Grfico 6. Resultados da questo 4.


Questo 5. O projeto foi executado com base em prazos mais realistas ?
As estimativas para horas de projeto representam um dos principais fatores de
conflitos entre cliente e fornecedor e entre os membros da equipe. Com o modelo
institucionalizado, o processo de gerncia de projetos preza pelo uso de tcnicas para
estimativas que na viso da equipe se mostrou satisfatria visto que 87% responderam
concordar ou concordar totalmente com a questo 5.





Grfico 7. Resultados da questo 5

0% 0% 0%
38%
62%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0%
13%
62%
25%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
155
Questo 6. Voc precisou trabalhar mais de 40 horas semanais com freqncia ?
Nenhum dos membros do projeto necessitou trabalhar, com freqncia, mais de 40
horas semanais com freqncia o que mostra um controle maior das atividades e uma
estimativa mais realista das tarefas executadas, ou seja, o tempo passou a ser melhor
considerado. No se administra Tempo que absoluto, mas as tarefas ao longo do tempo.





Grfico 8. Resultados da questo 6.

Questo 7. A qualidade do produto final foi melhor que projetos anteriores ?
Quanto a questo da qualidade do produto desenvolvido, 74% concordaram totalmente
com o fato da qualidade do produto ter sido melhor que de projetos anteriores, 13%
concordaram e 13% disseram ter sido indiferente. Considerando a qualidade do produto final
a conseqncia de um processo maduro, pode-se entender que o processo de desenvolvimento
ganhou maturidade e que poder ser melhorado ao longo de suas sucessivas aplicaes
(curvas de aprendizagem).





Grfico 9. Resultados da questo 7.

62%
38%
0% 0% 0%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0%
13%
74%
13%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
156
Questo 8. A consulta aos documentos do projeto foi facilitada com o uso do
SharePoint?

Aps a disponibilizao dos documentos na ferramenta SharePoint todos os membros
tiveram permisso de acesso, facilitando a consulta. Nesta questo, 13% dos membros
discordaram com o fato da ferramenta ter auxiliado, todos os outros julgam que a consulta aos
documentos, facilitou seu trabalho.






Grfico 10. Resultados da questo 8.

Questo 9. Existe maior preciso no controle das suas atividades ?
49 % da equipe concordam totalmente que neste projetos existiu um maior controle
sobre as suas atividades desempenhadas, isto se deve ao fato da gerncia ter sido mais atuante.
38 % concordam e 13 % acharam indiferente.






Grfico 11. Resultados da questo 9.

0%
13%
25%
62%
0%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0%
13%
49%
38%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
157
Questo 10. As atividades que voc executou foram passadas de forma mais clara ?
Para esta questo, 100% da equipe concordou que as atividades aps terem sido
definidas, foram passadas de forma mais clara. Os fatores que auxiliaram nesse quesito so:
1) reunio no incio do projeto para definio de papis e responsabilidades.
2) uso do Trac System que submete a cada desenvolvedor suas tarefas.






Grfico 12. Resultados da questo 10.



Questo 11. Os papis e responsabilidades de cada membro do projeto esto melhor
definidos ?

Assim como na pergunta anterior, 100% dos membros responderam concordar que as
responsabilidades foram melhor definidas. Neste modelo de referncia existe uma reunio
inicial onde cada membro recebe e assume suas funes, da qual lavrada ata, na qual os
participantes concordam e assinam sua participao.





Grfico 13. Resultados da questo 11.
0% 0% 0%
62%
38%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0% 0%
87%
13%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
158
Questo 12. O cliente percebeu as melhorias impostas pela empresa ?
Esta questo apesar de difcil de mensurar, principalmente para os desenvolvedores
que muitas vezes no tem contato com o cliente final se mostrou satisfatria visto que 75%
concordaram que a melhoria foi percebida.







Grfico 14. Resultados da questo 12.

Questo 13. A documentao gerada impossibilitou que seu trabalho fosse mais gil ?
Essa questo complementar a questo 5 que diz respeito a documentao gerada e
exigida. Porm, perguntada de forma invertida. 75 % dos membros discordaram que a
documentao foi um empecilho e 25 % disseram ser indiferente.






Grfico 15. Resultados da questo 13.


0% 0%
25%
50%
25%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
13%
62%
25%
0% 0%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
159
Questo 14. O fato de existir uma equipe de qualidade inspecionando seu trabalho
aumentou a qualidade do(s) produto(s) que voc gerou ?

A grande maioria (87%) acreditam que a equipe de qualidade fundamental para a
qualidade do processo e do produto. Apenas 13% acreditam ser indiferentes.







Grfico 16. Resultados da questo 14.

Questo 15. O seu nvel de satisfao aumentou aps a implantao do programa de
qualidade ?

Esta questo est mais relacionada ao sentimento que o colaborador tem em relao ao
esforo de se melhorar os processos da empresa e conseqentemente seu trabalho. 75%
concordaram que esse programa afetou positivamente sua satisfao e 25 % se mostraram
indiferentes.





Grfico 17. Resultados da questo 15.

0% 0%
13%
87%
0%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
0% 0%
25%
50%
25%
Discordo totalmente
Discordo
Indiferente
Concordo
Concordo Totalmente
160
Mesmo sendo uma pesquisa qualitativa, pode-se entender que os benefcios alcanados
nesses dois projetos foram satisfatrios para a equipe. Entende-se tambm que outros
benefcios, chamados de intangveis tambm surtiram efeitos, como por exemplo:
Quebra de Paradigma a medida que foram questionados processos vigentes e
colocados sob a tica de melhoria contnua;
Diminuio da reteno do conhecimento com a transmisso do conhecimento para a
organizao;
Alinhamento da organizao: Planejamento Estratgico foi determinado para a
institucionalizao do processo;
Aumento da Capacidade Gerencial da Empresa;
Segurana e credibilidade: obteve-se um aumento de confiana na equipe gerencial;
Necessidade de Visibilidade dos Resultados: implantao de GQA, avaliando os
resultados da real utilizao do processo
















161
6. CONCLUSO

Sendo o desenvolvimento de produto um dos fatores chave para que as organizaes
se mantenham no mercado de forma competitiva, deve-se almejar uma gesto de PDP
(Planejamento e Desenvolvimento de Produto) efetiva. Esta condio indispensvel e exige
que as organizaes tenham condies de garantir que o mesmo seja executado rigorosamente
com qualidade e produtividade (eficincia no processo) e venha a oferecer qualidade no
produto oferecido (eficcia na oferta). A conseqncia direta desta condio, que compem a
estratgia da organizao vencedora a garantia de sua competitividade.
Como apresentado neste trabalho existem desde os anos 90, esforos para auxiliar as
organizaes na busca desse elevado padro de qualidade, porm, todos esse esforos ainda
hoje so insuficientes para pequenas empresas. Percebendo-se esta condio, que tende a
perdurar ainda por algum tempo, surge esta proposta de um modelo referencial caracterstico
para pequenas empresas produtoras de software, composto por atividades, processos e
mtodos prprios as suas especificas condies de operao produtiva.
O modelo proposto e aplicado com sucesso, apoiou-se em modelos de
desenvolvimento de produtos industriais j disponveis, com inovaes capazes de oferecer
solues ao gerenciamento de softwares em pequenas empresas, o que representa uma
significativa contribuio ao assunto, pela abordagem e sistematizao oferecidas.
Como visto, esta pesquisa se justifica pela impossibilidade oferecida pelos atuais
modelos de desenvolvimento de software na garantia de qualidade. Os modelos e frameworks
atuais tm seu foco preponderantemente voltado para a fase de construo e negligenciam
atividades como planejamento estratgico, projeto do produto e descontinuidade do produto, o
que representa um tratamento apenas parcial da questo.
162
Para se chegar a este modelo de referncia, partiu-se inicialmente de uma pesquisa de
campo, na qual, buscou-se conhecer e entender as dificuldades de cinco empresas e os
desafios que enfrentam cotidianamente na criao de seus produtos.
Para esta pesquisa foi utilizado, aps um profundo estudo sobre os mtodos de
avaliao existentes, nascidos de uma reviso bibliogrfica, onde o contexto terico atualizado
proporcionou o uso do questionrio de contextualizao do mtodo MARES, criado por
pesquisadores da UNIVALI e j aplicado em dezenas de avaliaes.
Nesta pesquisa de campo, ficou evidente que todas as cinco organizaes apresentam
caractersticas semelhantes aos relatos bibliogrficos de empresas imaturas. Entre as
caractersticas se destacam a informalidade das aes, esforo herico dos colaboradores, falta
de documentao apropriada, falta de mtodos para estimativas, entre outros. Porm, todas
essas empresas almejam melhorar seus processos, mas no encontram maneira para isso,
devido principalmente a falta de uma estrutura sistematizada que auxilie nessa conquista.
A idealizao desse modelo de referncia para desenvolvimento de software teve
influncia marcante do modelo de desenvolvimento de produto criado em ao conjunta de 3
universidades brasileiras (EESC/USP, UFSCar e UFSC). Esse modelo, j usado em outras
reas de aplicao, foi de fundamental importncia nesta aplicao especfica, pois atravs da
definio de suas fases, atividades e marcos (Gates) auxiliou na criao do modelo proposto
nesta tese.
Com relao a qualidade, o foco esteve direcionado ao modelo de referncia chamado
de MPS.Br (melhoria do processo de software brasileiro), criado em 2004 pela SOFTEX e
que visto atualmente como uma alternativa mais realista para as pequenas empresas se
comparado a norma ISO 12207 e ao modelo CMMi. Atualmente o MPS.Br acha-se
implantado em 104 empresas no Brasil e est sendo expandido para outros pases da Amrica
Latina.
163
O modelo proposto foi utilizado em dois projetos em uma pequena empresa de
tecnologia com o objetivo de servir de base para validar o modelo. Cabe destacar que
qualquer movimento no sentido de melhorar a qualidade nos primeiros esforos facilmente
percebido, porm, a quantificao algo trabalhoso, principalmente por no existir mtodos
especficos difundidos e validados. Optou-se ento pelo o uso de um questionrio com 15
questes que pudessem apresentar, ainda que de forma qualitativa, os resultados.
Os resultados, para as atividades do processo de gerncia de requisitos e gerncia de
projetos, escolhidos como as etapas preponderantes, foram positivos. Entre eles, ficaram
evidentes: agilidade no processo de desenvolvimento, aumento da qualidade dos produtos
gerados, melhor controle das atividades e da aplicao dos recursos, estimativa mais precisa
de tempo e esforo, rapidez na documentao, que uma vez sistematizada passa a ser padro e
serve de base de conhecimento. Outro ponto de destaque que todos os nove entrevistados se
mostraram satisfeitos com o programa de melhoria, uma vez que descreveram no questionrio
palavras positivas, como: excelncia, satisfao, qualidade e melhoria.
Cabe destacar ainda que os dois projetos possuem diferenas quanto ao nmero de
colaboradores envolvidos, escopo do projeto, tempo de durao, entre outros, ou seja o
modelo pode ser aplicvel a diferentes circunstncias conceituais. Definitivamente cada
projeto de software nico devido a uma srie de fatores que incluem desde o tipo de
aplicao a ser construda, necessidades especficas de cada cliente e at restries de
cronograma e recursos. A idealizao do modelo de referncia, desde o princpio, visava a
possibilidade da definio de um nico processo de desenvolvimento de software que fosse
adaptvel a qualquer situao. Sendo assim, os trabalhos tanto na empresa quanto na pesquisa
desta Tese possuem possibilidades reais de continuidade.
Para a empresa em questo fica, a curto prazo, a conquista da certificao do nvel G
do MPS.Br e a mdio e longo prazo a melhoria de outros processos, com avanos que podero
164
ser atingidos em pontos como: testes, homologao, gerncia de configurao, medio,
treinamento, que se mostram possveis de significativas contribuies de melhoria.
A continuidade de aplicao deste modelo e a otimizao decorrente de sua difuso
ensejaro o aparecimento de um modelo referencial padro, de uso universal. Isso ser
atingido pelas contribuies de novas pesquisas e pela integrao de pesquisadores.
Em se tratando de pesquisa existe a possibilidade de aplicao de outros processos
propostos nesse trabalho, que podero ser experimentados e permitiro avaliao da melhoria.
Como conseqncia, sua adoo ensejar a aplicao referencial para que as pequenas
empresas venham a amadurecer seu processo de desenvolvimento e consolidar sua atuao
aos mais elevados patamares de competitividade, o que muito significativo pois, fortalecer
um universo de cerca de 1800 empresas existentes no Brasil.
Oferece-se assim, um modelo de referncia vlido para aplicao disciplinada em
pequenas empresas produtoras de software, no caso brasileiro.











165
REFERNCIAS BIBLIOGRFICAS


ABNT. Associao Brasileira de Normas Tcnicas. NBR ISO 9000:2000 Sistemas de
gesto da qualidade e garantia da qualidade Fundamentos e Vocabulrio. Rio de
Janeiro: ABNT, 2000.

______. Associao Brasileira de Normas Tcnicas. NBR 14724: Informao e
Documentao - Trabalhos acadmicos - Apresentao. Rio de Janeiro: ABNT, 2001.

ABES. Mercado Brasileiro de Software: panorama e tendncias, 1
o
edio. Associao
Brasileira das Empresas de Software. So Paulo, 2007.

ANACLETO, A. et al. A Method for Process Assessment in Small Software Companies.
Proc. 4th Int'l Software Process Improvement and Capability Determination Conf. (SPICE
04), SPICE User Group and Critical Software SA, 2004.
BARBALHO, S. C. M. Modelo de Referncia para Desenvolvimento de Produto
Mecatrnicos: proposta e aplicaes. 2006. 256f. Tese (Doutorado em Engenharia Mecnica)
Escola de Engenharia de So Carlos. Universidade de So Paulo, So Carlos, 2006.
BARBALHO, S. C. M. e ROZENFELD, H. Anlise do processo de desenvolvimento de
produtos de uma pequena empresa de alta tecnologia. Anais do XXIV Encontro Nacional
de Engenharia de Produo, 2004, Florianpolis. Associao Brasileira de Engenharia de
Produo, Novembro, 2004.
BECK, K.; ANDRES, C. Extreme programming explained: Embrace change. Second
Edition, Addison Wesley Professional, 2004.
BOEHM, B. W. A spiral model of software development and enhancement.
ACM Software Engineering Notes, v. 11, 1988.

BOOCH G.; RUMBAUGH J.; JACOBSON I. The Unified Modeling Language User
Guide, Second Edition. Addison-Wesley, 2005.

BRANDO, C. R. Repensando a Pesquisa Participante, 2
o
Edio, Editora Brasiliense, So
Paulo. 1985.

COOPER, R. G. Winning At New Products: Accelerating The Process From Idea To
Launch, Second Edition, Basic Books. 1993.

COLELLA, L. C. COLENCI NETO, A. VALENTE, J. F. BIANCHI, R. E. Uso da tecnologia
de identificao por rdio freqncia (RFID). Anais do XV Simpep Simpsio de
Engenharia de Produo. UNESP. Bauru. 2008.

COUTO, A. B. CMMI Integrao dos modelos de capacitao e maturidade de
sistemas. Rio de Janeiro: Cincia Moderna, 276 p. 2007.

166
CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for Process Integration
and Product Improvement. Pensilvnia, EUA: SEI Software Engineering Institute Addison-
Wesley. 2003.

CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy,
organization and management in the world auto industry. Boston, Mass.: Harvard
Business School Press. 1991.

CMMI-DEV. CMMI for Development. Carnegie Mellon University. Software Engineering
Institute. Version 1.2, 2006.

COCHANGO, Scrum for team systems, http://www.scrumforteamsystem.com. Acesso em
otubro de 2006.

DEMO, P. Pesquisa e construo do conhecimento: metodologia cientfica no caminho de
Habermas. 2
o
Edio, Tempo Brasileiro, Rio de Janeiro, 125p, 1994,

DRUCKER, P. Uma era de descontinuidade: orientao para uma era de mudana. So
Paulo. Crculo do Livro. 1968

FERNADES, A. A. Fbrica de Software: implantao e gesto de operaes. 1
o
Edio.
Atlas. So Paulo, 304p, 2004.

FIORINI, S. T., et al. Engenharia de Software com CMM, 1
o
Edio, Ed. Brasport, Rio de
Janeiro, 1998.

FOWLER, M. The New Methodology. Disponvel em
http://www.martinfowler.com/articles/newMethodology.html. 2005. Acessado em maio de
2006.

GIL, A. C. Como elaborar projetos de pesquisa. 3
o
edio, Atlas, So Paulo, 2001.

HUMPHREY, W. Managing the software process. SEI/CMU Addison Wesley publishing.
Boston, 1989.

JEFFRIES, R. et al. Extreme Programming Installed. EUA, Addison-Wesley. 2001.

KAMINSKI, P. C., et al. Evaluation of the real use of formal methodologies in the
product development process in brazilian SMEs. Product: Management & Development
- Revista Brasileira de Gesto de Desenvolvimento de Produto, v.3, n.2, So Carlos - SP,
2005.

KAPLAN R. S., NORTON D.P. Estratgia em Ao: Balanced Score Card. 21
o
Edio,
Editora Campus, Rio de Janeiro RJ. 1997.

KOHAN, S. QuickLocus: Proposta de um mtodo de avaliao de processo de
desenvolvimento de software em pequenas organizaes. 2003. Dissertao (Mestrado em
Engenharia de Computao). Instituto de Pesquisas Tecnolgicas do Estado de So Paulo
IPT, So Paulo, 2003.

167
KRUCHTEN, P. The Rational Unified Process: An Introduction, 3
th
Edition. Addison
Wesley. 2003.

MACHADO, C. A. F. in WEBER, K. C., et al. Qualidade e Produtividade em Software, 4
a

edio, So Paulo, Ed. Makron Books, 2001.

MAGALHAES, A. L. C. C, ROUIILER, A. C., VASCONCELOS, A. M. L. O
Gerenciamento de projetos de software desenvolvido luz das metodologias geis: uma
viso comparativa. PROQUALITY Qualidade na produo de software, v. 1, n. 1. 2005.

MCT. Qualificao CMM e CMMI no Brasil. Disponvel em:
www.mct.gov.br/upd_blob/0009/9238.pdf. Acessado em: Setembro de 2007.

_______. Pesquisa Qualidade e Produtividade no Setor de Software Brasileiro. Braslia:
Ministrio da Cincia e Tecnologia - MCT/SEPIN, 2005.

MIT. Slicing the Knowledge-Based Economy (KBE) in India, China and Brasil: a Tale of
Three Software Industries. Massachussets Institute of Technology. Cambridge, 2003.

MPS - Melhoria de Processo do Software Brasileiro: Guia Geral. Verso 1.2. Campinas:
SOFTEX, 2007.

MA-MPS - Melhoria de Processo do Software Brasileiro: Guia de Avaliao. Verso 1.1.
Campinas: SOFTEX, 2006.

MOPORSOFT. Modelo de Procesos para la Industria de Software Verso 1.3. Cidad del
Mxico. Agosto 2005.

____________. Software Industry Process Model.. Verso 1.3.2. Cidad del Mxico. April
2006.

NAKANO, D. N.; Fleury, A. C. C. Mtodos de Pesquisa na Engenharia de Produo. In;:
XVI ENEGEP Encontro Nacional de Engenharia de Produo, Anais. Piracicaba:
UNIMEP/ABEPRO. 1996 (CD ROM).
NBR ISO/ABNT, Associao Brasileira de Normas Tcnicas. Normas NBR/ISO 8402. Rio
de Janeiro, 1994.
NOGUEIRA, M. Qual a Importncia da adoo da Norma ISO 12207 nas Empresas de
Desenvolvimento de Software ? X Simpsio de Engenharia de Produo, Anais. Bauru:
Simpep. 2003

PAULK M. C. Capability Maturity Model: Guidelines for Improving the Software
Process. Addison-Wesley, 1995.

_____________. Using the Software CMM in Small Organizations. Software Engineering
Institute, CMU, Report. 1998.

_____________. Extreme Programming from a CMM Perspective. IEEE SOFTWARE,
november/december, Vol. 18, Publishing Press, p. 1-8. 2001.
168

PENSO, C. C. Modelo de referncia para processo de desenvolvimento de produto na
indstria de alimentos. 2003. 180f. Dissertao (Mestrado em Engenharia Mecnica)
Universidade Federal de Santa Catarina (UFSC), Florianpolis SC, 2003.

PFLEEGER S. L. Engenharia de Software: Teoria e Prtica. 2
o
Edio. So Paulo, Prentice
Hall, 2004.

PINTO, F. (2006). Comparao do MPS.Br com o CMMI. Disponvel em:
http://www.pontodatecnologia.com.br/2006/08/comparao-do-mpsbr-com-o-cmmi.html.
Acessado em 30 jan 2007.

PMBOK. A Guide to the Project Management Body of Knowledge. 2000 Edition, Project
Management Institute (PMI

) 2000.

PORTER, M. E. Estratgia competitiva. 16. ed. Rio de Janeiro: Editora Campus, 2004.

PRESSMAN, R. S. Software Engineering: A practitioners approach. 6
th
. ed. McGraw-
Hill, 2005.

PUGH, S. Total Design: integrated methods for successful product engineering.
Wokingham, Addison Wesley. 1990.

ROYCE, W. W., Managing the Development of Large Software Systems: concepts and
techniques, Los Angeles, Proceedings, IEEE Wescon, 1970.

ROZENFELD, H. et al. Gesto de Desenvolvimento de Produto. 1
o
Edio, So Paulo; SP.
Editora Saraiva, 2006.

ROMANO, L. N. Modelo de referncia para o processo de desenvolvimento de mquinas
agrcolas. 2003. 285f. Tese (Doutorado em Engenharia Mecnica) Universidade Federal de
Santa Catarina. Florianpolis (UFSC), Florianpolis SC, 2003.

SALVIANO, C. F. ANACLETO, A. WANGENHEIM, C. G. Avaliao de processos para
incio de programas de melhoria em micro e pequenas empresas de software. VI
Simpsio internacional de melhoria de processo de software. So Paulo, Brasil, novembro de
2004.

SCHMITZ E. A., ALENCAR A. J. VILLAR, C. B. Modelos Qualitativos de Anlise de
Risco para Projetos de Tecnologia da Informao. 1 edio, Brasport. 196 p. 2007

SCHWABER, K.; BEEDLE, M.. Agile Software Development with SCRUM. Prentice Hall,
2002.

SEBRAE. Inaugura a Casa do Empreendedor. Jornal de Negcios. So Paulo: SEBRAE, ano
VII, n.70, dez, 1998.

SEI - Software Engineering Institute. What is CMMI ? (Capability Maturity Model
Integration) Disponvel em: http://www.sei.cmu.edu/cmmi, acessado em maio de 2007.

169
SILVA, E. L. Metodologia da pesquisa e elaborao de dissertao. 3
o
Ed. - Florianpolis:
Laboratrio de Ensino a Distncia da UFSC, 2001.

SOMMERVILLE, I. Software Engineering. 6
th
. ed. Addison-Wesley, 2003.

SPINOLA, M. M., Diretrizes para o desenvolvimento de software de sistemas embutidos,
1999, Tese (Doutorado em Engenharia Eltrica), Universidade de So Paulo - So Paulo,
1999.

STANDISH - The Standish Group. Chaos Demographics and Project Resolution. 2004
Disponvel em: <http://www.standishgroup.com/sample_research/PDFpages/q3-
spotlight.pdf> Acesso em: 24 mar. 2008.

TELES, V. M. Extreme programming: aprenda como encantar seus usurios
desenvolvendo software com agilidade e alta qualidade. 1
o
Edio. So Paulo SP,
Novatec Editora, 2004.

THIOLLENT, M. Metodologia da Pesquisa-ao. 4 edio, So Paulo, Editora Cortez,
1988. 108p.

VERNADAT, F. B. Enterprise modeling and integration: principles and applications. 1
th
,
Chapman e Hall, London, UK, 1996.

WANGENHEIM, C. G. et al.. Aplicando Avaliaes de Contextualizao em Processos de
Software Alinhados ao CMMI-SE/SW. VII Simpsio Internacional de Melhoria de
Processos de Software. So Paulo/SP. 2005

________________________. Helping Small Companies Assess Software Processes, IEEE
SOFTWARE, Vol. 23, Issue 1, Page(s): 91 98. Jan.-Feb. 2006.

WANGENHEIM, C. G., SALVIANO, C. Consolidao de uma metodologia para
avaliao de processos de software de MPEs baseada na norma ISO/IEC 15504. Anais do
Simpsio Brasileiro de Qualidade de Software - SBQS. Porto Alegre, Brasil, 2005.

WEBER. K. C. et al. Brazilian Software Process Reference Model and assessment
method, Computer and information sciences - ISCIS 2005. Berlin, Germany.














170





Anexo I

Questionrio de Avaliao







































171



Questionrio de Caracterizao de Empresa para Avaliao
ISO/IEC 15504
baseado no Mtodo MARES/15504MPE (LQPS/UNIVALI e CenPRA)

A resposta a este questionrio faz parte da Fase 1 da avaliao para a melhoria da qualidade dos processos de
software.
A qualidade das respostas deste questionrio fundamental para o xito deste trabalho. Assim, a empresa deve
se comprometer a disponibilizar tempo adequado para que representantes da diretoria forneam as informaes
solicitadas de forma precisa.
Como em todas as atividades de obteno de informaes, esta atividade segue o compromisso de confidencialidade
assinado pelo Patrocinador e pela Equipe de Avaliao.
As respostas deste questionrio sero utilizadas para alinhar a avaliao com o contexto e os objetivos de
negcio da organizao.
A avaliao no tratar necessariamente de todos os aspectos abordados no questionrio. Portanto, o
participante no deve esperar que todas as suas respostas tenham uma ao neste projeto e nem que aquelas
que induzirem a uma ao sejam de curto prazo.
O tempo mdio de preenchimento deste questionrio de uma hora, podendo variar de uma empresa para
outra. No final do questionrio solicitado o tempo gasto com o preenchimento do mesmo para fins de
avaliao do mtodo utilizado.

Agradecemos a sua colaborao.
1. Caracterizao da Organizao
1.1 Razo Social:
1.2 Contato:
1.3 Endereo:
1.4 E-mail:
1.5 Telefone:
1.6 Website:
1.7 Incio das atividades em informtica:
1.8 Breve descrio da empresa:




1.9 Principal atividade da organizao no desenvolvimento de software:
Desenvolve software sob encomenda para terceiros (para cada cliente um software individual desenvolvido
para os requisitos especficos deste cliente)
Desenvolve software-padro sem customizao (software pacote)
Desenvolve software-padro com customizao para clientes (software que atende as necessidades de muitos
clientes mas que geralmente ainda adaptado para satisfazer completamente os requisitos especficos de um
cliente)
Outra: __________________________________________

1.10 Principal atividade da organizao em Tecnologia da Informao:
172
Comercializao de dados ou de bases de dados
Consultoria e projetos em informtica
Desenvolvimento de software
Distribuio ou editorao de software de terceiros
Distribuio ou revenda de produtos de hardware
Indstria de informtica, telecomunicao ou automao
Manuteno e assistncia tcnica em informtica
Provedor Internet
Servios de automao bancria
Servios de automao comercial
Servios de automao industrial
Servios de entrada de dados
Servios de processamento de dados
Treinamento em informtica
Outras. Especifique: ___________________________________________

1.11 Fora de trabalho da organizao:
(como total da fora de trabalho da organizao considere scios, dirigentes, empregados/funcionrios efetivos,
incluindo terceiros prestadores de servio, bolsistas e estagirios)
Scios, dirigentes e empregados efetivos ____
Bolsistas e estagirios ____
Terceiros prestadores de servio ____
Total ____

1.12 Organograma da empresa:














1.13 Porte da empresa segundo comercializao bruta anual:
At R$ 120 mil
De R$ 120 mil at R$ 720 mil
De R$ R$ 720 mil at R$ 2,5 milhes
Mais de R$ 2,5 milhes

1.14 Indique o nvel de crescimento que mais se assemelha a sua empresa atualmente:
Pr empresa a organizao caracterizada mais como um projeto (em pr-incubadoras, etc) do que
propriamente uma empresa.
Existncia o principal objetivo da empresa encontrar clientes e vender produtos para viabilizar o seu
negcio.
Sobrevivncia a empresa j mostrou ser vivel. Os principais objetivos so manter/buscar clientes para que
o fluxo de caixa permita a empresa crescer e gerar lucro.
Crescimento a empresa se consolidou e tem recursos para crescer.
1.15 Faixa de mercado (mais de um item pode ser marcado):
Atende a uma faixa de mercado que no enfocada pelas grandes empresas.
173
Produz componentes para suprir s empresas de mdio e grande porte.
Inicia o desenvolvimento de novos produtos inovadores.
Presta servios e manuteno para os produtos fabricados por grandes empresas.
Outra: ________________________________________________________________________

1.16 A organizao implantou programa da qualidade total, sistema da qualidade ou similar?
Sim. Em que ano? ___________
Em estudo ou implantao
No

1.17 Qual o tipo de certificao obtida?
Certificado IS0 9001
Certificado por cliente. Especifique: ________________________________________________
Certificado CMM/CMMI. Em que nvel?______
Outras certificaes. Especifique: __________________________________________________
Profissionais certificados (PMP, Microsoft, etc.). Especifique: ____________________________
No h nenhuma certificao

1.18 Relate at trs principais oportunidades de negcio para a organizao (fatores internos ou externos
que podem abrir, ampliar ou melhorar o mercado da organizao):






1.19 Relate at trs principais ameaas organizao (fatores internos ou externos que podem
atrapalhar ou mesmo inviabilizar a organizao):

















174
P
R
O
D
U
T
O
/
P
R
O
J
E
T
O

1

2.3 Breve descrio do produto/projeto:




2.4 Quais so as principais funcionalidades do produto/projeto:



2.5 Quem so os principais usurios do produto/projeto:



2.6 Tecnologias utilizadas no desenvolvimento do produto/projeto:



2.7 O software customizvel? Sim No
2.8 Sua empresa faz manuteno do software? Sim No
2.9 Quem responsvel pela instalao do software? A empresa O cliente
2.10 Sua empresa presta suporte aos clientes do software? Sim No
2.11 Qual a freqncia em que novos releases do software so gerados? (p.ex. 1 vez por ano)


2.12 Durao (mdia) dos projetos de software: __________ meses.
2.13 Tamanho (mdio) da equipe de projeto: __________ pessoas.
2.14 Tamanho aproximado do software: (p.ex. em Linhas de cdigo, Pontos por Funo, etc):


2.15 Complexidade do software:
alta: muitos algoritmos e clculos difceis, elementos e relaes de dados muitos complexos
mdia: alguns algoritmos e clculos difceis, vrios arquivos e interaes dos dados
baixa: maioria dos algoritmos e clculos simples, dados simples, poucas variveis
2.16 Aspectos de qualidade relevantes para o software: Crucial (C), Importante (I), Desejvel (D),
No Importante (N)
Confiabilidade(Capacidade do sw manter o seu nvel de desempenho dentro de condies
estabelecidas por um dado perodo de tempo.)
Usabilidade (Facilidade de uso e avaliao das caractersticas dos usurios do sw.)
Eficincia (Relao entre o nvel de desempenho do sw e a quantidade de recursos utilizados em
determinadas condies.)
Manutenibilidade (Esforo necessrio para executar modificaes especficas.)
Portabilidade (Facilidade do sw ser transferido de um ambiente para outro.)
Funcionalidade (O sw tem funes para satisfazer as necessidades explcitas e implcitas.)
Testabilidade (Capacidade de realizar testes no software)
Reusabilidade (Capacidade de reutilizar cdigo)
Outro:_________________________________
175
P
R
O
D
U
T
O
/
P
R
O
J
E
T
O

2

2.3 Breve descrio do produto/projeto:




2.4 Quais so as principais funcionalidades do produto/projeto:



2.5 Quem so os principais usurios do produto/projeto:



2.6 Tecnologias utilizadas no desenvolvimento do produto/projeto:



2.7 O software customizvel? Sim No
2.8 Sua empresa faz manuteno do software? Sim No
2.9 Quem responsvel pela instalao do software? A empresa O cliente
2.10 Sua empresa presta suporte aos clientes do software? Sim No
2.11 Qual a freqncia em que novos releases do software so gerados? (p.ex. 1 vez por ano)


2.12 Durao (mdia) dos projetos de software: __________ meses.
2.13 Tamanho (mdio) da equipe de projeto: __________ pessoas.
2.14 Tamanho aproximado do software: (p.ex. em Linhas de cdigo, Pontos por Funo, etc):


2.13 Complexidade do software:
alta: muitos algoritmos e clculos difceis, elementos e relaes de dados muitos complexos
mdia: alguns algoritmos e clculos difceis, vrios arquivos e interaes dos dados
baixa: maioria dos algoritmos e clculos simples, dados simples, poucas variveis
2.14 Aspectos de qualidade relevantes para o software: Crucial (C), Importante (I), Desejvel (D), No
Importante (N)
Confiabilidade (Capacidade do sw manter o seu nvel de desempenho dentro de condies
estabelecidas por um dado perodo de tempo.)
Usabilidade (Facilidade de uso e avaliao das caractersticas dos usurios do sw.)
Eficincia (Relao entre o nvel de desempenho do sw e a quantidade de recursos utilizados em
determinadas condies.)
Manutenibilidade (Esforo necessrio para executar modificaes especficas.)
Portabilidade (Facilidade do sw ser transferido de um ambiente para outro.)
Funcionalidade (O sw tem funes para satisfazer as necessidades explcitas e implcitas.)
Testabilidade (Capacidade de realizar testes no software)
Reusabilidade (Capacidade de reutilizar cdigo)
176
3. Qualidade dos Processos de Software
3.1 A maioria dos funcionrios da empresa conhece a norma ISO/IEC 15504 (SPICE)?
Sim No
3.4 Documentao Adotada:
Acompanhamento de custos
Acompanhamento de prazos
Contratos e acordos
Descrio do produto para comercializao
Documentao de marketing
Documentao de programas
Documentao do processo de software
Documentao no cdigo
Especificao do sistema
Guia de instalao
Help on-line
Histrico do projeto

Identificao de risco
Manual de treinamento
Manual do sistema
Manual do usurio
Plano de contingncia
Plano de controle da qualidade
Plano de testes
Projeto do sistema
Registro formal de revises e testes
Relatrio de teste
Outras. Especifique: __________________
No adota documentao

3.8 Cite os trs pontos mais fortes no desenvolvimento de software que voc observa na sua empresa:



3.9 Cite os trs pontos mais fracos no desenvolvimento de software que voc observa na sua empresa:



3.10 Como voc caracteriza sua organizao hoje, quanto aos aspectos relacionados a seguir:
Bom Mdio Ruim No sabe
Satisfao do cliente no atendimento s suas reais necessidades
Tratar as solicitaes de alterao dos requisitos
Cumprir os prazos estabelecidos
Cumprir o oramento/custos estabelecidos
Cumprir os requisitos estabelecidos
Qualidade do produto entregue
Produtividade no processo de software
Satisfao dos funcionrios no trabalho

3.11 Selecione na tabela abaixo a meta de negcio mais importante para a sua empresa.
Metas de Negcio Import
ante
Comentrios
Expandir faixa no mercado (aumentar vendas aos clientes j
existentes, entrar em novos segmentes do mercado, exportar, etc.)

Aumentar competitividade
Aumentar valor de negcio associado ao produto ou servio de sw
Melhorar satisfao dos clientes
Melhorar satisfao dos funcionrios
Outro:




177

3.12 Em relao pergunta anterior, o que se pretende melhorar para satisfazer estas metas de negcio?
Selecione na tabela abaixo as 2 metas de melhoria mais importantes para a sua empresa.
Metas de Melhoria Import
ante
Comentrios
Aumentar produtividade no processo de software
Reduzir custos
Reduzir tempo de desenvolvimento, instalao, manuteno, etc.
Melhorar habilidade em cumprir os custos estabelecidos

Melhorar habilidade em cumprir os prazos estabelecidos
Melhorar habilidade de atender as necessidades reais dos clientes
Melhorar a qualidade do produto de software
Especifique: confiabilidade, portabilidade,
eficincia, manutenibilidade, usabilidade,
reusabilidade, etc.
Obter certificao ISO 9000
Obter certificao CMMI nvel ____
Outro:
4. Questionrio
Data do preenchimento deste questionrio:
Responsvel pelo preenchimento:
Cargo:
Tempo gasto com o preenchimento do questionrio (em horas):




























178




Anexo II

Formulrio de Avaliao das Melhorias do Processo



































179
Avaliao do Processo
Data: ___/ ___/ ___
Escreva duas palavras que melhor representam o programa de melhoria como um todo:

Grau de comprometimento no projeto: [ ] Baixo [ ] Mdio [ ] Alto


1 - Discordo Totalmente / 2- Discordo / 3- Indiferente / 4- Concordo / 5- Concordo Totalmente
Peso
Questo
1 2 3 4 5
1) Houve melhoria na execuo do projeto aps a implantao dos processos ?
2) Houve agilidade no tempo de produo de software ?
3) A documentao gerada auxiliou no seu trabalho ?
4) A comunicao da equipe foi mais intensa e eficiente ?
5) O projeto foi executado com base em prazos mais realistas ?
6) Voc precisou trabalhar mais de 40 horas semanais com freqncia ?
7) A qualidade do produto final foi melhor que projetos anteriores ?
8) A consulta aos documentos do projeto foi facilitada com o uso do SharePoint ?
9) Existe maior preciso no controle das suas atividades ?
10) As atividades que voc executou foram passadas de forma mais clara ?
11) Os papis e responsabilidades de cada membro do projeto esto melhor definidos ?
12) O cliente percebeu as melhorias impostas pela empresa ?
13) A documentao gerada impossibilitou que seu trabalho fosse mais gil ?
14) O fato de existir uma equipe de qualidade inspecionando seu trabalho aumentou a
qualidade do(s) produto(s) que voc gerou ?
15) O seu nvel de satisfao aumentou aps a implantao do programa de qualidade ?


Descreva suas impresses sobre o programa de qualidade: