Universidade do Estado do Rio de Janeiro

Faculdade de Engenharia
Departamento de Engenharia de Sistemas e Computação

IMPLANTAÇÃO DO PROCESSO GERÊNCIA DE

REQUISITOS DO MPS.BR
EM UMA EMPRESA DE DESENVOLVIMENTO DE
SOFTWARE

Autora: CAMILA TEODORO DA SILVA

RIO DE JANEIRO
JANEIRO/2010
 Janeiro – 2010

SILVA, CAMILA TEODORO DA

Implantação do Processo Gerência de
Requisitos do MPS.BR em uma Empresa de
Desenvolvimento de Software [Rio de Janeiro]
2009.
xi, 67 p. 29,7 cm (FEN/UERJ, Engenheiro,
Engenharia Elétrica – ênfase em Sistemas e
Computação, 2010)
Monografia - Universidade do Estado do Rio
de Janeiro - UERJ
1. Gerência de Requisitos de Software
I. FEN/UERJ II. Título (série)
 IMPLANTAÇÃO DO PROCESSO GERÊNCIA DE
REQUISITOS DO MPS.BR EM UMA EMPRESA DE
DESENVOLVIMENTO DE SOFTWARE

Camila Teodoro da Silva

Monografia submetida ao corpo docente da Faculdade de Engenharia da

Universidade do Estado do Rio de Janeiro - UERJ, como parte dos requisitos necessários à
obtenção do diploma de Engenheiro Eletricista com ênfase em Engenharia de Sistemas e
Computação.

Aprovada por:

________________________________________________
Orientadora: Vera Maria Benjamim Werneck, D.Sc, UERJ.

________________________________________________
Co-orientador: Orlando Bernardo Filho, D.Sc, UERJ.

________________________________________________
Outro membro da banca: Jorge Duarte Pires Valério, D.Sc,
UERJ.

Rio de Janeiro, 11 de janeiro de 2010.

 Aos meus pais e amigos.

iv
Agradecimentos

Este trabalho teve a colaboração de muitas pessoas que, direta ou indiretamente,

contribuíram para sua realização.
Primeiramente gostaria de agradecer à minha orientadora, professora Vera
Werneck, que me auxiliou e me incentivou no decorrer deste trabalho e que doou parte do seu
tempo para a revisão do mesmo, e também ao meu co-orientador, professor Orlando Bernardo
Filho, pela confiança em mim depositada.
Um agradecimento mais que especial aos meus pais, pelo apoio incondicional em
todos os momentos de minha vida e por nunca me deixarem desistir ou fraquejar nos
momentos mais difíceis por que passei.
Agradeço aos meus colegas, amigos e ao meu namorado Wagner por sempre
estarem ao meu lado me dando apoio e contribuindo para meu crescimento pessoal e
profissional.
Agradeço especialmente ao diretor de operações da Gapso, Alexandre Pigatti,
pela confiança e responsabilidade que depositara em mim para que eu pudesse realizar este
projeto utilizando dados da empresa e pelos cursos oficiais de introdução ao CMMI e de
introdução ao MPS.BR.

v
Resumo da Monografia apresentada à FEN/UERJ como parte dos requisitos necessários para
a obtenção do grau de Engenheiro Eletricista com ênfase em Engenharia de Sistemas e
Computação.

IMPLANTAÇÃO DO PROCESSO GERÊNCIA DE REQUISITOS DO

MPS.BR EM UMA EMPRESA DE DESENVOLVIMENTO DE
SOFTWARE

Camila Teodoro da Silva

Janeiro/2010

Orientadora: Vera Maria Bejamim Werneck, D.Sc, UERJ.

Co-orientador: Orlando Bernardo Filho, D.Sc, UERJ.

Os produtos de software estão se tornando cada vez mais complexos e a demanda por eles
tem aumentado cada vez mais. Por falta de métodos de desenvolvimento, de ferramentas e
técnicas apropriadas, as organizações têm errado em suas estimativas, têm sofrido retrabalho,
atrasos na entrega, problemas relacionados aos custos dos projetos, inclusive na qualidade dos
mesmos. Um dos problemas mais graves que as empresas enfrentam é o de não atender às
expectativas dos clientes e dificuldades de manutenção por falta de um gerenciamento nos
requisitos. O objetivo deste trabalho é estabelecer uma estratégia de gerenciamento de
requisitos para empresas de desenvolvimento de software que atenda ao MPS.BR (Melhoria
de Processo de Software Brasileiro).

Palavras-chave: Gerência de Requisitos, MPS.BR, Engenharia de Software.

vi
Sumário

1. Introdução 1
1.1. Motivação 1
1.2. Objetivo 2
1.3. Metodologia do Trabalho 2
1.4. Estrutura do Texto 3
2. Fundamentação teórica 4
2.1. Engenharia de Software 4
2.2. Processos de Software 6
2.3. Requisitos de Software 6
2.4. Gerenciamento de Requisitos 8
3. MPS.BR 10
3.1. O Modelo MPS 10
3.2. Modelo de Referência 11
3.2.1. Níveis de Maturidade 11
3.2.2. Processos 13
3.2.3. Capacidade 13
3.2.4. Base Técnica do Modelo 14
3.3. O Nível G – Parcialmente Gerenciado 14
4. A Empresa 16
4.1. Ferramentas 16
4.1.1. Subversion e TortoiseSVN 17
4.1.2. Confluence 17
4.1.3. JIRA 18
4.2. Cenário Atual 20
4.3. Estrutura Organizacional 21
5. Definição da Metodologia Proposta 22
5.1. Alteração na Estrutura Organizacional 22
5.2. Política do Processo de Gerência de Requisitos 23
5.2.1. Aplicação da Política 24
5.2.1.1. Obter entendimento dos requisitos 24
5.2.1.2. Obter compromissos 25
5.2.1.3. Gerenciar Mudanças 25
5.2.1.4. Manter Rastreabilidade 25
5.2.1.5. Identificar e Corrigir Inconsistências 25
5.3. Documentos do Processo 26
5.4. Itens de Rastreabilidade 26
5.5. Plano de Estrutura de Issues 28
5.6. Estratégia de Rastreabilidade 33
5.6.1. Ferramentas 33
5.6.1.1. Mylyn 34
5.6.1.2. JIRA Subversion Plug-in 38
5.6.1.3. Clone and Move Plug-in 39
5.6.1.4. Trackback 40
5.6.2. Rastreabilidade Horizontal 41
5.6.3. Rastreabilidade Código -> Requisito 42
5.6.4. Rastreabilidade Requisito -> Código 43
5.7. Plano de Gerência de Requisitos 43
5.7.1. Glossário 44
5.7.2. Papéis e Responsabilidades 44
vii
 5.7.3. Critérios de Aceitação e Avaliação de Requisitos 45
5.7.4. Registro de Aceite dos Requisitos 45
5.7.5. Ferramentas, Documentos e Rastreabilidade 46
5.7.6. Agendamento dos Casos de Uso 46
5.7.7. Revisões em Planos e Produtos de Trabalho 46
5.7.8. Controle dos Produtos de Trabalho 47
5.8. Auditorias de Qualidade 49
5.9. Análise de Conformidade 50
6. Conclusões 57
6.1. Resultados Obtidos 57
6.2. Trabalhos Futuros 58
6.3. Considerações Finais 58
Referências Bibliográficas 60
Anexo A 62
Anexo B 66

Lista de Figuras

Figura 3.1 - Componentes do Modelo MPS (MPS.BR Guia Geral, 2009, p.13).....................10
Figura 3.2 - Níveis de Maturidade do MPS.BR (MPS.BR Guia Geral, 2009, p.23)................12

viii
Lista de Tabelas

Tabela 4.1 - Tipo de issues da ferramenta Jira.........................................................................18

Tabela 4.2 - Estados possíveis de uma issue.............................................................................18

ix
Lista de Siglas e Símbolos

AP Atributo do Processo
CMMI-DEV® Capability Maturity Model Integration for Development
DoD Department of Defense of US
GRE Gerência de Requisitos
IEC International Electrotechnical Commission.
ISO International Organization for Standardization.
MA-MPS Módulo de Avaliação do MPS.BR.
MN-MPS Módulo de Negócio do MPS.BR.
MPS.BR Melhoria de Processo de Software Brasileiro.
MR-MPS Modelo de Referência do MPS.BR.
RAP Resultado esperado do Atributo do Processo.
SOFTEX Associação para Promoção da Excelência do Software Brasileiro.

x
CAPÍTULO 1
INTRODUÇÃO
Nos primórdios da era da computação, o principal objetivo era desenvolver hardware com um
menor custo e um processamento mais eficiente. Com os avanços da tecnologia o custo do
hardware foi ficando cada vez menor. Com a redução do preço e tamanho do hardware houve
uma enorme difusão de computadores pessoais. Isso possibilitou, entre outras coisas, a
automatização de tarefas complexas do dia-a-dia de diversas empresas, resultando em um
crescimento exorbitante na demanda por software.
Com o passar do tempo os produtos de software ficaram cada vez mais complexos,
gerando vários problemas como dificuldade de manutenção e estimativas imprecisas de prazo
e custo. Além disso, muitas vezes os sistemas não atendiam às reais necessidades do usuário e
continham muitos erros, causando falta de confiabilidade. A causa principal destes problemas
era a falta de métodos, ferramentas e técnicas apropriadas para o desenvolvimento dos
mesmos.
Com o aumento da quantidade de empresas de desenvolvimento de software, o
mercado se tornou muito competitivo, fazendo com que muitas empresas buscassem como
um diferencial a melhoria de seus processos e produtos. Como a qualidade de um software
está diretamente relacionada com a qualidade de desenvolvimento do mesmo, visando à
melhoria dos processos de desenvolvimento de software, surgiram algumas normas e modelos
de qualidade voltadas para este setor. Para manter-se nesse cenário competitivo e diminuir o
tempo de resposta aos clientes, faz-se necessária a implantação de boas práticas para a
melhoria do processo de desenvolvimento de software. Neste contexto situam-se várias
organizações que vêm investindo na qualidade, almejando melhorar seus processos de
desenvolvimento de software.

1.1 Motivação
A especificação de software é uma das primeiras atividades realizadas no desenvolvimento de
um sistema. Através dela é que são estabelecidas as funcionalidades do software a ser
desenvolvido. É a atividade através da qual se levanta as necessidades do usuário, as funções
que são requisitadas pelo sistema e as restrições atribuídas a ele. Esta fase é de fundamental
importância, pois qualquer erro inevitavelmente causará problemas posteriores no projeto e
na fase de desenvolvimento do sistema.
É nesse estágio do desenvolvimento que é feita a documentação dos requisitos.
Existem, nas normas e modelos de qualidade de desenvolvimento de software, regras e

1
requisitos específicos para o levantamento e gerenciamento dos requisitos do sistema, que são
as necessidades dos usuários e as especificações detalhadas do mesmo.
O Programa Melhoria do Processo de Software Brasileiro (MPS.BR), especifica o que
deve ser feito para que se atinja o processo Gerência de Requisitos, porém, não diz como
fazer. O processo Gerência de Requisitos faz parte do nível G de maturidade, sendo o nível A
o mais alto, do MPS.BR. Neste processo o objetivo é gerenciar os requisitos do produto e dos
componentes do produto, bem como identificar inconsistências entre os requisitos, os planos
do projeto e os produtos de trabalho do projeto.
Conforme o desenvolvimento do produto de software vai evoluindo, os requisitos do
sistema vão sofrendo alterações e é necessário que esses sejam gerenciados e atualizados
visando corrigir inconsistências e atingir às reais necessidades do usuário. Quando algum
requisito muda ou é atribuído ao projeto, é preciso verificar a sua viabilidade, especificá-lo,
validá-lo e gerenciá-lo, para que não haja problemas futuros. Através da implantação do
processo Gerência de Requisitos do MPS.BR é possível cumprir todas essas etapas de forma
eficaz e garantindo a qualidade do processo de gerenciamento de requisitos de um projeto.

1.2 Objetivo
Com base na motivação acima, o presente estudo foi elaborado com o objetivo de atender aos
requisitos do MPS.BR no que se refere ao processo Gerência de Requisitos implantando-o na
Gapso Tecnologia da Decisão, uma empresa que desenvolve softwares de otimização de
planejamento de operações e recursos para empresas das mais variadas áreas de atuação.
Com o objetivo de prover uma estratégia de melhoria da qualidade dos processos de
desenvolvimento e dos produtos da Gapso, este projeto propõe a implantação do processo
Gerência de Requisitos do MPS.BR, otimizando o uso das ferramentas já utilizadas pela
empresa. Este processo, por fazer parte do primeiro nível de maturidade do MPS.BR, o nível
G, promove alguns desafios em sua implantação, pois geralmente se faz necessária uma
mudança cultural na organização.

1.3 Metodologia do Trabalho

Inicialmente, para este trabalho, foi realizada uma pesquisa na literatura relacionada às
técnicas e aos procedimentos considerados fundamentais para o desenvolvimento de software
com qualidade. Através dessas literaturas foi possível estabelecer um conjunto mínimo de
requisitos para garantir a qualidade do processo de gestão de requisitos de um sistema.
Em seguida foram levantadas as ferramentas utilizadas pela Gapso Tecnologia da
Decisão e estudado o seu funcionamento e sua aplicabilidade dentro da empresa. Além das
2
ferramentas, foi estudado o processo de requisitos da empresa para saber como a organização
trabalhava em cima dos requisitos levantados e se estes eram gerenciados.
Posteriormente foi montada uma estratégia para atingir o processo Gerência de
Requisitos utilizando as ferramentas da Gapso e adaptando o processo de requisitos da
empresa.
Finalmente, foi feito um estudo comparativo entre o que é de fato exigido pelo
processo Gerência de Requisitos MPS.BR e o que foi possível atingir com a estratégia
elaborada.

1.4 Estrutura do Texto

O capítulo 1 descreve a motivação, os objetivos e a metodologia do trabalho, além da
organização da monografia. A fundamentação teórica é vista no capítulo 2, onde é explicado
o que é requisito de software, o que é qualidade de software, o que se entende por processos e
por gestão de requisitos. O capítulo 3 descreve o programa de Melhoria do Processo de
Software Brasileiro, o MPS.BR. A empresa para qual será sugerida a metodologia para o
processo de gerência de requisitos é apresentada no capítulo 4. O capítulos 5 apresenta a
metodologia proposta e o estudo de avaliação da conformidade da metodologia com os
requisitos do processo de gerência de requisitos do MPS.BR respectivamente. No capítulo 6,
a conclusão indicando os resultados obtidos, os trabalhos futuros e as considerações finais.

3
CAPÍTULO 2
FUNDAMENTAÇÃO TEÓRICA
Desenvolver software com qualidade é um dos principais desafios do mercado atualmente.
Não é simples estimar custos, gerenciar recursos, estimar e manter prazos e atender às reais
necessidades do cliente. Faz-se necessário um controle dos processos de desenvolvimento
para atingir um determinado nível de qualidade dos mesmos, desde a criação do software até
sua instalação e manutenção. Uma fabricação de software com qualidade já não é mais apenas
uma diferenciação no mercado, é uma necessidade para que empresas e profissionais sejam
bem sucedidos.

2.1 Engenharia de Software

De 1950 até meados de 1960 os sistemas baseados em computador eram desenvolvidos pelo
gerenciamento orientado ao hardware, segundo Pressman (1995, p.5). Para controlar os
custos de hardware, os gerentes aplicavam métodos e ferramentas e praticavam cuidadosas
atividades de análise e projeto. O software era, muitas vezes, uma reflexão posterior, e era
visto como uma “forma de arte”.
Ainda segundo Pressman (1995, p.6), na segunda era da evolução dos sistemas
computadorizados, que se estendeu de meados da década de 1960 até o final da década de
1970, o número de sistemas baseados em computador começou a crescer. Todos esses
programas tinham que ser corrigidos quando surgiam falhas, ou tinham que ser alterados
conforme exigências do usuário ou até mesmo sofrer adaptações para um novo hardware.
Consequentemente errava-se constantemente nas estimativas de custo e prazo. Além disso, os
sistemas continham muitos erros e, consertá-los, geralmente culminava na produção de novos
sistemas.
O desenvolvimento de software não é uma tarefa trivial, a maneira artesanal de se
fabricar software persiste ainda em muitas empresas de desenvolvimento e o grau de incerteza
por parte dos clientes é muito elevado. E com a necessidade de softwares cada vez mais
complexos, aumentou-se a dificuldade de desenvolvimento e o custo do software passou a ser
predominante. Surgiu, então, a chamada Crise do Software.
Segundo Sommerville (2003, p.4), o termo “Engenharia de Software” e a noção
do que ele representava surgiu em 1968, em uma conferência na qual foi discutida a crise do
software. Algumas questões começaram a ser levantadas, como o porquê da demora para a
conclusão dos sistemas, dos custos muito elevados, do não descobrimento dos erros antes do
produto ser entregue e da dificuldade de medição do progresso do desenvolvimento do
software. Essa preocupação levou à adoção de práticas de engenharia.
4
 A introdução da disciplina de desenvolvimento chamada engenharia de software
foi a solução encontrada para melhorar a qualidade e reduzir custos de produção. Não há
discórdia quanto aos benefícios das metodologias de processo de desenvolvimento, porém os
métodos instituídos levantam muitos questionamentos. Esses questionamentos resultam em
novas metodologias que contribuem para a evolução da Engenharia de Software.
Segundo Pressman (1995, p.31), a engenharia de software abrange um conjunto
de três elementos fundamentais – métodos, ferramentas e procedimentos – que faz com que o
gerente do projeto de software tenha o controle do processo de desenvolvimento e ofereça aos
desenvolvedores a base para a construção de um produto de alta qualidade.
Os detalhes de como desenvolver o software são dados pelos métodos da
engenharia de software. As tarefas que os métodos envolvem são o planejamento e
estimativas do projeto, análise de requisitos de sistemas e de software, projeto da arquitetura e
dos dados, codificação, teste e manutenção. As ferramentas de engenharia de software
proporcionam uma maneira automatizada ou semi-automatizada para apoiar os métodos
utilizados. Os procedimentos, ou técnicas, da engenharia de software definem a ordem em
que os métodos serão utilizados, quais os produtos que serão entregues, quais os marcos para
controle e avaliação do progresso do desenvolvimento de software. São os procedimentos que
asseguram a qualidade do produto e do desenvolvimento do mesmo.
A engenharia de software não se limita aos programas de computador, mas
envolve também toda a documentação necessária para instalação, uso, desenvolvimento e
manutenção do sistema. Portanto, o gerenciamento do projeto e dos requisitos do sistema são
tarefas importantes da engenharia de software que visam garantir a qualidade necessária para
atingir determinado nível de maturidade da organização.
Neste contexto, surgiram algumas normas e modelos de qualidade voltadas para
este setor. Dentre as normas temos a ISO/IEC 12207, que trata do processo de ciclo de vida
de Software, e a ISO/IEC 15504, que se refere à avaliação de processo, além dos modelos de
maturidade de melhoria de processos como o Capability Maturity Model Integration (CMMI),
instituído pelo Department of Defense of US (DoD) e o MPS.BR um programa para Melhoria
de Processo do Software Brasileiro que é coordenado pela Associação para Promoção da
Excelência do Software Brasileiro (SOFTEX).
Os modelos de maturidade são um conjunto de boas práticas que estão sendo cada
vez mais implantadas pelas empresas de desenvolvimento de software que buscam alcançar a
competitividade pela garantia da qualidade.

2.2 Processos de Software

5
Processo, no contexto de desenvolvimento de software, é um conjunto de atividades
relacionadas entre si, ou uma sequência de práticas, que visa transformar insumos em
produtos de software, ou seja, tem por objetivo o desenvolvimento e a evolução do software.
Vem-se tentando automatizar processos de software, porém, os processos de
software são complexos, pois tem a necessidade de julgamento humano e criatividade. Além
disso, há uma grande diversidade de processos de software e diferentes organizações
desenvolvem diferentes abordagens para o desenvolvimento de software.
O MPS.BR define práticas para realizar alguns processos necessários para o
desenvolvimento de software de qualidade, como por exemplo, o processo Gerência de
Requisitos e o processo Gerência de Projeto. Este trabalho descreve uma abordagem para o
processo de gestão de requisitos, seguindo as exigências do Modelo de Processo de Software
Brasileiro.

2.3 Requisitos de Software

A questão “O que é qualidade de software” pode gerar diversas respostas distintas
dependendo de a quem se faz a pergunta, em que circunstâncias, para que tipo de sistema de
software e assim por diante. Do ponto de vista do usuário, a qualidade é a adequação à
finalidade ou a reunião das necessidades do usuário. Um software de qualidade é um software
que executa funções úteis como é especificado, ou seja, o software realiza corretamente as
funções que foram especificadas, são aptos para o uso e exerce suas funções com
confiabilidade. Para que isso ocorra, é realizada a atividade de especificação de software.
Requisitos de software são as funcionalidades requeridas, ou necessidades do
usuário, e as restrições sobre a operação e o desenvolvimento do sistema. A especificação de
software tem como objetivo levantar os requisitos do sistema e é de fundamental importância
para o sucesso de um projeto, visto que, se ocorrerem erros nessa fase, fica inevitável o
aparecimento de erros no projeto e na implementação.
Segundo Pfleeger (2007, p.111), “um requisito é uma característica do sistema ou
a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos". Para
Sommerville (2003, p.46) os requisitos para um sistema de software estabelecem as funções
que o sistema deve realizar e definem restrições sobre sua operação e implementação. Os
requisitos formam a base para o desenvolvimento do sistema, por isso devem ser analisados,
documentados e validados criteriosamente.
O processo de especificação de software é a identificação de todos os requisitos
do sistema, os quais devem ser documentados produzindo a documentação de requisitos, que
é a especificação para o sistema. O documento de requisitos de software ou especificação de

6
requisitos de software, para Sommerville (2003, p.95), “é a declaração oficial do que é
exigido dos desenvolvedores de sistema”. O documento de requisitos pode incluir tanto a
definição como a especificação dos requisitos.
Antes que os requisitos sejam encaminhados para o projeto, os clientes e
desenvolvedores devem ter a certeza de que conhecem a intenção e o entendimento uns dos
outros, para ter esta certeza os requisitos devem ser validados.
Para Pressman (1995, p.231), o cliente e o desenvolvedor são responsáveis pela
análise e especificação de requisitos. O cliente expressa em detalhes concretos, um conceito,
às vezes nebuloso, de função e desempenho de software, enquanto que o desenvolvedor age
como investigador e solucionador de problemas.
A análise e especificação de requisitos é uma tarefa extremamente complicada,
pois o conteúdo de comunicação é muito elevado, e são grandes as chances de surgirem
interpretações errôneas e informações falsas. Sendo assim, é altamente provável que
conforme o sistema vá sendo desenvolvido, surjam mudanças nos requisitos, não importa
onde se esteja no ciclo de vida do sistema.
Em 1994, o instituto Standish Group publicou uma pesquisa identificando os
fatores que contribuíam para falhas em projetos e para a falta de maturidade das empresas
desenvolvedoras de software. A pesquisa mostra que os Estados Unidos gastavam, na época,
mais de 250 bilhões de dólares por ano em desenvolvimento de Tecnologia da Informação de
aproximadamente 175 mil projetos. Segundo a pesquisa, 31,1% dos projetos são cancelados
antes de serem completados, representando um gasto em torno de 81 bilhões de dólares. Além
disso, 52,7% dos projetos custam 189% da estimativa inicial e representam 59 bilhões em
custo adicional, atrasados em até 222% da estimativa inicial, além de serem entregues com
apenas 61% das funcionalidades especificadas. Apenas 16,2% são entregues dentro do prazo
e orçamento.
Essa pesquisa identificou que as principais causas dos projetos extrapolarem prazo
e custo, e serem entregues com a funcionalidade prejudicada são: 12,8% relacionada à falta
de especificação do usuário; 12,3% a especificações incompletas de requisitos; 11,8% a
mudanças de requisitos; 7,5% a falta de apoio executivo; 7% a tecnologia imatura; 6,4% a
falta de recursos; 5,9% a expectativas não realistas; 5,3% a objetivos obscuros; 4,3% a
previsão irreal de tempo; 3,7% a novas tecnologias e 23% estão relacionados a outros tipos de
problemas.
A pesquisa mostra que a maior parte dos problemas encontrados no processo de
desenvolvimento de software está relacionada com os requisitos. Vê-se, assim, que identificar
e gerenciar os requisitos é de fundamental importância e é a parte mais difícil dos processos
de software.
7
2.4 Gerenciamento de Requisitos
Para grandes sistemas de software, estão sempre ocorrendo modificações em seus requisitos.
Isso ocorre, geralmente, porque na fase de especificação de requisitos, as necessidades do
usuário podem ser um tanto quanto obscuras, e o entendimento dos requisitos por parte do
desenvolvedor e também do cliente vai se aprimorando a medida que o software vai sendo
desenvolvido.
Além disso, novos requisitos surgem durante o processo de desenvolvimento do
software. Para Sommerville (2003, p.118), essas mudanças ocorrem pelas seguintes razões:
i. Geralmente os usuários do sistema que está sendo desenvolvido são
diversificados, com diferentes requisitos e prioridades, que podem gerar
inconsistências por se conflitarem ou se contradizerem.
ii. Raramente os usuários finais são as mesmas pessoas que pagam pelo software.
Os requisitos impostos pelos clientes são em razão de restrições orçamentárias
e organizacionais. Esses requisitos podem conflitar com os requisitos dos
usuários finais.
iii. Pode ser necessário fazer a integração do sistema com sistemas legados,
adaptações a novo hardware implementado, pode ocorrer mudança de
prioridade da empresa, causando mudanças no suporte necessário ao sistema,
podem ser criados novas legislações e regulamentos, e estes devem ser
implementados pelo sistema.
O objetivo do gerenciamento de requisitos é documentar, organizar e rastrear os
requisitos, além de controlar o seu desenvolvimento e as mudanças. É garantir que não haja
inconsistências entre o que foi especificado e o que está sendo desenvolvido e garantir que
não haja inconsistências entre um requisito e outro. Além de garantir que os requisitos tenham
sido entendidos e possam ser identificados, validados, testados e rastreados.
É preciso planejar o gerenciamento de requisitos, decidindo pelos seguintes
aspectos:
i. Identificação dos requisitos: é preciso identificá-los de modo único, para que
eles possam ser rastreados e referenciados com outros requisitos.
ii. Gerenciamento de mudanças: é preciso avaliar os impactos de uma mudança
nos requisitos.
iii. Rastreabilidade: é preciso fazer o rastreamento entre os requisitos para
estabelecer suas relações com os demais requisitos e com o projeto.

8
 iv. Ferramentas: o gerenciamento de requisitos envolve processar um grande
volume de informações, e é necessário o uso de ferramentas para esse
processamento. Para pequenos projetos pode não ser necessária a utilização de
ferramentas para o gerenciamento de requisitos.

CAPÍTULO 3
MPS.BR
Nos ambientes de negócio, as mudanças que têm ocorrido fazem com que as empresas de
software busquem um diferencial. Cada vez mais as organizações desenvolvedoras de
software tentam alcançar a competitividade pela qualidade. Isso implica tanto na melhoria da
qualidade dos produtos de software, quanto na qualidade do processo de desenvolvimento e
distribuição de software.
Para se obter um setor de software nacional e internacionalmente competitivo, é
essencial que se coloque a eficiência e a eficácia dos processos em foco nas empresas,
visando à oferta de produtos de software e serviços correlatos conforme padrões
internacionais de qualidade.
9
 O programa MPS.BR (Melhoria do Processo de Software Brasileiro) está em
desenvolvimento desde 2003, coordenado pela Associação para Promoção da Excelência do
Software Brasileiro (SOFTEX), 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).
Uma certificação de qualidade de processos de software possui um custo muito
elevado, tornando-se inviável para empresas de micro, pequeno e médio porte. Um dos
objetivos principais do MPS.BR é a disseminação e a adoção do modelo MPS, visando
principalmente as micro, pequenas e médias empresas, de forma a atender às suas
necessidades de negócio. O MPS.BR foi criado de acordo com a realidade das empresas
brasileiras, e tem um grande potencial para ser replicado nos demais países da América
Latina. Esse é mais um dos objetivos do programa.
O MPS.BR possui avaliações que permitem mensurar a maturidade dos processos
de uma empresa, ajudando-a a garantir aos seus clientes um produto que atenda às suas
necessidades e um serviço de qualidade.

3.1 O Modelo MPS

O modelo MPS é baseado nos conceitos de maturidade e capacidade de processo para a
avaliação e melhoria da qualidade e produtividade de produtos de software e serviços
correlatos. O modelo é subdividido em três componentes (figura 3.1):
1. MR-MPS – Modelo de Referência
2. MA-MPS – Método de Avaliação
3. MN-MPS – Modelo de Negócio

Figura 3.1 - Componentes do Modelo MPS (MPS.BR Guia Geral, 2009, p.13)

10
 Os seguintes guias descrevem o modelo MPS:
- Guia Geral: que contém a descrição geral do modelo e detalha o modelo de referência (MR-
MPS);
- Guia de Aquisição: para aquisição de software e serviços correlatos;
- Guia de Avaliação: processo e método de avaliação MA-MPS;
- Guia de Implementação: um conjunto de dez documentos com as orientações para a
implementação dos níveis de maturidade, descritos no MR-MPS, nas organizações.

3.2 Modelo de Referência

O modelo de referência MR-MPS define os requisitos aos quais os processos das
organizações devem atender para estar em conformidade com o mesmo, define níveis de
maturidade que são uma combinação entre os processos e sua capacidade. Segundo o Guia
Geral do MPS.BR (2009, p.16), a capacidade do processo é a caracterização da habilidade do
processo para alcançar os objetivos de negócio, atuais e futuros, estando relacionada com o
atendimento aos atributos de processo associados aos processos de cada nível de maturidade.

3.2.1 Níveis de Maturidade

O MR-MPS é composto por sete níveis de maturidade que estabelecem os patamares da
evolução dos processos (figura 3.2). Isto é, eles estabelecem estágios de melhoria da
implementação dos processos na empresa. Os níveis de maturidade evoluem do nível G até o
nível A e são acumulativos. Por exemplo, o nível C é composto pelos processos dos níveis de
maturidade anteriores (G ao D) mais os processos do mesmo.

11
 Figura 3.2 - Níveis de Maturidade do MPS.BR (MPS.BR Guia Geral, 2009, p.23)

A graduação em sete níveis de maturidade possibilita uma implementação e

reconhecimento da melhoria do processo de software mais gradual, o que facilita sua
adequação à realidade brasileira de micro, pequenas e médias empresas, com visibilidade dos
resultados em prazos mais curtos.
O nível de maturidade em que uma organização se encontra faz com que se possa
prever o desempenho futuro da mesma ao serem executados os processos.
Uma empresa é considerada em determinado nível se todos os seus setores forem
considerados naquele nível. Porém, uma empresa pode desejar que se avalie apenas alguns de
seus setores.

12
3.2.2 Processos
São descritos em termos de propósito, objetivo geral a ser alcançado e resultados esperados,
obtidos com a implementação do processo. Os resultados esperados podem ser um produto de
trabalho que vai ser produzido ou uma mudança de estado significativa que ocorra ao se
executar o processo.
Um processo é um conjunto de atividades inter-relacionadas que transforma
entradas em saídas. É composto de um propósito, o principal objetivo da execução do
processo e os prováveis resultados obtidos com sua efetiva implementação, e de resultado,
que é um resultado observável do sucesso do alcance do propósito daquele processo.

3.2.3 Capacidade
A capacidade de um processo é um conjunto de atribuições do mesmo descrito em termos de
resultados esperados. Expressa o grau de institucionalização com que o processo é executado
na empresa ou unidade organizacional. Conforme a organização evolui na escala, ou seja, à
medida que o nível de maturidade se eleva, é necessário atingir um maior nível de capacidade
para desempenhar o processo.
É necessário atender aos resultados esperados dos atributos do processo (RAP)
para que se atenda ao atributo do processo (AP). O atendimento a este é necessário para todos
os processos no nível correspondente ao nível de maturidade.
Um atributo de processo é uma característica mensurável da capacidade aplicável
a qualquer processo. O resultado de um atributo de processo é o resultado observável do
sucesso do alcance do atributo de processo.
No contexto deste trabalho, ou seja, para implantação do processo Gerência de
Requisitos, que pertence ao nível G, é necessário atingir os AP 1.1 e AP 2.1, como mostrado
na figura 3.2. O alcance de cada atributo é avaliado conforme definido no anexo A.
O AP 1.1 – O processo é executado, é uma medida de quanto o processo atinge o
seu objetivo principal e seus resultados esperados. O AP 2.1 – O processo é gerenciado, mede
o quanto a execução do processo está sendo gerenciada. Este atributo de processo está
relacionado ao planejamento da execução do processo, à atribuição de responsabilidades e
também ao fornecimento de recursos adequados.
Ao AP 1.1 está relacionado o resultado esperado RAP 1 - O processo atinge seus
resultados definidos. Ao AP 2.1 estão relacionados os seguintes resultados: RAP 2 - Existe
uma política organizacional estabelecida e mantida para o processo, RAP 3 - A execução do
processo é planejada, RAP 4 - A execução do processo é monitorada e ajustes são realizados,
RAP 5 - As informações e os recursos necessários para a execução do processo são

13
identificados e disponibilizados, RAP 6 - As responsabilidades e a autoridade para executar o
processo são definidas, atribuídas e comunicadas, RAP 7 - As pessoas que executam o
processo são competentes em termos de formação, treinamento e experiência, RAP 8 - A
comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu
envolvimento, RAP 9 - Os resultados do processo são revistos com a gerência de alto nível
para fornecer visibilidade sobre a sua situação na organização e RAP 10 - O processo
planejado para o projeto é executado.

3.2.4 Base Técnica do Modelo

A base técnica para a definição do modelo é composta pelas normas ISO/IEC
12207:2008 – Processo de Ciclo de Vida de Software e suas emendas 1 e 2, ISO/IEC 15504-
2:2003 – Avaliação de Processo Parte 2 e pelo CMMI-DEV® (Capability Maturity Model
Integration for Development).
As normas internacionais ISO/IEC 12207 e ISO/IEC 15504 foram criadas pela
ISO – International Organization for Standardization e o IEC – International
Electrotechnical Commission dentro de um esforço conjunto dessas organizações.
O CMMI-DEV® é um modelo para medição da maturidade de uma organização
no que diz respeito ao processo de desenvolvimento de software. Definido no SEI (Software
Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos. Este
framework foi desenvolvido para ser consistente e compatível com a norma ISO/IEC 15504.

3.3 O Nível G – Parcialmente Gerenciado

Este nível de maturidade é composto por dois processos: o processo Gerência de Projetos
(GPR) e o processo Gerência de Requisitos (GRE). O nível G é o primeiro nível de
maturidade do MR-MPS. A implementação deste nível deve ser feita com cautela por
representar o início da melhoria dos processos de software dentro da organização.
Os maiores desafios na implantação do nível G são a mudança de cultura
organizacional e a definição do que é um projeto para a organização. A organização precisa
estabelecer objetivos, prazos e escopo para a execução do projeto. No MPS.BR, a definição
de projeto é “Um empreendimento realizado para criar um produto. O projeto se caracteriza
por temporalidade e resultado, produto único e elaboração progressiva”.
Segundo o Guia de Implementação do MPS.BR (2009,p.18), 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.

14
 Os requisitos devem ser estabelecidos e documentados, representando assim a
especificação para o sistema. O objetivo principal da Gerência de Requisitos é fazer com que
toda a evolução dos requisitos seja controlada. Os requisitos incluem requisitos recebidos ou
gerados pelo projeto, funcionais e não-funcionais e também os requisitos impostos ao projeto
pela organização.
As mudanças nos requisitos também devem ser documentadas, bem como suas
justificativas. Além disso, deve ser mantida a rastreabilidade bidirecional entre os requisitos e
produtos de trabalho em geral. As inconsistências entre os requisitos, os produtos de trabalho
e os planos do projeto devem ser identificadas.
A rastreabilidade deve ser feita de forma horizontal e vertical. A rastreabilidade
horizontal é a rastreabilidade entre requisitos em um mesmo nível, por exemplo,
rastreabilidade dos requisitos entre si. Já a rastreabilidade vertical estabelece a dependência
desde um requisito fonte até o código de unidade ou módulos de software, ou seja, até o nível
de decomposição mais baixo do produto. A rastreabilidade vertical é de fundamental
importância para a análise de impacto de mudança nos requisitos.
Os resultados esperados para o processo Gerência de Requisitos são descritos no
anexo B.

CAPÍTULO 4
A EMPRESA
A empresa estudada, que será denominada Empresa A, é uma empresa de Tecnologia da
Decisão que desenvolve soluções que auxiliam decisores a definir estratégias, planejar
operações, reduzir custos, diminuir riscos e fazer o planejamento a curto, médio e longo
prazo.
Na página web da empresa (O QUE É AFINAL TECNOLOGIA DA DECISÃO? Disponível em
<http://www.gapso.com.br>. Acesso em: 11/12/2009.), tem-se a definição de Tecnologia da
Decisão: “Tecnologia da Decisão é um conjunto de avançadas técnicas e ferramentas analíticas
usadas para tomar decisões melhores. Em outras palavras, são tecnologias que permitem um
extensivo uso de dados, algoritmos de otimização combinatória, análises estatísticas e
quantitativas, modelos preditivos, avaliação de cenários e alternativas; que ajudam executivos a
tomar decisões melhores, baseadas em fatos”.
15
 As soluções desenvolvidas pela empresa são produtos de software que em geral
são compostos por dois subsistemas principais: Cliente e Resolvedor Matemático. O
subsistema Cliente é responsável por ler os dados de entrada, pré-processá-los, enviá-los para
o subsistema Solver e disponibilizar para o usuário a solução otimizada na forma de
relatórios. O subsistema Solver, ou Resolvedor Matemático, é responsável por implementar o
modelo matemático que descreve o problema de otimização e enviar a solução deste
problema para o subsistema Cliente.
Cada subsistema é desenvolvido por um setor da empresa. O subsistema Cliente é
desenvolvido pela equipe de TI (Tecnologia da Informação) e o subsistema Solver pela
equipe de Otimização, responsável por implementar o modelo matemático que irá fazer a
simulação e otimização do problema em questão.
O objetivo deste trabalho é implantar o processo Gerência de Requisitos do
MPS.BR no setor de TI da empresa, de forma a aumentar a competitividade no mercado e a
garantir a qualidade dos softwares e do desenvolvimento dos mesmos dentro da organização.
São apresentadas neste capítulo as ferramentas que a empresa utiliza para o
desenvolvimento dos seus produtos e qual a situação atual da empresa.

4.1 Ferramentas
A Empresa A utiliza uma plataforma de desenvolvimento JAVA chamada Eclipse, com
amplo suporte ao desenvolvedor com centenas de plug-ins. Através dessa ferramenta é que
são construídas as aplicações. Utiliza-se o Eclipse também para realização de testes unitários.
Os documentos de casos de uso são confeccionados utilizando-se o Microsoft Word ou no
Confluence. Além dessas, também são utilizadas as ferramentas descritas a seguir.
4.1.1 Subversion e TortoiseSVN
O Subversion, ou SVN, é um sistema de controle de versões, utilizado pela
Empresa A para gerenciar diferentes versões das aplicações desenvolvidas. A arquitetura
proposta pelo Subversion é parecida com a de um cliente-servidor. No servidor tem-se o
repositório dos arquivos que são armazenados em um banco de dados e diversos clientes que
são utilizados para acessar esses arquivos, no caso, os desenvolvedores é que vão fazer esse
acesso.
É feito check-out, ou seja, a recuperação dos documentos que estão no repositório,
e esses são armazenados localmente. Após os documentos serem alterados pode-se submetê-
los ao servidor através de um commit, essa atividade altera o número da revisão do
repositório. O número de revisão é seqüencial e inicia em 1 e é incrementado a cada alteração
dos documentos. Cada documento tem armazenado no repositório sua última situação e a
16
situação em cada uma das revisões, desta forma pode-se reverter qualquer alteração, alem de
se poder comparar o documento com uma revisão específica.
Todo o conteúdo do repositório fica registrado, assim pode-se saber em que
revisão o documento foi alterado e quem o alterou. Cada revisão possui a data, hora e usuário
que a efetuou.
Para realizar as operações sobre o Subversion, é utilizado o TortoiseSVN, que é o
cliente Subversion.

4.1.2 Confluence
O Confluence é um aplicativo Wiki desenvolvido pela Atlassian, uma companhia de software
australiana especializada em ferramentas de colaboração e desenvolvimento. Foi planejado
para favorecer a colaboração no ambiente corporativo, de forma a diminuir distâncias físicas
e hierárquicas de comunicação. Existem diversos plug-ins que permitem expandir o
Confluence e integrá-lo a outros sistemas.
Wiki é um software que permite que os usuários editem páginas web,
compartilhem dados e conhecimento. É uma nova e poderosa infra-estrutura para a
colaboração. É uma das principais ferramentas da chamada Web 2.0, em que os usuários
interagem entre si, gerando e compartilhando conteúdos, sem que precisem de conhecimentos
em qualquer linguagem de programação.
A Empresa A utiliza a ferramenta Confluence na confecção, armazenamento e
controle de versão da documentação do projeto, no compartilhamento de dados e arquivos,
difusão de conhecimento e controle de acesso às informações e notificações via e-mail.

4.1.3 JIRA
O JIRA é outra ferramenta desenvolvida pela Atlassian, voltada para gerenciamento de
projeto. Aumenta a produtividade e a qualidade de execução de inúmeras tarefas que
envolvem um projeto, além da rastreabilidade das mesmas.
Possui uma interface simples e eficaz que facilita o gerenciamento de bugs,
tarefas e qualquer tipo de demanda. É customizavel e permite a navegação por projetos e
tarefas de forma rápida.
É utilizado pela Empresa A para atribuição de tarefas a recursos humanos,
planejamento e gestão de projeto, gestão de problemas e acompanhamento do status do
projeto. Assim como o Confluence, o JIRA é utilizado para enviar notificações via e-mail.
Permite atribuir pendências (ou issues) a recursos humanos. Como default, o JIRA possui os
tipos de issues mostrados na tabela 4.1.
17
 Tabela 4.1 - Tipo de issues da ferramenta Jira
Nome Descrição Tipo
Bug Um problema que dificulta ou impede o funcionamento do produto. Standard
New Uma nova característica do produto, que ainda tem de ser desenvolvida. Standard
Feature
Task Uma tarefa que tem que ser realizada. Standard
Sub-task Uma sub-task ou sub-tarefa de uma issue. Sub-Task

Os estados que as issues podem assumir no JIRA estão organizados no workflow

da figura 4.2:

Figura 4.1 – Workflow do JIRA

A tabela 4.2 indica os estados possíveis de uma issue.

Tabela 4.2 - Estados possíveis de uma issue

Open A issue está aberta e pronta para que se comece a trabalhar sobre ela.
InProgress A issue está ativa.
Reopened Esta questão já foi resolvida, mas a resolução foi considerada incorreta.
Resolved A resolução foi tomada e está aguardando a verificação
Closed A issue é considerada terminada, a resolução está correta. Issues fechadas podem ser reabertas.

18
 As issues possuem alguns detalhes, que são fornecidos em sua criação. São eles:
• Project: Indica a qual projeto a issue pertence.
• Type: Indica o tipo da issue que pode ser bug, task, new feature ou improvement.
• Summary: Contém o assunto, o título da issue.
• Priority: Define o nível de atendimento às necessidades apresentadas. Pode ser:
o Blocker: Valor utilizado para identificar bloqueio do desenvolvimento ou do
teste, e, conseqüentemente, bloqueio da produção.
o Critical: Valor utilizado para identificar travamentos, perda de dados,
problemas de memória.
o Major: Valor utilizado para identificar necessidades que devem ser atendidas
na primeira iteração. O não atendimento desta necessidade impacta
diretamente na satisfação do cliente.
o Minor: Valor utilizado para identificar necessidades que podem ser atendidas
na primeira iteração, assim como podem ser atendidas nas versões
subseqüentes.
o Trivial: Valor utilizado para identificar necessidades que podem ser atendidas
na primeira iteração, nas versões subseqüentes, ou não serem atendidas. Não se
espera nenhum impacto significativo sobre a receita da empresa envolvida ou
para a satisfação do cliente, caso este item não seja incluído no Sistema.
• Due Date: Data de término da tarefa correspondente à issue.
• Compotent(s): Componentes do produto.
• Affect Version(s): Versão(ões) em que a issue foi identificada.
• Fix Version(s): Versão(ões) em que a issue será resolvida.
• Assignee: Pessoa responsável pela issue.
• Reporter: Criador da issue. Fornecido de forma automática.
• Description: Contém descrição da issue em questão.
• Attachments: Arquivos que podem ser anexados na issue: Imagens, vídeos,
Documentos etc.

4.2 Cenário Atual

Atualmente os requisitos são levantados em reuniões com os clientes e documentados em
forma de casos de uso. Cada caso de uso descreve uma funcionalidade, ou uma tela, do
sistema a ser desenvolvido. Esses documentos são confeccionados em documento Word ou no
Confluence, no space do projeto correspondente. Porém, quando há uma solicitação de
mudança, esses documentos, em geral, não são atualizados.

19
 Além disso, na maioria das vezes, as solicitações de mudança do cliente ou
geradas pelo próprio projeto não são documentadas. Há situações em que as solicitações são
feitas por telefonemas, onde o cliente se comunica diretamente com o desenvolvedor ou
analista que fará a modificação no código.
Isso acarreta em algumas dificuldades como a atualização do manual do usuário e
material de treinamento, pois o responsável por esta tarefa tem que percorrer todo o sistema
em busca de alterações que tenham sido feitas, correndo o risco de a documentação ficar
inconsistente com o produto.
Alguns problemas como erros causados por alguma alteração também podem
surgir, e como não há uma rastreabilidade dos requisitos até o código correspondente, nem a
atualização dos documentos de requisitos, dificulta ainda mais a descoberta da origem dos
erros, o que pode acarretar em atrasos no cronograma, re-trabalho, custos elevados, além da
insatisfação dos clientes e usuários do sistema.
Muitos desses problemas poderiam ser evitados se houvesse um processo de
engenharia de requisitos definido, controlado e aprimorado. Atualmente, cada projeto da
empresa realiza o processo de requisitos de maneira diferente, e, em alguns casos, nem
mesmo casos de uso são documentados.

4.3 Estrutura Organizacional

A estrutura organizacional pode ser visualizada na tabela 4.3.

Tabela 4.3 - Estrutura Organizacional da Empresa A

Papel Responsabilidade
Comitê Aprova ou não solicitações de mudanças que envolvem custos altos. Acompanha o projeto de
Executivo (CE) forma macro e atua em questões não resolvidas pela Gerência do Projeto. De acordo com a
apresentação de kick-Off as reuniões que envolvem o Comitê Executivo tem como objetivo:
• - identificar riscos para o projeto;
• - discutir tomadas de decisões com o objetivo de conter riscos que possam atrasar o
desenvolvimento do projeto.
Gerente Responsável pela área de TI. Auxilia no planejamento e acompanhamento do projeto. Aloca
Funcional de TI recursos.
(GTI)
Gerente de Responsável pelo planejamento e acompanhamento do projeto. Dimensiona tarefas e interage
Projeto (GP) com o cliente.
Gerente de Responsável pela área de Otimização e alocação de recursos de otimização.
Otimização
(GO)
Analista de TI Realiza a análise e levantamento dos requisitos de software. Responsável pelo design da
(ATI) aplicação e pela implementação do sistema.
Analista de Responsável pelo desenvolvimento e implementação do modelo matemático.
Otimização
(ATO)
Analista de O Analista de Teste é responsável por executar os testes, o que inclui a execução e
Teste (ATT) configuração dos testes, por avaliar os resultados de teste e por registrar os defeitos

20
 identificados.

CAPÍTULO 5
DEFINIÇÃO DA METODOLOGIA PROPOSTA
O foco da Gerência de Requisitos é controlar a evolução dos requisitos de um projeto. Para
assegurar que o conjunto de requisitos acordados de um projeto seja gerenciado e forneça
apoio às necessidades de planejamento e execução do projeto, este trabalho sugere um
processo de gestão de requisitos para que a Empresa A possa executar um conjunto de passos
definidos e apropriados para atender os objetivos do processo Gerência de Requisitos do
MPS.BR.

5.1 Alteração na Estrutura Organizacional

Para a implantação da nova metodologia de gerência de requisitos, foi necessário fazer
algumas alterações na estrutura organizacional da empresa. Foram identificados dois novos
papéis, Gerente de Qualidade e Analista de Qualidade.
O Gerente de Qualidade é responsável por atribuir tarefas de teste dos requisitos
de software e solicitações de mudança; atribuir tarefas de implantação e auditorias de
qualidade; atribuir tarefas de elaboração de manual do usuário, help online, apostilas de
treinamento; estudar e pesquisar formas de melhoria a serem aplicadas tanto aos processos de
desenvolvimento da Empresa A quanto aos produtos desenvolvidos pela mesma, baseando-se
nos modelos de melhoria CMMI e MPS.BR; estudar e pesquisar formas de melhoria do uso
das ferramentas utilizadas pela empresa, como pesquisas de novos plug-ins, integração e
organização; implantar as melhorias analisadas no âmbito organizacional bem como na gestão
e desenvolvimento de projetos; e gerenciar as atividades de melhoria e garantia da qualidade,
bem como as atividades de teste e documentação.
O Analista de Qualidade tem como atividades estudar e pesquisar formas de
melhoria a serem aplicadas tanto aos processos de desenvolvimento da Empresa A quanto aos
produtos desenvolvidos pela mesma, baseando-se nos modelos de melhoria CMMI e
MPS.BR; estudar e pesquisar formas de melhoria do uso das ferramentas utilizadas pela
empresa, como pesquisas de novos plug-ins, integração e organização; elaborar manual do
usuário, help online, apostilas de treinamento; implantar as melhorias analisadas no âmbito
organizacional bem como na gestão e desenvolvimento de projetos; realizar auditorias e
publicar os resultados; e relatar e acompanhar resolução de não conformidades encontradas
em auditorias.

21
 A figura 5.1 apresenta o novo organograma da empresa.

Figura 5.1 - Organograma

5.2 Política do Processo de Gerência de Requisitos

Primeiramente, foi criada uma política de gerenciamento de requisitos. O objetivo da política
é descrever as expectativas da empresa para o gerenciamento de requisitos dos projetos de
desenvolvimento. Essa política foi estabelecida para atender ao resultado do atributo do
processo RAP2, descrito no anexo A. Foi definido na política que
• Os fornecedores de requisitos para o projeto devem ser identificados após o
primeiro contato, após a solicitação do serviço;
• Os requisitos identificados para o projeto devem ser avaliados através de critérios
objetivos antes de serem apresentados aos clientes. O prosseguimento do projeto
depende da aprovação dos requisitos pelos clientes;
• O compromisso com os requisitos deve ser obtido;
• Toda mudança nos requisitos deve ser gerenciada. O impacto da mudança deve
ser calculado e registrado para conhecimento e aprovação do cliente. Os demais
documentos do projeto devem ser revisados para manter a consistência com os
requisitos;
• Os requisitos devem ser gerenciados através do registro da rastreabilidade entre os
mesmos e com os produtos de trabalho;
• Inconsistências entre o trabalho do projeto e os requisitos devem ser identificadas
e corrigidas.

22
 Na política foram acrescentadas as expectativas organizacionais, conforme
descrito a seguir:
• fazer parte de uma comunidade, elaborando produtos e gerando empregos;
• comercializar bens e serviços, obedecendo a padrões de qualidade;
• ter equilíbrio financeiro para seu crescimento;
• alcançar competitividade;
• acompanhar os avanços tecnológicos
• gerar lucro e perenidade.
E sobre a divulgação e institucionalização da política foi definido que a Política
de Desenvolvimento de Software da empresa deverá ser mantida e aprovada pela Direção. As
condições mínimas para que a Política seja revisada são:
• Quando o nível de maturidade da empresa for alterado para incluir novos
processos e capacidades
• Quando o organograma da empresa for alterado
• Quando algum dos itens que compõem a Política Organizacional da empresa for
alterado.
Todos os colaboradores devem ter conhecimento da Política através de mensagem
individual e disponibilização no space CMMI da wiki da empresa. Diretrizes técnicas
adicionais serão descritas e mantidas em documentos a parte, disponíveis a partir da página
principal do Space CMMI visando detalhar as obrigações indicadas nesta Política.

5.2.1 Aplicação da Política

Foi criado um documento extra explicando a aplicação da Política do Processo de Gerência
de Requisitos, definindo as tarefas do processo que representam a gerência de requisitos na
Empresa A.

5.2.1.1 Obter Entendimento dos Requisitos

Os requisitos são documentados de modo que todos os stakeholders tenham um entendimento
comum dos requisitos, estejam de acordo e possam assumir compromissos para a
implementação dos requisitos.
O Analista de Teste ou pessoa responsável deve revisar e analisar os requisitos
para garantir que critérios de aceitação dos requisitos sejam cumpridos;

5.2.1.2 Obter Compromissos

23
Stakeholders relevantes (que implementam os requisitos) avaliam o impacto dos novos
requisitos ou das mudanças dos requisitos nos compromissos existentes, no plano do projeto,
nas atividades do projeto e nos produtos de trabalho.
O Gerente de Projeto ou stakeholder responsável negocia, obtém e documenta
compromissos com os requisitos ou mudanças. Compromissos são negociados antes que os
participantes do projeto assumam os compromissos com os requisitos ou com as mudanças
nos requisitos.

5.2.1.3 Gerenciar Mudanças

O Gerente de Projeto, ou pessoa responsável, coleta e documenta as mudanças nos requisitos
requeridas externamente ou geradas pelo projeto.
O Gerente de Projeto e Analista de TI geram documento de análise dos impactos
da mudança.
O Comitê Executivo aprova ou não as mudanças nos requisitos de acordo com a
análise de impactos.
O Gerente de Projeto define quais produtos do processo devem ser mantidos sob
controle de configuração. É mantido um histórico de mudanças nos requisitos com a análise
de impacto e motivos das mudanças.
Os requisitos aprovados e dados das mudanças tornam-se disponíveis para os
stakeholders relevantes do projeto.

5.2.1.4 Manter Rastreabilidade

O Gerente de Projeto ou pessoa responsável mantém a rastreabilidade bidirecional dos
requisitos até os seus requisitos derivados conforme eles vão sendo decompostos ao longo do
ciclo de vida do projeto, como definido no plano do projeto.
O Gerente de Projeto ou pessoa responsável mantém a rastreabilidade bidirecional
dos requisitos até seu requisito derivado, bem como a sua alocação de funções, interfaces,
objetos, pessoas, processos e produtos de trabalho, como definido no plano do projeto.

5.2.1.5 Identificar e Corrigir Inconsistências

O Gerente de Projeto, o Analista de Qualidade e os stakeholders relevantes revisam os planos
do projeto, as atividades e os produtos de trabalho para verificar se estão consistentes com os
requisitos, as mudanças nos requisitos e documentam as inconsistências.
O Gerente de Projeto, os stakeholders relevantes ou pessoa responsável identifica
as fontes das inconsistências e as justificativas, para que ações corretivas possam ser tomadas.

24
 O Gerente de Projeto, os stakeholders relevantes ou pessoa responsável identifica
as mudanças que precisam ser feitas nos planos e produtos de trabalho resultantes das
mudanças na baseline de requisitos.
O Gerente de Projeto inicia as ações corretivas como necessário para atualizar o
plano e os produtos de trabalho resultantes das inconsistências ou mudanças na baseline de
requisitos.

5.3 Documentos do Processo

A tabela 5.1 define os documentos a serem utilizados no processo de gerência de requisitos. A
definição destes documentos deve estar registrada no Plano de Gerência de Requisitos, que
deve ser confeccionado para cada projeto.

Tabela 5.1 - Documentos do Processo de Gerência de Requisitos

Documento Template Objetivo
Especificação de Wiki Coletar, analisar e definir as necessidades e funcionalidades gerais do
Processos de sistema. Seu foco está nas necessidades dos usuários e no motivo da
Negócio existência destas necessidades.
Especificação de Wiki Detalhamento de um caso de uso. Esse detalhamento descreve as instâncias
Caso de Uso (UC) (cenários) de casos de uso, em que cada instância representa um conjunto
de passos que devem ser executados pelo sistema, com o objetivo de
produzir algo significativo para o(s) ator(es). Ou seja, descreve os
requisitos funcionais do sistema, podendo citar também requisitos não
funcionais.
Especificações Wiki Definir os requisitos do sistema que não são capturados diretamente pelos
Suplementares casos de uso, ou seja, os requisitos não funcionais.
(SR)
Solicitações de Wiki Apresentar as principais solicitações de mudança dos clientes. Devem
Mudança (CR) conter a justificativa para a alteração.
Bug Issue JIRA (issue) Apresentar as solicitações de mudança feitas pela equipe do projeto devido
a um erro ou problema encontrado no sistema.
Improvement Issue JIRA (issue) Apresentar as solicitações de mudança feitas pela equipe do projeto quando
é identificada a necessidade ou possibilidade de melhoria no sistema.

5.4 Itens de Rastreabilidade

A rastreabilidade é a capacidade de relacionar um elemento do projeto a outros elementos
relacionados aos requisitos. Os elementos do projeto envolvidos na rastreabilidade são
chamados de itens de rastreabilidade.
A proposta do estabelecimento desta estratégia é permitir: o entendimento das
origens dos requisitos; a gerência das mudanças nos requisitos; a avaliação do impacto, no
projeto, de uma alteração em um requisito; a avaliação do impacto, no requisito, de uma falha
em um teste (a falha do teste pode estar relacionada à não satisfação do requisito); e à
verificação de que o sistema faz somente o que está previsto no escopo do projeto. Para tal
25
foram identificados os itens de rastreabilidade de um projeto. Estes itens devem ser
documentados e rastreados ao longo do ciclo de vida do projeto.
Alguns dos itens não existiam e tiveram que ser criados para atingirem às
expectativas da estratégia de gerenciamento de requisitos. A tabela 5.2 apresenta os itens
identificados.
Tabela5.2 - Itens de Rastreabilidade
Item de Descrição Identificação Local Rastreabilidade
Rastreabilid
ade
Use Case Issue para Identificada com o JIRA Link para o documento confeccionado na
Issue gerenciamento do mesmo título do caso Wiki gerado automaticamente pela
caso de uso, desde de uso a ser cadastrado funcionalidade trackback do JIRA. Contém
sua criação até sua na wiki, com um as sub-tasks Documentation, Prototyping,
implementação e identificador contendo Requirement Test, Validation,
teste. sigla do projeto e Implementation e Implementation Test.
número gerados
automaticamente pelo
JIRA (IssueID).
Caso de uso Documento contendo UC## - nome do caso Wiki Deve conter a URL da issue
a especificação dos de uso correspondente no JIRA.
requisitos funcionais
do projeto.
Supplement Issue para Identificador contendo JIRA Link para documento correspondente na
ary gerenciamento da sigla do projeto e wiki gerado automaticamente pela
Requirement especificação número gerados funcionalidade trackback do JIRA. Contém
Issue suplementar, desde automaticamente pelo as sub-tasks Documentation,
sua criação até sua JIRA (IssueID), além de Requirement Test, Validation,
implementação e o mesmo título do Implementation e Implementation Test.
teste. documento de
Especificação
Suplementar.
Especificaçõ Documento contendo SR## - nome da Wiki Deve conter a URL da issue
es a especificação dos especificação correspondente no JIRA.
Suplementar requisitos não suplementar
es funcionais do projeto.
Change Issue para Identificada com o JIRA Link para Use Case issue correspondente
Request gerenciamento da mesmo título da (se houver um caso de uso derivado) e
Issue solicitação de Solicitação de link para a Solicitação de Mudança
mudança, desde sua Mudança da wiki, além confeccionada na Wiki, gerado
criação até sua de um identificador automaticamente pela funcionalidade
implementação e contendo sigla do trackback do JIRA. Contém as sub-tasks
teste. projeto e número Documentation, Prototyping,
gerados Requirement Test, Validation, Impact
automaticamente pelo Analysis, Implementation e
JIRA (IssueID). Implementation Test.
Solicitação Documento gerado a CR## - nome da Wiki Deve conter a URL da issue
de Mudança cada solicitação de Solicitação de Mudança correspondente no JIRA.
mudança nos
requisitos do projeto
feita pelo usuário.
Improvemen Issue que descreve Será identificada pela JIRA Link para a sub-task Implementation Test
t Issue alguma melhoria a sigla do projeto e e para o código (quando for resolvida).
ser implementada no número gerados
sistema. automaticamente pelo
JIRA (IssueID).

26
 Tabela 5.2 – (Continuação)
Item de Descrição Identificação Local Rastreabilidade
Rastreabilida
de
Bug Issue Issue que descreve Será identificado pela JIRA Link para a sub-task Implementation Test
algum problema ou sigla do projeto e e para o código (quando for resolvida).
erro encontrado no número gerados
sistema pela equipe automaticamente pelo
do projeto. JIRA (IssueID).
Código Código fonte do --- Subversio Referência para a issue correspondente
sistema. n no JIRA.
Documentati Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case,
on Sub-task da tarefa de IssueID gerada Suplementary Requirement ou Change
confecção do automaticamente. Request.
documento.
Prototyping Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case
Sub-task da tarefa de IssueID gerada ou Change Request.
prototipação. automaticamente.
Requirement Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case,
Test Sub- da tarefa de teste do IssueID gerada Suplementary Requirement ou Change
task documento. automaticamente. Request.
Validation Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case,
Sub-task da tarefa de IssueID gerada Suplementary Requirement ou Change
aprovação do automaticamente. Request.
documento.
Impact Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Change
Analysis Sub- da tarefa de calcular IssueID gerada Request.
task o impacto da automaticamente.
mudança no
requisito
Implementati Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case,
on Sub-task da tarefa de IssueID gerada Suplementary Requirement ou Change
implementação do automaticamente. Request. Pode receber link das issues de
que está desenvolvimento descritas abaixo.
especificado.
Implementati Issue para atribuição Identificado com uma JIRA Associação com a issue do tipo Use Case,
on Test Sub- da tarefa de teste do IssueID gerada Suplementary Requirement ou Change
task sistema baseado no automaticamente. Request, além de link para issues dos
documento tipos Bug e Improvement.
correspondente.
Issue de Issue que indica Identificado com uma JIRA Link (opção link do JIRA) para a sub-task
desenvolvime quais tarefas/ IssueID gerada Implementation correspondente e link
nto funcionalidades que automaticamente. para o código implementado através da
deverão ser aba Subversion Commits.
executadas/
implementadas.
Documentaçã Documentação para Identificados com o Wiki Este tipo de rastreabilidade não tem
o do Usuário o usuário final, que próprio nome do como ser mantida em ferramenta; porém,
Final inclui Manual do artefato. a documentação do usuário final
Usuário, Help Online (manuais e help on-line) e o material de
e Material de treinamento (apostilas e slides) devem
Treinamento. apresentar informações que estejam
compatíveis com os requisitos definidos
nas especificações de Casos de Uso.

5.5 Plano de Estrutura de Issues

27
Esta seção apresenta os itens de rastreabilidade que tiveram que ser criados para estabelecer a
estratégia de gestão de requisitos. Foram criadas novas estruturas de issues no JIRA.
As novas issues, que representam tarefas a serem realizadas, além das default já
apresentadas na tabela 4.1, estão representadas na tabela 5.3.
Tabela 5.3 - Novos tipos de issues
Nome Descrição Tipo
Bug Um problema que dificulta ou impede o funcionamento do produto Standard
Use Case Especificação dos requisitos funcionais Standard
Change Request Solicitação de Mudança Standard
Supplementary Especificação de requisitos não funcionais Standard
Requirements
Improvement Uma melhoria ou aperfeiçoamento de um recurso ou tarefaStandard
existente
New Feature Uma nova característica do produto, que ainda tem de serStandard
desenvolvida
Task Uma tarefa que tem que ser realizada Standard
Documentation Documentação dos requisitos Sub-Task
Prototyping Fase de prototipação do requisito Sub-Task
Requirement Test Fase de teste de requisitos Sub-Task
Validation Fase de validação por parte dos Stakeholders Sub-Task
Impact Analisys Avaliação do impacto da mudança no requisito Sub-Task
Implementation Codificação do requisito Sub-Task
Implementation Test Teste funcional ou não funcional do sistema Sub-Task
Sub-task Uma sub-task de uma issue Sub-Task

Em seguida, foi feito um plano de estrutura de issues, onde foi planejada uma
estrutura para cada situação: casos de uso, especificações suplementares e solicitações de
mudança. Na criação de uma issue dos tipos Use Case, Supplementary Requirement e
Change Request, além dos atributos descritos na seção 4.1.3, foi criado outro campo para
indicação do fornecedor do requisito, o campo Suggested by.
Para casos de uso foram criadas issues do tipo Use Case. No Jira, foi criado um
template para issues do tipo Use Case. O template possui a estrutura mostrada na figura 5.2:

28
 Figura 5.2 - Estrutura de uma issue do tipo Use Case

Na figura 5.2, e nas demais estruturas de issues que serão apresentadas nesta
seção, as issues representadas por uma caixa indicam que ela é do tipo Standard. As que são
representadas por um elemento oval indicam que ela é do tipo sub-task.
As issues do tipo Use Case contêm sub-tasks dos tipos: Documentation,
Prototyping, Requirement Test, Validation, Implementation e Implementation Test, que
indicam cada uma das fases de desenvolvimento de um caso de uso, desde sua confecção até a
sua implementação e teste.
Issues dos tipos Task e New Feature podem ser “linkadas” às issues de
Implementação (Implementation). Essas issues representam as tarefas que devem ser
executadas na fase de implementação.
Issues do tipo Bug ou Improvement são criadas quando um defeito ou uma
oportunidade/necessidade de melhoria é encontrada. Elas podem ser “linkadas” às issues de
teste de implementação (Implementation Test).
As setas tracejadas indicam links de relacionamento entre issues. Ou seja, que
uma issue está relacionada (relates to) com a outra. Essa é uma funcionalidade do JIRA, que
é feita através da opção Link this issue to another issue.
29
 A figura 5.3 mostra o template para issues do tipo Use Case que foi criado no
JIRA:

Figura 5.3 - template para issues do tipo Use Case

A figura 5.4 representa a estrutura de uma issue do tipo Supplementary

Requirement.

Figura 5.4 - Estrutura de uma issue do tipo Supplementary Requirement

O template para Supplementary Requirement Issues é ilustrado na figura 5.5:

30
 Figura 5.5 - template para issues do tipo Supplementary Requirement

A estrutura da Change Request Issue e a Change Request Issue Template são

dadas pelas figuras 5.6 e 5.7 respectivamente:

Figura 5.6 - Estrutura de uma issue do tipo Change Request

31
 Figura 5.7 - Template para issues do tipo Change Request

5.6 Estratégia de Rastreabilidade

Como foi definido na Política do Processo de Gerência de Requisitos, a rastreabilidade
bidirecional dos requisitos até os seus requisitos derivados deve ser mantida conforme eles
vão sendo decompostos ao longo do ciclo de vida do projeto, bem como a sua alocação de
funções, interfaces, objetos, pessoas, processos e produtos de trabalho.

5.6.1 Ferramentas
As ferramentas utilizadas para que a rastreabilidade pudesse ser realizada foram o
Confluence, o Jira, o Eclipse e seu plug-in Mylyn, o TortoiseSVN e o Subversion.
A figura 5.8 representa a integração entre as ferramentas utilizadas para a
rastreabilidade de requisitos:

32
 Figura 5.8 - Integração entre as ferramentas para rastreabilidade

5.6.1.1 Mylyn
O Mylyn é um plug-in do Eclipse que tem por função o gerenciamento de tarefas. Ele faz a
integração do Eclipse com o JIRA, permite visualizar as issues atribuídas do JIRA, ativar a
issue em que se vai trabalhar e anexar arquivos que foram alterados ao contexto da issue,
permitindo uma rastreabilidade desta até o código e vice-versa.
Foi necessário instalar os itens mostrados na figura 5.9 e o conector para o JIRA,
como indicado na figura 5.10.

33
 Figura 5.9 - Instalação do Mylyn

Figura 5.10 - Instalação do Conector do JIRA ao Mylyn

34
 Após instalar o Mylyn, foi necessário configurá-lo para acessar o JIRA. A tela de
configuração é exibida na figura 5.11:

Figura 5.11 - Configuração do Mylyn para acessar o JIRA

Todos os analistas de TI devem realizar essas operações, pois este é um passo

crucial para que se possa manter a rastreabilidade dos requisitos até o código correspondente,
conforme será explicado mais adiante. Feito isso, as issues do JIRA deverão ser importadas
da maneira que o analista achar conveniente, configurando os filtros para tal.
Com as issues no Eclipse, o analista pode, agora, consultá-las, alterar seu status e
fazer comentários. Com o Mylyn, o Eclipse poderá associar os arquivos de código que estão
abertos a uma issue. Um exemplo pode ser visto na figura 5.12.

35
 Figura 5.12 - Exemplo de associação de código e issue

Ao ser realizado um commit, o Mylyn adiciona automaticamente a issueID da

issue em que se está trabalhando ao comentário do commit. Veja um exemplo na figura 5.13.

36
 Figura 5.13 - Comentário adicionado pelo Mylyn ao fazer commit

5.6.1.2 JIRA Subversion Plug-in

Este plug-in faz integração do JIRA com o Subversion. Ele mostra informações sobre os
commits realizados no Subversion associados às issues do JIRA. Este plug-in é de
fundamental importância para manter a rastreabilidade vertical. É através dele que vai ser
possível saber qual parte do código foi alterada para qual requisito. Foi necessário instalar o
plug-in no JIRA e configurá-lo.
Através do Mylyn é feito o commit e automaticamente é adicionado ao
comentário a issueID. Nos commits realizados através do Totoise, o analista adiciona a
issueID ao comentário. O Plug-in JIRA Subversion localiza, para cada issue os commits que
foram realizados, buscando a issueID correspondente no comentário do commit. Encontrando
os commits, o JIRA Subversion adiciona à aba Subversion Commits os arquivos que foram
alterados referentes àquela issue. Um exemplo é mostrado na figura 5.14.
37
 Figura 5.14 - Aba Subversion Commits do JIRA

5.6.1.3 Clone and Move Plug-in

Este plug-in do JIRA faz com que se possa criar uma issue através da clonagem de outra. Esta
funcionalidade permite que seja feita a clonagem das issues templates apresentadas
anteriormente na seção 5.5.

Figura 5.15 - Clonando uma issue no JIRA

No campo Summary coloca-se o nome do Caso de Uso, Solicitação de Mudança,
ou Especificação Suplementar. Selecionando o campo Clone Sub Tasks, todas as sub-tasks
que representam as fases do ciclo de vida do requisito serão clonadas também (figura 5.15).

38
 Figura 5.16 - Selecionando o Projeto

Ao clicar no botão Create é exibida a página da figura 5.16 para que se escolha o
projeto para o qual será criada a issue.

5.6.1.4 Trackback
Trackback é uma funcionalidade do JIRA. Cada caso de uso que é criado no Confluence
possui um link para a issue correspondente no JIRA. O Trackback cria um link na issue para
cada documento que a referencie no Confluence.
Um exemplo pode ser visto na figura 5.17, em External References.

39
 Figura 5.17 - External References

Somando-se esta funcionalidade, com a do JIRA Subversion plug-in e a do

Mylyn, é mantida a rastreabilidade desde o documento de requisito confeccionado no
Confluence, até o código correspondente no Subversion.

5.6.2 Rastreabilidade Horizontal

A rastreabilidade entre um requisito e outro será feita através de referências, ou links, dentro
do próprio documento de requisitos. Os documentos de requisitos são confeccionados no
Confluence, que permite estabelecer esses links facilmente. Na figura 5.18 temos um exemplo
de um trecho de um documento de requisitos que contém links para outros documentos de
requisitos:

Figura 5.18 - Exemplo de rastreabilidade horizontal

5.6.3 Rastreabilidade Código -> Requisito

Através do Mylyn, o analista de TI faz o commit do código e a ID da issue relacionada à
tarefa que está sendo executada é adicionada automaticamente ao comentário do commit. O
Através da funcionalidade Blame da ferramenta TortoiseSVN, cada linha do
código que foi alterada, conterá a ID do responsável pela alteração e o número da revision
(figura 5.19).

40
 Figura 5.19 - Blame

A funcionalidade Show Log (figura 5.20) exibe o comentário de cada commit

feito, mantendo-se a rastreabilidade até a issue através da issueID desta. São mostrados todos
os arquivos para os quais foram realizados commits.

Figura 5.20 - Show Log

5.6.4 Rastreabilidade Requisito -> Código

41
A rastreabilidade do requisito até o código pode ser feita através do Jira. De posse da
identificação do documento de requisitos, é possível, através da issue correspondente, ver
todos os commits que foram realizados para aquele requisito na aba Subversion Commits
daquela issue e das issues relacionadas com ela, como mostra a figura 5.21.

Figura 5.21 - Aba Subversion Commits

5.7 Plano de Gerência de Requisitos

Foi criado um template para o Plano de Gerência de Requisitos. Cada projeto deverá ter seu
próprio plano, baseado no template.
O plano inclui controle de versões do plano; introdução, dizendo quais os
objetivos do plano, quais as responsabilidades pelo plano, as definições, acrônimos e
abreviaturas, papéis e responsabilidades da Gerência de Requisitos; Critérios de aceitação e
avaliação; Ferramentas; Documentos; Rastreabilidade; Agendamento dos Casos de uso;
Revisões em planos e produtos de trabalho; e Controle dos produtos de trabalho.
O objetivo do plano é descrever como será realizado o gerenciamento dos
requisitos do projeto. O Gerente de Projeto deverá ser o responsável pelo plano, ou seja, por
desenvolver e manter o documento.
Foi criado um Glossário com todos os termos necessários para o entendimento do
plano, e todos os papéis para a realização da gerência de requisitos e suas atividades foram
identificados.

5.7.1 Glossário
Os seguintes termos foram adicionados ao glossário:
• GRE: Gerência de Requisitos
• ATI: Analista de TI
• TI: Tecnologia de Informação
• ATO: Analista de Otimização
• GP: Gerente de Projeto

42
 • GTI: Gerente de TI
• AQ: Analista de Qualidade
• ATT: Analista de Teste
• Baseline: Conjunto de requisitos formalmente aprovados que servem de base para
as etapas seguintes de desenvolvimento
• Stakeholders: Todas as pessoas que influenciam ou são influenciadas pelas ações
da organização.

5.7.2 Papéis e Responsabilidades

Os papéis da empresa A são apresentados na tabela 5.4. Eles representam as funções que são
exercidas dentro da empresa. A tabela 5.4 apresenta também as responsabilidades de cada
papel, ou seja, as tarefas que cada função executa no processo de Gerência de Requisitos.

Tabela 5.4 - Tabela de papéis e responsabilidades

Papel Responsabilidades
ATI Assumem compromissos com os requisitos e os desenvolvem.
ATO Assumem compromissos com os requisitos e os desenvolvem.
ATT Verificam e avaliam os documentos de requisitos e de mudanças nos requisitos de acordo com os
critérios listados em Critérios de aceitação e avaliação de requisitos.
Cliente Fornece e aprova o documento de requisitos e de mudanças nos requisitos.
GP Responsável pela implementação do processo de Gerência de Requisitos; responsável pela análise
de impacto das mudanças nos requisitos.
AQ Avalia o processo de gerência de requisitos e os produtos de trabalho de acordo com os requisitos e
padrões.
Comitê Avalia impactos de mudanças no projeto e aprova ou não essas mudanças.
Executivo

5.7.3 Critérios de Aceitação e Avaliação de Requisitos

A avaliação dos requisitos deve ser feita baseada em critérios pré-definidos, e é feita após a
identificação dos requisitos a fim de garantir que os requisitos levantados atendem às
necessidades e expectativas do cliente. Para fornecer essa garantia, foi criada a lista abaixo, a
qual define que os requisitos devem ser
• Clara e apropriadamente declarados
• Não Ambíguos
• Completos

43
 • Consistentes uns com os outros
• Identificados de forma única
• Apropriados para serem implementados
• Verificáveis (podem ser testados)
• Rastreáveis
• Todos os requisitos devem seguir um padrão de comportamento para o sistema

5.7.4 Registro de Aceite dos Requisitos

Deve-se ter uma evidência de que os documentos de requisitos foram aprovados. O Plano
define que devem ser registrados na wiki os aceites dos requisitos através de cópia de emails,
estando essa anexada à página de artefatos do projeto no Confluence. Se o aceite for feito de
outra maneira, também deverá ser anexado o registro do aceite dos requisitos no mesmo local.

5.7.5 Ferramentas, Documentos e Rastreabilidade

O Plano de Gerência de Requisitos estabelece o uso das ferramentas descritas na seção 5.6.1.
Os documentos que farão parte da gerência de requisitos foram mostrados na seção 5.3, e a
estratégia de rastreabilidade, na seção 5.6.

5.7.6 Agendamento dos Casos de Uso

Foi estabelecido no Plano de Gerência de Requisitos que o gerente do projeto deverá realizar
o agendamento para o detalhamento dos casos de uso. O agendamento deverá ser
confeccionado no Confluence e disponibilizado no Space do Projeto. O Agendamento deverá
ser aprovado pelo cliente e o aceite deve ser anexado junto ao agendamento.
Um exemplo desse agendamento pode ser visto na figura 5.22.

44
 Figura 5.22 - Agendamento para Detalhamento dos Casos de Uso

5.7.7 Revisões em Planos e Produtos de Trabalho

Foi estabelecido no plano que sempre que surgir novos requisitos, ou houver mudança nos
requisitos, o Gerente de Projeto deve atribuir a tarefa de revisão ao Analista de Qualidade. As
revisões são feitas ao final de cada iteração da fase de construção do ciclo de vida do projeto.
O Analista de Qualidade deve examinar se os demais artefatos estão consistentes com as
alterações realizadas como, por exemplo: verificar se a planilha de estimativas está
contemplando todos os requisitos e mudanças; verificar se as mudanças dos requisitos foram
incorporadas ao escopo ou cronograma do projeto; identificar inconsistências entre os
requisitos e os demais elementos do projeto como, por exemplo, planos, atividades e produtos
de trabalho; e outros.
As inconsistências identificadas devem ser registradas no JIRA como Bug e ações
corretivas executadas a fim de resolvê-las. As ações para correções das inconsistências devem
ser acompanhadas até que sejam resolvidas.

5.7.8 Controle dos Produtos de Trabalho

O controle de versionamento dos requisitos será feito através da Wiki por uma tabela
contendo uma coluna Versão em que será indicada a versão do documento com um link para
45
esta; uma coluna Descrição indicando a confecção ou as alterações que foram realizadas no
documento e identificando revisões; e uma coluna Data indicando o dia, mês e ano da versão,
além do Autor (figura 5.23).

Figura 5.23 - Tabela de Controle de Versão

O controle de acesso será feito também através da Wiki. Na administração do

Space do projeto, é possível definir quem poderá acessar o Space dentre outras restrições,
como mostra a figura 5.24.

46
 Figura 5.24 - Permissão de Acesso no Confluence

O controle de acesso também pode ser feito por página, como é mostrado na
figura 5.25.

Figura 5.25 - Restrição de Acesso a Página do Confluence

47
5.8 Auditorias de Qualidade
Para atender aos resultados esperados RAP4 e RAP10 do MPS.BR, para o processo de
gerência de requisitos, foram criados templates de reportes de auditoria de qualidade, um para
o processo de gerência de requisitos e outro para avaliar o plano de gerência de requisitos. O
primeiro reporte consiste de questões específicas do processo, o segundo, de questões
relativas ao documento confeccionado. Os templates são apresentados nas tabelas 5.5 e 5.6.

Tabela 5.5 - Template do Reporte de Auditoria de Qualidade para o Processo

Atend
Questão
e? Issue
Foram definidos os critérios de aceitação e avaliação dos requisitos?
Os requisitos são definidos a partir do entendimento junto aos fornecedores de
requisitos?

Foram criados documentos de requisitos garantindo o entendimento?

Foram identificados todos os recursos necessários? (Ex: Equipamentos, ferramentas,
serviços...)
É feito o teste do documento de requisitos de acordo com os critérios de aceitação e
avaliação de requisitos?
É feita a validação do documento de requisitos de acordo com os critérios de
aceitação e avaliação de requisitos?

Foram identificados os itens de rastreabilidade?

Foi estabelecido um mecanismo que rastreie a dependência entre os requisitos e os
produtos de trabalho?
São corrigidas as inconsistências, se identificadas, entre os requisitos e os demais
elementos do projeto como, por exemplo, planos, atividades e produtos de trabalho?

Foi definido o ciclo de vida das solicitações de mudança dos requisitos?

As solicitações de mudanças são registradas?
É feita uma análise do impacto das mudanças?

Tabela 5.6 - Template para o Reporte de Auditoria de Qualidade para o Plano

Atend
Questão
e? Issue
Existem erros ortográficos ou gramaticais no documento?

O documento apresenta um controle de versões?

O documento está completo em relação ao template?

Foram incluídas as definições de termos específicos do documento?
Todos os responsáveis pelas atividades praticadas no plano são identificados?
O documento está consistente internamente? (relacionamento entre 2 ou mais
seções)
O documento está consistente externamente? (relacionamento do conteúdo com
outros documentos)
O documento está claro?
O documento apresenta aderência aos padrões?

O Gerente do Projeto define quando serão realizadas as auditorias e as adiciona ao

cronograma do projeto. As auditorias de qualidade são realizadas pelos analistas de qualidade
da empresa. Para cada não conformidade encontrada, uma issue do tipo Bug deve ser criada e
48
atribuída a um responsável por resolvê-la. O Gerente do Projeto e o Analista de Qualidade
são responsáveis por acompanhar a issue até sua resolução.

5.9 Análise de Conformidade

São descritos aqui os requisitos do MPS.BR para o Processo Gestão de Requisitos de forma a
atendê-lo e quais foram as evidências geradas para atingir os requisitos necessários. Dessa
forma é feita uma análise do que foi alcançado através da metodologia utilizada para o
processo de gestão de requisitos na Empresa A levantada por este trabalho.
É visto como a estratégia estabelecida para o processo abrange os resultados
esperados do GRE. Foram incluídos na análise os resultados esperados específicos do
processo e os resultados esperados dos Atributos do Processo (AP1.1 e AP2.1), os RAP’s,
para o nível G.
Ao longo do diagnóstico, foram analisadas evidências da implementação dos
resultados esperados do modelo, identificando-se o nível de implementação de cada resultado.
Cada resultado esperado pode ser classificado como “Totalmente Implementado”,
“Largamente Implementado”, “Parcialmente Implementado” e “Não Implementado”. Sendo
que para atingir o nível G do MR-MPS, a implementação dos processos deve satisfazer os
atributos de processo AP 1.1 e AP 2.1. No que se refere aos atributos de processo, uma
organização deve atender aos resultados esperados RAP 1 a RAP 10. Em uma avaliação
segundo o MA-MPS (2009, p.55) é exigido para se considerar um processo “satisfeito” no
nível G que o atributo de processo AP 1.1 seja caracterizado como totalmente implementado
e o atributo de processo AP 2.1 seja caracterizado como totalmente ou largamente
implementado.
GRE1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de
requisitos, utilizando critérios objetivos.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: O plano define quais são os documentos de requisitos, como
são avaliados, tanto pela organização quanto pelo cliente. Está definido
no plano, também, que deverá haver registro dos aceites dos requisitos.
o Evidência: Agenda para Detalhamento dos Casos de Uso
 Tipo: Página do Confluence

49
  Detalhes: Comprova que há um planejamento para que haja um
entendimento dos requisitos.
o Evidência: Casos de Uso, Especificações Suplementares e Solicitações de
Mudança
 Tipo: Página na Wiki
 Detalhes: Documento que representa a comprovação do entendimento
dos requisitos.
o Evidência: Registro de Aceite
 Tipo: Anexo em página do Confluence
 Detalhes: Garantia de que os requisitos propostos atendem às
necessidades e expectativas do cliente e dos usuários.
o Evidência: Critérios de Aceitação e Avaliação dos Requisitos
 Tipo: Página na Wiki
 Detalhes: Evidência de que os requisitos são avaliados e aprovados
com base em um conjunto de critérios objetivos, previamente
estabelecidos.
GRE2 – O comprometimento da equipe técnica com os requisitos aprovados é obtido.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Issues de Requisitos
 Tipo: Registros do JIRA
 Detalhes: As issues dos tipos Use Case, Supplementary Requirement e
Change Request possuem os campos Suggested by e Assignee, que
representam o fornecedor do requisito e o responsável por sua
implementação, respectivamente.
GRE3 – A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é
estabelecida e mantida.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: O plano apresenta a seção “Estratégia de Rastreabilidade”
que, como o nome diz, apresenta a estratégia estabelecida para manter
as rastreabilidades horizontal e vertical dos requisitos.
o Evidência: Sub-Tasks das Issues

50
  Tipo: Registros do JIRA
 Detalhes: As sub-tasks geram os relacionamentos descritos na seção
“Estratégia de Rastreabilidade” no Plano de Gerência de Requisitos.
o Evidência: Mylyn
 Tipo: Ferramenta (Plugin do Eclipse)
 Detalhes: Faz com que, na hora de fazer o commit, o comentário receba
a issueID correspondente à tarefa executada, relativa ao requisito em
questão. Mantém a rastreabilidade entre requisito e código.
o Evidência: Links entre casos de uso
 Tipo: Funcionalidade do Confluence
 Detalhes: Mantém a rastreabilidade entre requisitos.
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.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Sub-tasks Validation, Documentation Test e Implementation Test
 Tipo: Registros do JIRA
 Detalhes: Representam revisões que verificam a consistência entre os
requisitos e os produtos de trabalho.
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página do Confluence
 Detalhes: Seção “Revisões em Planos e Produtos de Trabalho”.
GRE5 – Mudanças nos requisitos são gerenciadas ao longo do projeto.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Issues do tipo Change Request
 Tipo: Registro do JIRA
 Detalhes: Representam o acompanhamento de toda a vida de uma
solicitação de mudança, desde a especificação do requisito até a
implementação e teste.
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: A seção “Revisão em planos e produtos de trabalho”
apresenta a descrição do como proceder ao haver mudança nos

51
 requisitos. A seção “Itens de Rastreabilidade” apresenta as solicitações
de mudança e as issues Change Request como itens a serem rastreados.
(AP1.1 – O processo é executado)
RAP1 – O processo atinge seus resultados definidos.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Fluxos executados no JIRA
 Tipo: Registros do JIRA
 Detalhes: A empresa implantou a estratégia e já pode ser observado seu
uso na prática, logo, os resultados dos processos geram os principais
produtos requeridos.
o Evidência: Casos de Uso, Especificações Suplementares e Solicitações de
Mudança.
 Tipo: Página na Wiki
 Detalhes: Link de rastreabilidade e controle de versões garantem que o
processo de gerência de requisitos está sendo executado corretamente.
(AP2.1 – O processo é gerenciado)
RAP2 – Existe uma política organizacional estabelecida e mantida para o processo.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Política do Processo de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: Existe uma política e esta está publicada e foi comunicada a
todos os interessados em sua execução.
RAP3 – A execução do processo é planejada.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Aplicação da Política do Processo de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: Possui a descrição do processo, as responsabilidades e
atividades para execução do mesmo.
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: Possui a descrição do processo, as responsabilidades e
atividades para a execução do mesmo.

52
RAP4 – (Para o nível G) A execução do processo é monitorada e ajustes são realizados.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: A seção “Revisões em Planos e Produtos de Trabalho”
demonstra que há um monitoramento na execução do processo e que
ações corretivas são tomadas sempre que necessário.
o Evidência: Reporte de Auditoria
 Tipo: Planilha Excel
 Detalhes: Documento que comprova o monitoramento da execução do
processo, pois avalia se o processo está sendo executado de acordo com
a descrição do processo.
RAP5 – (Até o nível F) As informações e os recursos necessários para a execução do
processo são identificados e disponibilizados.
• Implementação: Largamente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: A seção “Ferramentas” mostra recursos (ferramentas)
necessários para a execução do processo. A seção “Papéis e
Responsabilidades” mostra as funções necessárias para execução do
processo.
• Observações: Não foram apresentadas definições de recursos financeiros e de
condições físicas adequadas, apenas ferramentas.
RAP6 – (Até o nível F) As responsabilidades e a autoridade para executar o processo
são definidas, atribuídas e comunicadas.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: A seção “Papéis e Responsabilidades” cobre este resultado
esperado, uma vez que define claramente as autoridades e
responsabilidades para execução do processo.
o Evidência: Email de criação de issue

53
  Tipo: Funcionalidade do JIRA
 Detalhes: Quando uma issue é criada, o assignee (responsável pela
issue) recebe um email de notificação. Logo, a comunicação é
estabelecida e a autoridade atribuída.
RAP7 – (Até o nível F) As pessoas que executam o processo são competentes em termos
de formação, treinamento e experiência.
• Implementação: Parcialmente Implementado
• Fonte de Evidências:
o Evidência: Plano de Gerência de Requisitos
 Tipo: Página na Wiki
 Detalhes: A seção “Papéis e Responsabilidades” mostra as
competências necessárias para a execução do processo.
• Observações: A evidência para este resultado esperado não é suficiente pois não
garante que a pessoa que representa aquele papel possui aquelas competências. A
empresa deve fazer um dossiê com o currículo de todos os funcionários, e, se
possível, anexando cópia dos certificados dos colaboradores.
RAP8 – A comunicação entre as partes interessadas no processo é gerenciada de forma
a garantir o seu envolvimento.
• Implementação: Não Implementado
• Fonte de Evidências: Não há
• Observações: A empresa pode estabelecer que cada projeto deva ter um Plano
de Comunicação para identificar os interessados e permitir que se mantenha a
comunicação entre eles.
RAP9 – (Até o nível F) Os resultados do processo são revistos com a gerência de alto
nível para fornecer visibilidade sobre a sua situação na organização.
• Implementação: Não implementado
• Fonte de Evidências: Não há
• Observações: O gerente de projeto poderá definir reuniões periódicas no Plano
de Comunicação para comunicar o estado da execução do processo à gerência de
alto nível.
RAP10 – (Para o nível G) O processo planejado para o projeto é executado.
• Implementação: Totalmente Implementado
• Fonte de Evidências:
o Evidência: Reporte de Auditoria
 Tipo: Planilha Excel

54
  Detalhes: Garante que existem registros da execução do processo, com
base no planejamento do mesmo, pois o template da planilha é baseado
na política do processo de gerência de requisitos.

CAPÍTULO 6
CONCLUSÕES

6.1 Resultados Obtidos

A partir da análise da situação atual da empresa foi possível identificar que esta pode
implantar melhorias na realização do processo de gestão de requisitos. A documentação que a
empresa utilizada é incompleta, principalmente no que diz respeito à rastreabilidade dos
requisitos e controle na alteração de requisitos.
A empresa faz reuniões com os clientes para levantamento dos requisitos de
software, elabora casos de uso e solicitações de mudança quando há alguma alteração nos

55
requisitos, atribui tarefas através do JIRA para implementação dos sistemas, porém não existe
um padrão de modelo para gestão dos requisitos definidos.
Alguns gerentes de projeto têm a impressão de que o processo de requisitos é
necessário somente em projetos desenvolvidos desde o início. Porém, a identificação e o
desenvolvimento de requisitos ocorrem mesmo em projetos customizados ou adaptados. O
que ocorre, nesses casos é a alteração dos requisitos existentes em vez da criação de um novo
sistema, gerando uma complicação maior: o gerenciamento de mudanças nos requisitos, com
a identificação de impacto de tempo e custo. Até em projetos desenvolvidos desde o início,
alterações ocorrem durante o ciclo de vida, sendo necessário o acompanhamento dessas
mudanças durante todo esse período.
Foi proposta uma metodologia para implantação de um processo definido de
gerência de requisitos na empresa, de forma a atender aos resultados esperados do MPS.BR
para esse processo, atingindo, assim, os requisitos de qualidade de software reconhecidos
nacional e internacionalmente. Para que isso fosse possível, foi sugerida uma pequena
alteração na estrutura organizacional da empresa, a adoção de novos papéis.
Para verificar a cobertura da metodologia proposta em relação aos resultados
esperados do processo de gerência de requisitos do modelo de qualidade, foi feita uma análise
de conformidade, onde foram listadas, para cada resultado, as evidências geradas que
atendem aos requisitos. Foi feita, então, uma avaliação da implementação de cada resultado.
O atributo de processo AP 1.1 foi caracterizado como “Totalmente Implementado”, porém
nem todos os resultados do atributo de processo AP 2.1 foram caracterizados da mesma
forma. Dos nove RAP’s, um foi caracterizado como “Largamente Implementado”, dois como
“Não Implementados”, um como “Parcialmente Implementado” e cinco como “Totalmente
Implementados”. Visto que todos os RAP’s do AP 2.1 devem ser, no mínimo, largamente
implementados para que o processo atinja o nível G de maturidade, três dos dez RAP’s
precisam ser revistos e evidências devem ser geradas para eles.
Tem-se, então, que 70% dos resultados esperados foram atingidos pela
metodologia sugerida. E através dos resultados é possível perceber que a melhoria da gerência
de requisitos não pode ser feita de forma isolada dentro da organização. É preciso combinar
um melhor controle sobre os requisitos de software com um melhor gerenciamento dos
projetos existentes. Este trabalho é o passo inicial para um objetivo maior, a definição de
processos aderentes ao nível G do MPS.BR.

6.2 Trabalhos Futuros

56
A partir da análise de conformidade realizada, para verificar o alinhamento com o processo
de gerência de requisitos do MPS.BR, identificou-se a necessidade de verificar algumas
questões mais detalhadamente: os resultados do atributo de processo AP 2.1, assim como a
forte ligação que existe entre o processo de gerência de requisitos e os demais processos do
MPS.BR, que, em um trabalho futuro, poderão ser consideradas.

6.3 Considerações Finais

Reconhecer que não é possível cumprir prazos, custos e desenvolver software com qualidade
atendendo às expectativas dos usuários sem ter um processo de gerência de requisitos bem
elaborado, compreendido e utilizado por todos os interessados, é de fundamental importância.
Muitas empresas têm buscado investir em certificações relacionadas a software,
pois vêem a importância da qualidade de software no mercado. O projeto MPS.BR foca no
processo, pois uma vez que não se tenham processos definidos e bem elaborados, a
probabilidade de ocorrerem problemas é alta.
Sabe-se que obter qualidade nos processos e produtos de software não é uma
tarefa trivial e exige muita dedicação de todos os envolvidos. São diversos os fatores que
dificultam atingir os objetivos de qualidade. No entanto, é frustrante produzir um software
que não satisfaça às necessidades esperadas.
Como um processo é um conjunto de passos definidos para se alcançar
determinado objetivo, vale ressaltar que não existe um processo ideal ou genérico o suficiente
para atender a qualquer projeto ou organização. Certamente será necessário fazer adaptações
devido a características do sistema, dos usuários, da equipe, da organização, do tipo de
sistema, da tecnologia e até mesmo da metodologia de desenvolvimento utilizada.
A estratégia proposta neste trabalho se aplica a empresas que desenvolvem
software, sugerindo uma metodologia para melhorar o processo de gerenciamento de
requisitos. Partindo da utilização dos modelos e processos aqui definidos, acredita-se que seja
possível melhorar a qualidade dos requisitos, tanto para os sistemas desenvolvidos desde o
início, quanto para os customizados ou adaptados. Não é fácil a implementação de uma
metodologia como esta, ou de um processo qualquer. Requer investimentos de recursos,
treinamentos e uma mudança cultural.

57
REFERÊNCIAS BIBLIOGRÁFICAS
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia de Avaliação:2009, maio 2009. Disponível em: <www.softex.br>.
Acesso em: 26/11/2009.

ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –

SOFTEX. MPS.BR – Guia de Implementação – Parte 1: Nível G:2009, maio 2009.
Disponível em: <www.softex.br>. Acesso em: 26/11/2009.

ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –

SOFTEX. MPS.BR – Guia Geral:2009, maio 2009. Disponível em: <www.softex.br>. Acesso
em: 26/11/2009.

JIRA CLONE AND MOVE PLUGIN. Disponível em: <http://confluence.atlassian.com>.

Acesso em: 26/11/2009.
58
JIRA SUBVERSION PLUGIN. Disponível em: <http://confluence.atlassian.com>. Acesso
em: 26/11/2009.

MYLYN. Disponível em: <http://www.eclipse.org>. Acesso em: 26/11/2009.

PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo:
Pearson Prentice Hall, 2007.

PRESSMAN, Roger S. Engenharia de Software. 1. ed. São Paulo: Makron Books, 1995.

SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV),

Version 1.2, Technical Report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, 2006.

SOMMERVILE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003.
The Chaos Report (1994). Disponível em: <http://www.standishgroup.com>. 26 Nov.2009.

O QUE É AFINAL TECNOLOGIA DA DECISÃO? Disponível em

<http://www.gapso.com.br>. Acesso em: 11/12/2009.

TRACKBACK LINKING. Disponível em: <http://www.atlassian.com>. Acesso em:

26/11/2009.

59
ANEXO A
A seguir, os atributos de processo AP 1.1 e AP 2.1, conforme aplicáveis no nível G, são
descritos com detalhes.
AP 1.1 - O processo é executado
Este atributo é uma medida do quanto o processo atinge o seu propósito.
Este atributo de processo está diretamente relacionado ao atendimento do propósito do
processo. Relacionado a este atributo de processo está definido o seguinte resultado esperado:
RAP 1 - O processo atinge seus resultados definidos
Este resultado esperado busca garantir que o processo transforma produtos de trabalho
de entrada identificáveis em produtos de trabalho de saída, também identificáveis,
permitindo, assim, atingir o propósito do processo. Ou seja, este resultado implica
diretamente na geração dos principais produtos requeridos pelos resultados dos
processos.
AP 2.1 - O processo é gerenciado
Este atributo é uma medida do quanto a execução do processo é gerenciada.
Este atributo de processo está relacionado à gerência dos processos. A implementação deste
atributo de processo implica no planejamento da execução do processo, atribuindo
responsabilidade e autoridade para sua execução, bem como fornecendo recursos adequados.
Envolve também o monitoramento e controle da execução dos processos, tomando ações

60
corretivas, quando necessárias. Relacionados a este atributo de processo estão definidos os
seguintes resultados esperados:
RAP 2 - Existe uma política organizacional estabelecida e mantida para o
processo
Este resultado visa à definição de uma política contendo as diretrizes de como a
organização planeja e implementa os seus processos, bem como informações sobre as
expectativas organizacionais para a execução dos processos e a indicação de como
devem ser atendidos os aspectos mais importantes de cada processo. Isso pode incluir
princípios básicos e definições gerais de como executar os processos, incluindo
aspectos de responsabilidades, tempos e instrumentos. A política não deve ser uma
reprodução de textos do MR-MPS, mas sim, como a organização enxerga seus
processos. Um documento genérico pode existir definindo quem tem autoridade,
delegada pela gerência de alto nível, para aprovar cada tipo de documento.
Normalmente, as políticas são definidas e aprovadas pela gerência de alto nível, não
havendo a obrigatoriedade de serem rotuladas exatamente de “políticas”. Uma vez
definidas, as políticas devem ser publicadas e divulgadas aos interessados em sua
execução. Tal publicação pode ser realizada, por exemplo, na Intranet da organização.
Em geral, a divulgação da política pela alta gerência ajuda a enfatizar a importância
dos processos, facilitando sua institucionalização.
RAP 3 - A execução do processo é planejada
Este resultado visa à realização de um plano para a execução do processo. Este
planejamento deve incluir recursos, responsabilidades e tempo, bem como as
atividades de controle e monitoramento da execução do processo. Deve ser
estabelecido e documentado um plano para a execução do processo, o que inclui sua
própria descrição, porém não se restringindo a ela.. É importante que o planejamento
seja revisto, sempre que necessário, especialmente quando forem aprovadas mudanças
significativas.
RAP 4 - A execução do processo é monitorada e ajustes são realizados
Este resultado só se aplica ao nível G e visa monitorar a execução dos processos
conforme o que foi planejado e assegurar que ações corretivas sejam tomadas sempre
que houver desvios significativos em relação ao planejado. Desta forma, revisões das
atividades, estado e resultados dos processos devem ser realizadas e podem ocorrer
tanto periodicamente ou motivadas por algum evento. Durante o monitoramento dos
processos, questões poderão ser identificadas, para as quais ações corretivas deverão
ser tomadas e acompanhadas até o seu encerramento. O monitoramento do processo

61
pode ser incluído nas próprias atividades de monitoramento do projeto, quando
aplicável.
RAP 5 - As informações e os recursos necessários para a execução do processo
são identificados e disponibilizados
Este resultado visa assegurar que as informações e os recursos necessários para
executar o processo serão identificados previamente e que estarão disponíveis quando
forem necessários. Incluem recursos financeiros, condições físicas adequadas, pessoal
e ferramentas apropriadas (incluindo processos e modelos de documentos
predefinidos). Estas informações e recursos podem estar estabelecidos na própria
descrição do processo ou podem, também, estar presentes em planos específicos para
os processos nos níveis da organização e/ou projeto.
RAP 6 - As responsabilidades e a autoridade para executar o processo são
definidas, atribuídas e comunicadas
Este resultado visa assegurar que as responsabilidades e a autoridade para executar o
processo estão claramente definidas e bem compreendidas.
Deve-se assegurar, também, que as responsabilidades e a autoridade para executar o
processo foram atribuídas explicitamente e comunicadas a todas as partes interessadas,
por exemplo, patrocinador, implementadores etc.
RAP 7 - As pessoas que executam o processo são competentes em termos de
formação, treinamento e experiência
Este resultado visa assegurar que as pessoas tenham as habilidades, conhecimentos e
experiências necessários para executar ou apoiar o processo. Deve-se assegurar que as
pessoas tenham o conhecimento em relação ao seu papel no processo: conhecimento
completo para aqueles que vão realizar as atividades do processo e conhecimento
genérico para os que vão interagir com o processo. Conhecimento e habilidades não se
restringem aos documentos de processo, mas podem incluir trabalho em grupo,
liderança, análise e solução de problemas. Quando se julgar necessário, um
treinamento apropriado deve ser fornecido para as pessoas que executarão os
processos. Os treinamentos podem ser de diferentes tipos, por exemplo: treinamento
autodirecionado; instrução programada autodefinida; treinamento formal dentro do
trabalho; mentoring; treinamento formal em salas de aula. Mantendo-se o registro das
competências atuais e necessárias das pessoas para a realização dos diversos papéis na
execução dos processos, pode-se planejar os treinamentos necessários.
RAP 8 - A comunicação entre as partes interessadas no processo é gerenciada de
forma a garantir o seu envolvimento

62
O objetivo deste resultado é identificar as partes interessadas no processo, planejar e
manter o seu envolvimento. Os interessados podem ser envolvidos tipicamente em
atividades tais como: planejamento; coordenação; revisão; e definição dos requisitos
para a execução do processo. É importante gerenciar a interface entre as partes
interessadas de forma a assegurar a comunicação.
RAP 9 - Os resultados do processo são revistos com a gerência de alto nível para
fornecer visibilidade sobre a sua situação na organização
O objetivo deste resultado é fornecer visibilidade à alta gerencia com relação ao
estado da execução dos processos, considerando sua adequação, operação com
recursos apropriados e alcance dos resultados esperados. Um dos métodos de
monitoração de processo é a revisão, junto à gerência de alto nível, de seu estado,
atividades realizadas e resultados alcançados. As revisões devem ocorrer
periodicamente ou, então, motivadas por algum evento e não necessitam ser
presenciais. Desta forma, o andamento da implantação dos processos, tendências e
problemas são relatados e tratados em níveis apropriados. Caso pertinente, ações
corretivas são estabelecidas e gerenciadas até a sua conclusão, com escalonamento aos
níveis adequados de gerência, sempre que necessário.
Este resultado não deve ser confundido com a monitoração do processo conforme
definida no RAP 4, mas pode utilizar também os dados obtidos a partir de sua
execução.
RAP 10 - O processo planejado para o projeto é executado
O objetivo deste resultado é garantir que o projeto é conduzido a partir da execução do
seu processo planejado. Deve-se garantir que existem registros de execução das
atividades do processo com base no seu planejamento. Esses registros devem ser
mantidos e revistos periodicamente para garantir que o processo planejado está sendo
seguido para atingir os objetivos do projeto.

63
ANEXO B
Resultado esperados para o processo Gerência de Requisitos segundo o Guia de
Implementação – parte 1 do MPS.BR.
GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de
requisitos, utilizando critérios objetivos
O objetivo deste resultado é entender os requisitos junto com seus fornecedores.
Esses requisitos devem ser analisados para se assegurar que eles foram claramente definidos e
se foram compreendidos, com base em critérios pré-estabelecidos, como, por exemplo,
estarem clara e apropriadamente declarados, ter identificação única, não ser ambíguo, ser
implementável, ser rastreável.
A comprovação do entendimento dos requisitos é feita através do documento de
requisitos. Deve ser feito um aceite do documento de requisitos por parte dos fornecedores,
que deve ser registrado.
Se forem feitas mudanças nos requisitos, novas avaliações e aprovações dos
requisitos devem ser feitas.
GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido
Tendo obtido o entendimento dos requisitos, sua aprovação e documentação, é
necessário que a equipe técnica obtenha um comprometimento com os mesmos. A equipe
técnica é composta por todos aqueles envolvidos diretamente com o desenvolvimento do
produto, por exemplo, desenvolvedores, analista de sistemas, projetistas, entre outros. O
comprometimento com os requisitos deve ser registrado.
Caso haja mudança nos requisitos, deve ser obtido um novo comprometimento da
equipe técnica com os requisitos alterados, após estes terem sido documentados e aprovados.
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é
estabelecida e mantida

64
 O objetivo deste resultado é manter a rastreabilidade entre os requisitos do projeto
e o produto de software. A rastreabilidade é uma propriedade que facilita identificar os
requisitos relacionados e também os elementos de software correspondentes a eles.
Tendo um mecanismo que permita essa rastreabilidade, é facilitada a avaliação do
impacto das mudanças de requisitos que possam ocorrer. A inclusão de novos requisitos ou
alteração dos requisitos existentes pode impactar, por exemplo, nas estimativas do escopo,
nos produtos de trabalho e nas tarefas 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
Este resultado tem por objetivo verificar se existem inconsistências entre os
produtos de trabalho e os requisitos do projeto. Todos os problemas que forem encontrados
devem ser registrados e corrigidos. Portanto, deve haver um mecanismo através do qual possa
se realizar revisões para identificar essas inconsistências.
GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto
Por diversas razões, no decorrer do projeto, os requisitos podem sofrer alterações
e novos requisitos podem ser adicionados ao projeto. Portanto, torna-se necessário o
gerenciamento eficiente e eficaz dessas mudanças. Também é necessário documentar toda e
qualquer alteração, e um histórico das decisões tomadas deve estar disponível.

65