Trabalho de Conclusão de Curso - Sexta Feira 22 CORRECOES

FACULDADE INTEGRADA DO RECIFE
CURSO DE SISTEMA DE INFORMAÇÃO
MARCELO THIAGO ANDRADE NOBRE

RENATO ALEXANDRE DE SALES
ANÁLISAR A VIABILIDADE PARA A IMPLANTAÇÃO DO MODELO DE

QUALIDADE DE DESENVOLVIMENTO DE SOFTWARE MPS.BR NÍVEL
G NO ORGÃO PÚBLICO ABC
RECIFE
2010
1
FACULDADE INTEGRADA DO RECIFE


RECIFE
2010
2

Monografia apresentada ao curso de sistemas

de informação com habilitação em engenharia
de software da Faculdade Integrada do Recife,
sob a orientação da Profª. Patrícia Moser,
como parte dos requisitos para a obtenção do
título de bacharel em sistemas de informação.
RECIFE
2010
3
TERMO DE APROVAÇÃO


_____________________________________
Profº(ª) Titulação e nome
Orientador – FIR
______________________________________
Profº(ª) Titulação e nome
Examinador – FIR
_____________________________________
Profº(a) Titulação e nome
4
AGRADECIMENTOS
Marcelo Nobre:
A meu pai, pelo apoio e incentivou em todos os momentos de minha vida.
Renato Sales:
A minha mãe e ao meu pai que sempre me acompanhou e deu-me força para enfrentar as
dificuldades.
A professora, Patrícia Moser agradecemos pela orientação e apoio que nos proporcionou estrutura
para concluir este projeto.
5
RESUMO
O objetivo deste trabalho é apresentar uma análise de viabilidade para a implantação do

MPS.BR Nível G como modelo de melhorias de processos de desenvolvimento de software no
órgão publico ABC.
Verifica-se que o ambiente de desenvolvimento de software no Brasil vem obtendo

crescimento significativo, tornando a área de desenvolvimento de software mais competitiva, e
para se obter sucesso neste âmbito a qualidade nos produtos desenvolvidos é uma das
características para. Analisando os modelos de qualidade que certificam empresas de software no
Brasil, identifica-se que o modelo de qualidade MPS.BR estabelece a melhor opção para pequenas
e medias empresas, assim facilitando a sua aquisição para o enriquecimento dos processos de
desenvolvimento de software.
Tendo esses dados levantados a pesquisa sugere que o órgão publico ABC adote o
MPS.BR nível G para otimizar sua produção, gerenciando pessoas, custos e cronogramas, onde
através de uma analise de ambiente foi constatado que, o atual ciclo de vida de software usado na
ABC não obtém qualidade necessária para atender os requisitos necessários do MPS.BR nível G,
assim com o apoio deste trabalho, o órgão ABC execute mudanças indicadas por esta pesquisa
tornando a empresa gerenciada e controlada para fabricar software com qualidade.
Palavras Chaves: Qualidade, ABC, MPS.BR, Processos, Modelo,Software
6
LISTA DE FIGURAS
Figura 2.2 - Níveis de avaliação da ISO 15504. ................................................................................................21

Figura 2.3 - Níveis de Maturidade e Níveis Capacidade. ..................................................................................23
Figura 2.4 - Equivalência entre os modelos CMMI e MPS.BR.........................................................................24
Figura 2.5 - Organograma da equipe de TI dO ORGÃO PÚBLICO ABC. ......................................................30
Figura 4.1 - Fluxograma ATUAL DE GERENCIA DE PROJETOS:...............................................................37
Figura 4.2 – Fluxograma PROPOSTO PARA Gerenciamento de Projetos ......................................................41
7
LISTA DE TABELAS
Tabela 2.4.1 ESTRUTURA DO MPS.BR. ........................................................................................................26
8
LISTA DE ABREVIATURAS E SIGLAS
MPS.BR – Melhoria de Processo do Software Brasileiro

CMMI - Capability Maturity Model Integration
ISO – International Organization for Standardization
ABES – Associação Brasileira de Empresa de Software
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro
ABNT – Associação Brasileira de Normas Técnica
SEBRAE – Serviço Brasiliero de Apoio as Micro e Pequenas Empresa
FINEP – Financiadora de Estudos e Projetos
MCT – Ministério da Ciência e Tecnologia
BID – Banco Interamericano de Desenvolvimento
TI – Tecnologia de Informática
AP – Atributo de Processo
RAP – Resultado do Atributo de Processo
SAD - Secretaria de Administração do Estado
9
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 PERGUNTA DE PESQUISA ............................................................................................. 16
1.2 OBJETIVO GERAL....................................................................................................... 16
1.3 OBJETIVOS ESPECÍFICOS ........................................................................................ 16
1.4 JUSTIFICATIVA ........................................................................................................... 16
1.5 ORGANIZAÇÃO DESTE DOCUMENTO.................................................................. 16
2 FUNDAMENTAÇÃO TEÓRICA ........................................................................................ 18
2.2 ISO/IEC 15504 – AVALIAÇÃO DO PROCESSO DE SOFTWARE ............................ 21
2.3 CMMI .................................................................................................................................. 22
2.4 MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO ........... 23
2.4.1 CONCEITOS IMPORTANTES DO MPS.BR NIVEL G ....................................... 25
2.4.2 PROCESSO DE GRP E GRE DO MPS.BR NIVEL G ........................................... 27
3 O ORGÃO PÚBLICO ABC E SUA PROBLEMÁTICA ................................................... 30
3.2 PONTOS FRACOS DO PROCESSO ........................................................................... 35
3.3 PROBLEMAS ENCONTRADOS ................................................................................. 35
4 RESULTADO ENCONTRADOS ......................................................................................... 37
4.1 GERÊNCIA DE REQUISITO ........................................................................................... 37
4.1.1 IDENTIFICAR E REGISTRAR REQUISITOS .......................................................... 37
4.1.2 DETALHAR REQUISITOS ........................................................................................... 38
4.1.3 VALIDAÇÃO DOS REQUISITOS COM O FORNECEDOR ................................... 39
4.1.4 ALTERAR REQUISITO ................................................................................................. 39
4.1.5 COMPROMETIMENTO DA EQUIPE TÉCNICA ...................................................... 39
4.1.6 PREPARAR O CRONOGRAMA DE DESENVOLVIMENTO E IMPLANTAÇÃO
..................................................................................................................................................... 39
4.1.7 ATUALIZAR PLANO DO PROJETO........................................................................... 40
4.1.7 FAZER ANALISE DE IMPACTO ................................................................................. 40
10
4.2 GERENCIA DE PROJETOS ............................................................................................ 40
4.2.1 DEFINIR REPOSITÓRIO DE DADOS ......................................................................... 40
4.2.2 ESTABELECER PLANO DE COMUNICAÇÃO......................................................... 41
4.2.3 DEFINIR ESCOPO DO PROJETO ............................................................................... 42
4.2.5 ALTERAR ESCOPO DO PROJETO............................................................................. 42
4.2.6 IDENTIFICAR REQUISITOS ........................................................................................ 43
4.2.7 DEFINIR PAPEIS, ESFORÇO E CUSTO..................................................................... 43
4.2.8 ESTABELECER CRONOGRAMA DAS ATIVIDADES ............................................ 44
4.2.9 LEVANTAR RISCOS DO PROJETO ........................................................................... 44
4.2.10 DEFINIR INFRA ESTRUTURA .................................................................................. 44
4.2.11 IMPLEMENTAR PROJETO ........................................................................................ 45
4.2.12 MONITORAR O ANDAMENTO DO PROJETO ...................................................... 45
4.2.13 REALIZAR FECHAMENTO DO PROJETO ............................................................ 46
5 CONCLUSÃO..................................................................................................................... 47
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 49
ANEXO 1 – REGISTRO DE REUNIÕES .............................................................................. 51
ANEXO 2 – MATRIZ DE RASTREABILIDADE ................................................................. 52
ANEXO 3 – TERMO DE ACEITE .......................................................................................... 53
ANEXO 4 – ATA DE REUNIÃO ............................................................................................. 54
ANEXO 5 – CRONOGRAMA .................................................................................................. 55
ANEXO 6 – CUSTO .................................................................................................................. 56
ANEXO 7 – PLANO DE COMUNICAÇÃO ........................................................................... 58
ANEXO 8 – ESCOPO DO PROJETO ..................................................................................... 63
ANEXO 9 – MATRIZ DE RESPONSABILIDADE ............................................................... 65
ANEXO 10 – RISCOS ............................................................................................................... 66
ANEXO 11 – STATUS REPORT ............................................................................................. 67
ANEXO 12 – TERMO DE ENCERRAMENTO .................................................................... 70
ANEXO 13 – TERMO DE ABERTURA ................................................................................. 71
11
ANEXO 14 - CARACTERISTICA DE QUALIDADE DE SOFTWARE ............................ 72
12
1 INTRODUÇÃO
A atividade de desenvolvimento de software no Brasil é umas das que mais cresce

segundo a ABES (Associação Brasileira de Empresas de software). Em 2008, a participação
de programas de computador desenvolvidos no país atingiu 32,5 % do total do mercado
brasileiro de software e, embora tenha representado uma participação ligeiramente menor do
que no ano anterior, ainda indica a tendência de crescimento que vem sendo apontada desde
2004, quando a participação era de 27%. Este mercado é explorado por quase 8.500
empresas, dedicadas ao desenvolvimento, produção e distribuição de software e de prestação
de serviços. Daquelas que atuam no desenvolvimento e produção de software, 94% são
classificadas como micro e pequenas empresas (ABES, 2009).
Observando os dados levantados pela ABES verifica-se o grande crescimento no

desenvolvimento de software no Brasil, para a maioria das organizações o software é sua
principal ferramenta de apoio dos seus negócios, o que o torna de extrema importância, assim
exigindo do software uma maior qualidade e confiabilidade no seu uso e na sua produção.
Mas, se acredita que, a qualidade do software está diretamente relacionada à qualidade

do processo de desenvolvimento, desta forma, é comum que a busca por um software de
maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.
Um processo de desenvolvimento é nada mais que é um conjunto de atividades e resultados
associados que produzem um produto de software (SOMMERVILLE, 1995).
Porém, muitas das empresas ainda não levam em conta a qualidade no processo de
desenvolvimento de seus softwares, acarretando em problemas já vistos anteriormente na
crise do software datada nos anos 70. Tais problemas podem ser indicados como (1)
estimativas de prazo e de custos frequentemente são imprecisas; (2) a produtividade das
pessoas da área de software não tem acompanhado a demanda por seus serviços; (3) a
qualidade de software as vezes é menos que adequada; e (4) o software existente é muito
difícil de manter. Os prazos arrastam-se por meses ou anos. Pouca coisa tem sido feita para
melhorar a produtividade dos profissionais da área de software. Os índices de erros para
novos programas causam insatisfação ao cliente e falta de confiança (PRESSMAN, 2006).
As dificuldades no desenvolvimento de sistemas começam durante as etapas iniciais

de um projeto. Um dos fatores que exerce influência negativa sobre a qualidade de um projeto
é a complexidade, que está associada ao tamanho das especificações, delimitar o escopo de
um sistema está longe de ser uma tarefa trivial. A volatilidade dos requisitos é um das maiores
causas de insucesso de projetos de software. Uma mudança nas necessidades declaradas por
um usuário pode repercutir em vários elementos da estrutura do programa. Mais tarde,
embora a solução tenha sido projetada, ainda não se conhecem de antemão e em detalhes os
algoritmos que efetivamente resolvem o problema. Em conseqüência, comumente se
considera que é bastante difícil prever como será o programa acabado e se o mesmo terá sua
funcionalidade acordada com os requisitos exigidos pelo cliente (KOSCIANSKI, ANDREO
2007).
Crescentes demandas de clientes e usuários e a maior complexidade das tecnologias
usadas para o gerenciamento da qualidade, exigindo das empresas maior confiabilidade,
menor custo e prazo, estão levando as organizações a se convencerem que a abordagem
artesanal no desenvolvimento e manutenção de software é um problema que precisa ser
abandonado, as mudanças que estão ocorrendo nos ambientes de negócios têm motivado as
empresas a modificar suas estruturas organizacionais, saindo da visão tradicional baseada em
áreas funcionais em direção a redes de processos bem definidos centrados no cliente visando
uma maior qualidade no escopo de seus projetos (SOFTEX, 2009).
A competitividade depende, cada vez mais, do estabelecimento de conexões nestas

redes, criando elos essenciais nas cadeias produtivas. Alcançar competitividade pela
qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos
de software e serviços correlatos, como dos processos de produção e distribuição de software.
Desta forma, assim como para outros setores, a qualidade é fator crítico de sucesso para a
indústria de software. Para que se tenha um setor de software competitivo, nacional e
internacional, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia
dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços
correlatos conforme padrões internacionais de qualidade (SOFTEX, 2009).
Nesse contexto pode ser percebida a importância de se ter um processo de

desenvolvimento de software para que a produção seja potencializada. Existem selos de
qualidade como o CMMI e MPS.BR que dão suporte a qualidade de processos e agem em
todas as etapas de produção de software, partindo do levantamento dos dados com o usuário
até a etapa de manutenção e suporte com o cliente.
14
O Modelo de qualidade CMMI foi desenvolvido para atender a solicitação do
departamento de defesa dos Estados Unidos. Desenvolvido por engenheiros, tem como
principal objetivo ser um modelo de referencia para a qualidade de processo na produção de
software mundial (OLIVEIRA, 2008).
Já o MPS.BR é dirigido pela Associação para Promoção da Excelência do Software
Brasileiro, a SOFTEX, que vem realizando esforços para obter o reconhecimento
internacional do MPS.BR como garantia de qualidade, uma vez que é um modelo equivalente
ao CMMI.
O MPS.BR é mais adequado a realidade brasileira se comparada ao CMMI, por

exemplo. Uma vez que é dividido em sete níveis, equivalentes ao CMMI, porém mais
adequado a realidade das empresas de micro e pequeno porte, que podem implantar o modelo
em etapas menores. Além disso, o MPS.BR custa em torno de quatro vezes menos que a
certificação CMMI (OLIVEIRA, 2008).
Para o escopo deste trabalho será abordado o MPS.BR como selo de qualidade na
produção de software no órgão público ABC.
Pelo que foi descrito acima e com os dados levantados através de reuniões e
questionários feitos nessa pesquisa qualitativa sobre o ambiente de desenvolvimento de
software no órgão público ABC verifica-se que a forma empírica e manual de produção de
software realizada pelo órgão público ABC tem a grande probabilidade de ter sérios
problemas nos seus procedimentos como exemplo a duplicidade de códigos, falta de
entendimento entre a equipe de desenvolvimento e a gerência, requisitos mal elaborados sem
levar em conta critérios intrínsecos da organização e a ausência de documentos que atestem os
comprometimentos entres os stakeholders.
Estes são alguns dos resultados da não aceitação de um modelo que associe a
modelagem e a criação de um processo para unificar todas as etapas de levantamento e
desenvolvimento de software. Com a adoção do MPS.BR o órgão público ABC passa a ter
um selo de qualidade de âmbito nacional que ateste o seu nível de qualidade em relação a sua
gerência de projetos e gerência de requisitos dando resultados excelentes e animadores para a
organização criando uma estrutura unificada e comprometida com a manutenção de
desenvolvimento de software.
15
1.1 PERGUNTA DE PESQUISA
Analisando todos os aspectos abordados acima, chegamos à seguinte pergunta de

pesquisa: Como melhorar a qualidade de processos e de software do órgão publico
ABC utilizando o modelo de qualidade MPS.BR ?
1.2 OBJETIVO GERAL

Analisar a viabilidade para a implantação do modelo de qualidade de desenvolvimento
de software MPS.BR nível G no órgão público ABC.
1.3 OBJETIVOS ESPECÍFICOS
 Compreender as normas do modelo o MPS.BR.

 Mapear os processos necessários para a implantação do MPS.BR nível G.
 Definir documentos que apóiem o gerenciamento de projetos.
1.4 JUSTIFICATIVA
Este estudo é relevante, pois comprova a eficácia da adoção do MPS.BR nível G
como modelo de qualidade de desenvolvimento de software no órgão público ABC, uma vez
que aplicado conforme as exigências do seu guia de implementação, uma empresa passa a ter
seus processos gerenciados por ferramentas e documentos que atestam a qualidade e a
seriedade do software e de todos os envolvidos no desenvolvimento de software da
organização, trazendo melhorias em aspectos tecnológicos e humanos.
A razão para adotar uma metodologia conhecida como o MPS.BR é que essa
metodologia já se mostrou eficiente em outras empresas de tecnologia do âmbito nacional, o
que reduz o tempo de implantação de um processo para desenvolvimento de software
(SOFTEX, 2009).
Além da qualidade, seguir uma metodologia conhecida é um diferencial competitivo
em relação a empresas que seguem metodologias próprias, que não são conhecidas ou que não
tem metodologias ou processos.
1.5 ORGANIZAÇÃO DESTE DOCUMENTO

Este trabalho está organizado em 5 capítulos.
O primeiro capítulo traz a introdução ao conteúdo a ser apresentado neste documento,
16
como a apresentação do tema, o objetivo geral, os objetivos específicos e justificativa.
O segundo capitulo elabora uma abordagem sobre a historia da qualidade, qualidade
de software, modelos de qualidade e o porquê da adoção do MPS.BR.
O terceiro capitulo traz uma análise de ambiente atual do setor de desenvolvimento de

sistemas no órgão público ABC levantando o processo atual bem como sua vulnerabilidade e
seus erros.
O quarto capitulo realiza a análise de viabilidade da adoção do MPS.BR pelo no órgão
público ABC criando uma nova estrutura de processos de desenvolvimentos de software
seguindo os padrões do MPS.BR
O quinto capitulo finaliza esse trabalho com uma visão geral e os propósitos atingidos
por está pesquisa.
No próximo capítulo será abordada a fundamentação teórica, compostas pelo conceito

de software, engenharia de software, a crise do software bem como etapas de evolução e o
ciclo de vida de um sistema de software, modelos de qualidade de desenvolvimento de
software como CMMI, ISO e MPS.BR e suas etapas do processo de implantação.
17
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são abordados aspectos referentes à fundamentação teórica que dará
embasamento a este estudo. Conceitos relacionados a qualidade de software,padrões de
qualidade serão discutidos, respectivamente, nas seções 2.1, 2.2 , 2.3 e 2.4.
2.1 UMA VISÃO GERAL DE QUALIDADE DE SOFTWARE
Segundo o SEBRAE a qualidade é um conjunto de características de todo produto e

serviço ou relação planejada, praticada e verificada, visando superar as expectativas de
satisfação das pessoas envolvidas (SEBRAE, 2010).
A origem da qualidade se deve ao grande desenvolvimento das organizações que houve no
marco da revolução industrial, esse período também é associado a profundas mudanças
econômicas e sociais,como o início da automação e o surgimento do consumo de massa.
Durante essa época de efervescência, milhares de novas empresas surgiram. A criação de
diversas indústrias levou rapidamente à concorrência entre elas, o que, por sua vez,
desencadeou um processo de melhoria contínua, passando da visão tradicional e mecanicista
para uma visão mais humana e sistêmica observando aspectos como qualidade de trabalho
que interferiam na fabricação do produto final (CHAVIENATO, 2004).
O grande marco histórico particular das empresas TI se dá nos anos 70, quando a
engenharia de software e a qualidade associada à produção do produto era praticamente
inexistente. O termo expressava as dificuldades do desenvolvimento de software frente ao
rápido crescimento da demanda por software, da complexidade dos problemas a serem
resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que
funcionassem adequadamente ou pudessem ser validados técnicas que garantisse a
qualidade.Com a crise do software foi necessária a criação de uma nova abordagem para o
desenvolvimento de software foi então que foi desenvolvida a disciplina de engenharia de
software (PRESSMAN, 2006).
A engenharia de software é a criação e a utilização de sólidos princípios de engenharia

a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em
maquinas reais. Uma definição mais abrangente é que a engenharia de software é uma
18
abordagem sistemática, disciplinada e quantificável, para desenvolvimento, operação e
manutenção do software, isto é a aplicação da engenharia ao software (PRESSMAN, 2006).
A engenharia de software compreende um conjuntos de etapas que envolvem controles,
métodos e ferramentas que são comumente chamado de ciclo de vida de um software, O ciclo
de vida de software tem a finalidade de definir as atividades a serem executadas na
organização por cada stakeholder e descrevem todas as fases, que abrange as seguintes etapas:
levantamento e análise de requisitos, projeto, implementação, testes e manutenção.
 Levantamento de Requisitos: É a fase em que o profissional de informática deve estar

diretamente ligado ao usuário. Exige um trabalho em equipe para a coleta das
necessidades do usuário em relação ao desenvolvimento do sistema em termos de:
funções, dados, escopo e hardware. Esses requisitos podem ser classificados
funcionais e não funcionais:
 Requisitos funcionais: devem descrever o que o software deverá fazer;
 Requisitos não funcionais: segurança, integridade, riscos e restrições e
problemas de negócio.
 Análise de requisitos: constitui a modelagem lógica do sistema. Nessa fase, os
requisitos levantados são transformados em modelos os quais representam o sistema
em nível conceitual. O resultado dessa fase deve ser um documento ou vários
documentos que sejam: inteligíveis, precisos, completos, consistentes, sem
ambigüidade e, facilmente modificáveis. Esses documentos servirão de instrumento de
comunicação entre desenvolvedores e usuários.
 Projeto: A fase de projeto permite que o software possa ser avaliado antes da
programação ter início, nessa fase os modelos conceituais são transformados em
modelos físicos, os quais devem estar mais próximos da implementação.
 Implementação: Tradução do projeto em uma forma que seja legível pela máquina.
 Testes: Os testes são realizados após a implementação. Os testes são feitos
internamente a um módulo, linha a linha, e também são feitos testes de integração dos
módulos.
 Manutenção: A fase de manutenção pode ser definida em:
 Corretiva: Erros podem ser encontrados durante o funcionamento do sistema.
19
 Adaptativa: O usuário pode propor alguma mudança a fim de acomodar
mudanças de procedimentos, como, por exemplo, nova versão do sistema
operacional etc.
 Preventiva: Alterar o sistema em função de mudanças necessárias para manter
sua confiabilidade e eficiência (PRESSMAN, 2006).
Mesmo com um paradigma de ciclos de vida de software os erros continuaram, pois

não se tinha uma definição de qualidade de software consistente que criasse normas e selos de
qualidades que atestassem as empresas que o seu desenvolvimento estava maduro o suficiente
para atender o mercado, o conceito de qualidade de software ainda estava confuso para o
mercado de TI onde a empresa e o cliente tinha entendimentos diferentes ocasionando sérios
erros e problemas no software (PRESSMAN, 2006).
A definição de qualidade de software segundo a norma ISO/IEC 9126 é que a
totalidade de características de um produto de software que lhe confere a capacidade de
satisfazer necessidades explícitas e implícitas. As necessidades explicitas são regras e objetivo
estabelecidos por aqueles que produzem o software,são portanto fatores relacionados a
qualidade do processo de desenvolvimento do produto e são percebidas pelas pessoas que
estão relacionadas diretamente com o desenvolvimento. As necessidades implícitas são
necessidades subjetivas dos stakeholders como usuários, operadores, clientes e mantenedores
do produto, também chamados de fatores externos.
As necessidades implícitas são caracterizadas também pela qualidade do uso do
software que devem permitir que o usuário tenha certa afetividade com uso do software como
requisitos de produtividade, segurança e satisfação (ABNT- ISO/IEC 9126, 2010).
A qualidade do software pode estar associada ao produto e ao processo em que o software é
produzido. A qualidade do produto pode ser vista como um conjunto de características que
devem ser alcançadas em um determinado grau, para que o produto atenda às necessidades de
seus usuários (ABNT- ISO/IEC 9126, 2010).
Cada característica pode ser detalhada chegando-se a um amplo conjunto de atributos,
que descrevem a qualidade do produto de software. Assim, é necessária a escolha de um
modelo que organize os atributos e permita avaliar a qualidade do software. A norma
ISO/IEC 9126 surgiu para consolidar as diferentes visões da qualidade de produto em um
modelo como norma internacional. A ISO/IEC 9126 lista um conjunto de características que
20
devem ser verificadas em um software para que ele seja considerado um "software de
qualidade".
São seis grandes grupos de características, cada um dividido em algumas sub-
características conforme vide (ANEXO 14 – CARACTERISTICAS DE QUALIDADE)
(ABNT- ISO/IEC 9126, 2010).
Para produzir software com qualidade precisa-se estar atento também na qualidade dos
processos de fabricação de software. Segundo a definição de PRESSMAN um processo de
software é um conjunto de ferramentas, métodos e práticas usadas para produzir software, a
qual pode ser representada por um conjunto seqüencial de atividades, objetivos,
transformações e eventos que integram estratégias para cumprimento da evolução de software
(PRESSMAN, 1995).
Atualmente existem diversos padrões e selos de qualidade que visam à certificação de
empresas de TI, criando uma estrutura de níveis de maturidade e atestando a qualidade de
processo de desenvolvimento de software ou serviço. Padrões como ISO 15504, CMMI e
MPS.BR estão sendo descritos na sessão 2.2, 2.3 e 2.4 desta pesquisa.
2.2 ISO/IEC 15504 – AVALIAÇÃO DO PROCESSO DE SOFTWARE

O ISO 15504 é uma norma que define um modelo de qualidade que tem o objetivo de
realizar avaliações de processos de software com o foco da melhoria dos processos,
identificando os pontos fracos e fortes, que serão utilizados para a elaboração de um plano de
melhorias.
Ultilizado como guia de referências de processos de ambito universal para a boa
prática da engenharia de software, onde define níveis de capacidade, seqüenciais e
cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização
está realizando um determinado processo (ISOSPICE, 2010).
FIGURA 2.2 - NÍVEIS DE AVALIAÇÃO DA ISO 15504.
21
Fonte: (ISOSPICE, 2010).
2.3 CMMI
O CMMI é um modelo de qualidade para desenvolvimento de software criado no ano
de 2000, foi idealizado a partir do modelo CMM com a adoção da norma ISO assim dando o
nome CMM-Integrated. O propósito do CMMI é estabelecer um guia para melhorar o
processo da organização e sua capacidade para gerenciar o desenvolvimento, aquisição e
manutenção de produtos e serviços.
A implantação do CMMI numa empresa segue um amadurecimento gradativo em
patamares de cinco níveis de maturidade, que determina qual é a capacitação do processo e a
maturidade que a organização possui para desenvolver software: nível inicial, repetível,
definido, gerenciado e otimizado. A maior parte dos padrões voltados a qualidade de software
possuem arquitetura similar ao do CMMI, utilizando a idéia de níveis de maturidade e
capacidade de processo (COUTO, 2007).
22
FIGURA 2.3 - NÍVEIS DE MATURIDADE E NÍVEIS CAPACIDADE.
Fonte (OLIVEIRA, 2008).
O modelo CMMI é proprietário e para a realização das avaliações do modelo, o custo

fica entre RS$200 mil a RS$1 milhão a depender da complexidade do processo.
Além disso, é necessário investir tempo, geralmente para se chegar aos níveis de
maturidade mais altos leva em média 4 a 8 anos. Essas dificuldades contrastam com a
realidade das empresas brasileiras que não podem realizar um investimento tão alto na
obtenção da certificação (OLIVEIRA, 2008).
2.4 MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO

O MPS.BR é um programa de melhoria no processo de software brasileiro, criado em
dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software
Brasileiro(SOFTEX), que conta com apoio do Ministério da Ciência e Tecnologia (MCT),
Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID).
23
FIGURA 2.4 - EQUIVALÊNCIA ENTRE OS MODELOS CMMI E MPS.BR.
Fonte: (OLIVEIRA, 2008).

O MPS.BR estabelece sete níveis de maturidade que mostram os patamares da
evolução dos processos da organização, caracterizados pelos estágios de implementação de
melhorias nos processo da organização.(SOFTEX, 2009). Os níveis de maturidade são os
seguintes:
A – Em otimização – Equivalente ao nível 5 CMMI;
B – Gerenciado Quantitativamente – Equivalente ao nível 4 do CMMI;
C – Definido – Equivalente ao nível 3 do CMMI;
D – Largamente Definido – Parcialmente de acordo com o nível 3 do CMMI;
E – Parcialmente Definido - Parcialmente de acordo com o nível 3 do CMMI;
F – Gerenciado – Equivalente ao nível 2 do CMMI;
G – Parcialmente Gerenciado - Parcialmente de acordo com o nível 2 do CMMI;
A organização obtém determinado nível de maturidade quando atende aos propósitos
de todos os resultados esperados nos processos e atributos de processo do respectivo nível de
maturidade. A divisão em estágio tem graduação diferente para possibilitar mais etapas
durante a implementação, mais adequado ao contexto das micro, pequenas e médias empresas.
Além disso, ter mais níveis possibilita que os resultados de melhorias sejam visualizados mais
rapidamente (SOFTEX, 2009).
24
2.4.1 CONCEITOS IMPORTANTES DO MPS.BR NIVEL G
A seguir será apresentado um glossário com algumas nomenclaturas usadas no MPS.BR.

 Atributo de processo é Qualquer coisa que a organização considere útil para atingir
os objetivos do processo, por exemplo, políticas, processos definidos, lições
aprendidas, modelos de documentos, padrões, material de treinamento (SEI, 2006).
 Avaliação de processo: Uma avaliação disciplinada dos processos da organização em
relação a um modelo de avaliação de processo (ISO/IEC, 2004).
 Ativo de processo: Qualquer coisa que a organização considere útil para atingir os
objetivos do processo, por exemplo, políticas, processos definidos, lições aprendidas,
modelos de documentos, padrões, material de treinamento (SEI, 2006).
 Nível de maturidade: Grau de melhoria de processo para um predeterminado
conjunto de processos no qual todos os resultados esperados do processo e dos
atributos dos processos são atendidos.
 Processo: Um conjunto de atividades inter-relacionadas ou interativas, que transforma
insumos (entradas) em produtos (saídas) (ABNT, 2001).
 Processo definido: Um processo que é gerenciado (planejado, monitorado e ajustado)
e adaptado de um conjunto de processos-padrão de acordo com os guias de adaptação
da organização (ISO/IEC, 200).
 Capacidade do processo: Uma caracterização da habilidade do processo atingir aos
objetivos de negócio atuais ou futuros (ISO/IEC, 2004).
25
A tabela 2.4.1 mostra os processos utilizados por cada nível do MR-MPS. Cada
processo possui suas práticas próprias e os resultados esperados de sua aplicação. Esses
resultados contribuirão para que o atributo do processo seja verificado.
TABELA 2.4.1 ESTRUTURA DO MPS.BR.

Níveis Processos Atributos de Processo (AP)
A – 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*,

4.2*, 5.1* - o processo é
objeto de melhorias e
inovações, 5.2* - o
processo é otimizado
continuamente
B Gerência de Projetos – GPR (evolução) 1.1, 2.1, 2.2, 3.1, 3.2, 4.1* - o
processo é medido, 4.2* -
o processo é controlado
C Gerência de Riscos – GRI,
Desenvolvimento para
Reutilização – DRU, Gerência de 1.1, 2.1, 2.2, 3.1, 3.2
Decisões – GDE
D Verificação – VER, Validação – VAL,
Projeto e Construção do Produto
– PCP, Integração do Produto – 1.1, 2.1, 2.2, 3.1, 3.2
ITP, Desenvolvimento de
Requisitos - DRE
E Gerência de Projetos – GPR

(evolução), Gerência de
Reutilização – GRU, Gerência de 1.1, 2.1, 2.2, 3.1 – o processo é
Recursos Humanos – GRH, definido, 3.2 – o
Definição do Processo processo está
Organizacional – DFP, Avaliação implementado
e Melhoria do Processo
Organizacional – AMP
F Medição – MED, Garantia da
Qualidade – GQA, Gerência de 1.1, 2.1, 2.2 – os produtos de
Portfólio de Projetos – GPP, trabalho do processo são
Gerência de Configuração – gerenciados
GCO, Aquisição - AQU
G Gerência de Requisitos – GRE,

Gerência de Projetos - GPR 1.1 – o processo é executado,
2.1 – o processo é gerenciado
Fonte: (SOFTEX, 2009).
26
No MPS. BR existem diferentes níveis de capacidade dos processos são descritos por
nove atributos de processo (AP). O alcance de cada atributo de processo é avaliado utilizando
os respectivos resultados esperado de atributo de processo (RAP), conforme definido a seguir:
2.4.1.1 AP 1.1 O PROCESSO É EXECUTADO
Este atributo é uma medida do quanto o processo atinge o seu propósito.
Resultado esperado:
 RAP 1. O processo atinge seus resultados definidos.
2.4.1.2 AP 2.1 O PROCESSO É GERENCIADO
Este atributo é uma medida do quanto a execução do processo é gerenciada.
Resultados esperados:
 RAP 2. Existe uma política organizacional estabelecida e mantida para o
processo;
 RAP 3. A execução do processo é planejada;
 RAP 4. (Para o nível G) A execução do processo é monitorada e ajustes são
realizados;
 RAP 5. (Até o nível F) As informações e os recursos necessários para a execução
do processo são identificados e disponibilizados;
 RAP 6. (A partir do nível E) Os recursos e informações necessários para executar
o processo definido são disponibilizados, alocados e utilizados;
 RAP 7. (Até o nível F) As responsabilidades e a autoridade para executar o
processo são definidas, atribuídas e comunicadas;
 RAP 8. (A partir do nível E) Os papéis requeridos, responsabilidades e
autoridade para execução do processo definido são atribuídos e comunicados;
 RAP 9. (Até o nível F)7 As pessoas que executam o processo são competentes
em termos de formação, treinamento e experiência;
 RAP 10. A comunicação entre as partes interessadas no processo é gerenciada de
forma a garantir o seu envolvimento;
2.4.2 PROCESSO DE GRP E GRE DO MPS.BR NIVEL G

Cada processo tem um propósito e seus resultados esperados. No nível G, estão os
processos Gerência de Projetos e Gerência de Requisitos. Os atributos de processo a serem
atendidos nesse nível são o AP 1.1 e AP 2.1, conforme citado anteriormente.
27
2.4.2.1 GERÊNCIA DE PROJETOS
Propósito do processo de gerência de projetos é estabelecer e manter planos que
definem as atividades, recursos e responsabilidades do projeto, bem como prover informações
sobre o andamento do projeto que permitam a realização de correções quando houver desvios
significativos no desempenho do projeto. O propósito deste processo evolui à medida que a
organização cresce em maturidade (SOFTEX, 2009).
Resultados esperados:
 GPR 1. O escopo do trabalho para o projeto é definido;
 GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando
métodos apropriados;
 GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;
 GPR 4. (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos
de trabalho são estimados com base em dados históricos ou referências técnicas;
 GPR 4. (A partir do nível E) O planejamento e as estimativas das atividades do projeto
são feitos baseados no repositório de estimativas e no conjunto de ativos de processo
organizacional;
 GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e mantidos;
 GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados;
 GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o
conhecimento necessários para executá-lo;
 GPR 8. Os recursos e o ambiente de trabalho necessário para executar o projeto são
planejados;
 GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma
de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-
los, incluindo, se pertinente, questões de privacidade e segurança;
 GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração
de planos específicos;
 GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os
recursos disponíveis, é avaliada. Se necessário, ajustes são realizados;
28
 GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso
com ele é obtido; GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e
outros planos que afetam o projeto e os resultados são documentados;
 GPR 14. O envolvimento das partes interessadas no projeto é gerenciado;
 GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no
planejamento;
 GPR 16. Registros de problemas identificados e o resultado da análise de questões
pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes
interessadas;
 GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a
repetição dos problemas identificados são estabelecidas, implementadas e
acompanhadas até a sua conclusão;
2.4.2.2 GERÊNCIA DE REQUISITOS
Propósito da Gerência de Requisitos é gerenciar os requisitos do produto e dos
componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos
do projeto e os produtos de trabalho do projeto (SOFTEX, 2009).
Os resultados esperados:
 GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de
requisitos, utilizando critérios objetivos;
 GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido;
 GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é

estabelecida e mantida;
 GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando

identificar e corrigir inconsistências em relação aos requisitos;
 GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
29
3 O ORGÃO PÚBLICO ABC E SUA PROBLEMÁTICA
Neste capítulo são abordados aspectos referentes à qual metodologia usada para
encontrar os problemas no ambiente atual de desenvolvimento de software no órgão público
ABC que dará embasamento a este estudo. Conceitos relacionados à análise de ambiente, o
processo atual de desenvolvimento, pontos fracos do processo e erros encontrados, são
relatados respectivamente, nas seções 3.1, 3.2, 3.3 e 3.4.
3.1 ANÁLISE DE AMBIENTE
O órgão publico ABC é uma entidade autônoma, com personalidade jurídica de direito
público, integrante da administração indireta do Governo do estado de Pernambuco.
Em sua estrutura organizacional existe o setor de TI responsável por dar suporte e
desenvolver novas soluções para dar apoio aos processos internos da ABC.
Atualmente a equipe de TI da ABC é formada pelo organograma exibido na figura 3.1.
FIGURA 3.1 - ORGANOGRAMA DA EQUIPE DE TI DO ORGÃO PÚBLICO ABC.
Fonte: Dados levantados junto ao setor de TI do órgão público ABC.
30
A seguir será apresentado cada integrante da equipe de TI bem como suas atividades e
responsabilidades.
Coordenador de Projetos e Equipes: Tem o papel de gerenciar novos e antigos
projetos e coordenar a equipe de suporte ao usuário e desenvolvimento de sistemas, assim
recebendo requisições por parte dos outros setores do órgão público ABC para criar novos
projetos e funcionalidades gerenciando tempo e custo nos seu desenvolvimento.
Administrador de Redes: Responsável por gerenciar toda a parte de infra-estrutura
desde cabeamento a servidores de dados.
Suporte ao usuário: Responsável por receber reclamações de usuários de sistemas e
redes dando a ajuda necessária a problemas relacionados a operacionalização de sistemas
internos, redes e sistemas operacionais.
Manutenção: Realiza toda a manutenção necessária em computadores e impressoras
no nível de hardware como problemas de memória de computador, recuperação de dados
perdidos e instalação de programas e drivers.
Analista de Sistemas: Responsável por analisar, desenvolver, testar e implantar
sistemas de dados internos do órgão público ABC, realizando a codificações de requisitos
para programas de computadores a partir de solicitação dos usuários e da coordenação TI.
A definição de um padrão de qualidade foi crucial para fazer uma analise previa do
que seria refeito no órgão publico ABC, analisando os modelos relatados na seção 2.2, 2.3 e
2.4 verifica-se que o modelo MPS.BR é mais viável para o órgão público ABC uma vez que
os custos envolvidos na sua implantação são mais acessíveis comparando com CMMI e ISO.
Para uma organização governamental de pequeno porte, o custo é fator decisivo de
escolha, levando em conta que o MPS.BR é uma metodologia legitimamente brasileira onde
suas documentações são em português e sua missão é atender pequenas e medias empresas de
software.
Para criar a análise do ambiente atual de desenvolvimento do órgão público ABC, foi
necessário o agrupamento de todos os artefatos que ajudassem nesse levantamento
bibliográfico, contendo documentos como email, solicitações de usuários, acervo de
31
problemas dos sistemas do órgão público ABC, assim criando uma pesquisa qualitativa
coletando dados em reuniões, conversas com a coordenação da informática, setores e analistas
de sistemas dando ênfase em aspectos de gerência de requisitos e gerência de projetos que são
os necessários para o nível G do MPS.BR. que serão abordados nos nas sessões 3.1.1 e 3.1.2.
3.1.1 GERÊNCIA DE REQUISITOS
Foi verificado que o ambiente atual de desenvolvimento de software no órgão público

ABC encontra-se espalhado de forma a que documentos obtidos de um mesmo requisito
tinham entendimentos diferentes e linguagens diferentes entre setores da empresa,
coordenadoria de TI e equipe de desenvolvimento, acarreando em sérios problemas de
requisitos finalizados que entravam em contradição com o que foi pedido pelos setores do
órgão público ABC o órgão público ABC. Um outro ponto fraco encontrado foi a falta de
comprometimento entre os stakeholders do projeto, como a excessividade de alterações no
escopo do projeto e na especificação funcional de um requisito, ocasionando um certo stress
entre equipe de desenvolvimento e coordenadoria, onde o problema estava localizado na
elaboração de um documento no qual o solicitante do projeto concorda com os requisitos
solicitados bem como a forma a ser desenvolvida.
A ausência de uma ferramenta que auxilie no gerenciamento de requisitos é outro

problema encontrado nesse levantamento. Com o uso de uma ferramenta todos os
stakeholders teriam acesso a mesma visão do escopo de um projeto e todos os seus requisitos,
verificando detalhes pertinentes como status de cada requisito, observações encontradas
durante o processo, prazo de entrega e anexos com documento e planilhas e imagens que
ajudem no entendimento. Assim com uma simples adoção de uma ferramenta, o impacto e
inconformidades entre os envolvidos no processo são reduzidos potencialmente.
3.1.2 GERÊNCIA DE PROJETOS
Verifica-se no órgão público ABC que não há uma cultura de gerenciamento de

projetos onde os documentos bem como problemas e lições aprendidas de cada projeto não
são catalogadas, assim mantendo um registro histórico, permitindo que pessoas envolvidas em
novos projetos tenham uma fonte de soluções para possíveis problemas acontecidos
32
anteriormente. Com a ausência e a despadronização de processos, cada projeto pode seguir
caminhos diferentes tornando o resultado final uma caixa de surpresa, podendo criar
insegurança e insatisfação com os gestores e usuário no órgão público ABC.
Com a ausência de metodologias que auxilie no acompanhamento de um projeto as

dificuldades só tende a crescer, a falta de formalização e apresentação inicial e final de um
projeto causa duvidas a quem vai trabalhar especificamente num requisito do projeto como no
caso dos analistas de sistema. Observa-se que questões de extrema importância eram obtidas a
parti da intuição humana e muitas vezes elaboradas por uma única pessoa envolvida do
projeto.
Observa-se que com os dados levantados nos itens 3.1.1 e 3.2.1 a maior parte dos
problemas de desenvolvimento de software do órgão público ABC se deve pela falta de uma
gerência de requisitos. Com a adoção de técnicas de elicitação de requisitos, a elaboração de
documentações e um processo de gerenciamento de requisitos já alcançariam um bom nível
de maturidade, mas não descartando a utilização de técnicas de gerenciamento de projeto.
Na sessão 3.2 apresenta-se um processo que foi mapeado no órgão público ABC, com
uma visão macro de como os projetos são desenvolvidos.
O PROCESSO ATUAL
Atualmente no órgão público ABC não existe nenhum tipo de processo mapeado.
Consegui-se obter um processo misto onde existem etapas que visam a gerência de requisitos
e etapas que atende a gerência de projetos.
O Processo foi mapeado baseado na experiência dos profissionais no órgão público
ABC e em documentações e reuniões junto com o coordenador de TI, e dependendo da
necessidade os stakeholders eram convocados para darem sua contribuição. Como resultado
das reuniões de mapeamento foi obtido um fluxograma exibido na figura 3.2.
33
Figura 3.2 - Fluxograma da área de TI no órgão público ABC.
Fonte: Dados levantados junto ao setor de TI no órgão público ABC.
Com este fluxograma visualiza-se o processo de gerência de projeto no órgão público

ABC, onde para cada atividade descreve-se como este processo é executado na instituição.
3.1.3 REGISTRAR SOLICITAÇÃO

Nessa atividade o coordenador de TI recebe a solicitação através de email, telefone, ou
documento, e analisa a viabilidade de produção, se a sua decisão for de aceitação o fluxo
passa para o próximo item senão o fluxo dirige para o estado final.
3.2.2 ANALISAR IMPACTO
Está atividade é feita pelo próprio analista de sistemas junto com a gerente de TI.
Juntos analisam empiricamente o impacto da mudança solicitada e onde será o impacto do
requisito solicitado se a sua decisão for de aceitação o fluxo passa para o próximo item senão
o fluxo dirige para o estado de alteração da solicitação.
3.2.3 ALTERAÇÃO DA SOLICITAÇÃO
O Coordenador de TI toma conhecimento da alteração do requisito e define junto aos
usuários e demandadores de requisitos se a alteração pode ser feia caso não exista um
entendimento o fluxo passa para o próximo item senão o fluxo dirige para o estado final.
34
3.2.4 DESENVOLVIMENTO
Está fase é feita pelo analista de sistemas codificando o requisito em linguagem de
maquina tornando um produto ou funcionalidade do sistema. Ao termino dessa etapa o fluxo
passa para o próximo estado.
3.2.5 IMPLANTAÇÃO
Realizada pelo analista de sistemas, caracteriza pelo estado final onde o usuário e
demandante de requisitos toma conhecimento do que foi feito ao longo do processo.
3.2 PONTOS FRACOS DO PROCESSO

Observa-se que o processo atual no órgão público ABC é totalmente imaturo, baseado
nas regras do Nível G do MPS.BR para avaliar um processos de software, verifica-se
inconsistências e características de um processo mal elaborado.
 O Processo não é rigorosamente seguido e o cumprimento não é controlado.

 O Processo é dependente dos profissionais atuais.
 O Processo é constantemente alterado para atender necessidades do projeto.
 A Funcionalidade e a qualidade do produto final podem ficar comprometidas
para que prazos sejam cumpridos.
 A Qualidade do projeto difícil de prever.
 O Processo não é documentado.
 Não existe divisão de competência técnica na etapa de desenvolvimento e
implantação de software.
3.3 PROBLEMAS ENCONTRADOS

Observando os dados levantados nos itens 3.1 e 3.2 deste capitulo, verificam-se
diversos problemas tanto no nível de processo como de estrutura organizacional da empresa,
onde os problemas gerais serão relatados nesta sessão.
 Ausência de documentos de requisitos:
 Os requisitos desenvolvidos estão em conflito com o que foi pedido
35
 Ausência de manual de desenvolvimento
 Ausência de um meio comum de veiculação e armazenagem das

informações (intranet, banco de dados, etc.);
 Replicação de requisitos por parte dos analistas de sistemas
 Estimativas de prazo e custo mal elaboradas usando a intuição humana
 Excesso de alteração de escopo;
 Não existem ferramentas que der apoio ao gerenciamento de requisitos e

gerenciamento de projeto.
 Não existe termo de abertura de projeto
Hoje a estrutura no órgão público ABC está conforme foi listado acima, sem seguir
critérios de qualidade de desenvolvimento, ocasionando perda de produtividade. A falta de
gerência de projeto sem critérios de qualidade faz com que o tempo não seja definido de
forma satisfatória e também não existe um plano de comunicação que hoje ocasiona muito
retrabalho. Com este resumo pode-se visualizar e até mesmo planejar as mudanças cabíveis
que é o intuito do nosso trabalho.
No capitulo 4, dar-se-á prosseguimento aos passos para a análise de viabilidade

implantação do MPS.BR nível G.
36
4 RESULTADO ENCONTRADOS
Neste capítulo são abordados aspectos referentes aos resultados encontrados nesta
pesquisa a serem proposta no órgão público ABC. Conceitos relacionados a gerencia de
projetos, gerência de requisitos e utilização de ferramentas de apoio, são relatados
respectivamente, nas seções 4.1, 4.2 e 4.3.
4.1 GERÊNCIA DE REQUISITO

O processo de gerencia de requisitos possui atividades como definição, elicitação,
acompanhamento, documentação e rastreamento de solicitação. Para um gerenciamento
eficiente de requisitos deve-se incluir um documento padrão ou ferramenta para monitorar os
requisitos onde também possa fazer a rastreabilidade para outros requisitos. Utiliza-se uma
ferramenta para gerenciar os requisitos onde a mesma atende a boa parte dos GREs.
Após definir a ferramenta que será utilizada, cria-se um processo de gerência de

requisitos que tem o intuito de assegurar que qualquer mudança nos requisitos do sistema seja
analisada de forma que o impacto das mudanças seja conhecido e tratado. O processo de
Gerência de Requisitos pode ser visualizado na figura 4.1:
4.1.1 IDENTIFICAR E REGISTRAR REQUISITOS

Para a atividade de identificar e registrar os requisitos o analista de sistema deve
registrar o pedido do cliente informando se o status é de dúvida, solicitação ou mudança de
requisitos. Depois de o pedido ser registrado o analista encaminha para o gerente de projetos
que informa a prioridade da solicitação e registra na ferramenta de gerencia de requisitos e
encaminha para seu detalhamento. Está atividade tem a finalidade de garantir que os
requisitos estejam claramente entendidos entre as partes interessadas e documentadas
(ANEXO 1 – REGISTRO DE REUNIÕES).
Resultados Esperados Atendidos:
 GRE1- Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores
de requisitos, utilizando critérios objetivos
FIGURA 4.1 - FLUXOGRAMA ATUAL DE GERENCIA DE PROJETOS:
37
Fonte: O próprio
4.1.2 DETALHAR REQUISITOS

Está atividade tem a finalidade de rastrear o impacto de cada requisito solicitado onde
se deve prover de um mecanismo bidirecional entre os requisitos e o produto do trabalho, está
atividade não exigi que um sistema que rastreia os requisitos e sim de um mecanismo que
possibilite encontrar o impacto de cada requisito no produto do trabalho. Está atividade
também avalia que tipo de requisito que está sendo analisado, podendo ser funcional ou não-
funcional. está é onde gerente de projeto encaminha a solicitação para um analista de sistema
para que o mesmo detalhe o requisito. É aqui que o gerente de projeto adiciona o novo
requisito na matriz de rastreabilidade (ANEXO 2 – MATRIZ DE RASTREABILIDADE),
onde se tem um cruzamento dos requisitos e qual classe ou artefato vai impactar.

de requisitos, utilizando critérios objetivos.
 GRE3- A rastreabilidade bidirecional entre os requisitos e os produtos de

trabalho é estabelecida e mantida.
38
4.1.3 VALIDAÇÃO DOS REQUISITOS COM O FORNECEDOR
Está atividade tem a finalidade comprovar o entendimento do requisito junto ao
fornecedor do requisito o mesmo deve estar definido no documento de aceitação.Para está
atividade propor um documento chamado Termo de Aceite (ANEXO 3 – TERMO DE
ACEITE) onde o fornecedor de requisitos e o analista assinam um termo mostrando que estão
cientes do requisito solicitado.

de requisitos, utilizando critérios objetivos.
4.1.4 ALTERAR REQUISITO

Está atividade tem por finalidade de corrigir e refinar o requisito ate chega-se à
aprovação definitiva do fornecedor dos requisitos.
Para está atividade de alteração dos requisitos utiliza-se a ferramenta de gerencia de
requisitos e mudar o status da solicitação.
4.1.5 COMPROMETIMENTO DA EQUIPE TÉCNICA

Está atividade tem a finalidade de comprometer a equipe técnica, comprovando que as
partes interessadas estão conscientes do requisito solicitado, e onde será formalizado
utilizando alguma ferramenta, email, ata de reunião (em anexo) ou algum mecanismo que
assegure que as partes estão comprometidas. Para está atividade solicita-se um envio de email
e/ou o preenchimento da ata de reunião (vide ANEXO 4 – ATA DE REUNIÃO).
 GRE1- O comprometimento da equipe técnica com os requisitos aprovados é

obtido.
4.1.6 PREPARAR O CRONOGRAMA DE DESENVOLVIMENTO E IMPLANTAÇÃO

Está atividade descreve o tempo e recurso necessário para realização e implantação
dos requisitos solicitados (vide ANEXO 5 – CRONOGRAMA).
39
4.1.7 ATUALIZAR PLANO DO PROJETO
Caso as modificações discutidas na atividade anteriores tenha impacto no plano do
projeto o mesmo é atualizado pelo Gerente de Projetos onde deve modificar Plano de Projeto
para contemplar as modificações requisitadas. Para está atualização utiliza-se uma ferramenta
que nos auxilia no acompanhamento do projeto.
 GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas

visando a identificar e corrigir inconsistências em relação aos requisitos
4.1.7 FAZER ANALISE DE IMPACTO

Está atividade visa criar um histórico de mudanças de requisitos. Este histórico deve
ser criado por meio de realização de análises de impacto da mudança no projeto e podem
incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço,
cronograma, riscos e custo (vide ANEXO 6 E 5 – RISCO E CRONOGRAMA).
 GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto
4.2 GERENCIA DE PROJETOS

O Propósito do processo gerência de projetos é estabelecer e manter planos que
definem as atividades, recursos e responsabilidades do projeto, bem como prover informações
sobre o andamento do projeto que permitam a realização de correções quando houver desvios
significativos no desempenho do projeto. O processo de gerência de projeto pode ser
visualizado na figura 4.2:
4.2.1 DEFINIR REPOSITÓRIO DE DADOS

Verificar se existe algum planejamento sobre gerenciamento de dados que relacione
todos os documentos gerados no projeto, a sua identificação, coleta, armazenamento, sua
distribuição, mídia para armazenamento, forma de proteção (segurança e sigilo) e recuperação
dos dados. para está atividade pode ser disponibilizada uma ferramenta ou uma pasta na rede
da organização para publicar os artefatos para os seus devido responsável.está pasta ou
ferramenta deve ser institucionalizada na organização para que não entre em desuso entre os
seus envolvidos.
40
 GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à
forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido
para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.
FIGURA 4.2 – FLUXOGRAMA PROPOSTO PARA GERENCIAMENTO DE PROJETOS
Fonte: O próprio
4.2.2 ESTABELECER PLANO DE COMUNICAÇÃO

Verificar se os acordos assumidos pelas partes interessadas estão sendo cumpridos ou
negociados, sendo eles internos ou externos, tendendo identificar aqueles que não foram
satisfeitos ou ainda os que têm um grande risco de não serem satisfeitos. para está atividade
tem-se que analisar a situação atual e estabelecer uma estratégia onde a organização deve
assumir e institucionalizar tornando a comunicação mais descentralizada e não deixando ser
criado ilhas na organização (vide ANEXO 7 – PLANO DE COMUNICAÇÃO).

 GPR14 - O envolvimento das partes interessadas no projeto é gerenciado.
41
4.2.3 DEFINIR ESCOPO DO PROJETO
Verificar se a declaração de escopo foi detalhada para o projeto, definindo em alto nível, o
que vai ser realizado pelo projeto e incluindo as limitações do projeto. Está finalidade
descreve todos os produtos de um projeto, serviços necessários para realizá-los e os resultados
esperados. Também descreve como o projeto será realizado para que alcance seus objetivos
com os recursos e funções especificados (vide ANEXO 8 – ESCOPO DO PROJETO).

 GPR1 - O escopo do trabalho para o projeto é definido
 GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos
4.2.4 ELABORAR ABERTURA DO PROJETO (KICK OFF)
Essa é a atividade que é apresentada o Plano de Projeto para a equipe técnica do

projeto, fornecedores de requisitos e direção dos setores no órgão público ABC envolvidos no
projeto. Essa atividade serve para que as pessoas conheçam o plano do projeto, discutam e
sugiram modificações para em seguida registrar o seu comprometimento com o plano do
projeto (vide ANEXO 13 – TERMO DE ABERTURA).

 GPR12 - O Plano do Projeto é revisado com todos os interessados e o
compromisso com ele é obtido.
4.2.5 ALTERAR ESCOPO DO PROJETO

Essa atividade tem o propósito de alterar artefatos e registrar solicitações de melhorias
encontradas entre os stakeholders na reunião de comprometimento com o escopo do projeto.
(vide ANEXO 8 – ESCOPO DO PROJETO).

 GPR12 - O Plano do Projeto é revisado com todos os interessados e o
compromisso com ele é obtido.
42
4.2.6 IDENTIFICAR REQUISITOS
O propósito do processo gerência de requisitos é gerenciar os requisitos do produto e
dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os
planos do projeto e os produtos de trabalho do projeto.
 GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos
fornecedores de requisitos, utilizando critérios objetivos.
 GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é
obtido.
 GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho é estabelecida e mantida.
 GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas

visando a identificar e corrigir inconsistências em relação aos requisitos.
 GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto.
4.2.7 DEFINIR PAPEIS, ESFORÇO E CUSTO

Espera-se nessa atividade definir superficialmente o tempo total para a execução do
projeto, assim como o esforço de cada papel para executar as atividades do projeto. Para essa
atividade é necessário que se saiba as atividades do projeto, mesmo que superficialmente. A
execução dessa atividade inicia com o gerente de projetos, baseado no escopo do projeto,
definindo as atividades do projeto e registrando-as no sistema de gerenciamento de projetos.
Em seguida deve ser estimado o esforço para realizar cada atividade do projeto. Após definido
o esforço para executar cada tarefa, deve ser identificado quais papéis, como analistas de
sistemas, certificadores e gerencia de banco de dados para realizar as atividades do projeto.
Após essas etapas o gerente de projetos pode definir a duração do projeto.
(vide ANEXO 5, 6 E 9 – CRONOGRAMA, CUSTO, MATRIZ DE

RESPONSABILIDADE).
 GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados
43
utilizando métodos apropriados.
 GPR4 - O esforço e o custo para a execução das tarefas e dos produtos de
trabalho são estimados com base em dados históricos ou referências técnicas.
 GPR7 - Os recursos humanos para o projeto são planejados considerando o
perfil e o conhecimento necessários para executá-lo.
4.2.8 ESTABELECER CRONOGRAMA DAS ATIVIDADES

Para cria o cronograma do projeto o gerente de projetos estabelece a dependência entre
as atividades para poder determinar o menor tempo de execução do projeto. Após essa etapa,
o gerente de projetos estabelece as datas para início e fim de cada atividade. Essa etapa
acontece no sistema de gerenciamento de projetos, a partir da WBS previamente estabelecida
(vide ANEXO 5 – CRONOGRAMA).
 GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de

marcos e pontos de controle, são estabelecidos e mantidos.
4.2.9 LEVANTAR RISCOS DO PROJETO

A atividade de planejamento de riscos significa identificar o maior número de
possíveis riscos aos qual o projeto estará exposto ao longo de sua execução.
Para isso foi criada uma lista com os riscos mais comuns, que é acessada para que sejam
selecionados os riscos a qual o projeto em planejamento estará exposto. Após identificação
dos riscos, é feito os registros no sistema de gerenciamento de projetos para que sejam
classificados quanto ao seu impacto, à probabilidade e a prioridade. (ANEXO 10 – RISCO).
 GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade

de ocorrência e prioridade de tratamento são determinados e documentados.
4.2.10 DEFINIR INFRA ESTRUTURA

É nessa atividade que se deve planejar e alocar a infra-estrutura necessária para o
projeto. Essa atividade é realizada baseada em um checklist em que constam todos os
recursos físicos no órgão público ABC, atribuindo as datas em que os recursos serão
utilizados e seus responsáveis. Deve-se ainda acrescentar os recursos específicos necessários
44
para o projeto em planejamento e em seguida referenciar este checklist no plano de projeto.
 GPR8 - Os recursos e o ambiente de trabalhos necessários para executar o
projeto são planejados.
4.2.11 IMPLEMENTAR PROJETO

Realizar a codificação e implementação dos requisitos seguindo os documentos de
especificação dos requisitos utilizando recursos humanos classificando conforme foi
planejado no item 4.2.7.
Para o Nível G do MPS.BR não foi identificado nenhum atributo de processo.
4.2.12 MONITORAR O ANDAMENTO DO PROJETO

Essa atividade tem como objetivo, orientar ao gerente de projetos a verificar se a
execução do projeto está de acordo com o planejamento realizado. Para essa atividade deve-se
observar os indicadores de projeto como andamento do cronograma, custos do projeto,
esforço, aderência ao processo, ações corretivas e gerência dos dados e envolvimento dos
interessados. Essas informações devem ser registradas no template chamado Status Report
(ANEXO 11 – STATUS REPORT). A partir do preenchimento do status report deve-se
realizar uma reunião com o time do projeto. Nessa atividade podem ser abertas ações
corretivas de acordo com as diferenças entre a situação atual e planejada para o momento.
Para cada um dos itens verificados em cada status report existe um critério para que seja
aberta uma ação corretiva. Esses critérios são especificados no plano de projeto. A
periodicidade para realizar as monitorações é definida no plano de projeto.
 GPR10 - Um plano geral para a execução do projeto é estabelecido com a

integração de planos específicos.
 GPR11 - A viabilidade de atingir as metas do projeto, considerando as

restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são
realizados.
 GPR13 - O projeto é gerenciado utilizando-se o Plano do Projeto e outros
45
planos que afetam o projeto e os resultados são documentados.
 GPR15 - Revisões são realizadas em marcos do projeto e conforme

estabelecido no planejamento.
 GPR16 - Registros de problemas identificados e o resultado da análise de

questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados
com as partes interessadas.
 GPR17 - Ações para corrigir desvios em relação ao planejado e para prevenir a

repetição dos problemas identificados são estabelecidas, implementadas e
acompanhadas até a sua conclusão.
4.2.13 REALIZAR FECHAMENTO DO PROJETO

Atividade responsável por documentar o resultado final do projeto em termos de
características do produto e do gerenciamento do projeto e registra numa base histórica os
pontos fortes e fracos do trabalho envolvido, lições aprendidas bem como as melhores
práticas para futuros projetos (ANEXO 12 – TERMO DE ENCERRAMENTO).
Para o Nível G do MPS.BR não foi identificado nenhum atributo de processo.
46
5 CONCLUSÃO
Este trabalho proporcionou analisar a viabilidade da implantação do MPS.BR Nível G

no órgão publico ABC com o intuito de obter melhorias significativas no processo de
desenvolvimento de seus software.
Com informações levantadas por este trabalho verifica-se que, a sobrevivência de

uma empresa de desenvolvimento de software seja ela publica ou privada está associada a
critérios de qualidade que envolve documentação e organização de informações que auxiliem
no mapeamento de seus processos, para obter uma rastreabilidade entre os produtos
desenvolvidos e os artefatos que colaboraram para sua produção. Assim criando uma base de
dados histórica com todos os problemas e soluções ocorridas durante o processo de
desenvolvido de um software, a fim de, resgatar dados em momentos oportunos para
gerenciar riscos ao longo do projeto.
Neste contexto verifica-se que a adoção de um modelo de qualidade que pré-

estabelece critérios é imprescindível para certificar um desenvolvimento de software. Com
este objetivo foi adotado o modelo de qualidade MPS.BR dentre outros como CMMI e ISO
por ser uma metodologia brasileira e de custo acessível para dar embasamento a essa
pesquisa. Para desenvolver a pesquisa foi necessário um estudo aprofundado para
compreender as normas envolvidas no nível G do MPS.BR bem como sua estrutura. Com o
levantamento de dados feito dentro das dependências da ABC através de um levantamento
bibliográfico e de uma pesquisa qualitativa foram possíveis obter uma visão processual do
desenvolvimento de software da ABC, assim documentando erros e pontos francos do
processo. A parti do processo atual da ABC foi permitido à criação de um novo processo de
desenvolvimento de software de acordo com os atributos de processo do nível G do MPS.BR
assim propondo uma estrutura que pode ser gerenciada e medida através de ferramentas e
documentos de apoio a gerência de projetos e gerência de requisitos controlando custos,
requisitos, cronogramas, recursos humanos e comunicação.
47
Conclui-se que os objetivos previstos por esta pesquisa foram alcançados a fim de
indicar que o MPS.BR é viável para uma futura implantação como modelo de qualidade de
desenvolvimento de software na ABC uma vez que com o uso de ferramentas e processos
bem estabelecidos qualquer organização passa a ser classificada como madura suficiente para
fornecer produtos de qualidade ao mercado de software brasileiro.
5.1 TRABALHOS FUTUROS
Durante o desenvolvimento e a aplicação da analise de viabilidade do modelo de

qualidade MPS.BR, algumas possibilidades de trabalhos futuros foram identificadas:
Expandir o processo de gerenciamento de projetos proposto por está pesquisa a fim de

atender os níveis superiores do MPS.BR, como nível F e E.
A partir disso, identificar melhorias na mesma que não tenham sido observadas como
necessárias na implantação do nível G.
Realizar manutenção evolutiva dos processos existentes no órgão ABC.
48
REFERÊNCIAS BIBLIOGRÁFICAS
ABES, Associação Brasileira de Empresas de Software, 2009. Disponível em:

< http://www.abes.org.br/>. Acesso em: 12 maio. 2010.
ALCINO SIMÕES, Tecnologia Educativa guião para a produção de um hiperdocumento,

abril. 2010. Disponível em: <
http://www.prof2000.pt/users/folhalcino/tec_educ/site_do/guiao.htm >. Acesso em: 08 maio.
2010.
SILVA , C. O.; Titulo: Comparando CMMi x MPS. BR: As Vantagens e Desvantagens dos
Modelos de Qualidade no Brasil. Rio Grande do Sul.p. 1-3.Nov. 2008.
CHIAVENATO, IDALBERTO. Introdução à teoria geral da administração. 3. ed. São Paulo:

Campus, 2001. 520 p.
COMPANHIA DE INFORMÁTICA DO PARANÁ - CELEPAR, abril. 2010. Disponível em:

< http:// www.batebyte.pr.gov.br >. Acesso em: 08 maio. 2010.
COUTO, ANA BRASIL., CMMI – Integração dos Modelos de Capacitação e Maturidade

de Sistemas, Editora:Ciência Moderna. 2007
ISO - SPICE, abril. 2010. Disponível em: < http:// www.isospice.com >. Acesso em: 18 maio.
2010.
KOSCIANSKI, ANDRÉ. Qualidade de software. 1ª edição ,São Paulo, Novatec , 2007. 400 p.
MICROSOFT, abril. 2010. Disponível em: < http://office.microsoft.com/pt-

br/project/FX100487771046.aspx>. Acesso em: 08 maio. 2010.
PRESSMAN, ROGER S; Engenharia de Software. São Paulo: Makron Books, 1995. 432 p.
PRESSMAN, ROGER S., Engenharia de Software. 6ª edição. São Paulo, BookMan
49
Companhia , 2006. 752 p.
PRESSMAN, Roger S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2001.
SOFTWARE ENGINEERING INSTITUTE, abril. 2010. Disponível em: < http://

www.sei.cmu.edu >. Acesso em: 08 maio. 2010.
SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia

Geral, Junho 2009. Disponível em http://www.softex.br/mpsbr/_guias/.
Acesso em maio de 2010.
SOFTEX, MPS-BR - Melhoria de Processo do Software Brasileiro, Guia de

Implementação Parte 1 – Nível G, Dezembro de 2006b. Disponível em
http://www.softex.br/mpsbr/_guias/. Acessado em maio de 2010.
SOMMERVILLE, I. Software engineering. 5th. ed. Addison-Wesley, 1995.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003.
50
ANEXO 1 – REGISTRO DE REUNIÕES
Registro de Reuniões Gerente do Projeto

Projeto Data/Versão
Número Data Participantes Pauta Resumo da Ata
51
ANEXO 2 – MATRIZ DE RASTREABILIDADE
Matriz de Rastreabilidade Gerente do Projeto

Requisito 1 Requisito 2 Requisito 3

Requisito 1
Requisito 2 X
Requisito 3 X
52
ANEXO 3 – TERMO DE ACEITE
Termo de Aceite Gerente do Projeto :

Projeto: Data/Versão:
Descrição do está sendo aceito
Características do produto/serviço aceito
Testes realizados para homologação
Outros serviços prestados
Ressalvas e comentários do cliente que recebe
Observações finais
Aprovação
Cliente
Gerente de Projeto
53
ANEXO 4 – ATA DE REUNIÃO
Registro de Reuniões Gerente do Projeto

Número Data Participantes Pauta Resumo da Ata
54
ANEXO 5 – CRONOGRAMA
Cronograma Gerente do Projeto :

Tarefa Descrição Vinculado a Responsável Duração
55
ANEXO 6 – CUSTO
Orçamento Gerente do Projeto :

EMPRESA 1– Qtde Un Valor/Unit Valor/Subt
Custos Diretos
Item de custo 0 PC $0,00 $0,00

Item de custo 0 HR $0,00 $0,00
Item de custo 0 PC $0,00 $0,00
TOTAL dos Custos Diretos $0,00
Custos Indiretos
Item de custo 0 HR $0,00 $0,00

Item de custo 0 Un $0,00 $0,00
TOTAL dos Custos Indiretos $0,00
Custo Total $0,00
EMPRESA 1–
Custo 0 HR $30,00 $0,00
Exemplo
EMPRESA 1– Qtde Un Valor/Unit Valor/Subt
Custos Diretos
Compra da Licença do Software 4 PC $2.000,00 $8.000,00

Remuneração do Analista 100 HR $50,00 $5.000,00
Remuneração do Programador 300 HR $30,00 $9.000,00
Remuneração do Gerente de Projetos 50 HR $70,00 $3.500,00
Compra do Hardware do servidor 1 PC $10.000,00 $10.000,00
Compra do Sistema Operacional do servidor 1 PC $2.000,00 $2.000,00
TOTAL dos Custos Diretos (CD) $37.500,00
Custos Indiretos
Custo de Alocação do Gerente Financeiro 40 HR $50,00 $2.000,00

Custo de Alocação do Gerente de TI 10 HR $40,00 $400,00
Custo de Alocação do Supervisor Financeiro 80 HR $10,00 $800,00
Custo de Alocação do Analista de Suporte 20 HR $6,00 $120,00
Custo de Alocação dos usuários para 32 HR $6,00 $192,00
56
treinamento
TOTAL dos Custos Indiretos (CI) $3.512,00
Custo Total (CD+CI) $41.012,00
OPEX – Operational Expenditure
Remuneração do Programador 10 HR $30,00 $300,00
57
ANEXO 7 – PLANO DE COMUNICAÇÃO
Plano de Comunicação
Logo Logo do
Organização Cliente
<Organização>
Cliente: <nome do cliente>
Projeto: <nome do projeto>

Versão: <X.X>
58
Histórico de Alterações
Data Versão Descrição Autor

<dd/mm/aa> <x.x> <Descrição da modificação> <nome do autor>
59
Conteúdo
1 Introdução 61
2 Políticas para Informações Confidenciais 61
3 Políticas para Comunicação Externa 61
4 Políticas para Comunicação Interna 62
5 Referências 62
Introdução
Este documento define o Plano de Comunicação do projeto <nome do projeto>, com o objetivo
de registrar os procedimentos necessários para garantir que a informação gerada pelo projeto
seja reunida, gerenciada e distribuída de maneira precisa e adequada entre seus participantes.
Políticas para Informações Confidenciais

<Algumas informações podem ter caráter confidencial, tanto para a equipe do projeto como para
conjuntos de pessoas e organizações relacionadas ao projeto. Esta seção descreve qual é tal
tipo de informação e como lidar com questões relacionadas, como:
 Necessidade de acesso a informações confidenciais por parte de um indivíduo não-
autorizado;
 Garantia da eficácia de medidas para preservar informações confidenciais;
 Vazamento de informações confidenciais.
Um membro ou conjunto de membros da equipe pode ser alocado para lidar com as questões
acima.>
<Os artefatos do projeto que forem confidenciais devem ser listados na tabela abaixo. Demais
informações confidenciais que não constituam artefatos devem ser abordadas em um parágrafo
à parte.>
Artefato Confidencial Acesso restrito a... Modo de divulgação

<Ex..: Postmortem> <Equipe de Projeto> <Este artefato estará disponível
apenas através da ferramenta de
controle de versão, não devendo
ser encaminhado ao cliente.>
… ... …
Políticas para Comunicação Externa

<Essa seção define os procedimentos de comunicação com entidades externas à equipe do
projeto, como o cliente, usuários ou outros stakeholders externos. A tabela abaixo deve ser
preenchida após a identificação de cada uma dessas entidades externas, assim como suas
informações de contato e, por fim, os membros da equipe de projeto responsáveis pela
comunicação com a entidade externa.>
Documento Destino Responsável Freqüência
<João da Silva (Presidente de

<Relatório de <Toda segunda-feira
empresa X), através do email <José Silva>
Status> ao final da tarde>
joao.silva@x.org.br>
<Pesquisa de <João da Silva (Presidente de <José Silva> <Apenas um vez,
61
satisfação> empresa X), através do email após a conclusão do
joao.silva@x.org.br> projeto>
<Caso informações referentes à publicidade do projeto existam, elas devem constar no final
desta seção.>
Políticas para Comunicação Interna

<A comunicação interna aborda informações relevantes apenas à equipe de projeto, que não
interessam ao cliente. Nesta seção, deve ser registrado, textualmente, como se dará esse
processo interno de comunicação, incluindo as regras e protocolos a serem respeitados. Alguns
exemplos de definições deste tipo são:
 Requisições entre membros de diferentes partes do projeto (como testes,
implementação, etc.) devem ser feitas apenas através de seus respectivos gerentes ou
será aberta?
 Como se dará o processo de levantamento de informações para a avaliação crítica do
projeto? Entrevistas com o time, preenchimento de questionários, reuniões de
brainstorming, etc.?
Adicionalmente, esta seção pode referenciar ou incluir templates de documentos de
comunicação internos da organização, como avisos, memorandos, etc.>
Referências
<Cite aqui outros documentos do projeto ou de fontes externas que contribuam para a
elaboração e um melhor entendimento deste Plano de Comunicação.>
62
ANEXO 8 – ESCOPO DO PROJETO
 Objetivos do projeto. Os objetivos do projeto incluem os critérios mensuráveis do

sucesso do projeto. Os projetos podem possuir uma ampla variedade de objetivos técnicos,
de negócios, custo, cronograma e qualidade. Os objetivos do projeto também podem
incluir metas de custo, cronograma e qualidade. Cada objetivo do projeto possui atributos
como custo, uma métrica como dólares e um valor absoluto ou relativo como inferior a 1,5
milhão de dólares.
 Descrição do escopo do produto. Descreve as características do produto, serviço ou
resultado para cuja criação o projeto foi realizado. Essas características terão normalmente
menos detalhes nas fases iniciais e mais detalhes nas fases posteriores, conforme as
características do produto forem progressivamente elaboradas. Embora a forma e o
conteúdo das características variem, a descrição do escopo deve sempre fornecer detalhes
suficientes para dar suporte ao planejamento posterior do escopo do projeto.
 Requisitos do projeto. Descreve as condições ou capacidades que devem ser atendidas ou
possuídas pelas entregas do projeto para satisfazer um contrato, norma, especificação ou
outros documentos formalmente impostos. As análises das partes interessadas de todas as
suas necessidades, desejos e expectativas são convertidas em requisitos priorizados.
 Limites do projeto. Normalmente identifica o que está incluído dentro do projeto.
Declara de forma explícita o que está excluído do projeto, para evitar que uma parte
interessada possa supor que um produto, serviço ou resultado específico é um componente
do projeto.
 Entregas do projeto. As entregas incluem tanto as saídas que compõem o produto ou
serviço do projeto, como resultados auxiliares, como documentação e relatórios de
gerenciamento de projetos. Dependendo da declaração do escopo do projeto, as entregas
podem ser descritas de forma sumarizada ou detalhada.
 Critérios de aceitação de produtos. Define o processo e os critérios para aceitar os
produtos terminados.
 Restrições do projeto. Lista e descreve as restrições específicas do projeto associadas ao
escopo do projeto que limitam as opções da equipe. Por exemplo, são incluídos um
orçamento predefinido ou datas impostas (marcos do cronograma) divulgadas pelo cliente
ou pela organização executora. Quando um projeto for realizado sob contrato, em geral as
63
cláusulas contratuais se constituirão em restrições. As restrições listadas na declaração do
escopo detalhada do projeto são normalmente mais numerosas e mais detalhadas do que as
listadas no termo de abertura do projeto.
 Premissas do projeto. Lista e descreve as premissas específicas do projeto associadas ao
escopo do projeto e o impacto potencial dessas premissas, se não forem confirmadas.
Freqüentemente, as equipes de projetos identificam, documentam e validam as premissas
como parte do seu processo de planejamento. As premissas listadas na declaração do
escopo detalhada do projeto são normalmente mais numerosas e mais detalhadas do que as
listadas no termo de abertura do projeto.
 Organização inicial do projeto. São identificados os membros da equipe do projeto e as
partes interessadas. A organização do projeto também é documentada. Riscos iniciais
definidos. Identifica os riscos conhecidos.
 Marcos do cronograma. O cliente ou a organização executora podem identificar marcos
e colocar datas impostas nesses marcos do cronograma. Essas datas podem ser
consideradas como restrições do cronograma.
 Limitação de fundos. Descreve qualquer limitação dos recursos financeiros do projeto,
uma limitação do valor total ou uma limitação imposta em prazos especificados.
 Estimativa de custos. A estimativa de custos do projeto indica o custo total esperado do
projeto e é normalmente precedida de um modificador que fornece alguma indicação de
exatidão como, por exemplo, conceitual ou definitiva.
 Requisitos do gerenciamento de configuração do projeto. Descreve o nível de
gerenciamento de configuração e controle de mudanças que será implementado no projeto.
 Especificações do projeto. Identifica os documentos de especificação com os quais o
projeto deve estar de acordo.
 Requisitos de aprovação. Identifica os requisitos de aprovação que podem ser aplicados a
itens como objetivos, entregas, documentos e trabalho do projeto.
64
ANEXO 9 – MATRIZ DE RESPONSABILIDADE
Matriz de Responsabilidades Gerente do Projeto

Usuário
Trabalho ou Deliverable Gerente Analista Programador Patrocinador do
Projeto de Sistemas (Ger Fin) depto fin.
65
ANEXO 10 – RISCOS
Riscos Gerente do Projeto :

Risco Descrição Probabilidade Impacto Ação Contingência Resposta
66
ANEXO 11 – STATUS REPORT
STATUS REPORT
Preparado por ____________ RV1
Aprovado por ____________ __________
Período coberto:____ à ____.
Tabela com valores de referência
Quinzenal Diário
Taxa de Retorno (desvios) Recursos Tempo
Verde +/-5% 70% < = 120% <= 10%

Amarelo +/-10% 85% 120 a 135% 10 a 25%
Vermelho > / < 10% > 85% > 135% > 25%
Situação Geral do Projeto
Taxa de Retorno (desvio) Recursos (alocação) Tempo (desvio)
-4% 150% 0%
67
Principais atividades do período coberto
Atividade Início Fim Planejado Início Real Fim Status

Planejado
Real
Elaboração do Termo de Abertura 27/04/2009 04/05/2009 27/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Aquisição 27/04/2009 04/05/2009 28/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Qualidade 27/04/2009 04/05/2009 29/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Custos 27/04/2009 04/05/2009 27/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Tempo 27/04/2009 04/05/2009 27/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Escopo 27/04/2009 04/05/2009 29/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Integração 27/04/2009 07/05/2009 27/04/2009 - Iniciada
Elaboração do Plano de Comunicação 27/04/2009 04/05/2009 30/04/2009 04/05/2009 Finalizada
Elaboração do Plano de Risco 01/05/2009 04/05/2009 01/05/2009 04/05/2009 Finalizada
Elaboração do Plano de RH 27/04/2009 08/05/2009 28/04/2009 - Iniciada
Principais atividades do próximo período (de 04/05/2009 a 11/05/2009)
Atividade Início Planejado Fim Planejado Início Real Fim Status
Real
Replanejar elaboração do plano de 04/05/2009 05/052009 04/05/2009 - Iniciada

projeto para diminuir
sobrealocação
Elaboração do Plano de Projeto 04/05/2009 11/05/2009 02/05/2009 - Iniciada
Elaboração da Declaração de 04/05/2009 07/05/2009 04/052009 - Iniciada

Escopo
68
Riscos associados às próximas atividades
Item Probabilidade Impacto Status
Recursos com sobrealocação Alta Médio Resolvido Parcialmente
Atividades predecessoras não Média Alto Resolvido

concluídas
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
[Data] [Responsável] [Descrição da mudança].
[Data] [Responsável] [Descrição da mudança].
APROVAÇÕES
Gerente de Projetos Data
05/05/2009
69
ANEXO 12 – TERMO DE ENCERRAMENTO
Termo de Encerramento Gerente do Projeto :

Descrição do que foi aceito
Auditorias realizadas
Metas não atingidas
Metas atingidas
Metas superadas
Indicadores de performance
Multas e custos adicionais
Prêmios & bonificação
Ressalvas e ações a tomar
Osebravções
Aprovação
Patrocinador
Gerente de Projeto
70
ANEXO 13 – TERMO DE ABERTURA
Termo de Abertura Gerente do Projeto :

Necessidades de negócios (business case)
Requisitos que atendam às necessidades da

empresa
Propósito do projeto e justificativa
Gerente de Projeto e autoridade
Principais marcos (milestones)
Fatores Críticos de Sucesso
Participação dos interessados
Participação das organizações funcionais
Hipóteses & Restrições
Orçamento resumido e Retorno do Investimento
Aprovação
Patrocinador
Gerente de Projetos
71
ANEXO 14 - CARACTERISTICA DE QUALIDADE DE SOFTWARE
72

Trabalho de Conclusão de Curso - Sexta Feira 22 CORRECOES

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Trabalho de Conclusão de Curso - Sexta Feira 22 CORRECOES

Загружено:

Авторское право:

Доступные форматы

FACULDADE INTEGRADA DO RECIFE

CURSO DE SISTEMA DE INFORMAÇÃO

MARCELO THIAGO ANDRADE NOBRE

ANÁLISAR A VIABILIDADE PARA A IMPLANTAÇÃO DO MODELO DE

MARCELO THIAGO ANDRADE NOBRE

ANÁLISAR A VIABILIDADE PARA A IMPLANTAÇÃO DO MODELO DE

ANÁLISAR A VIABILIDADE PARA A IMPLANTAÇÃO DO MODELO DE

Monografia apresentada ao curso de sistemas

ANÁLISAR A VIABILIDADE PARA A IMPLANTAÇÃO DO MODELO DE

MARCELO THIAGO ANDRADE NOBRE

A meu pai, pelo apoio e incentivou em todos os momentos de minha vida.

O objetivo deste trabalho é apresentar uma análise de viabilidade para a implantação do

Verifica-se que o ambiente de desenvolvimento de software no Brasil vem obtendo

Palavras Chaves: Qualidade, ABC, MPS.BR, Processos, Modelo,Software

Figura 2.2 - Níveis de avaliação da ISO 15504. ................................................................................................21

Tabela 2.4.1 ESTRUTURA DO MPS.BR. ........................................................................................................26

MPS.BR – Melhoria de Processo do Software Brasileiro

A atividade de desenvolvimento de software no Brasil é umas das que mais cresce

Observando os dados levantados pela ABES verifica-se o grande crescimento no

Mas, se acredita que, a qualidade do software está diretamente relacionada à qualidade

As dificuldades no desenvolvimento de sistemas começam durante as etapas iniciais

A competitividade depende, cada vez mais, do estabelecimento de conexões nestas

Nesse contexto pode ser percebida a importância de se ter um processo de

O MPS.BR é mais adequado a realidade brasileira se comparada ao CMMI, por

Analisando todos os aspectos abordados acima, chegamos à seguinte pergunta de

1.2 OBJETIVO GERAL

1.3 OBJETIVOS ESPECÍFICOS

 Compreender as normas do modelo o MPS.BR.

1.5 ORGANIZAÇÃO DESTE DOCUMENTO

O terceiro capitulo traz uma análise de ambiente atual do setor de desenvolvimento de

No próximo capítulo será abordada a fundamentação teórica, compostas pelo conceito

2.1 UMA VISÃO GERAL DE QUALIDADE DE SOFTWARE

Segundo o SEBRAE a qualidade é um conjunto de características de todo produto e

A engenharia de software é a criação e a utilização de sólidos princípios de engenharia

 Levantamento de Requisitos: É a fase em que o profissional de informática deve estar

Mesmo com um paradigma de ciclos de vida de software os erros continuaram, pois

2.2 ISO/IEC 15504 – AVALIAÇÃO DO PROCESSO DE SOFTWARE

FIGURA 2.2 - NÍVEIS DE AVALIAÇÃO DA ISO 15504.

Fonte (OLIVEIRA, 2008).

O modelo CMMI é proprietário e para a realização das avaliações do modelo, o custo

2.4 MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO

Fonte: (OLIVEIRA, 2008).

A seguir será apresentado um glossário com algumas nomenclaturas usadas no MPS.BR.

TABELA 2.4.1 ESTRUTURA DO MPS.BR.

A – 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*,

E Gerência de Projetos – GPR

G Gerência de Requisitos – GRE,

Fonte: (SOFTEX, 2009).

2.4.2 PROCESSO DE GRP E GRE DO MPS.BR NIVEL G

 GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é

 GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando

 GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

3.1 ANÁLISE DE AMBIENTE

FIGURA 3.1 - ORGANOGRAMA DA EQUIPE DE TI DO ORGÃO PÚBLICO ABC.

Fonte: Dados levantados junto ao setor de TI do órgão público ABC.

3.1.1 GERÊNCIA DE REQUISITOS

Foi verificado que o ambiente atual de desenvolvimento de software no órgão público

A ausência de uma ferramenta que auxilie no gerenciamento de requisitos é outro

3.1.2 GERÊNCIA DE PROJETOS

Verifica-se no órgão público ABC que não há uma cultura de gerenciamento de

Com a ausência de metodologias que auxilie no acompanhamento de um projeto as

Fonte: Dados levantados junto ao setor de TI no órgão público ABC.

Com este fluxograma visualiza-se o processo de gerência de projeto no órgão público

3.1.3 REGISTRAR SOLICITAÇÃO