UNIP INTERATIVA

Projeto Integrado Multidisciplinar VIII

Curso Superior de Gestão de Tecnologia da Informação

SERVIÇO DE CONSULTORIA
Cliente: Empresa Software Developer

POLO FERNÃO GAIVOTA

2010
 Paulo Joaquim do Canto

RA: 0906384

Curso Gestão de Tecnologia da Informação

Semestre: 4º

SERVIÇO DE CONSULTORIA
Cliente: Empresa Software Developer

Relatório apresentado como Projeto Integrado

Multidisciplinar VIII com requisito parcial para

obtenção de média bimestral

Orientador: Adriane Paulieli Colossetti

________________________________

________________________________

POLO FERNÃO GAIVOTA

2010
Resumo

Tendo como objetivo principal da certificação CMMI-DEV de nível dois,

pretende-se aumentar a produtividade e a qualidade. Utilizando as metodologias
mais avançadas será possível desenvolver aplicações de software de uma forma
mais eficiente e com níveis mais elevados de produtividade. Em relação à qualidade,
temos em vista responder de forma mais eficaz e eficiente aos clientes, entendendo-
se aqui a qualidade como sinônimo daquilo que é totalmente adequado ao uso final
dos softwares desenvolvidos ou às expectativas dos utilizadores.

A adoção do CMMI-DEV e correspondente certificação implicam que sejam

seguidos padrões de atuação mais exigentes, decorrentes de boas práticas
internacionais. Estes padrões deverão, em última análise, aumentar a produtividade
das equipes de desenvolvimento e a qualidade do software que é desenvolvido. Um
dos problemas comuns na atividade de desenvolvimento de software são os prazos
e os custos. A adoção 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 são seguidos padrões de trabalho idênticos 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 conseqüente
perda de dinheiro e de tempo. No entanto, isto também implica mudanças na forma
de trabalhar e na cultura da própria empresa. No caso concreto da Software
Developer, passou-se de uma organização orientada essencialmente por funções,
para uma orientação a processos e projetos.

Palavras chave: Certificação 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

Sumário

1. Introdução .......................................................................................................... 08

2. Descrição da Software Developer ....................................................................... 08

3. Objetivos dos trabalhos da Consulting ................................................................ 10

4. A utilização do CMMI-DEV ................................................................................... 10

4.1. Instituticionalização 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 básicas do trabalho a ser realizado........................................ 15

V. Descrição do Projeto ...................................................................................... 15

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

2. Cronograma básico do Projeto.................................................. 17

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

VI. Administração ................................................................................................ 18

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

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

3. Controle e gerenciamento das informações do projeto ............ 21

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

VIII. Gerenciamento de Comunicação .................................................................. 26

IX. Sugestões ...................................................................................................... 26

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

XI. Aprovações .................................................................................................... 28

6. Conclusão ............................................................................................................ 29

7. Referências .................................................................................,....................... 30

8. Glossário ............................................................................................................. 32
Lista de Figuras

Figura 1 – Nível de Maturidade do Modelo CMMI..................................................... 09

Figura 2 – Institucionalização do CMMI ................................................................... 12

Figura 3 – Organograma da Software Developer...................................................... 18

Tabela 1 – Acompanhamento do Projeto.................................................................. 21

Tabela 2 – Ocorrência de Riscos ............................................................................. 24

Tabela 3 – Gerenciamento de Comunicação ........................................................... 26

 8

1. Introdução

Este é um projeto para a implantação da melhoria de processos de

desenvolvimento de software, através 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. São exigidas destas pessoas, habilidades para motivar, treinar, orientar,
sugerir técnicas e procedimentos etc., bem como analisar os desvios que implicam
na não aderência de um processo às metas e práticas impostas pelo CMMI-DEV. O
CMMI-DEV é um modelo de referência que fornece direcionamento para as práticas
a serem seguidas em um processo de desenvolvimento de software.
O principal objetivo foi realizar um planejamento para a construção de um
processo consistente e maduro baseado nas metas e práticas do CMMI-DEV nível 2,
utilizando as recomendações do PMBOK, focando-se na mitigação dos riscos do
projeto, no cumprimento dos prazos e no alcance da qualidade dos serviços a serem
executados. Com isto, foi realizada a criação de um estudo de caso baseado em um
cenário típico de processo ad hoc de trabalho e nos problemas inerentes da
empresa Software Developer que se encontra no nível caótico de maturidade em
processo de desenvolvimento de software e que pretende obter a certificação CMMI-
DEV nível 2. Este trabalho objetivou também realizar a identificação de riscos do
projeto e um planejamento para sua mitigação ou contingenciamento; a realização
de estimativas de custos e de esforço para execução do projeto; a determinação de
critérios para o sucesso do projeto; a especificação de recursos necessários para as
atividades do projeto; a criação e definição de demais produtos de trabalho que
possam facilitar o planejamento e o controle do projeto etc.

2. Descrição da Software Developer

A Software Developer é uma empresa sediada em São Paulo, SP, cujo foco
do negócio é o desenvolvimento de pacotes de software voltados para órgãos do
sistema financeiro. Sua estratégia de longo prazo é a inserção nesse mercado
através do desenvolvimento de softwares para o segmento.
 9

Compõe este produto ferramentas de Sistema de Consórcio, Sistema de

Financiamento e Sistema para Empréstimo.
A empresa enfrenta problemas na área de desenvolvimento de
software, causados pela má gestão das mudanças dos requisitos e das
necessidades dos clientes, má organização na execução das tarefas, aonde
geralmente é realizada dentro de prazos curtos para entrega, definição precária das
atribuições e responsabilidades dos recursos humanos, acompanhados do conflito e
acúmulo de papéis, 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 são caracterizados pela execução de tarefas baseadas na experiência de
pessoas que gerenciaram atividades para a construção de produtos de software
novos, de complexidade média 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 deverão estar aderentes às melhores práticas definidas de acordo
com o Capability Maturity Model Integration for Development (CMMI-DEV) e com isto
obter um selo de qualidade reconhecido internacionalmente, após uma avaliação
positiva pelo Instituto de Engenharia de Software dos Estados Unidos (SEI). Esta
decisão foi tomada devido às problemáticas apresentadas anteriormente e a outros
fatores que a influenciaram, como aqueles que dizem respeito à necessidade de
divulgar os serviços 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;
• Não é rigorosamente seguido e o seu cumprimento não é controlado;
• Altamente dependente dos profissionais atuais;
• Com baixa visão 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 manutenção excessivos;
• Com qualidade difícil 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 certificação CMMI-
DEV (Nível 2).
A Software Developer desenvolve softwares para instituições financeiras e
de acordo com a Lei Sarbanes-Oxley a ação de TI é de fundamental importância. A
área de Tecnologia da Informação é responsável pelo controle, segurança da
informação e sistemas. Deverá estar alinhada na adequação da Lei Sarbanes-Oxley
para garantir às regras de transparência fiscal e financeira.
Este trabalho tem os seguintes objetivos:

· Implantar o modelo CMMI-DEV para desenvolvimento de suas áreas de processo,

metas e práticas;

· 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 organização-alvo e avaliar seu desempenho.

4. A utilização do CMMI-DEV

De um modo geral as empresas que melhoram seus processos utilizando o

CMMI-DEV como referência, passam a ter os seguintes benefícios:

• Aumento de produtividade: Não se re-inventa a roda, o que deve ser feito esta
definido.

• Diminuição de custo: A partir da redução do re-trabalho e aumento de

produtividade.

• Estimativas mais corretas: Isso gera propostas mais adequadas o que pode
representar mais negócios. Estimativas mais corretas evitam projetos
deficientes.
 11

• Qualidade: A padronização dos processos e uso das melhores práticas te leva

a gerar produtos de melhor qualidade.

• Aumento da satisfação do cliente: Há um aumento de satisfação por parte do

cliente através da entrega de produtos de melhor qualidade e nos prazos
acordados.

Atualmente as empresas fornecedoras de software necessitam obter um nível

de maturidade para enfrentar os concorrentes. De acordo com pesquisa realizada
pelo Ministério de Ciência e Tecnologia/Secretaria de Política e Tecnologia em
Pesquisa de Qualidade no Setor de Software Brasileiro foi constatada a seguinte
informação:

Figura 1

4.1. Institucionalização do CMMI-DEV

Sugerimos a idéia de “institucionalizar” as iniciativas referentes à implantação

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

eficiência é entre média e baixa, mas não deve ser descartada.

Workshop: Evento de apresentação do modelo de um jeito mais informal, pode

tornar-se interativo, fazendo brincadeiras e distribuindo prêmios – tem eficiência
média.

E-Mails rápidos: E-mails curtos, de até 15 linhas resumindo ao máximo um

determinado assunto, sua linha deve ser informal – tem eficiência entre média e alta,
com isso a Software Developer, através de seu help-desk, utilizando os smartphones
poderia acionar sua equipe de campo (manutenção), para atender imediatamente os
chamados dos clientes.

Dicas: E-mails ou avisos com dicas de determinados assuntos, devem ser rápidos e
preferencialmente gráficos – tem eficiência médio-baixa
 13

Quadros: Colocar um quadro de avisos na empresa apresentando mais informações

detalhadas a respeito do andamento dos projetos – tem eficiência baixa.

Banners: Banners sempre ajudam, o ideal é torná-los o mais gráfico e fácil possível,
deixe os detalhes nos processos e use uma linguagem de fácil interpretação – tem
eficiência alta

Guias: criar um guia para os principais trabalhos – tem eficiência média

Testes: Incentivam que as pessoas estudem, seus resultados são medianos, mas
sempre devem ser usados como complemento aos treinamentos – tem eficiência
média

Concursos: Quando com prêmios, os concursos ajudam demais a

institucionalização, as pessoas vão atrás dos prêmios e de quebra, aprendem mais
sobre os processos – tem eficiência média alta.

Essas iniciativas ajudam, mas não 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 Início de Projeto

I. Projeto: Melhoria da Qualidade no Desenvolvimento de Softwares

II. Objetivo do projeto

Implantar o framework CMMI-DEV Nível 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: Valéria Agostini de Campos Almeida

Responsabilidades: Administrar o desenvolvimento dos projetos, cumprindo

cronogramas, gerenciar o progresso do empreendimento e através das
variáveis (qualidade, custo, prazo e âmbito) verificar seus desvios, minimizando
possíveis falhas.

Determinar e executar as necessidades do cliente, baseado nos seus próprios

conhecimentos. A habilidade de adaptar-se aos diversos procedimentos pode
lhe proporcionar um melhor gerenciamento das variáveis e desta forma uma
maior satisfação do cliente.

Cuidar da parte de recursos humanos, contratando pessoas com formação

necessárias para as áreas de desenvolvimento.

Cuidar da parte jurídica do negócio junto aos clientes, as implicações legais, a

legabilidade do contrato.

Trabalhar pela implantação de Processos de Qualidade.

Autoridade: O Gerente de Projetos possui autoridade para negociar os projetos,

delegar funções, contratar pessoas, etc.
 15

IV. Necessidades básicas do trabalho a ser realizado

Produtos

• Processo de Desenvolvimento de Software;

• Modelos de artefatos necessários à execução das atividades do

processo;

• Definição de papéis, contendo atribuições, responsabilidades e

requisitos para contração;

• Sistemas de banco de dados de requisitos e de rastreabilidade;

• Sistemas de comunicação;

Serviços

Implantação de sistemas servidores de banco de dados, distribuição de

informações (sites) e de projetos;

Implantação de sistema de controle de versão;

Realização de treinamentos em gerenciamento de projetos, de configuração,

aquisições, medição e análise, qualidade de processo e de produto.

Trabalho de conscientização de todos os funcionários da Software Developer

a respeito da melhoria no atendimento aos clientes. Utilização das melhores
práticas voltadas à qualidade do produto. Todos deverão estar envolvidos no
processo desde o inicio, do cliente aos desenvolvedores (stakholders).

V. Descrição do projeto

Fazem parte do escopo deste projeto:

1. Realização do levantamento dos problemas atuais relacionados aos

procedimentos de trabalho das equipes técnicas das unidades organizacionais
da empresa;
 16

2. Contratação de consultoria especializada e aquisição de ferramentas;

3. Capacitação das equipes para a execução das práticas recomendadas pelo

CMMI-DEV, nível 2.

4. Criação de um processo padrão de desenvolvimento de software;

5. Contratação da equipe CMMI de avaliação;

6. Obtenção do certificado CMMI-DEV nível 2 para a empresa.

1. Produto do projeto
Com o objetivo de melhorar a qualidade de seus produtos e serviços, a
empresa verificou a real necessidade de realizar modificações nos
procedimentos de trabalho de sua equipe técnica de desenvolvimento. A
necessidade do negócio é 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 alcançado pela melhoria do processo
de desenvolvimento de software, baseando-se nas melhores práticas e
padrões de qualidade da Engenharia de Software. Inclusive, algumas
entidades financeiras, como potenciais clientes, estão exigindo a
certificação como pré-requisito para participação em certames licitatórios;

ii) Oportunidade estratégica, onde a aquisição de uma certificação de nível

internacional poderá garantir melhor presença da organização perante os
mercados interno e externo, revelando o compromisso da empresa com a
qualidade de seus serviços 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 precário. É também necessário obter melhor satisfação 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 básico do projeto

Neste cronograma não estão computadas as horas trabalhadas do Gerente de

Projetos, o qual só não está presente na fase de programação.

3. Estimativas iniciais de custo

 18

VI. Administração
1. Necessidade inicial de recursos
A equipe do projeto será composta por:

Gerente do Projeto: Valéria Agostini de Campos Almeida

Analista de Negócios: 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

Funções:
 20

2. Desenvolvendo o Software
A técnica TDD.
Test Driven Development, ou Desenvolvimento Guiado por Testes, ou
simplesmente TDD, consiste numa técnica de desenvolvimento de software
onde primeiro são criados os testes e somente depois é escrito o código
necessário para passar por eles.
Benefícios:
· Melhor entendimento do negócio do sistema: a primeira etapa do TDD é o
Design, ou seja, antes de começar a implementar algum código, o
desenvolvedor/arquiteto deve entender o problema/funcionalidade e projetar a
solução. Essa fase é extremamente importante no processo do TDD, o que
geralmente acontecia antes de usarmos o TDD, era que o desenvolvedor
começava 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 o desenvolvedor entre a fundo no entendimento do
problema/funcionalidade.
· Criação de testes ricos: quando se implementa testes unitários depois do
código estar pronto, a tendência é implementar testes de baixa qualidade,
pois inconscientemente escreve um teste para rodar no código produzido, e o
correto seria o contrário, seu código é que deveria passar no teste
previamente implementado.
· Maior confiança no código: em pesquisa realizada em projetos que rodaram
TDD notou-se que os desenvolvedores entregaram um código com mais
confiança no trabalho produzido.
· Maior valor agregado ao produto: sem dúvida alguma entregar um produto
ao cliente já com os testes implementados, representa uma entrega de maior
valor agregado ao produto. Se vender bem essa idéia ao cliente, e fizer com
que ele entenda os benefícios dos testes, pode ser que ele até pague a mais
para implementar os testes unitários 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 implementação, usando TDD, quando terminamos nossa unidade
de desenvolvimento, realmente acabamos. Ou seja, dificilmente temos que
retornar ao código futuramente para corrigir falhas, pois as mesmas já foram
previamente detectadas e corrigidas durante a confecção dos testes.

3. Controle e gerenciamento das informações do projeto

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

deverá aprovar o projeto. O plano de projeto e o cronograma deverão ser
apresentados e a partir da aprovação, o projeto estará validado para a execução.

Na execução do projeto, o monitoramento deve ser realizado de acordo com a

tabela a seguir:

Tipo Periodicidade Realizado por: Produtos gerados: Ferramenta/técnica utilizada

Monitoramento Diariamente Gerente do Projeto - Project Server -

Diário Verificação da atualização
diária das atividades

Monitoramento Semanalmente Gerente do Projeto Planilha de Avaliação semanal

Planejado Acompanhamento do projeto

Revisões em Em marcos Gerente do Projeto Planilha de Avaliação dos marcos

marcos planejados no Acompanhamento do projeto
cronograma

Acompanhamento Quinzenalmente Comitê Gerencial Ata de Reunião de

Gerencial Acompanhamento Acompanhamento

Tabela 1 - Acompanhamento do Projeto

Em cada tipo de monitoramento, o foco é diferenciado buscando identificar

eventos que podem alterar o planejamento. Essa alteração pode não influenciar
 22

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

As mudanças e problemas que surgem no decorrer do projeto e que impactam
negativamente devem ser identificados e, quando possível, ações serão tomadas
para contingenciar esses impactos e mapeá-los, para que em outros projetos o
mesmo não ocorra, ou pelo menos, seja minimizado.

O controle de mudanças do projeto considerará solicitações referentes às

mudanças entre o que foi planejado e o realizado, bem como controlar as alterações
de escopo do projeto referentes às solicitações de mudança. Tais solicitações
podem ser propostas pelo cliente ou pela equipe de desenvolvimento do projeto,
sendo passíveis de um novo dimensionamento do esforço e custo necessários para
sua implementação.

Para que uma alteração seja incorporada ao projeto, o impacto dessa

alteração deve ser avaliado (custo, esforço, prazo...) e deverá ser aprovada pelo
cliente.

VII. Plano de Riscos

Descrição dos processos de gerenciamento de riscos

• O gerenciamento de riscos do projeto será realizado através de monitoramento e

controle dos riscos inicialmente identificados, e da incorporação de eventuais novos
riscos ao processo.

• Todos os riscos não previstos originalmente no plano devem ser incorporados ao

projeto dentro do sistema de controle de mudança de riscos.

• Os riscos a serem identificados serão os riscos internos ao projeto, os riscos

relacionados ao mercado e os relacionados à legislação vigente.

• As respostas possíveis aos riscos identificados pelo projeto serão a aceitação

ativa, através de contingências, e a atenuação (mitigação).
 23

• A identificação, avaliação e monitoramento de riscos, durante a execução do

projeto, serão efetuados através de reuniões quinzenais entre o gerente de projetos
e a equipe.

RBS – Risk Breakdown Structure para a identificação dos riscos

Os riscos serão identificados e contextualizados nas 3 diferentes áreas a seguir:

• Gerência do Projeto

• Recursos Humanos

• Financeiro

Riscos identificados

Os riscos identificados no projeto, através da técnica de brainstorming e analisando

a WBS e a RBS estão apresentados na estrutura a seguir.

GERÊNCIA DO PROJETO

Mau planejamento e controle inadequado

RECURSOS HUMANOS

Contratação de Coordenador do projeto que não atenda às necessidades do projeto

Perda de membro da equipe durante a execução do projeto

FINANCEIRO

Problema de Fluxo de Caixa

Extensão no prazo do projeto

Qualificação dos riscos

Os riscos identificados foram qualificados pela probabilidade de ocorrência e pela

severidade dos resultados, conforme critérios a seguir:
 24

Probabilidade - Classificação concedida com base na probabilidade de ocorrência do

risco, podendo ser de baixa, média ou alta probabilidade.

Na tabela abaixo a classificação da probabilidade de ocorrência dos riscos segundo

percentual:

Baixa Probabilidade Média Probabilidade Alta Probabilidade

Até 40 % De 40 a 60% Acima de 60%

Tabela 2 – Ocorrência de Riscos

Severidade – Classificação concedida com base no somatório dos impactos

potenciais do risco no prazo do projeto, podendo ser de baixa, média ou alta
severidade.

Os riscos com impacto estimado em até 1 mês de atraso são classificados como
severidade baixa, entre 1 e 2 meses são classificados como severidade média e os
riscos com impacto que gere atraso de mais de 2 meses são de severidade alta.

Quantificação dos riscos

O mecanismo e processos para quantificação dos riscos estão apresentados a

seguir:

1 - Risco no gerenciamento do projeto: Este risco pode causar o impacto de

comprometer a criação de uma metodologia de gerenciamento de projetos que
realmente atenda as necessidades dos clientes comprometendo assim o resultado
final.

Resposta ao Risco: Realização de reuniões 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 reunião quinzenal com toda a equipe do projeto para que
todos possam expressar os pontos fortes e fracos do projeto. Também deverão 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
contratação urgente de outro profissional e o treinamento do mesmo na metodologia.
Também 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.

- Ocorrência 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 médio da equipe contratada acrescida de 10% de taxa de
serviço

- Resposta ao Risco: Fazer uma reserva de contingência 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.

Freqüência de avaliação dos riscos do projeto

Os riscos identificados no projeto devem ser avaliados quinzenalmente, na reunião

de acompanhamento de riscos, conforme previsto no plano de gerenciamento das
comunicações.

Administração do plano de gerenciamento de riscos

Responsáveis pelo plano

• Gerente do Projeto

Freqüência de atualização do plano de gerenciamento de riscos

Este Plano de Gerenciamento e resposta aos riscos deverá ser atualizado

quinzenalmente ou sempre que necessário.
 26

VIII. Gerenciamento de Comunicação

A execução da comunicação será baseada nas evidências geradas pelos artefatos

descritos na tabela abaixo e sua gerência acontecerá de acordo com o previsto no
cronograma.

Tipo de Comunicação Formato da Comunicação Público Alvo

Abertura do Projeto Reunião de início do projeto Equipe do Projeto

com todos os envolvidos

Equipe do Projeto e
Controle de Mudança Reunião, email demais interessados

Email, Reuniões,
Acompanhamento Apontamentos Equipe do Projeto

Tabela 3 - Gerenciamento de Comunicação

IX. Sugestões

Os avanços tecnológicos tornam os equipamentos eletroeletrônicos

obsoletos rapidamente, o que faz aumentar o consumo de novos aparelhos, como
celulares, computadores, monitores, eletrodomésticos, além de baterias e pilhas. Os
equipamentos rejeitados transformam-se em lixo eletrônico. Nem todo mundo sabe
que lixo eletrônico não deve ser jogado junto com o lixo comum, cujo destino é os
lixões e aterros sanitários, porque, em geral, contém metais pesados e elementos
químicos altamente nocivos à saúde, contaminando o solo, inclusive, podendo
chegar ao lençol freático.

Uma vez que você decidir usar apenas material de escritório reciclável, é
pouco provável que você terá problemas em encontrar um lugar para se reciclar.
Existem inúmeras empresas que estão trabalhando para reciclar mais.
 27

Sugerimos um trabalho de conscientização a todos os envolvidos, para que

tenham cuidado na hora de descartar os materiais de informática. Que procurem
empresas que reutilizem esse material, não prejudicando o meio ambiente.

Podemos citar um exemplo de "diminuição de fardo" nesse segmento como o

aproveitamento dos computadores pelo maior tempo possível (se possível), e na
troca da máquina aconselhamos a doá-las (ou vendê-las), ou até mesmo comprar
máquinas usadas se forem usadas apenas para trabalhar com sistemas de
documentação, digitação 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 máximo 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 evidências geradas

baseando-se na Declaração de Escopo deste projeto e no término da última
atividade descrita no Cronograma do Projeto.

O projeto será efetivado com sucesso se todos os objetivos definidos no

Termo de Abertura e Declaração de Trabalho foram alcançados e se todos os
requisitos do projeto foram atendidos.

Deve-se observar que a obtenção do selo de qualidade que comprova se a

organização observa e executa as práticas definidas no CMMI-DEV nível 2, não é a
única evidência de sucesso deste projeto, pois deve também ser observado se as
práticas trouxeram os benefícios esperados e que a satisfação da maioria seja
alcançada.
 28

XI. Aprovações

Tendo ciência da execução do projeto, dos prazos, dos custos e do

orçamento previstos de acordo com o que foi estabelecido neste Plano de Projeto,
firmamos o compromisso o mesmo:

APROVAÇÕES
Carlos Roberto de
Souza ___________________________ ____/_____/_____
Diretor Presidente da Software
Developer Assinatura Data

Valéria A. de Campos
Almeida ___________________________ ____/_____/_____
Gerente de Projetos Assinatura Data

Paulo Joaquim do Canto ___________________________ ____/_____/_____

Representante da Consulting Assinatura Data

Nota: Quaisquer alterações neste documento deverão ser submetidas ao

processo de controle de projeto.
 27

Conclusão

É importante que os gerentes de projeto reconheçam que não é possível

desenvolver sistemas de qualidade, cumprir prazos e custos e atender às
expectativas dos usuários sem ter um processo de desenvolvimento de requisitos
definido, compreendido e utilizado por todos os desenvolvedores.

Convém ressaltar que não existe um processo ideal que possa ser utilizado
em qualquer projeto. Será sempre necessário realizar adaptações, em função das
características do sistema, dos usuários, da equipe, da organização, 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 aplicação atende necessidades específicas de uma organização,
bem como o gerenciamento de contratos com fornecedores de diferentes tipos,
garantindo uma integração efetiva e harmoniosa.

Contudo, a vasta documentação e a abordagem ambígua dificultam a

implementação do CMMI, tornando a contratação de consultorias imprescindível em
muitos casos. Sendo assim, muitas organizações de pequeno porte jamais o
estudam, bloqueando a adoção do modelo por não dispor de verba para contratar
uma consultoria pelo prazo necessário. Uma vez estando no nível de maturidade 1,
todo esforço, prazo e verba é destinado para contornar problemas criados por
processos mal planejados e gerenciados.

A empresa analisada neste trabalho certamente encaixa-se neste cenário,

concentrando seus esforços na tentativa de contornar problemas, sem considerar a
adoção de uma metodologia que aprimore seus processos e, portanto, a qualidade
de seus produtos. A Consulting procurou orientá-los para utilizarem os
procedimentos do CMMI-DEV, visando obter produtos de qualidade, dentro das
normas internacionais, obtendo plena satisfação dos clientes.

Manifesto para o desenvolvimento ágil de software (Original em inglês)

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
 28

1. Indivíduos e interação entre eles mais que processos e ferramentas

2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda.

Princípios do manifesto do Software ágil

Nós seguimos os seguintes princípios:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e

contínua de software de valor.
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa tirar
vantagens competitivas.
• Entregar software funcionando com freqüência, na escala de semanas até
meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente
e suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e por dentro
de um time de desenvolvimento, é através de uma conversa cara a cara.
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente,
passos constantes.
• Contínua atenção a excelência técnica e bom design aumentam a agilidade.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou
ser feito.
• As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis.
 29

• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se

ajustam e otimizam seu comportamento de acordo.
 30

Referências

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.

Fábrica de Software - Definição da organização da fábrica por Tweets that mention–|

Caverna do Software —Fonte: <http://voat.com.br/rdal/?tag=qualidade> - acesso
10/12/10.

Gestão de Projetos de Sotfwares - Fonte:<http://www.sergiodias.inf.br/engenharia-

de-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 - Ministério de Ciência

e Tecnologia - Fonte:<http://www.mct.gov.br/upd_blob/0210/210931.pdf> - acesso
08/12/10.

Reunião de kickoff de um projeto Fonte:

<http://www.gpemdestaque.com.br/2010/05/10/reuniao-de-kick-off/> - 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 IMPLANTAÇÃO DO CMMI-DEV NÍVEL 2

DE MATURIDADE CONFORME O GUIA PMBOK Fonte:
<http://www.fatecjp.com.br/revista/tcc/gp01.pdf> - acesso 10/12/10.
 31

Informações sobre reciclagem

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

12/12/10.

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

acesso em 12/12/10.

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

Figuras

Figura 1- Obtido em: Pesquisa de Qualidade no setor de Software Brasileiro 2009 -

Ministério de Ciência e Tecnologia

Figura 2 – 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

Glossário

Ad-hoc - para um propósito/caso específico

RBS – Risk Breakdown Structure – ferramenta para identificação 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 decisões certas na hora certa.