UNIP INTERATIVA

Projeto Integrado Multidisciplinar VIII

Curso Superior de Gesto de Tecnologia da Informao

SERVIO DE CONSULTORIA
Cliente: Empresa Software Developer

POLO FERNO GAIVOTA

2010

Paulo Joaquim do Canto

RA: 0906384
Curso Gesto de Tecnologia da Informao
Semestre: 4

SERVIO DE CONSULTORIA
Cliente: Empresa Software Developer

Relatrio apresentado como Projeto Integrado

Multidisciplinar VIII com requisito parcial para
obteno de mdia bimestral

Orientador: Adriane Paulieli Colossetti

________________________________
________________________________

POLO FERNO GAIVOTA

2010

Resumo
Tendo como objetivo principal da certificao CMMI-DEV de nvel dois,
pretende-se aumentar a produtividade e a qualidade. Utilizando as metodologias
mais avanadas ser possvel desenvolver aplicaes de software de uma forma
mais eficiente e com nveis mais elevados de produtividade. Em relao qualidade,
temos em vista responder de forma mais eficaz e eficiente aos clientes, entendendose aqui a qualidade como sinnimo daquilo que totalmente adequado ao uso final
dos softwares desenvolvidos ou s expectativas dos utilizadores.
A adoo do CMMI-DEV e correspondente certificao implicam que sejam
seguidos padres de atuao mais exigentes, decorrentes de boas prticas
internacionais. Estes padres devero, em ltima anlise, aumentar a produtividade
das equipes de desenvolvimento e a qualidade do software que desenvolvido. Um
dos problemas comuns na atividade de desenvolvimento de software so os prazos
e os custos. A adoo da metodologia CMMI-DEV permite disciplinar todo o
processo de desenvolvimento, de modo a que decorra dentro dos prazos e dos
custos inicialmente previstos.
Por outro lado, como so seguidos padres de trabalho idnticos em qualquer
projeto, pretende-se aumentar a previsibilidade do resultado final e evitar o risco de
desenvolver produtos inadequados s necessidades do cliente, com a conseqente
perda de dinheiro e de tempo. No entanto, isto tambm implica mudanas na forma
de trabalhar e na cultura da prpria empresa. No caso concreto da Software
Developer, passou-se de uma organizao orientada essencialmente por funes,
para uma orientao a processos e projetos.

Palavras chave: Certificao CMMI-DEV, Metodologia, Processos

Abstract

With the main objective of CMMI-DEV level two, we intend to increase

productivity and quality. Using the most advanced methodologies will be possible to
develop software applications more efficiently and with higher levels of productivity.
Regarding quality, we aim to respond more effectively and efficiently to customers, it
being understood here as synonymous with the quality of what is entirely appropriate
to end use of software developed or the expectations of users.
The adoption of CMMI-DEV certification and corresponding mean that they are
followed more demanding performance standards, derived from international best
practices. These standards must, ultimately, increase productivity of development
teams and software quality that is developed. One of the common problems in
software development activities are the timelines and costs. The adoption of the
CMMI-DEV methodology allows discipline throughout the development process, so
that takes place within the time and cost originally anticipated.
Moreover, as they are followed identical patterns of work in any project, we
intend to increase the predictability of its outcome and avoid the risk of developing
inappropriate products to customer needs, with the consequent loss of money and
time. However, this also implies changes in the way of working and culture of the
company. In the case of Software Developer, went from an organization focused
essentially functions, to an orientation to processes and projects.

Keywords: CMMI-DEV Certification, Methodology, Process

Sumrio
1. Introduo .......................................................................................................... 08
2. Descrio da Software Developer ....................................................................... 08
3. Objetivos dos trabalhos da Consulting ................................................................ 10
4. A utilizao do CMMI-DEV ................................................................................... 10
4.1. Instituticionalizao do CMMI-DEV.......................................................... 11
5. Termo de Inicio do Projeto.................................................................................... 14
I.

Projeto ............................................................................................................ 14

II.

Objetivo do Projeto ........................................................................................ 14

III.

Nome do gerente do projeto, suas responsabilidades e sua autoridade....... 14

IV.

Necessidades bsicas do trabalho a ser realizado........................................ 15

V.

Descrio do Projeto ...................................................................................... 15

VI.

1.

Produto do Projeto..................................................................... 16

2.

Cronograma bsico do Projeto.................................................. 17

3.

Estimativas iniciais de custos.................................................... 17

Administrao ................................................................................................ 18
1.

Necessidade inicial de recursos ............................................... 18

2.

Desenvolvendo o software ....................................................... 20

3.

Controle e gerenciamento das informaes do projeto ............ 21

VII.

Plano de Riscos ............................................................................................. 22

VIII.

Gerenciamento de Comunicao .................................................................. 26

IX.

Sugestes ...................................................................................................... 26

X.

Encerramento do Projeto .............................................................................. 27

XI.

Aprovaes .................................................................................................... 28

6. Concluso ............................................................................................................ 29
7. Referncias .................................................................................,....................... 30
8. Glossrio ............................................................................................................. 32

Lista de Figuras
Figura 1 Nvel de Maturidade do Modelo CMMI..................................................... 09
Figura 2 Institucionalizao do CMMI ................................................................... 12
Figura 3 Organograma da Software Developer...................................................... 18
Tabela 1 Acompanhamento do Projeto.................................................................. 21
Tabela 2 Ocorrncia de Riscos ............................................................................. 24
Tabela 3 Gerenciamento de Comunicao ........................................................... 26

1. Introduo
Este um projeto para a implantao da melhoria de processos de
desenvolvimento de software, atravs do CMMI-DEV, sendo uma tarefa que exige
conhecimento sobre a abordagem adotada, comprometimento, envolvimento e
disponibilidade das pessoas envolvidas no projeto, principalmente daqueles que o
coordenam. So exigidas destas pessoas, habilidades para motivar, treinar, orientar,
sugerir tcnicas e procedimentos etc., bem como analisar os desvios que implicam
na no aderncia de um processo s metas e prticas impostas pelo CMMI-DEV. O
CMMI-DEV um modelo de referncia que fornece direcionamento para as prticas
a serem seguidas em um processo de desenvolvimento de software.
O principal objetivo foi realizar um planejamento para a construo de um
processo consistente e maduro baseado nas metas e prticas do CMMI-DEV nvel 2,
utilizando as recomendaes do PMBOK, focando-se na mitigao dos riscos do
projeto, no cumprimento dos prazos e no alcance da qualidade dos servios a serem
executados. Com isto, foi realizada a criao de um estudo de caso baseado em um
cenrio tpico de processo ad hoc de trabalho e nos problemas inerentes da
empresa Software Developer que se encontra no nvel catico de maturidade em
processo de desenvolvimento de software e que pretende obter a certificao CMMIDEV nvel 2. Este trabalho objetivou tambm realizar a identificao de riscos do
projeto e um planejamento para sua mitigao ou contingenciamento; a realizao
de estimativas de custos e de esforo para execuo do projeto; a determinao de
critrios para o sucesso do projeto; a especificao de recursos necessrios para as
atividades do projeto; a criao e definio de demais produtos de trabalho que
possam facilitar o planejamento e o controle do projeto etc.

2. Descrio da Software Developer

A Software Developer uma empresa sediada em So Paulo, SP, cujo foco
do negcio o desenvolvimento de pacotes de software voltados para rgos do
sistema financeiro.

Sua estratgia de longo prazo a insero nesse mercado

atravs do desenvolvimento de softwares para o segmento.

Compe este produto ferramentas de Sistema de Consrcio, Sistema de

Financiamento e Sistema para Emprstimo.
A empresa enfrenta problemas na rea de desenvolvimento de
software, causados pela m gesto das mudanas dos requisitos e das
necessidades dos clientes, m organizao na execuo das tarefas, aonde
geralmente realizada dentro de prazos curtos para entrega, definio precria das
atribuies e responsabilidades dos recursos humanos, acompanhados do conflito e
acmulo de papis, desconhecimento das causas dos altos custos despendidos,
gerenciamento ad hoc dos riscos de projeto e baixa qualidade dos produtos gerados.
Os procedimentos de trabalho adotados para o desenvolvimento de
software so caracterizados pela execuo de tarefas baseadas na experincia de
pessoas que gerenciaram atividades para a construo de produtos de software
novos, de complexidade mdia que, em at certo tempo, tiveram algum sucesso,
mas que na verdade, esconderam futuros problemas.
A diretoria decidiu que os procedimentos de desenvolvimento de software
das suas equipes devero estar aderentes s melhores prticas definidas de acordo
com o Capability Maturity Model Integration for Development (CMMI-DEV) e com isto
obter um selo de qualidade reconhecido internacionalmente, aps uma avaliao
positiva pelo Instituto de Engenharia de Software dos Estados Unidos (SEI). Esta
deciso foi tomada devido s problemticas apresentadas anteriormente e a outros
fatores que a influenciaram, como aqueles que dizem respeito necessidade de
divulgar os servios de qualidade da empresa aos seus clientes e futuros parceiros.
Sem seguir um modelo para a melhora da qualidade de seus produtos a
empresa apresenta:
Ad hoc, improvisado por profissionais e gestores;
No rigorosamente seguido e o seu cumprimento no controlado;
Altamente dependente dos profissionais atuais;
Com baixa viso do progresso e da qualidade;
Cujas funcionalidades e qualidade do produto podem ficar comprometidas
para que os prazos sejam cumpridos;
Arriscado do ponto de vista do uso de novas tecnologias;
Com custos de manuteno excessivos;
Com qualidade difcil de prever.

10

3. Objetivos dos trabalhos da Consulting

O objetivo deste estudo foi definir metodologias a serem adotadas pela
empresa Software Developer para como implementar e obter a certificao CMMIDEV (Nvel 2).
A Software Developer desenvolve softwares para instituies financeiras e
de acordo com a Lei Sarbanes-Oxley a ao de TI de fundamental importncia. A
rea de Tecnologia da Informao responsvel pelo controle, segurana da
informao e sistemas. Dever estar alinhada na adequao da Lei Sarbanes-Oxley
para garantir s regras de transparncia fiscal e financeira.
Este trabalho tem os seguintes objetivos:
Implantar o modelo CMMI-DEV para desenvolvimento de suas reas de processo,
metas e prticas;
Avaliar a Software Developer para identificar o processo atual e as possibilidades e
necessidades de melhorias
Definir um perfil de capacidade de processos alvo e uma metodologia de
desenvolvimento aderente a este perfil.
Implantar a metodologia na organizao-alvo e avaliar seu desempenho.
4. A utilizao do CMMI-DEV
De um modo geral as empresas que melhoram seus processos utilizando o
CMMI-DEV como referncia, passam a ter os seguintes benefcios:
Aumento de produtividade: No se re-inventa a roda, o que deve ser feito esta
definido.
Diminuio de custo: A partir da reduo do re-trabalho e aumento de
produtividade.
Estimativas mais corretas: Isso gera propostas mais adequadas o que pode
representar mais negcios. Estimativas mais corretas evitam projetos
deficientes.

11

Qualidade: A padronizao dos processos e uso das melhores prticas te leva

a gerar produtos de melhor qualidade.
Aumento da satisfao do cliente: H um aumento de satisfao por parte do
cliente atravs da entrega de produtos de melhor qualidade e nos prazos
acordados.
Atualmente as empresas fornecedoras de software necessitam obter um nvel
de maturidade para enfrentar os concorrentes. De acordo com pesquisa realizada
pelo Ministrio de Cincia e Tecnologia/Secretaria de Poltica e Tecnologia em
Pesquisa de Qualidade no Setor de Software Brasileiro foi constatada a seguinte
informao:

Figura 1

4.1. Institucionalizao do CMMI-DEV

Sugerimos a idia de institucionalizar as iniciativas referentes implantao
do CMMI-DEV.

12

Figura 2
Para isso utilizamos a figura acima que descreve o seguinte:
Treinamentos: Esta iniciativa a mais bvia de todas, mas fundamental, sua
eficincia entre mdia e baixa, mas no deve ser descartada.
Workshop: Evento de apresentao do modelo de um jeito mais informal, pode
tornar-se interativo, fazendo brincadeiras e distribuindo prmios tem eficincia
mdia.
E-Mails rpidos: E-mails curtos, de at 15 linhas resumindo ao mximo um
determinado assunto, sua linha deve ser informal tem eficincia entre mdia e alta,
com isso a Software Developer, atravs de seu help-desk, utilizando os smartphones
poderia acionar sua equipe de campo (manuteno), para atender imediatamente os
chamados dos clientes.
Dicas: E-mails ou avisos com dicas de determinados assuntos, devem ser rpidos e
preferencialmente grficos tem eficincia mdio-baixa

13

Quadros: Colocar um quadro de avisos na empresa apresentando mais informaes

detalhadas a respeito do andamento dos projetos tem eficincia baixa.
Banners: Banners sempre ajudam, o ideal torn-los o mais grfico e fcil possvel,
deixe os detalhes nos processos e use uma linguagem de fcil interpretao tem
eficincia alta
Guias: criar um guia para os principais trabalhos tem eficincia mdia
Testes: Incentivam que as pessoas estudem, seus resultados so medianos, mas
sempre devem ser usados como complemento aos treinamentos tem eficincia
mdia
Concursos:

Quando

com

prmios,

os

concursos

ajudam

demais

institucionalizao, as pessoas vo atrs dos prmios e de quebra, aprendem mais

sobre os processos tem eficincia mdia alta.
Essas iniciativas ajudam, mas no resolvem no todo, preciso o
comprometimento de todos pela qualidade..
A melhor iniciativa as pessoas praticarem os processos, a mais simples e
mais eficiente.

14

5. Termo de Incio de Projeto

I.

Projeto: Melhoria da Qualidade no Desenvolvimento de Softwares

II.

Objetivo do projeto
Implantar o framework CMMI-DEV Nvel 2 visando melhoria nos processos
de desenvolvimento de software com garantia de qualidade.

III.

Nome do gerente do projeto, suas responsabilidades e sua autoridade

Gerente do Projeto: Valria Agostini de Campos Almeida
Responsabilidades: Administrar o desenvolvimento dos projetos, cumprindo
cronogramas, gerenciar o progresso do empreendimento e atravs das
variveis (qualidade, custo, prazo e mbito) verificar seus desvios, minimizando
possveis falhas.
Determinar e executar as necessidades do cliente, baseado nos seus prprios
conhecimentos. A habilidade de adaptar-se aos diversos procedimentos pode
lhe proporcionar um melhor gerenciamento das variveis e desta forma uma
maior satisfao do cliente.
Cuidar da parte de recursos humanos, contratando pessoas com formao
necessrias para as reas de desenvolvimento.
Cuidar da parte jurdica do negcio junto aos clientes, as implicaes legais, a
legabilidade do contrato.
Trabalhar pela implantao de Processos de Qualidade.
Autoridade: O Gerente de Projetos possui autoridade para negociar os projetos,
delegar funes, contratar pessoas, etc.

15

IV.

Necessidades bsicas do trabalho a ser realizado

Produtos
Processo de Desenvolvimento de Software;
Modelos de artefatos necessrios execuo das atividades do
processo;
Definio de papis, contendo atribuies, responsabilidades e
requisitos para contrao;
Sistemas de banco de dados de requisitos e de rastreabilidade;
Sistemas de comunicao;
Servios
Implantao de sistemas servidores de banco de dados, distribuio de

informaes (sites) e de projetos;

Implantao de sistema de controle de verso;
Realizao de treinamentos em gerenciamento de projetos, de configurao,
aquisies, medio e anlise, qualidade de processo e de produto.
Trabalho de conscientizao de todos os funcionrios da Software Developer
a respeito da melhoria no atendimento aos clientes. Utilizao das melhores
prticas voltadas qualidade do produto. Todos devero estar envolvidos no
processo desde o inicio, do cliente aos desenvolvedores (stakholders).

V.

Descrio do projeto
Fazem parte do escopo deste projeto:
1. Realizao do levantamento dos problemas atuais relacionados aos
procedimentos de trabalho das equipes tcnicas das unidades organizacionais
da empresa;

16

2. Contratao de consultoria especializada e aquisio de ferramentas;

3. Capacitao das equipes para a execuo das prticas recomendadas pelo
CMMI-DEV, nvel 2.
4. Criao de um processo padro de desenvolvimento de software;
5. Contratao da equipe CMMI de avaliao;
6. Obteno do certificado CMMI-DEV nvel 2 para a empresa.

1.

Produto do projeto
Com o objetivo de melhorar a qualidade de seus produtos e servios, a

empresa verificou a real necessidade de realizar modificaes nos

procedimentos de trabalho de sua equipe tcnica de desenvolvimento. A
necessidade do negcio relacionada a:
i) Demanda

do

mercado,

que

vem

exigindo

urgentemente

um

aprimoramento na qualidade dos produtos de software entregues pela

empresa. Isto somente poder ser alcanado pela melhoria do processo
de desenvolvimento de software, baseando-se nas melhores prticas e
padres de qualidade da Engenharia de Software. Inclusive, algumas
entidades financeiras, como potenciais clientes, esto exigindo a
certificao como pr-requisito para participao em certames licitatrios;
ii) Oportunidade estratgica, onde a aquisio de uma certificao de nvel
internacional poder garantir melhor presena da organizao perante os
mercados interno e externo, revelando o compromisso da empresa com a
qualidade de seus servios e produtos, adquirindo maior respeitabilidade;
iii) Necessidade interna, em organizar e padronizar os procedimentos para
desenvolvimento de software da empresa, que atualmente encontra-se em
estado muito precrio. tambm necessrio obter melhor satisfao dos
nossos colaboradores e assim evitar a alta rotatividade de pessoal.

17

iv) Necessidade social, adicionando atendimento de qualidade dos nossos

clientes sociedade.
2.

Cronograma bsico do projeto

Neste cronograma no esto computadas as horas trabalhadas do Gerente de

Projetos, o qual s no est presente na fase de programao.

3.

Estimativas iniciais de custo

18

VI.

Administrao
1.

Necessidade inicial de recursos

A equipe do projeto ser composta por:

Gerente do Projeto: Valria Agostini de Campos Almeida
Analista de Negcios: Celso O. R. Neves de Oliveira
Analista de Desenvolvimento: Jos Manuel Pontes
Arquiteto de Software: Paula U. Tavares Alves
Desenvolvedor/Tester: Antonio T. Andrade

Figura 3

19

Funes:

20

2.

Desenvolvendo o Software

A tcnica TDD.
Test Driven Development, ou Desenvolvimento Guiado por Testes, ou
simplesmente TDD, consiste numa tcnica de desenvolvimento de software
onde primeiro so criados os testes e somente depois escrito o cdigo
necessrio para passar por eles.
Benefcios:
Melhor entendimento do negcio do sistema: a primeira etapa do TDD o
Design, ou seja, antes de comear a implementar algum cdigo, o
desenvolvedor/arquiteto deve entender o problema/funcionalidade e projetar a
soluo. Essa fase extremamente importante no processo do TDD, o que
geralmente acontecia antes de usarmos o TDD, era que o desenvolvedor
comeava a implementar a funcionalidade sem entender direito o que ele
realmente precisava fazer, gerando muitos bugs e retrabalho mais pra frente.
Com o TDD, precisamos projetar os testes antes, e para projetarmos os
testes, temos que entender o que realmente deve ser testado, fazendo com
que

desenvolvedor

entre

fundo

no

entendimento

do

problema/funcionalidade.
Criao de testes ricos: quando se implementa testes unitrios depois do
cdigo estar pronto, a tendncia implementar testes de baixa qualidade,
pois inconscientemente escreve um teste para rodar no cdigo produzido, e o
correto seria o contrrio, seu cdigo que deveria passar no teste
previamente implementado.
Maior confiana no cdigo: em pesquisa realizada em projetos que rodaram
TDD notou-se que os desenvolvedores entregaram um cdigo com mais
confiana no trabalho produzido.
Maior valor agregado ao produto: sem dvida alguma entregar um produto
ao cliente j com os testes implementados, representa uma entrega de maior
valor agregado ao produto. Se vender bem essa idia ao cliente, e fizer com
que ele entenda os benefcios dos testes, pode ser que ele at pague a mais
para implementar os testes unitrios que j estavam previstos no processo de
desenvolvimento, e com isso, todos ganham: o cliente, com um produto de

21

maior qualidade e a empresa desenvolvedora com o ganho da produtividade

proporcionado pelo TDD.
Na fase de implementao, usando TDD, quando terminamos nossa unidade
de desenvolvimento, realmente acabamos. Ou seja, dificilmente temos que
retornar ao cdigo futuramente para corrigir falhas, pois as mesmas j foram
previamente detectadas e corrigidas durante a confeco dos testes.

3.

Controle e gerenciamento das informaes do projeto

Na fase de planejamento, o gerente de projetos da Software Developer

dever aprovar o projeto. O plano de projeto e o cronograma devero ser
apresentados e a partir da aprovao, o projeto estar validado para a execuo.
Na execuo do projeto, o monitoramento deve ser realizado de acordo com a
tabela a seguir:

Tipo

Periodicidade

Realizado por:

Monitoramento

Diariamente

Gerente do Projeto

Produtos gerados: Ferramenta/tcnica utilizada

Dirio

Project Server Verificao da atualizao

diria das atividades

Monitoramento

Semanalmente

Gerente do Projeto

Planejado

Revises em

Em marcos

marcos

planejados no

Gerente do Projeto

Planilha de

Avaliao semanal

Acompanhamento

do projeto

Planilha de

Avaliao dos marcos

Acompanhamento

do projeto

Ata de

Reunio de

Acompanhamento

Acompanhamento

cronograma

Acompanhamento Quinzenalmente
Gerencial

Comit Gerencial

Tabela 1 - Acompanhamento do Projeto

Em cada tipo de monitoramento, o foco diferenciado buscando identificar
eventos que podem alterar o planejamento. Essa alterao pode no influenciar

22

negativamente o projeto, mas deve ser acompanhado e aprovado pelos envolvidos.

As mudanas e problemas que surgem no decorrer do projeto e que impactam
negativamente devem ser identificados e, quando possvel, aes sero tomadas
para contingenciar esses impactos e mape-los, para que em outros projetos o
mesmo no ocorra, ou pelo menos, seja minimizado.
O controle de mudanas do projeto considerar solicitaes referentes s
mudanas entre o que foi planejado e o realizado, bem como controlar as alteraes
de escopo do projeto referentes s solicitaes de mudana. Tais solicitaes
podem ser propostas pelo cliente ou pela equipe de desenvolvimento do projeto,
sendo passveis de um novo dimensionamento do esforo e custo necessrios para
sua implementao.
Para que uma alterao seja incorporada ao projeto, o impacto dessa
alterao deve ser avaliado (custo, esforo, prazo...) e dever ser aprovada pelo
cliente.
VII.

Plano de Riscos

Descrio dos processos de gerenciamento de riscos

O gerenciamento de riscos do projeto ser realizado atravs de monitoramento e
controle dos riscos inicialmente identificados, e da incorporao de eventuais novos
riscos ao processo.
Todos os riscos no previstos originalmente no plano devem ser incorporados ao
projeto dentro do sistema de controle de mudana de riscos.
Os riscos a serem identificados sero os riscos internos ao projeto, os riscos
relacionados ao mercado e os relacionados legislao vigente.
As respostas possveis aos riscos identificados pelo projeto sero a aceitao
ativa, atravs de contingncias, e a atenuao (mitigao).

23

A identificao, avaliao e monitoramento de riscos, durante a execuo do

projeto, sero efetuados atravs de reunies quinzenais entre o gerente de projetos
e a equipe.
RBS Risk Breakdown Structure para a identificao dos riscos
Os riscos sero identificados e contextualizados nas 3 diferentes reas a seguir:
Gerncia do Projeto
Recursos Humanos
Financeiro
Riscos identificados
Os riscos identificados no projeto, atravs da tcnica de brainstorming e analisando
a WBS e a RBS esto apresentados na estrutura a seguir.
GERNCIA DO PROJETO
Mau planejamento e controle inadequado
RECURSOS HUMANOS
Contratao de Coordenador do projeto que no atenda s necessidades do projeto
Perda de membro da equipe durante a execuo do projeto
FINANCEIRO
Problema de Fluxo de Caixa
Extenso no prazo do projeto
Qualificao dos riscos
Os riscos identificados foram qualificados pela probabilidade de ocorrncia e pela
severidade dos resultados, conforme critrios a seguir:

24

Probabilidade - Classificao concedida com base na probabilidade de ocorrncia do

risco, podendo ser de baixa, mdia ou alta probabilidade.
Na tabela abaixo a classificao da probabilidade de ocorrncia dos riscos segundo
percentual:
Baixa Probabilidade

Mdia Probabilidade

Alta Probabilidade

At 40 %

De 40 a 60%

Acima de 60%

Tabela 2 Ocorrncia de Riscos

Severidade Classificao concedida com base no somatrio dos impactos
potenciais do risco no prazo do projeto, podendo ser de baixa, mdia ou alta
severidade.
Os riscos com impacto estimado em at 1 ms de atraso so classificados como
severidade baixa, entre 1 e 2 meses so classificados como severidade mdia e os
riscos com impacto que gere atraso de mais de 2 meses so de severidade alta.
Quantificao dos riscos
O mecanismo e processos para quantificao dos riscos esto apresentados a
seguir:
1 - Risco no gerenciamento do projeto: Este risco pode causar o impacto de
comprometer a criao de uma metodologia de gerenciamento de projetos que
realmente atenda as necessidades dos clientes comprometendo assim o resultado
final.
Resposta ao Risco: Realizao de reunies semanais da equipe do grupo de
desenvolvimento da metodologia com o gerente do projeto para avaliar cronograma
e realizar controle financeiro do projeto.
Dever ser realizada uma reunio quinzenal com toda a equipe do projeto para que
todos possam expressar os pontos fortes e fracos do projeto. Tambm devero ser
revistos o plano do projeto e os mecanismos de controle do projeto.

25

2 - Risco nos Recursos Humanos: Este risco tem como impacto a necessidade de
contratao urgente de outro profissional e o treinamento do mesmo na metodologia.
Tambm tem como impacto a sobrecarga aos outros que trabalham na equipe do
projeto.
Resposta ao Risco: Assinatura de um contrato em que deixe para o final do projeto
uma boa parte do valor a ser pago ao profissional contratado.
3 - Risco Financeiro: Este risco tem como impacto o comprometimento nos
pagamentos previstos no projeto.
- Ocorrncia do Risco: Caso o projeto tenha atraso, o custo do projeto sofrer um
aumento. Os custos considerados correspondem ao burn rate do projeto, que
incluem o custo mensal mdio da equipe contratada acrescida de 10% de taxa de
servio
- Resposta ao Risco: Fazer uma reserva de contingncia de 20% do total do projeto
a fim de cobrir os principais custos do projeto e garantir o pagamento das despesas
prevendo 30 dias de atraso.
Freqncia de avaliao dos riscos do projeto
Os riscos identificados no projeto devem ser avaliados quinzenalmente, na reunio
de acompanhamento de riscos, conforme previsto no plano de gerenciamento das
comunicaes.
Administrao do plano de gerenciamento de riscos
Responsveis pelo plano
Gerente do Projeto
Freqncia de atualizao do plano de gerenciamento de riscos
Este Plano de Gerenciamento e resposta aos riscos dever ser atualizado
quinzenalmente ou sempre que necessrio.

26

VIII.

Gerenciamento de Comunicao

A execuo da comunicao ser baseada nas evidncias geradas pelos artefatos

descritos na tabela abaixo e sua gerncia acontecer de acordo com o previsto no
cronograma.
Tipo de Comunicao

Formato da Comunicao

Pblico Alvo

Abertura do Projeto

Reunio de incio do projeto

com todos os envolvidos

Equipe do Projeto

Controle de Mudana

Reunio, email

Equipe do Projeto e
demais interessados

Acompanhamento

Email, Reunies,
Apontamentos

Equipe do Projeto

Tabela 3 - Gerenciamento de Comunicao

IX.

Sugestes
Os avanos tecnolgicos tornam os equipamentos eletroeletrnicos

obsoletos rapidamente, o que faz aumentar o consumo de novos aparelhos, como

celulares, computadores, monitores, eletrodomsticos, alm de baterias e pilhas. Os
equipamentos rejeitados transformam-se em lixo eletrnico. Nem todo mundo sabe
que lixo eletrnico no deve ser jogado junto com o lixo comum, cujo destino os
lixes e aterros sanitrios, porque, em geral, contm metais pesados e elementos
qumicos altamente nocivos sade, contaminando o solo, inclusive, podendo
chegar ao lenol fretico.
Uma vez que voc decidir usar apenas material de escritrio reciclvel,
pouco provvel que voc ter problemas em encontrar um lugar para se reciclar.
Existem inmeras empresas que esto trabalhando para reciclar mais.

27

Sugerimos um trabalho de conscientizao a todos os envolvidos, para que

tenham cuidado na hora de descartar os materiais de informtica. Que procurem
empresas que reutilizem esse material, no prejudicando o meio ambiente.
Podemos citar um exemplo de "diminuio de fardo" nesse segmento como o
aproveitamento dos computadores pelo maior tempo possvel (se possvel), e na
troca da mquina aconselhamos a do-las (ou vend-las), ou at mesmo comprar
mquinas usadas se forem usadas apenas para trabalhar com sistemas de
documentao, digitao e internet. Vender ou fazer upgrade em computadores
usados oferece de cinco a vinte vezes mais economia de energia do que reciclar.
Portanto para reduzir esse impacto ambiental a melhor maneira mesmo estender a
vida til dos computadores o mximo que pudermos.
A empresa possuir um selo informando que respeita a natureza de grande
valia na conquista de novos clientes.

X.

Encerramento do Projeto
O encerramento deste projeto estar baseado nas evidncias geradas

baseando-se na Declarao de Escopo deste projeto e no trmino da ltima

atividade descrita no Cronograma do Projeto.
O projeto ser efetivado com sucesso se todos os objetivos definidos no
Termo de Abertura e Declarao de Trabalho foram alcanados e se todos os
requisitos do projeto foram atendidos.
Deve-se observar que a obteno do selo de qualidade que comprova se a
organizao observa e executa as prticas definidas no CMMI-DEV nvel 2, no a
nica evidncia de sucesso deste projeto, pois deve tambm ser observado se as
prticas trouxeram os benefcios esperados e que a satisfao da maioria seja
alcanada.

28

XI.

Aprovaes
Tendo cincia da execuo do projeto, dos prazos, dos custos e do

oramento previstos de acordo com o que foi estabelecido neste Plano de Projeto,
firmamos o compromisso o mesmo:
APROVAES
Carlos Roberto de
Souza

___________________________

____/_____/_____

Assinatura

Data

___________________________
Assinatura

____/_____/_____
Data

Paulo Joaquim do Canto ___________________________

Assinatura
Representante da Consulting

____/_____/_____
Data

Diretor Presidente da Software

Developer

Valria A. de Campos
Almeida
Gerente de Projetos

Nota: Quaisquer alteraes neste documento devero ser submetidas ao

processo de controle de projeto.

27

Concluso
importante que os gerentes de projeto reconheam que no possvel
desenvolver sistemas de qualidade, cumprir prazos e custos e atender s
expectativas dos usurios sem ter um processo de desenvolvimento de requisitos
definido, compreendido e utilizado por todos os desenvolvedores.
Convm ressaltar que no existe um processo ideal que possa ser utilizado
em qualquer projeto. Ser sempre necessrio realizar adaptaes, em funo das
caractersticas do sistema, dos usurios, da equipe, da organizao, do tipo de
sistema e da tecnologia a ser utilizada, dentre outros fatores.
O CMMI-DEV um framework de aprimoramento de processos muito
completo, cuja aplicao atende necessidades especficas de uma organizao,
bem como o gerenciamento de contratos com fornecedores de diferentes tipos,
garantindo uma integrao efetiva e harmoniosa.
Contudo, a vasta documentao e a abordagem ambgua dificultam a
implementao do CMMI, tornando a contratao de consultorias imprescindvel em
muitos casos.

Sendo assim, muitas organizaes de pequeno porte jamais o

estudam, bloqueando a adoo do modelo por no dispor de verba para contratar

uma consultoria pelo prazo necessrio. Uma vez estando no nvel de maturidade 1,
todo esforo, prazo e verba destinado para contornar problemas criados por
processos mal planejados e gerenciados.
A empresa analisada neste trabalho certamente encaixa-se neste cenrio,
concentrando seus esforos na tentativa de contornar problemas, sem considerar a
adoo de uma metodologia que aprimore seus processos e, portanto, a qualidade
de

seus

produtos.

Consulting

procurou

orient-los

para

utilizarem

os

procedimentos do CMMI-DEV, visando obter produtos de qualidade, dentro das

normas internacionais, obtendo plena satisfao dos clientes.
Manifesto para o desenvolvimento gil de software (Original em ingls)
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns
mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar:

28

1. Indivduos e interao entre eles mais que processos e ferramentas

2. Software em funcionamento mais que documentao abrangente
3. Colaborao com o cliente mais que negociao de contratos
4. Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens
esquerda.
Princpios do manifesto do Software gil
Ns seguimos os seguintes princpios:

Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e

contnua de software de valor.

Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento.

Processos geis se adequam a mudanas, para que o cliente possa tirar
vantagens competitivas.

Entregar software funcionando com freqncia, na escala de semanas at

meses, com preferncia aos perodos mais curtos.

Pessoas relacionadas a negcios e desenvolvedores devem trabalhar em

conjunto e diariamente, durante todo o curso do projeto.

Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente

e suporte necessrio, e confiar que faro seu trabalho.

O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro

de um time de desenvolvimento, atravs de uma conversa cara a cara.

Software funcional a medida primria de progresso.

Processos geis promovem um ambiente sustentvel. Os patrocinadores,

desenvolvedores e usurios, devem ser capazes de manter indefinidamente,
passos constantes.

Contnua ateno a excelncia tcnica e bom design aumentam a agilidade.

Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou

ser feito.

As melhores arquiteturas, requisitos e designs emergem de times autoorganizveis.

29

Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se

ajustam e otimizam seu comportamento de acordo.

30

Referncias

Entrevista com o CMMI Lead Appraiser Antonio Braga em 12/julho de 2010

Fonte:: <http://www.blogcmmi.com.br/category/cmmi-svc> - acesso 09/12/10.
Fbrica de Software - Definio da organizao da fbrica por Tweets that mention|
Caverna do Software Fonte: <http://voat.com.br/rdal/?tag=qualidade> - acesso
10/12/10.
Gesto de Projetos de Sotfwares - Fonte:<http://www.sergiodias.inf.br/engenhariade-software/gestao-de-projetos-de-software> - acesso 09/12/10.
"Introduction

to

Test

Driven

Design

(TDD)"

Fonte:

<

http://www.agiledata.org/essays/tdd.html> - acesso 11/12/10.

Lista de empresas CMMI Brasil - Fonte:<http://www.blogcmmi.com.br/tag/cmmi-3>
acesso em 09/12/10
Manifesto Agil - Fonte: <http://manifestoagil.com.br/principios.html> - acesso
11/12/10.
Pesquisa de Qualidade no setor de Software Brasileiro 2009 - Ministrio de Cincia
e Tecnologia - Fonte:<http://www.mct.gov.br/upd_blob/0210/210931.pdf> - acesso
08/12/10.
Reunio

de

kickoff

de

um

projeto

<http://www.gpemdestaque.com.br/2010/05/10/reuniao-de-kick-off/>

Fonte:
-

acesso

10/12/10.
Roberto Luiz Sena de Alencar - O desenvolvimento guiado por testes - A voz Java
no Brasil Fonte: < http://www.javafree.org> - acesso 08/12/10.
UMA PROPOSTA DE PROJETO PARA IMPLANTAO DO CMMI-DEV NVEL 2
DE

MATURIDADE

CONFORME

GUIA

PMBOK

<http://www.fatecjp.com.br/revista/tcc/gp01.pdf> - acesso 10/12/10.

Fonte:

31

Informaes sobre reciclagem

Fonte: <http://www.compute-rs.com/pt/conselho-1093760.htm>
12/12/10.

acesso

Fonte: < http://www.forumpcs.com.br/comunidade/viewtopic.php?t=240003>

acesso em 12/12/10.

em
-

Fonte:
<http://blogambientese.blogspot.com/2009/05/destino-certo-para-o-lixoeletronico.html> - acesso em 12/12/10.

Figuras

Figura 1- Obtido em: Pesquisa de Qualidade no setor de Software Brasileiro 2009 Ministrio de Cincia e Tecnologia
Figura

Obtido

em

<http://www.blogcmmi.com.br/comunicacao/dicas-de-

institucionalizacao-do-cmmi> - acesso 10/12/10.

Figura 3 Desenvolvida no programa BizAgi minha autoria.

32

Glossrio

Ad-hoc - para um propsito/caso especfico

RBS Risk Breakdown Structure ferramenta para identificao dos riscos.
WBS Work Breakdown Structure - ferramenta utilizada para definir e agrupar
tarefas de modo que ajude a organizar e definir o trabalho total do escopo do
projeto.
TDD Test-Driven Development - uma metodologia que utiliza os testes para
auxiliar os desenvolvedores tomar as decises certas na hora certa.