PS DocumentoDescritivo

MINISTÉRIO DA CIÊNCIA, TECNOLOGIA, INOVAÇÕES E COMUNICAÇÕES
SECRETARIA EXECUTIVA
DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO
COORDENAÇÃO-GERAL DE SISTEMAS
Processo de Gestão de Demandas do

Ministério da Ciência, Tecnologia, Inovações e Comunicações
PS-MCTIC
Versão 4.0
Pág. 1 de 165
Ministério da Ciência, Tecnologia, Inovações e Comunicações - MCTIC

Diretoria de Tecnologia da Informação
Coordenação-Geral de Gestão da Tecnologia da Informação - CGSI
Ministro
Gilberto Kassab
Secretaria Executiva
Elton Santa Fé Zacarias
Diretoria de Tecnologia da Informação

Bernardo Manuel Veiga
Coordenação-Geral de Sistemas
George Hildeyuki Kuroki Júnior
Equipe Técnica da CGSI:
Anivaldo Vale,
Fernando Szimanski.
Pág. 2 de 165
Histórico de Revisões
Rev. Nº Data Descrição Autor

1.0 08/08/2014 Criação do documento RSI Informática
Ajustes realizados conforme Relatório de não
1.1 09/09/2014 RSI Informática
conformidades enviado pelo MCTI.
Ajustes realizados conforme e-mail enviado pelo
MCTI.
Revisão dos processos Revisão Técnica, Solução
Técnica e Gerenciamento de Riscos.
Revisão dos processos Integração do Produto (IP) e
Teste (TS)
Revisão dos processos Gestão de Configuração (GC) e
Monitoramento e Controle do Projeto (MCP)
Revisão dos processos de Garantia da Qualidade de
Processo e Produto (GQ) e Medição e Análise (MA)
como parte de Planejamento de Projeto (PP) e
Monitoramento e Controle do Projeto (MCP).
1.7 17/10/2014 Correções na formatação e padronização. RSI Informática
1.8 28/10/2014 Adequações solicitadas pelo MCTI. RSI Informática
1.9 08/12/2014 Adequações sinalizadas pelo MCTI. RSI Informática
Inclusão da disciplina Análise e Design separada da
Implementação, conforme solicitado pelo MCTI.
1.11 23/01/2015 Inclusão do artefato Dicionário de Dados. RSI Informática
Ajustes conforme solicitado com referências aos
1.12 28/01/2015 Guias Operacionais, inclusão das LVs como entrada RSI Informática
das atividades e na seção final do documento.
Atualização das unidades considerando a
reestruturação ministerial, adequação do
1.13 28/08/2017 documento a atualização dos diagramas referentes CTIS
ao PS com atualização dos descritivos e imagens,
inclusão do diagrama do desenvolvimento de serviço.
Pág. 3 de 165
Conteúdo
1 Introdução ............................................................................................................................. 6
2 Conceitos Básicos e Definições ............................................................................................. 7
2.1 Demanda ....................................................................................................................... 7
2.2 APF – Análise por Pontos de Função ............................................................................. 7
2.3 Sustentação de Aplicações ............................................................................................ 7
2.4 Unified Modeling Language (UML) ............................................................................... 8
2.5 Sistema em Desenvolvimento ....................................................................................... 8
2.6 Sistema em Homologação ............................................................................................. 8
2.7 Sistema em Produção.................................................................................................... 8
3 Acrônimos e Abreviaturas ..................................................................................................... 9
4 O Processo de Software do MCTIC ...................................................................................... 10
4.1 Fases do ciclo de vida .................................................................................................. 10
4.1.1 Fase de Concepção ............................................................................................. 11
4.1.2 Fase de Elaboração ............................................................................................. 12
4.1.3 Fase de Construção ............................................................................................. 13
4.1.4 Fase de Transição................................................................................................ 13
4.2 Disciplinas .................................................................................................................... 14
4.2.1 Gestão de Projetos ............................................................................................. 15
4.2.2 Modelagem de Negócios .................................................................................... 16
4.2.3 Requisitos............................................................................................................ 17
4.2.4 Gestão de Configuração ..................................................................................... 17
4.2.5 Análise e Design .................................................................................................. 18
4.2.6 Implementação ................................................................................................... 18
4.2.7 Testes .................................................................................................................. 19
4.2.8 Controle de Qualidade ....................................................................................... 19
4.2.9 Implantação ........................................................................................................ 20
4.2.10 Ambiente ............................................................................................................ 20
4.2.11 Ambiente ............................................................................................................ 20
4.3 Grupos de Processo ..................................................................................................... 21
4.3.1 Planejamento de Projeto (PP) ............................................................................ 21
4.3.2 Engenharia de Requisitos (ER) ........................................................................... 38
Pág. 4 de 165
4.3.3 Revisão Técnica (RT) ........................................................................................... 54

4.3.4 Solução Técnica (ST) ........................................................................................... 59
4.3.5 Integração do Produto (IP) ................................................................................. 74
4.3.6 Teste (TS)............................................................................................................. 84
4.3.7 Gestão de Configuração (GC) ............................................................................. 92
4.3.8 Monitoramento e Controle do Projeto (MCP) ................................................... 98
4.3.9 Garantia da Qualidade de Processo e Produto (GQ) ....................................... 115
4.3.10 Controlar Mudanças ......................................................................................... 119
4.3.11 Desenvolvimento de Serviço ............................................................................ 124
4.3.12 Analisar Serviço (AS) ......................................................................................... 126
4.3.13 Projetar Serviço (PS) ......................................................................................... 132
4.3.14 Realizar Governança de Serviço (GS) ............................................................... 139
4.4 Método de Estimativa do Software .......................................................................... 144
4.5 Papéis e Responsabilidades ...................................................................................... 146
4.6 Artefatos de Saída ..................................................................................................... 150
4.7 Listas de Verificação (LVs) ......................................................................................... 161
4.8 Premissas no Atendimento de Demandas de Software ............................................ 161
5 Referências ........................................................................................................................ 163
6 Apêndice............................................................................................................................ 164
Pág. 5 de 165
1 Introdução
Atualmente, um dos maiores desafios da Área de Tecnologia da Informação (TI) de uma
organização governamental é oferecer suporte às áreas finalísticas no alcance de sua missão,
metas e indicadores e atendimento às exigências legais. A chave para vencer este desafio está
na geração de Sistemas de Informação (SI), a partir de modelos do negócio que, bem analisados
e adequadamente especificados, originam produtos que usem como matéria prima a realidade
do negócio e seus objetivos estratégicos.
Nesse sentido, o Processo de Software do MCTIC (PS-MCTIC) aqui definido tem o objetivo de
suportar, em um nível satisfatório de maturidade, o desenvolvimento de projetos de software
através da descrição de um conjunto de diretrizes, processos, critérios, artefatos, regras e
padrões, imprescindíveis para a execução de projetos com qualidade, produtividade e
segurança. Este processo encontra-se em evolução constante visando incorporar as lições
aprendidas.
A Coordenação de Desenvolvimento de Sistemas (CODS) está subordinada à Coordenação-Geral
de Sistemas (CGSI), sendo responsável pelo recebimento das demandas de projetos de software
do Ministério da Ciência, Tecnologia, Inovações e Comunicações (MCTIC). As atividades de
planejamento, gestão e fiscalização das demandas executadas por empresas terceirizadas são
realizadas pelos gerentes de projetos, gestores de contrato e fiscais técnicos dessa coordenação,
alocados para acompanhar cada projeto.
As versões anteriores do PS-MCTIC, no momento e contexto em que foram concebidas, estavam
voltadas para os processos de gestão e fiscalização contratuais, conforme descrito na IN 04/2010
do Ministério do Planejamento, Desenvolvimento e Gestão (MP). No entanto, os processos que
foram definidos no PS-MCTIC destas versões anteriores não estavam aderentes aos modelos e
às normas de melhoria de processo de software internacionalmente aceitos pela indústria e
comunidade acadêmica, pois não foram concebidos para este propósito.
Neste contexto, visando alcançar maiores índices de sucesso nos projetos de software do MCTIC
e também elevar o nível de maturidade da CGSI em relação aos projetos de software, fez-se
necessária a definição de um processo de software que esteja em conformidade com os modelos
e normas de desenvolvimento de software visando obtenção da melhoria contínua e obtenção
de melhores resultados. Desta forma, com base nos fatos supracitados, foi elaborada uma nova
versão do Processo de Software do MCTIC (PS-MCTIC - versão 4) visando elevar de forma
gradativa o nível de maturidade no desenvolvimento de software, com base nos padrões e
normas mundialmente aceitos como guias na produção de software.
Pág. 6 de 165
2 Conceitos Básicos e Definições

Esta seção visa esclarecer os conceitos básicos e apresentar as definições que estão relacionadas
com o PS-MCTIC.
2.1 Demanda
Entende-se por demanda (“chamado” ou “ticket”) como sendo o registro, na Ferramenta de

Gestão de Demandas, de solicitação efetuada por um requisitante, tendo como fundamentação
uma necessidade de negócio.
As demandas são divididas da seguinte forma: demanda de manutenção e de projeto.
 Demanda “Manutenção”: São solicitações em sistemas existentes no ambiente
produtivo de tecnologia. As manutenções podem ser: Corretivas, Evolutivas e
Adaptativas. As Demandas Corretivas são solicitações de correções em sistemas já
existentes. Os motivos destas correções podem ser desde a inadequação da aplicação
às regras de negócio até problemas que passaram a ocorrer em aplicações
anteriormente estáveis. As Demandas Evolutivas são solicitações de melhoria e
evoluções em sistemas já implantados em produção. Demandas evolutivas podem ser
abertas no caso de uma nova regra de negócio que altere a lógica inicial ser definida em
momento de homologação, de maneira que configure alteração do escopo. As
Demandas Adaptativas são adequação do sistema às mudanças de ambiente
operacional e infraestrutura, compreendendo hardware e software básico, mudanças
de versão, linguagem, SGBD e ajustes de performance, que não impliquem em inserção,
alteração ou exclusão de funcionalidades e/ou regras de negócio.
 Demanda “Projeto”: São solicitações de desenvolvimento de um novo sistema com
novas funcionalidades que ainda inexistam no ambiente produtivo de tecnologia.
2.2 APF – Análise por Pontos de Função
A análise de Pontos de Função (IFPUG, 1994), é uma técnica de medição das funcionalidades
fornecidas por um software do ponto de vista de seu usuário. Ponto de Função é a unidade de
medida desta técnica que tem por objetivo tornar a medição independente da tecnologia
utilizada para a construção do software, ou seja, a APF busca medir o que o software faz e não
como foi construído.
2.3 Sustentação de Aplicações
São as atividades de suporte necessárias para a manutenção do funcionamento correto da

aplicação em produção.
Pág. 7 de 165
2.4 Unified Modeling Language (UML)
Traduzida como Linguagem de Modelagem Unificada, destina-se à especificação,

documentação, visualização e desenvolvimento de sistemas orientados a objetos. Sintetiza os
principais métodos existentes, sendo considerada uma das linguagens mais expressivas para a
modelagem de sistemas orientados a objetos. Por meio de seus diagramas é possível
representar sistemas de softwares sob diversas perspectivas de visualização. Facilita a
comunicação de todas as pessoas envolvidas no processo de desenvolvimento de um sistema –
gerentes, coordenadores, analistas, designers e desenvolvedores – por apresentar um
vocabulário de fácil entendimento.
2.5 Sistema em Desenvolvimento
Qualquer sistema que esteja com alguma atividade do processo de implementação em execução
e que ainda não tenha sido colocado em ambiente de produção.
2.6 Sistema em Homologação
Qualquer sistema que esteja com alguma atividade do processo de implementação em execução
e que foi disponibilizado em um ambiente específico (ambiente de homologação) para sua
validação pelo usuário que o solicitou.
2.7 Sistema em Produção
Qualquer sistema que já tenha sido entregue e disponibilizado para sua total e irrestrita
utilização conforme solicitado pelo usuário.
Pág. 8 de 165
3 Acrônimos e Abreviaturas
APF – Análise por Pontos de Função
CGSI – Coordenação-Geral de Sistemas
DS – Desenvolvimento de Serviço
EPTI – Escritório de Projetos de Tecnologia da Informação
ER – Engenharia de Requisitos
GC – Gestão de Configuração
GQ – Garantia da Qualidade de Processo e Produto
IP – Integração do Produto
MCP – Monitoramento e Controle do Projeto
MCTIC – Ministério da Ciência, Tecnologia, Inovações e Comunicação
MP – Ministério do Planejamento, Desenvolvimento e Gestão
PGP-MCTIC – Processo de Gestão de Projetos do MCTIC
PMBoK – Project Management Body of Knowledge – Conjunto de Conhecimentos em
Gerenciamento de Projetos
PMI – Project Management Institute
PMO – Project Management Office
PP – Planejamento de Projeto
PS-MCTIC – Processo de Software do MCTIC
RT – Revisão Técnica
ST – Solução Técnica
TI – Tecnologia da Informação
TS – Teste
Pág. 9 de 165
4 O Processo de Software do MCTIC

O PS-MCTIC foi concebido a partir das melhores práticas de mercado, brainstormings internos e
fontes como o guia Project Management Body of Knowledge (PMBOK) (PMBOK, 2013), o
Rational Unified Process (RUP) (RUP, 2006), Capability Maturity Model Integration (CMMI)
(CMMi, 2010) e o Test Maturity Model Integration (TMMI) (TMMi, 2012).
O ciclo de vida do PS-MCTIC é baseado no desenvolvimento iterativo incremental, possibilitando
que o modelo seja utilizado em projetos de software de tamanhos variados, suportando projetos
onde não seja possível definir o problema e construir o software em um único passo. Dentre as
vantagens desta estratégia que foi adotada pode-se destacar: a integração é feita passo a passo
durante o processo de desenvolvimento, limitando-se cada passo a poucos elementos; a
integração é menos complexa, reduzindo seu custo e aumentado sua eficiência; partes
separadas de projeto e/ou implementação podem ser facilmente identificadas para posterior
reuso; mudanças de requisitos são registradas e podem ser acomodadas; os riscos são
abordados no início do desenvolvimento e cada iteração permite a verificação de riscos já
percebidos bem como a identificação de novos; a arquitetura de software é melhorada através
de um escrutino repetitivo. Idealmente, ao término de cada iteração haverá uma entrega com
valor real para o requisitante.
4.1 Fases do ciclo de vida
Do ponto de vista do gerenciamento, o ciclo de vida de software do PS-MCTIC é dividido em

quatro fases sequenciais, cada uma concluída por um marco principal, ou seja, cada fase é
basicamente um intervalo de tempo entre dois marcos principais. Ao final de cada fase, uma
avaliação é executada para determinar se os objetivos da fase foram alcançados. Uma avaliação
satisfatória permite que o projeto passe para a próxima fase.
Nesta direção, chegou-se a um processo composto por 4 (quatro) fases:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
A visão geral do ciclo de vida que representa o PS-MCTIC está ilustrado na Figura 1 a seguir:
Figura 1. Visão geral do ciclo de vida de desenvolvimento de software
Pág. 10 de 165
As fases descritas na Figura 1 são compostas de iterações. As iterações são janelas de tempo
que possuem prazo definido enquanto as fases são objetivas. Todas as fases geram artefatos
que serão utilizados nas próximas fases e documentam o projeto, além de permitir melhor
acompanhamento. A Figura 2 ilustra estas fases indicando a ênfase que é dada no projeto em
um dado instante em relação às disciplinas, grupos de processo e categorias.
Figura 2. Relacionamento entre as fases, disciplinas, grupos de processo e suas respectivas categorias
4.1.1 Fase de Concepção
A fase de Concepção visa atingir o consenso entre todos os investidores sobre os objetivos do
ciclo de vida do projeto. A fase de concepção tem muita importância principalmente para os
esforços dos novos desenvolvimentos, nos quais há muitos riscos de negócio e de requisitos,
que devem ser tratados visando potencializar o sucesso do projeto. Para projetos que visam
Pág. 11 de 165
melhorias em um sistema existente, a fase de concepção é mais rápida, mas ainda se concentra
em assegurar que o projeto seja compensatório e que seja possível fazê-lo. Os objetivos
principais da fase Concepção incluem:
 Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão
operacional, critérios de aceitação e o que deve ou não estar no produto;
 Discriminar os casos de uso críticos do sistema, os principais cenários de operação que
direcionarão as principais trocas de design;
 Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários
básicos;
 Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas
para a fase de elaboração);
 Calcular os riscos em potencial (as fontes de imprevistos);
 Preparar o ambiente de suporte para o projeto.
4.1.2 Fase de Elaboração
A fase de elaboração visa criar a baseline para a arquitetura do sistema a fim de fornecer uma
base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de uma
análise dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do
sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou
mais protótipos de arquitetura.
Os objetivos principais da fase Elaboração incluem:
 Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que
os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo
e a programação para a conclusão do desenvolvimento. Para a maioria dos projetos,
ultrapassar essa marca também corresponde à transição de uma operação rápida e de
baixo risco para uma operação de alto custo e alto risco com uma inércia organizacional
frequente;
 Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.
 Estabelecer uma arquitetura de baseline derivada do tratamento dos cenários
significativos do ponto de vista da arquitetura, que normalmente expõem os maiores
riscos técnicos do projeto;
 Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim
como um ou mais protótipos de pesquisa, descartáveis, para diminuir riscos específicos
como:
o Trocas de design/requisitos
o Reutilização de componentes
o Possibilidade de produção do produto ou demonstrações para investidores,
clientes e usuários finais
 Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo
justo e em tempo justo.
Pág. 12 de 165
 Estabelecer um ambiente de suporte.

Para atingir esses objetivos básicos, é também importante configurar o ambiente de suporte
para o projeto. Isso inclui adaptar o processo para o projeto, preparar gabaritos, diretrizes e
configurar ferramentas.
4.1.3 Fase de Construção
Na fase de Construção o objetivo é esclarecer os requisitos restantes e concluir o

desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de
certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e
controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a
mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade
intelectual durante a concepção e elaboração, para o desenvolvimento dos produtos que podem
ser implantados durante a construção e transição.
Os objetivos principais da fase Construção incluem:
 Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento
e retrabalho desnecessários;
 Atingir a qualidade adequada com rapidez e eficiência;
 Atingir as versões úteis (alfa, beta e outros releases de teste) com rapidez e eficiência.
 Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades
necessárias;
 Desenvolver de modo iterativo e incremental um produto completo que esteja pronto
para a transição para a sua comunidade de usuários. Isso implica na descrição dos casos
de uso restantes e de outros Requisitos, atualizando o design, concluindo a
Implementação e testando o software;
 Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja
implantado;
 Atingir um grau de paralelismo no trabalho das equipes de desenvolvimento. Mesmo
em projetos menores, normalmente há componentes que podem ser desenvolvidos um
independente do outro, permitindo o paralelismo natural entre as equipes (se os
recursos permitirem). O paralelismo pode acelerar bastante as atividades de
desenvolvimento; mas também aumenta a complexidade do gerenciamento de
recursos e da sincronização dos fluxos de trabalho. Uma arquitetura sofisticada será
essencial para atingir um paralelismo significativo.
4.1.4 Fase de Transição
O foco da Fase de transição é assegurar que o software esteja disponível a seus usuários. A Fase
de Transição pode atravessar várias iterações e inclui testar o produto em preparação para
Pág. 13 de 165
release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida,
o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os
problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido
trabalhados muito antes no ciclo de vida do projeto.
No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto
deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode
coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou
versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação
total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e
melhorias no sistema liberado.
Essa Fase de Transição pode ser muito fácil ou muito complexa, dependendo do tipo de produto.
As atividades realizadas durante uma iteração na Fase de Transição dependem da meta. Por
exemplo, ao corrigir erros, normalmente bastam a implementação e o teste. Se, entretanto,
novos recursos forem incluídos, a iteração será semelhante àquela na fase da construção
requerendo análise, design, etc.
A Fase de Transição entra quando uma baseline estiver desenvolvida o suficiente para ser
implantada no domínio do usuário final. Isso normalmente requer que um subconjunto utilizável
do sistema tenha sido concluído com nível de qualidade aceitável, e documentação do usuário,
de forma que a transição para o usuário forneça resultados positivos para todas as partes.
Os objetivos primários da Fase de Transição incluem:
 Teste beta para validar o novo sistema em confronto com as expectativas do usuário;
 Teste beta e operação paralela relativa a um sistema legado que está sendo substituído;
 Conversão de bancos de dados operacionais;
 Treinamento de usuários e equipe de manutenção;
 Atividades de ajuste, como correção de erros, melhoria no desempenho e na
usabilidade;
 Avaliação das baselines de implementação tendo como base a visão completa e os
critérios de aceitação para o produto;
 Obtenção de auto-suportabilidade do usuário;
 Obtenção do consentimento dos envolvidos de que as baselines de implementação
estão completas;
 Obtenção do consentimento dos envolvidos de que as baselines de implementação são
consistentes com os critérios de avaliação da visão.
4.2 Disciplinas
O PS-MCTIC está organizado através de disciplinas da engenharia de software que agrupam

diversos grupos de processo, conforme descrito na Tabela 1.
Pág. 14 de 165
Disciplina Grupos de Processo
Gestão de Projetos Planejamento de Projeto (PP)

Monitoramento e Controle do Projeto (MCP)
Modelagem de Negócios Especificação de Negócio (EN)
Requisitos Engenharia de Requisitos (ER)
Gestão de Configuração Gestão de Configuração (GC)

Solução Técnica (ST)
Análise e Design
Integração do Produto (IP)
Solução Técnica (ST)
Implementação
Revisão Técnica (RT)
Testes
Teste (TS)
Controle da Qualidade Garantia da Qualidade de Processo e Produto (GQ)
Implantação Integração do Produto (IP)

Engenharia de Requisitos (ER)
Gestão de Configuração (GC)
Ambiente Solução Técnica (ST)
Teste (TS)
Analisar Serviço (AS)
Desenvolvimento de Serviço Projetar Serviço (PS)
Realizar Governança de Serviço (GS)
Tabela 1. Conjuntos de grupos de processo agrupados por disciplina
Desta forma, os processos de desenvolvimento e manutenção de software do MCTIC seguem

padrões de qualidade e modelos de melhores práticas, com o objetivo de atingir um nível
elevado de maturidade, necessário para atingir o sucesso nos projetos no âmbito do MCTIC.
4.2.1 Gestão de Projetos
A Gestão de Projetos concentra-se principalmente sobre os aspectos importantes de um

processo de desenvolvimento iterativo: Gestão de riscos; Planejamento de projeto iterativo
através do ciclo de vida e para uma iteração particular; e o processo de monitoramento e
controle. As atividades da disciplina de gerência de projeto são baseadas nas melhores práticas
do PMBOK. No entanto, no contexto da administração pública que faz o tratamento diferenciado
para algumas questões devido à legislação aplicável para alguns casos, esta disciplina não
abrange todas as áreas de conhecimento do PMBOK, sendo excluídas/adaptadas algumas
atividades das seguintes áreas: Gestão de Pessoas; Orçamento Geral; Gestão de Contratos.
Pág. 15 de 165
Nesta direção, as atividades da disciplina de gestão de projetos, que no PS-MCTIC engloba os

grupos de processo Planejamento de Projeto (PP) e Monitoramento e Controle do Projeto
(MCP), estão alinhadas com o Processo de Gerenciamento de Projetos do MCTIC (PGP-MCTIC),
conforme a visão geral ilustrada na Figura 3.
As atividades desta disciplina estão organizadas conforme os seguintes grupos de processos:
1. Iniciação: Formalização do início do projeto ou de uma fase do projeto;
2. Planejamento: Detalhamento dos objetivos e seleção das melhores alternativas para
alcançar os objetivos do projeto;
3. Execução: Coordenar pessoas e outros recursos para realizar o plano;
4. Controle: Assegurar que os objetivos do projeto estão sendo atingidos, por meio de
monitoramento.
Figura 3. Grupos de Processos de Gerenciamento de Projetos do PGP-MCTIC
4.2.2 Modelagem de Negócios
A disciplina de Modelagem de Negócios, que no PS-MCTIC inclui o grupo de processo

Especificação de Negócio (EN) é responsável por fornecer orientação sobre diferentes técnicas
de modelagem que podem ser utilizadas durante um esforço de engenharia de negócio.
As finalidades da modelagem de negócio são:
 Entender os problemas atuais na organização de destino e identificar os potenciais de
aprimoramento.
 Avaliar o impacto da alteração organizacional.
Pág. 16 de 165
 Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma

compreensão comum da organização.
 Derivar os requisitos do sistema de software necessários para suportar a organização de
destino.
 Entender como um sistema de software a ser implementado se ajusta à organização.
4.2.3 Requisitos
A disciplina de Requisitos, que no PS-MCTIC inclui o grupo de processo Engenharia de Requisitos

(ER) é responsável pelo levantamento e documentação dos requisitos e requerimentos de uma
solução de software que servirá, ao mesmo tempo, para subsidiar o desenvolvimento e os testes
da solução e para documentar o produto durante seu ciclo de vida.
Esta disciplina explica como levantar as necessidades das partes interessadas ("stakeholders") e
transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema
a ser construído e fornecem requisitos detalhados para o que deve fazer o sistema. O Analista
de Requisitos recebe a demanda e inicia a tratativa, com envolvimento das áreas de
desenvolvimento, bancos de dados, infraestrutura e testes, além do acompanhamento
constante do Gerente de Projetos.
Além disso, essa disciplina visa mostrar como o sistema vai ser realizado. O objetivo é construir
um sistema que:
 Execute, em um ambiente de execução específico, as tarefas e funções especificadas
nas descrições de casos de uso;
 Cumpra todas as suas necessidades;
 Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais.
Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de
análise. O modelo de design serve como uma abstração do código-fonte, isto é, o projeto atua
como um modelo de "gabarito" de como o código-fonte é estruturado e escrito. O modelo de
projeto consiste em classes de design estruturado em pacotes e subsistemas com interfaces
bem definidas, representando o que irá se tornar componentes da aplicação. Ele também
contém descrições de como os objetos dessas classes colaboram para desempenhar casos de
uso do projeto.
4.2.4 Gestão de Configuração
A disciplina de Gestão da Configuração, que no PS-MCTIC inclui o grupo de processo Gestão de

Configuração (GC), tem o de fornecer subsídios para estabelecer e manter a integridade dos
produtos de trabalho, utilizando identificação de configuração, controle de configuração,
balanço das atividades de configuração e auditorias de configuração. Esta disciplina abrange três
Pág. 17 de 165
gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e

medição.
 Gerenciamento de configuração: A gestão de configuração é responsável pela

estruturação sistemática dos produtos. Artefatos, como documentos e modelos,
precisam estar sob controle de versão e essas alterações devem ser visíveis. Ele também
mantém o controle de dependências entre artefatos para que todos os artigos
relacionados sejam atualizados quando são feitas alterações;
 Auditoria da Configuração: A gestão de configuração é responsável pelas auditorias de
configuração que confirmam se baselines e documentações resultantes estão de acordo
com o padrão ou requisito especificados.
4.2.5 Análise e Design
A disciplina de Análise e Design, que no PS-MCTIC engloba os grupos de processo Solução

Técnica (ST) e Integração do Produto (IP), explica como transformar os requisitos dos produtos
de trabalho em produtos de trabalho especificando o design do software que o projeto
desenvolverá. A finalidade da Análise e Design é:
 Transformar os requisitos em um design do sistema a ser criado;
 Desenvolver uma arquitetura sofisticada para o sistema;
 Adaptar o design para que corresponda ao ambiente de implementação, projetando-o
para fins de desempenho.
4.2.6 Implementação
A disciplina de Implementação, que no PS-MCTIC engloba os grupos de processo Solução Técnica

(ST) e Integração do Produto (IP), explica como desenvolver, organizar, testar a unidade e
integrar os componentes implementados de acordo com as especificações do design. A
finalidade da Implementação é:
 Definir a organização do código em termos de subsistemas de implementação

organizados em camadas;
 Implementar os elementos de design em termos de elementos de implementação
(arquivos de origem, executáveis e outros);
 Testar os componentes desenvolvidos como unidades;
 Integrar os resultados produzidos por implementadores individuais (ou equipes) ao
sistema executável.
A disciplina de Implementação limita o seu escopo a como classes individuais devem ser testadas
em unidade. O teste do sistema e o teste de integração são descritos na disciplina Teste.
Pág. 18 de 165
4.2.7 Testes
O Processo de Desenvolvimento de Software tem uma abordagem iterativa, o que significa que
se deve testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que
reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de quatro
dimensões da qualidade: segurança, usabilidade, confiabilidade, funcionalidade, desempenho
da aplicação, e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o
processo descreve como você passar pelo teste do ciclo de planejamento, modelagem,
implementação, execução e avaliação da qualidade.
Nesta direção, a disciplina de Teste, que no PS-MCTIC engloba os grupos de processo Revisão
Técnica (RT) e Teste (TS), fornece orientação sobre como avaliar a qualidade do produto,
atuando como um fornecedor de serviços para as outras disciplinas de diversas maneiras. Os
testes são direcionados principalmente na avaliação da Qualidade do Produto, que é realizada
através destas práticas principais:
 Localizar e documentar defeitos na qualidade do software;

 Sugestões sobre a qualidade do software;
 Validar e provar as suposições feitas nas especificações de projeto e requisitos através
de demonstração concreta;
 Validar se o software funciona conforme o projeto;
 Validar se os requisitos são implementados adequadamente para verificar a interação
entre objetos;
 Para verificar a integração adequada de todos os componentes do software;
 Identificar e garantir que os defeitos são abordados antes da implantação do software;
 Garantir que todos os defeitos são corrigidos, reanalisados e fechados.
4.2.8 Controle de Qualidade
A disciplina de Controle da Qualidade, que no PS-MCTIC engloba o processo de Garantia da

Qualidade de Processo e Produto (GQ), apoia todas as outras disciplinas, fornecendo práticas
para avaliar objetivamente processos, produtos de trabalho e serviços em relação a descrições
de processos, padrões e procedimentos aplicáveis, e assegurando o tratamento de quaisquer
questões críticas que surjam nessas avaliações. Este processo assegura a entrega de produtos e
serviços de alta qualidade, proporcionando à equipe do projeto e aos gerentes de todos os níveis
a visibilidade apropriada e retorno sobre os processos e produtos de trabalho associados, ao
longo do ciclo de vida do projeto.
Nessa disciplina também está descrito que as análises de qualidade devem identificar,
documentar e fornecer informações sobre não conformidades, aos membros da equipe e seus
superiores, para assegurar que os desvios do padrão de qualidade definido sejam tratados.
As avaliações podem ser feitas usando métodos formais ou não, e podem ser executadas por
um grupo de garantia de qualidade, caso haja na organização. O processo recomenda que as
Pág. 19 de 165
avaliações sejam iniciadas nas fases iniciais dos projetos, para que seja definido a tempo
procedimentos que irão agregar valor ao projeto.
Em resumo, a disciplina de Controle de Qualidade pode ser aplicada às atividades e aos produtos
de trabalho de um projeto, por meio de avaliações que geram relatórios de não conformidades
e podem garantir uma melhor qualidade desde que esses itens sejam tratados. O fluxo de
trabalho desta disciplina está ilustrado.
4.2.9 Implantação
A disciplina de Implantação, que no PS-MCTIC engloba o processo de Integração do Produto (IP),

descreve as atividades associadas a garantir que o produto de software esteja disponível a seus
usuários.
A disciplina Implantação está relacionada a outras disciplinas da seguinte maneira:
 A disciplina Requisitos produz os requisitos funcionais, o modelo de caso de uso e

requisitos não funcionais. Juntamente com as interfaces com o usuário, a especificação
dos requisitos de software é uma das entradas-chave para desenvolver os materiais de
suporte do usuário e os materiais de treinamento.
 O Teste é um parceiro indispensável para a implementação e os elementos essenciais
do teste são o Sumário de Avaliação de Teste e as atividades para implementar, executar
e gerenciar os testes.
 A disciplina Gestão de Configuração é referida por fornecer a construção do baseline e
liberar o produto.
 A disciplina Ambiente fornece o suporte para o ambiente de teste.
4.2.10 Ambiente
A disciplina de Ambiente, que engloba atividades previstas nos processos de Engenharia de

Requisitos (ER), Gestão de Configuração (GC), Solução Técnica (ST), Integração do Produto (IP),
Teste (TS), concentra-se nas atividades necessárias à configuração do processo para um projeto.
Ela descreve as atividades para o desenvolvimento das diretrizes de suporte de um projeto. A
meta das atividades dessa disciplina é oferecer à organização o ambiente de desenvolvimento
de software — processos e ferramentas — que dará suporte à equipe de desenvolvimento.
4.2.11 Ambiente
A disciplina de Desenvolvimento de Serviço, que engloba atividades previstas nos processos

Analisar Serviços (AS) e Projetar Serviço (PS), concentra-se nas atividades necessárias ao
desenvolvimento de peças de negócio reutilizáveis, especificadas separadamente, catalogadas
e disponibilizadas de forma global.
Pág. 20 de 165
4.3 Grupos de Processo
Os processos que fazem parte do PS-MCTIC, que juntos formam um grupo de processos, são um
conjunto de atividades ou tarefas estruturadas relacionadas que produzem um serviço ou
produto específico, ou seja, no caso do PS-MCTIC visam produzir software para um
determinando cliente (requisitante) do MCTIC. Nesta direção, chegou-se a um conjunto de 9
processos que estão descritos em detalhes nas subseções seguintes, com o respectivo fluxo de
trabalho e quadros de estruturação das atividades.
4.3.1 Planejamento de Projeto (PP)
O objetivo do processo Planejamento de Projeto (PP) é fornecer subsídios para estabelecer e

manter planos do projeto visando definir as atividades de projeto. Inclui a elaboração do plano
de projeto, o envolvimento apropriado das partes interessadas, identificação e análise dos
riscos, planejamento das medições e análise dos dados coletados, a obtenção de
comprometimento com o plano e sua manutenção. O fluxo de trabalho deste processo está
ilustrado na Figura 4.
Pág. 21 de 165
Figura 4. Fluxo do processo Planejamento do Projeto (PP)
Pág. 22 de 165
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Planejamento de Projeto (PP)

podem ser verificadas em ITQ_PS_PlanejamentoProjeto. O detalhamento das atividades
definidas para este processo está descrito nos quadros a seguir.
Atividade: Iniciar Projeto
Objetivo
Autorizar formalmente a existência do projeto e dar ao gerente do projeto a autoridade necessária para
aplicar recursos organizacionais às atividades do projeto.
Papel
 Gerente de Projetos
 Patrocinador do Projeto
Descrição
O Gerente do Projeto deve descrever o Termo de Abertura do Projeto (TAP), formalizando a existência
do projeto. Este documento deverá conter a justificativa do projeto, a descrição em alto nível do escopo
do projeto, estimativas iniciais, premissas e restrições e, também, a designação formal do Gerente do
Projeto, com suas responsabilidades e níveis de autoridade.
Após escrito, o Termo de Abertura de Projeto deve ser aprovado pelas partes interessadas cabíveis,
principalmente pelo Patrocinador do Projeto. É importante também divulgar o início do projeto em sua
área de abrangência.
Produtos de Entrada
 Avaliação Técnica
 Declaração de trabalho ou documento similar
 Planilha de Lições Aprendidas
Critérios de Entrada
 Avaliação Técnica aprovada

Produtos de Saída
 Termo de Abertura do Projeto (TAP)

Critérios de Saída
 Formalização da designação do gerente do projeto

 Termo de Abertura do Projeto (TAP) aprovado
Atividade: Identificar as Partes Interessadas
Objetivo
Pág. 23 de 165
Identificar e documentar todas as pessoas ou organizações que tenham interesse ou podem ser afetadas
pelo projeto. Devem ser registradas as informações relevantes sobre os seus interesses, envolvimento
e impacto no sucesso do projeto.
Papel
Descrição
Identificar pessoas, grupos ou organizações que podem ter impacto ou serem impactados por uma
decisão, atividade ou resultado do projeto.
É necessário analisar e documentar informações relevantes relativas aos seus interesses, nível de
engajamento, interdependências, influência e seu impacto potencial no sucesso do projeto. Essas
informações precisam ser documentadas em um Registro das Partes Interessadas, que irá compor o
Plano de Projeto durante a etapa de planejamento do projeto.
Após identificadas, as partes interessadas precisam ser classificadas em relação ao seu nível de poder
sobre o projeto e também em relação ao seu grau de comprometimento com o projeto. Isto permitirá
ao Gerente do Projeto definir a sua estratégia de atuação sobre as partes.
Esta análise deverá ser feita para cada parte interessada, atribuindo-se uma classificação em relação ao
seu grau de influência no projeto (baixo, médio ou alto), de acordo com sua hierarquia ou
responsabilidade. Em seguida, é necessário definir o grau de interesse pelo projeto (baixo, médio ou
alto), de acordo com as reuniões ocorridas e informações da equipe. Ao representar estas informações
numa Matriz de Interesse e Poder, estabelece-se a estratégia para abordagem.
Para maiores informações sobre a elaboração da Matriz de Interesse e Poder, consulte o Guia
Operacional PS-MCTIC_GO_MatrizInteressePoder.
Produtos de Entrada
 Organograma
 Termo de Abertura do Projeto aprovado

Produtos de Saída
 Registro das Partes Interessadas (como parte do Plano de Projeto)

 Matriz de Interesse e Poder (como Parte do Plano de Projeto)
 Partes interessadas identificadas
Atividade: Definir Escopo
Pág. 24 de 165
Objetivo
Desenvolver a descrição detalhada do projeto e do produto, definindo os seus limites e identificando

quais requisitos serão incluídos e quais serão excluídos do escopo do projeto.
Papel
Descrição
Determinar e documentar as necessidades, requisitos e objetivos das partes interessadas, de forma a

definir os limites do projeto.
O escopo inicial do projeto deve ser detalhado, analisado e registrado de forma clara e objetiva e será
documentado como parte do Plano de Projeto, descrevendo as principais entregas, os critérios de
aceitação, as premissas e as restrições do projeto. Também podem ser descritas as exclusões do escopo
do projeto a fim de auxiliar o gerenciamento das expectativas das partes interessadas.
O escopo do projeto precisa ser aprovado junto às partes interessadas antes de prosseguir com as
demais atividades do projeto. Caso não seja aprovado, esta atividade deve ser executada novamente,
visando sua reformulação.
O escopo do projeto deve seguir as diretrizes do Guia Operacional PS-

MCTIC_GO_EspecificacaoEscopoProjeto.
Produtos de Entrada
 Termo de Abertura de Projeto (TAP)
 Registro das Partes Interessadas
 Ativos de Processos Organizacionais
 Fatores Ambientais da Empresa
 Termo de Abertura do Projeto aprovado

Produtos de Saída
 Especificação do Escopo (como parte do Plano de Projeto)

 Escopo aprovado
Atividade: Desenvolver EAP
Objetivo
Pág. 25 de 165
Fornecer uma visão estruturada das entregas e dos pacotes de trabalho decompostos em componentes
gerenciáveis, dentro de uma Estrutura Analítica do Projeto (EAP). É uma etapa fundamental para a
definição das atividades e desenvolvimento do cronograma.
Papel
Descrição
A Estrutura Analítica do Projeto (EAP) é o artefato que decompõe os itens do escopo em componentes
menores, de forma a fornecer uma visão estruturada das entregas do projeto.
Desenvolver a EAP, organizando e definindo o escopo total do projeto e representando o trabalho

descrito na Especificação de Escopo do Plano de Projeto.
As fases do ciclo de vida do projeto podem ser utilizadas como um nível macro de decomposição, com
os produtos, serviços ou entregas inseridos um nível abaixo. Para cada entrega, devem ser definidos os
pacotes de trabalho que darão origem às atividades do projeto.
Para detalhes sobre a elaboração da EAP, consulte o Guia Operacional PS-

MCTIC_GO_EstruturaAnaliticaProjeto.
Produtos de Entrada
 Especificação do Escopo
 Escopo aprovado
Produtos de Saída
 Representação Gráfica da EAP

 EAP decomposta hierarquicamente
Atividade: Identificar Adaptações dos Processos
Objetivo
Indicar quais processos serão utilizados para desenvolver o projeto, visando assegurar uma operação
eficiente de acordo com as características do projeto.
Papel
Pág. 26 de 165
Descrição
Identificar as adaptações necessárias aos processos que serão utilizados no desenvolvimento do projeto
durante todo o ciclo de vida, visando assegurar uma operação eficiente de acordo com as características
do projeto.
Produtos de Entrada
 Estrutura Analítica do Projeto (EAP)
 Critérios para adaptação do processo
 EAP decomposta hierarquicamente

Produtos de Saída
 Caso de Desenvolvimento
 Características e adaptações do processo para o projeto identificadas no Caso de Desenvolvimento
Atividade: Realizar a Contagem de PF Estimada
Objetivo
Realizar a estimativa de pontos de função do projeto.
Papel
 Analista de Métrica
Descrição
Realizar e documentar a contagem estimada do projeto, conforme documentação existente do projeto.
Produtos de Entrada

 Lista de Atividades
 Estrutura Analítica do Projeto
Pág. 27 de 165

 Escopo aprovado
Produtos de Saída
 Contagem Estimada
 Resultado da estimativa em pontos de função documentado
Atividade: Planejar Riscos
Objetivo
Planejar a estratégia de gerenciamento dos riscos do projeto, bem como realizar a identificação dos
riscos, a análise qualitativa e o planejamento de respostas dos riscos do projeto.
Papel
Descrição
Definir os métodos de gerenciamento dos riscos, os critérios de análise, a identificação dos riscos, a
análise qualitativa e o planejamento de respostas aos riscos, documentando-os no Plano de
Gerenciamento de Riscos.
Determinar os riscos que podem afetar o projeto, documentando suas características, com o objetivo
de monitorá-los e tomar as devidas ações para que eles não ocorram, ou se ocorrerem, que as medidas
necessárias para a redução do seu impacto sejam tomadas. Os riscos devem ser documentados em uma
Planilha de Riscos.
Produtos de Entrada

 Matriz de Interesse e Poder
 Lista de Riscos Organizacionais
 Estrutura Analítica do Projeto
 Custos identificados
Pág. 28 de 165
 Documentos de Aquisições
 Escopo aprovado
Produtos de Saída
 Plano de Gerenciamento de Riscos

 Planilha de Riscos
 Riscos documentados com os respectivos planos de respostas
Atividade: Estimar Atividades
Objetivo
Identificar, sequenciar e estimar os recursos e a duração das atividades que deverão ser executadas para
atender cada pacote trabalho definido na EAP.
Papel
Descrição
Para cada produto de entrega definido na EAP do projeto, será necessário identificar as ações específicas
que a equipe deverá executar para produzir as entregas do projeto. A lista completa destas ações
formará a Lista de Atividades do projeto. Cada atividade deve ter um título exclusivo de forma que a
equipe consiga entender o trabalho a ser realizado, mesmo fora de contexto.
Na lista de atividades, deverão ser identificados também os marcos do projeto, que são pontos ou
eventos significativos no projeto, como uma entrega ou a aprovação de um artefato.
Para cada atividade, deve-se planejar os recursos que serão necessários para sua execução e estimar
individualmente a duração das atividades.
Produtos de Entrada
 Escopo aprovado
Pág. 29 de 165
 EAP elaborada
Produtos de Saída
 Lista de Atividades (como parte do Cronograma do Projeto)

 Lista de Atividades sequenciada
Atividade: Definir Equipe
Objetivo
Identificar os membros da equipe, seus papéis, responsabilidades e disponibilidade para alocação ao

projeto.
Papel
Descrição
Identificar e documentar todos os recursos humanos que irão executar as atividades do projeto. Devem
ser descritos os nomes, cargos, responsabilidades e período de disponibilidade no projeto.
Deve-se avaliar os produtos do projeto que precisam ser elaborados para identificar corretamente os
perfis.
A lista de atividades do projeto poderá ser atualizada com os recursos disponibilizados na equipe. As
informações básicas da equipe, como identificação e disponibilidade irão compor a Lista da Equipe do
Projeto do Plano de Projeto.
Produtos de Entrada

 Não se aplica.
Produtos de Saída
 Lista de Atividades atualizada (como parte do Cronograma do projeto)

 Lista da Equipe do Projeto (como parte do Plano de Projeto)
 Equipe do projeto definida
Pág. 30 de 165
Atividade: Desenvolver Cronograma
Objetivo
Analisar as sequências, durações e recursos das atividades, confrontando com as restrições existentes,
a fim de elaborar o cronograma do projeto. Através dele serão definidas as datas planejadas de início e
término das atividades.
Papel
Descrição
Definir cronograma preliminar que contém a data planejada de início e término das atividades, de
acordo com as características do projeto e com a lista de atividades do projeto, com os recursos e
durações estimados. É necessário analisar se as datas previstas dos marcos e do término do projeto
atingem as restrições de prazo definidas pelas partes interessadas.
Este cronograma deverá ser aprovado junto às partes interessadas, juntamente com o planejamento do
projeto. Após aprovado, deverá ser gerada uma linha de base do cronograma para o efetivo
acompanhamento.
Para mais detalhes sobre a elaboração do cronograma, consulte o Guia Operacional PS-
MCTIC_GO_CronogramaProjeto.
Produtos de Entrada
 Especificação do Escopo (Premissas e Restrições)
 Lista de Atividades consolidada

Produtos de Saída
 Cronograma do Projeto
 Cronograma do projeto otimizado
Pág. 31 de 165
Atividade: Planejar Custos
Objetivo
Estimar os custos dos itens que compõem a solução a ser fornecida pelo projeto (contratos com
terceiros, equipamentos, serviços, etc.), bem como identificar as fontes de recursos necessárias ao
projeto.
Papel
Descrição
Planejar os custos do projeto, avaliando a composição dos custos do projeto que é a união dos custos
individuais de cada parte da solução a ser desenvolvida. Estes custos podem ser contratos de aquisição
de produtos e materiais, contratos de serviço ou custos de manutenção de um produto ou serviço.
Deve-se avaliar a EAP do projeto a fim de identificar as responsabilidades de fornecimento de cada item
e estimar o seu custo.
Identificar as fontes de recursos atreladas aos componentes que serão adquiridos/construídos. Estas
informações irão compor os custos do projeto, que deverá ser registrado no Plano de Projeto.
Produtos de Entrada

 Escopo aprovado
Produtos de Saída
 Custos Identificados (como parte do Plano de Projeto)

Atividade: Planejar Comunicação
Objetivo
Estabelecer como as informações sobre o projeto chegarão às partes interessadas de forma clara e no
tempo adequado. Envolve planejar como será realizada a geração, coleta, armazenamento,
recuperação, distribuição e organização das informações referentes ao projeto e seus resultados.
Pág. 32 de 165
Papel
Descrição
Descrever todo o processo de coleta e comunicação das informações do projeto e os meios que serão
utilizados para a comunicação do projeto. Deve-se:
 Identificar as necessidades de informação de cada parte interessada (tanto externa, quanto da

equipe do projeto) e documentar os meios que serão utilizados. Dependendo da criticidade e
natureza da informação, deve-se decidir por comunicações formais ou informais, que podem ser
repassadas por reuniões, e-mail, relatórios, ofícios, etc. Também deve ser analisada a periodicidade
que estas informações precisam ser distribuídas. Estas informações estarão registradas em uma
Tabela de Eventos de Comunicação, no Plano de Projeto.
 Identificar para cada evento importante do projeto, quais as partes interessadas que são
responsáveis pela execução ou aprovação, e quais devem ser consultadas ou informadas. Estas
informações devem ser registradas em uma Matriz RACI, no Plano de Projeto.
Produtos de Entrada

 Partes interessadas registradas

 Equipe do projeto definida
Produtos de Saída
 Matriz de Responsabilidade (RACI) (como parte do Plano de Projeto)

 Tabela de Eventos de Comunicação (como parte do Plano de Projeto)
 Tabela de eventos de comunicação definida e matriz de responsabilidade montada
Atividade: Planejar Qualidade
Objetivo
Determinar as políticas de qualidade da organização que irão afetar o projeto, de forma a garantir que
os requisitos do projeto e do produto sejam cumpridos e validados, atendendo às expectativas das
partes interessadas.
Papel
Pág. 33 de 165
Descrição
Identificar dentro dos ativos organizacionais, quais os padrões de qualidade a que o projeto e o produto
estarão submetidos. Estes padrões estarão descritos no Manual da Qualidade e em outros documentos
organizacionais.
Os padrões aplicáveis ao projeto podem ser processos de gestão, processos de desenvolvimento e

normas de qualidade da área fim do projeto. A relação destes padrões deverá compor o Plano de
Gerenciamento da Qualidade.
Adicionalmente, podem ser identificadas atividades específicas de garantia da qualidade do projeto e

do produto que precisam compor a Lista de Atividades do projeto.
Produtos de Entrada
 Manual da Qualidade
 Padrões de qualidade organizacionais previamente definidos

Produtos de Saída
 Plano de Gerenciamento da Qualidade

 Lista de Atividades atualizada – Opcional
 Plano de Gerenciamento da Qualidade elaborado
Atividade: Planejar Medições do Projeto
Objetivo
Definir os indicadores que serão analisados durante a execução do projeto e identificar as necessidades
de outras medições específicas para o projeto.
Papel
Descrição
Definir os objetivos de medição, as medidas, procedimentos de coleta e armazenamento dos dados,

além dos procedimentos de análise dos indicadores do projeto e identificar as necessidades de outras
medições específicas para o projeto, documentando-os no Plano de Medições do projeto.
Pág. 34 de 165
Os objetivos da medição devem ser derivados de necessidades de informação e objetivos identificados

para o projeto e para a organização.
Medidas de projeto geralmente podem ser rastreadas a uma ou mais categorias de informação de
medição. Estas categorias incluem o seguinte: cronograma e progresso, esforço e custo, tamanho e
estabilidade, qualidade.
Definir e documentar como os dados resultantes de medição serão obtidos e armazenados, bem como,
auxiliar a esclarecer as necessidades de informação e os objetivos de medição.
Assegurar que as análises sejam executadas e comunicadas de forma adequada de modo a satisfazer
aos objetivos documentados das medições e, portanto, para satisfazer às necessidades de informação e
aos objetivos de medição definidos.
Os padrões de medição do MCTIC estarão descritos no Manual de Medição e em outros documentos

organizacionais.
Adicionalmente, podem ser identificadas atividades específicas de medição do projeto que precisam
compor a Lista de Atividades do projeto.
Produtos de Entrada
 Manual de Medição
 Padrões organizacionais de medição previamente definidos

Produtos de Saída
 Plano de Medições
 Lista de Atividades atualizada – Opcional
 Plano de Medições elaborado
Atividade: Planejar Aquisições e Contratações (IN04 SLTI/MP)
Objetivo
Identificar as necessidades do projeto que serão atendidas com produtos ou serviços fornecidos por
entidades externas à organização do projeto e realizar o planejamento da contratação. Todas as
Pág. 35 de 165
atividades devem seguir a Instrução Normativa N. 04 do Ministério do Planejamento, Desenvolvimento

e Gestão (MP).
Papel
Descrição
Todas as atividades de contratação de terceiros para os projetos deverão ser executadas em

conformidade com a Instrução Normativa N. 04 do MP. Maiores informações devem ser buscadas no
Manual de Contratação de Serviços de TI e demais documentos da IN04, disponíveis no site do Governo
Eletrônico.
Produtos de Entrada
 Documentos Previstos na IN04

 Necessidade de contratação externa identificada

Produtos de Saída

 Contratações planejadas
Atividade: Consolidar Plano de Projeto
Objetivo
Integrar e consolidar todos os planos auxiliares desenvolvidos no planejamento num único instrumento
que deverá ser aprovado para compor a linha de base do projeto.
Papel
Descrição
Todos os planos e instrumentos elaborados por cada atividade de planejamento devem ser unificados
em um documento central, chamado Plano de Projeto. Ele define a base de todo o trabalho do projeto,
descrevendo como ele será executado, monitorado e controlado e encerrado.
Alguns artefatos produzidos serão parte do Plano de Projeto, enquanto outros devem existir em um
documento separado. Entretanto o conjunto destes artefatos irá compor a linha de base do projeto,
após aprovado.
Produtos de Entrada
Pág. 36 de 165

 Lista da Equipe do Projeto
 Custos Identificados
 Matriz de Responsabilidade (RACI)
 Tabela de Eventos de Comunicação
 Lista de Verificação – Plano de Projeto
 Plano de Gerenciamento de Riscos definido

 Plano de Gerenciamento da Qualidade definido
 Cronograma do Projeto elaborado
 Eventos de Comunicação definidos
 Partes Interessadas identificadas e qualificadas
 Equipe definida e responsabilidades atribuídas
 Caso de Desenvolvimento elaborado
 Plano de Medições definido
Produtos de Saída
 Plano de Projeto (PP)

 Plano de Projeto elaborado
Atividade: Realizar Reunião de Aprovação do Planejamento
Objetivo
Realizar a reunião de apresentação do planejamento do projeto com os principais envolvidos para obter
sua aprovação, registrando todas as informações em ata.
Papel
Pág. 37 de 165
Descrição
Após elaborados, os artefatos e o planejamento do projeto devem ser apresentados às partes

interessadas para avaliação e aprovação.
Os resultados da reunião de apresentação devem ser registrados em uma Ata de Reunião. Caso o
planejamento não seja aprovado, será necessário revisar os planos para atender às expectativas das
partes interessadas.
Caso seja aprovado, deverá ser realizada uma linha de base do planejamento, autorizando sua execução.
Produtos de Entrada

 Artefatos de planejamento elaborados

Produtos de Saída
 Ata de Reunião
 Reunião de apresentação realizada

 Resultado da aprovação do planejamento obtido
4.3.2 Engenharia de Requisitos (ER)
O objetivo do processo Engenharia de Requisitos (ER) é fornecer subsídios para gerenciar os

requisitos e componentes do produto, identificar inconsistências entre esses requisitos e os
planos e produtos de trabalho do projeto, além de produzir e analisar os requisitos de cliente,
de produto e de componente de produto. O processo de ER é responsável por identificar as
necessidades do cliente e traduzir essas necessidades em requisitos de produto. O conjunto de
requisitos de produto é analisado para gerar uma solução conceitual de alto nível. Esse conjunto
de requisitos é então alocado para estabelecer um conjunto inicial de requisitos de produto.
Outros requisitos que ajudam a definir o produto são derivados e alocados aos componentes de
produto. Esse conjunto de requisitos de produto e de componentes de produto descreve
claramente o desempenho do produto, suas características de design e seus requisitos de
verificação, de forma que o desenvolvedor possa entendê-los e utilizá-los. Além disso, fornece
rastreabilidade entre os requisitos, desde o cliente até o produto ou o componente de produto.
O fluxo de trabalho deste processo está ilustrado na
Pág. 38 de 165
Figura 5.
Pág. 39 de 165
Figura 5. Fluxo do processo Engenharia de Requisitos (ER)
Pág. 40 de 165
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Engenharia de Requisitos (ER)

podem ser verificadas em ITQ_PS_EngenhariaRequisitos. O detalhamento das atividades
definidas para este processo foi descrito nos quadros a seguir.
Atividade: Definir Estratégias de Gerenciamento de Requisitos
Objetivo
Definir as estratégias, a organização dos requisitos em todos os níveis e o ambiente de gerenciamento

dos requisitos do projeto.
Papel
 Analista de Requisitos
Descrição
Estabelecer a estratégia de gerenciamento, os tipos de requisitos, os atributos de cada tipo de requisito,

o empacotamento e a nomenclatura dos requisitos e os tipos de documentos. Além de definir o ambiente
necessário para o desenvolvimento e implementação dos requisitos do projeto.
Definir estratégias de gerenciamento dos requisitos envolve principalmente:
 Estratégias de rastreabilidade;
 Estratégias para realizar o levantamento de requisitos;
 Definição de responsáveis e responsabilidades para manutenção da integridade dos requisitos;
 Estratégias para garantir o completo entendimento e comprometimento dos requisitos entre
todos os envolvidos do projeto;
 Estratégias para identificar inconsistências entre artefatos ou produtos e os requisitos.
Definir o ambiente de requisitos composto por:
 Ferramenta de gerenciamento e desenvolvimento dos requisitos;

 A configuração da ferramenta para suportar a estrutura de requisitos definida;
 Customização dos templates para especificação dos requisitos.
Produtos de Entrada
 Especificação do Escopo (como parte do Plano de Projeto)

 Escopo do projeto especificado
Pág. 41 de 165
Produtos de Saída
 Plano de Gerenciamento de Requisitos

 Plano de Gerenciamento de Requisitos atualizado com a estratégia, a organização dos requisitos e o

ambiente de gerenciamento dos requisitos do projeto
Atividade: Identificar Fornecedores de Requisitos
Objetivo
Identificar os fornecedores de requisitos, cujas necessidades devem ser atendidas pelo sistema que está
sendo construído.
Papel
Descrição
Selecionar fornecedores de requisitos a partir dos seguintes critérios:
 Gestores do negócio;
 Usuários finais, que são os fornecedores de requisitos preferenciais;
 Pessoas com alçada para tomada de decisão;
 Pessoas ou áreas que avaliarão e aprovarão os produtos gerados;
 Patrocinador ou cliente do projeto.
Produtos de Entrada

 Estratégias de gerenciamento de requisitos definida

Produtos de Saída
 Lista dos Fornecedores de Requisitos (como parte do Plano de Gerenciamento de Requisitos)

 Plano de Gerenciamento de Requisitos atualizado com as informações dos fornecedores de

requisitos
Pág. 42 de 165
Atividade: Obter Entendimento dos Requisitos
Objetivo
Desenvolver um entendimento com os fornecedores dos requisitos sobre o significado dos mesmos e os
critérios para avaliação e aceitação dos requisitos.
Papel
Descrição
Chegar a um entendimento dos requisitos com o fornecedor dos requisitos, de forma que os
participantes do projeto possam estabelecer compromissos com relação a eles e definir os critérios
objetivos para aceitação de requisitos.
Os critérios para avaliação e aceitação dos requisitos devem ser documentados no Plano de
Gerenciamento de Requisitos.
Após levantamento dos requisitos iniciais, é necessário existir o entendimento da estratégia dos
requisitos junto às partes interessadas antes de prosseguir com as demais atividades do projeto. Caso
não haja esse entendimento, as atividades devem ser executadas novamente, visando chegar a um
entendimento comum da estratégia dos requisitos.
A análise em relação aos critérios de aceitação deve ser registrada em Ata de Reunião.
Produtos de Entrada

 Fornecedores de requisitos identificados

Produtos de Saída
 Critérios de Aceitação dos Requisitos (como parte do Plano de Gerenciamento de Requisitos)

 Ata de Reunião
 Entendimento dos requisitos com os fornecedores dos requisitos

 Critérios objetivos para avaliação e aceitação de requisitos definidos
Atividade: Levantar Necessidades
Pág. 43 de 165
Objetivo
Trabalhar com os provedores de requisitos para obter um melhor entendimento do problema e das suas
necessidades, identificado “o que” é desejado no novo sistema, além do grupo de pessoas que irá utilizar
o sistema ou parte dele.
Papel
 Fornecedores de Requisitos
Descrição
Levantar e entender o domínio do problema e as necessidades dos fornecedores e delimitar o escopo do

sistema.
Mapear claramente as necessidades dos fornecedores dos requisitos, bem como as necessidades de
integração com sistemas ou com outras áreas envolvidas. Além de estabelecer níveis de prioridade e de
benefício esperados para cada necessidade identificada.
Mapear usuários que irão utilizar o sistema ou parte dele e suas responsabilidades no que diz respeito
ao sistema que está sendo desenvolvido; ou seja, seu interesse como envolvido. Pode ser desde um
usuário avançado, com acessos irrestritos até um simples operador. Deve-se descrever o ambiente
operacional dos diversos tipos ou níveis de usuários.
Após levantamento das necessidades, é necessário existir a aprovação junto às partes interessadas antes
de prosseguir com as demais atividades do projeto. Caso não haja esse entendimento, a atividade deve
ser executada novamente, visando chegar a um entendimento comum das necessidades identificadas.
Produtos de Entrada

 Planejamento do projeto aprovado

Produtos de Saída
 Registro das Necessidades (como parte do Documento de Visão)

 Usuários Identificados (como parte do Documento de Visão)
 Necessidades aprovadas pelos fornecedores de requisitos
Atividade: Levantar Requisitos do Cliente
Pág. 44 de 165
Objetivo
Levantar os requisitos do cliente, iniciar o domínio da solução, propor características ou capacidades que
atenda às necessidades dos interessados e identificar as restrições que irão impactar no desenvolvimento
do sistema.
Papel
 Arquiteto de Software
Descrição
Levantar os requisitos do cliente e propor características ou capacidades que o produto ou sistema deve
fornecer para atender as necessidades dos interessados, como por exemplo:
 O sistema deve ser compatível com um determinado Sistema Operacional (SO)

 O sistema deve distinguir perfis de usuários
 O sistema deve reportar o inventário de todos os itens, atualizados na data e hora da emissão.
 O sistema deve controlar acesso de usuários
 O sistema deve ser capaz de armazenar o histórico de operações.
Mapear as restrições que irão impactar diretamente o desenvolvimento, com o apoio do Arquiteto de
Software, a partir dos seguintes critérios:
 Econômicas: licenças de software, custos não cobertos pela métrica

 Tecnologia: novas tecnologias, ambiente físico, plataformas
 Sistemas: sistemas operacionais, compatibilidade com soluções existentes
 Ambiente: requisitos legais e estatutários
 Cronograma: prazos legais, indisponibilidade de recursos
As restrições identificadas poderão ser tratadas como riscos do projeto, nesse caso, será necessária a
atualização da lista de riscos do projeto.
Para maiores informações sobre técnicas de levantamento de requisitos, consulte o Guia Operacional PS-
MCTIC_GO_TecnicasElicitacaoRequisitos.
Produtos de Entrada

 Registro das Necessidades
 Usuários Identificados
Pág. 45 de 165
Produtos de Saída
 Características do Produto (como parte do Documento de Visão)

 Planilha de Riscos – Opcional
 Características do produto registradas
Atividade: Identificar Requisitos do Produto
Objetivo
Identificar as capacidades que o sistema deve fornecer e os requisitos de software do aplicativo,

estabelecendo uma comunicação e entendimento em um alto nível de abstração.
Papel
Descrição
Identificar e registrar os requisitos funcionais, definindo as funções ou ações que o sistema deve fornecer
(Casos de uso; Funções; Regras de negócio; Interfaces Internas; Interfaces Externas).
Identificar e registrar os requisitos não funcionais, descrevendo os atributos do sistema ou do ambiente

do sistema (Usabilidade; Confiabilidade; Desempenho; Suportabilidade; Restrições de projeto; Requisitos
de Implementação; Requisitos de Interface; Requisitos Físicos).
Realizar a priorização dos requisitos identificados juntamente com os fornecedores de requisitos.
Os requisitos funcionais e não funcionais do produto devem ser registrados como parte do Documento
de Visão, juntamente com a sua priorização.
Produtos de Entrada

 Características do Produto
 Requisitos do cliente identificados

Produtos de Saída
Pág. 46 de 165
 Lista de Requisitos do Produto e Priorização (como parte do Documento de Visão)

 Requisitos do produto identificados
Atividade: Consolidar Escopo do Produto
Objetivo
Integrar e consolidar todas as informações desenvolvidas no levantamento do escopo do produto

(necessidades, características, requisitos) em um único instrumento que deverá ser aprovado para
compor a linha de base do projeto.
Papel
Descrição
Todas as informações desenvolvidas no levantamento do escopo do produto e instrumentos elaborados

por cada atividade do desenvolvimento do escopo do produto devem ser unificadas em um documento
central, chamado Documento de Visão. Ele define a base de todo o escopo do projeto, definindo
problemas, necessidades, usuários, características do produto, restrições, requisitos e priorização, entre
outras.
Definir um vocabulário comum contendo os termos, as expressões e as siglas mais frequentes do domínio
do problema. Este vocabulário será utilizado pela equipe de projeto e fornecedores de requisitos,
servindo de base para a compreensão do domínio do negócio. As informações devem ser consolidadas
no documento Glossário.
Elaborar o Modelo de Casos de Uso, dividindo o sistema em várias visões ou pacotes, além disso,
identificando os atores, cada caso de uso que compõe o sistema e esboçando o diagrama de casos de
uso da forma que forma conveniente.
Alguns artefatos produzidos serão parte do Documento de Visão, enquanto outros devem existir em um
documento separado. Entretanto o conjunto destes artefatos irá compor a linha de base do projeto, após
aprovado.
Realizar a rastreabilidade entre os requisitos e os produtos de trabalho.
Após levantamento dos requisitos, é necessária sua aprovação junto às partes interessadas antes de
prosseguir com as demais atividades do projeto. Caso não haja aprovação, as atividades devem ser
executadas novamente, visando obter a aprovação do escopo do produto.
Pág. 47 de 165
Produtos de Entrada

 Características do Produto
 Lista de Requisitos do Produto e Priorização
 Lista de Verificação – Documento de Visão
 Lista de Verificação – Modelo de Casos de Uso
 Lista de Verificação – Glossário
 Analisar os requisitos para assegurar satisfação dos critérios definidos

Produtos de Saída
 Documento de Visão
 Modelo de Casos de Uso
 Glossário
 Matriz de Rastreabilidade
 Escopo do Produto aprovado
Atividade: Levantar Requisitos Funcionais
Objetivo
Realizar o levantamento dos requisitos funcionais e gerar a documentação de maneira que esses
requisitos sejam suficientes para retratar todo o comportamento funcional do sistema.
Papel
Descrição
Documentar os detalhes dos requisitos funcionais, especificando pré-condições e pós-condições, fluxos

de operação, entradas e saídas, interação do sistema com as interfaces externas e usuários; interfaces
internas; restrições de segurança e permissões; exceções e regras de negócio.
Devem-se especificar as regras de negócio que definem como o seu negócio funciona, podem abranger
diversos assuntos como suas políticas, interesses, objetivos, compromissos éticos e sociais, obrigações
contratuais, decisões estratégicas, leis e regulamentações entre outros.
Pág. 48 de 165
Gerar a lista das mensagens informativas, de alerta e de erro que serão exibidas no sistema.
Para maiores informações sobre a especificação de caso de uso, consulte o Guia Operacional PS-
MCTIC_GO_EspecificacaoCasoUso.
Produtos de Entrada
 Lista de Verificação – Especificação de Caso de Uso
 Lista de Verificação – Regras de Negócio
 Lista de Verificação – Lista de Mensagens

Produtos de Saída
 Especificação de Caso de Uso

 Regras de Negócio
 Lista de Mensagens
 Especificações de caso de uso consolidadas
Atividade: Levantar Requisitos Não Funcionais
Objetivo
Realizar o levantamento dos requisitos não funcionais e gerar a documentação de maneira que esses
requisitos sejam suficientes para retratar todas as características não funcionais do sistema.
Papel
Descrição
Documentar os detalhes dos requisitos não funcionais, especificando os seguintes itens: usabilidade,
confiabilidade, desempenho, suportabilidade, restrições de projeto, requisitos de implementação,
requisitos de interface, requisitos físicos.
Gerar as especificações de requisitos não funcionais para determinar a complexidade do sistema.
Produtos de Entrada
Pág. 49 de 165
 Lista de Verificação – Especificação Suplementar

Produtos de Saída
 Especificação Suplementar
 Especificação Suplementar consolidada
Atividade: Especificar Cenários Operacionais
Objetivo
Estabelecer e manter a sequência de eventos que devem ocorrer no uso do produto.
Papel
Descrição
Descrever os objetivos do cenário, tipos de entradas e o resultado final esperado pelos usuários
principais. Para cada cenário deve ser descrito a sequência de execução do cenário operacional, com os
requisitos, descrição e restrições de ambiente.
Um cenário é geralmente uma sequência de eventos que podem ocorrer no uso do produto e é utilizado
para tornar explícita alguma necessidade das partes interessadas.
Produtos de Entrada
 Glossário
 Especificações de Caso de Uso
 Lista de Verificação – Especificação de Cenários Operacionais
Pág. 50 de 165

Produtos de Saída
 Especificação de Cenários Operacionais

 Cenários operacionais definidos
Atividade: Especificar Interfaces com o Usuário
Objetivo
Realizar o detalhamento das interfaces com o usuário, descrevendo todas as ações, controles, regras e
exceções relacionados às funcionalidades representadas pelas interfaces com o usuário.
Papel
 Analista de Design
Descrição
Descrever o ator para cada interface com o usuário, além das ações, controles, regras e exceções
relacionados às funcionalidades. As regras de apresentação devem ser registradas e uma descrição para
cada item da tela deve ser feita informando o tipo, tamanho, obrigatoriedade, se existe alguma
formatação específica para o item da tela, o domínio da informação.
Produtos de Entrada
 Lista de Verificação – Especificação de Interface com o Usuário
 Especificações de caso de uso consolidadas

Produtos de Saída
Pág. 51 de 165
 Especificação de Interface com o Usuário

 Especificações de interface com o usuário consolidadas
Atividade: Validar Requisitos
Objetivo
Validar os requisitos para aumentar a probabilidade de que o produto resultante funcione conforme
pretendido.
Papel
 Equipe Técnica
Descrição
O Analista de Requisitos deve realizar apresentações de requisitos com a equipe de projeto e os

fornecedores de requisitos para obter a aprovação formal das especificações de requisitos.
Após apresentação dos requisitos, é necessária sua validação junto às partes interessadas antes de
prosseguir com as demais atividades do projeto. Caso durante a validação inconsistências sejam
identificadas, as atividades devem ser executadas novamente, visando obter a validação dos requisitos.
Os resultados da validação devem ser registrados em uma Ata de Reunião.
Produtos de Entrada

 Especificações de Interface com o Usuário
 Documentação de requisitos consolidada pela equipe de projeto

Produtos de Saída
 Ata de Reunião
Pág. 52 de 165
 Documentação de requisito gerada e validada pelos fornecedores de requisitos
Atividade: Obter Comprometimento com os Requisitos
Objetivo
Obter comprometimento dos participantes do projeto com os requisitos.
Papel
Descrição
Identificar os compromissos necessários para implementar os requisitos do projeto. Os compromissos

devem ser registrados em Ata de Reunião e, se necessário, no Plano de Projeto (PP) ou no Plano de
Gerenciamento de Requisitos.
Produtos de Entrada

 Não se aplica.
Produtos de Saída
 Ata de Reunião
 Plano de Gerenciamento de Requisitos – Opcional
 Plano de Projeto (PP) – Opcional
 Negociar e registrar compromissos
Atividade: Manter Rastreabilidade Bidirecional
Objetivo
Manter a rastreabilidade bidirecional dos requisitos para cada nível de decomposição do produto.
Papel
Pág. 53 de 165
Descrição
Manter a rastreabilidade dos requisitos para assegurar que a fonte dos requisitos de mais baixo nível está
documentada.
Manter a rastreabilidade dos requisitos até seu requisito derivado, bem como a sua alocação de funções,
objetos, pessoas, processos e produtos de trabalho. Manter a rastreabilidade horizontal de função para
função e entre interfaces. Gerar a matriz de rastreabilidade de requisitos.
Produtos de Entrada

 Produtos de trabalho do projeto
 Assegurar que a origem dos requisitos esteja documentada

Produtos de Saída
 Matriz de Rastreabilidade
 Gerar a matriz de rastreabilidade bidirecional de requisitos
Atividade: Identificar Inconsistências
Objetivo
Identificar inconsistências entre os planos de projeto, produtos de trabalho e estratégia de requisitos.
Papel
Descrição
Revisar os planos de projeto, atividades e produtos de trabalho, visando à sua compatibilidade com os
requisitos e com as mudanças neles realizadas. As ações corretivas devem ser registradas.
Produtos de Entrada

Pág. 54 de 165
 Planos, produtos de trabalhos e/ou requisitos finalizados

Produtos de Saída
 Registro de Ações Corretivas

 Ações corretivas registradas
4.3.3 Revisão Técnica (RT)
O objetivo do processo Revisão Técnica (RT) é fornecer subsídios para assegurar que os produtos
de trabalho selecionados satisfaçam aos seus requisitos especificados. O fluxo de trabalho deste
processo está ilustrado na Figura 6.
Figura 6. Fluxo do processo Revisão Técnica (RT)
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Revisão Técnica (RT) podem
ser verificadas em ITQ_PS_RevisaoTecnica. O detalhamento das atividades definidas para este
processo está descrito nos quadros a seguir.
Atividade: Planejar Revisões em Pares
Objetivo
Identificar e definir a obrigatoriedade ou não da aplicação de revisão técnica em pares nos produtos de
trabalho, as abordagens de revisão técnica para os produtos, os recursos humanos e infraestrutura
necessária para a realização das revisões técnicas nos produtos de trabalho.
Papel
Pág. 55 de 165
Descrição
Estabelecer o grau de formalismo mínimo das revisões técnicas do projeto, definindo os produtos,
segundo os critérios abaixo:
 Produtos de alta complexidade;

 Produtos que tenham requisitos de origem instáveis, suscetíveis a mudanças;
 Produtos desenvolvidos por novos colaboradores ou iniciantes;
 Produtos que sejam críticos para o sistema;
 Produtos entregáveis ao cliente;
 Produtos fundamentais e base para todo o projeto (Ex.: Especificações de requisitos);
 Produtos nos quais decisões críticas são tomadas (Ex.: Documento de Arquitetura de Software).
Definir as abordagens de revisão técnica para os produtos do projeto levando em consideração o

método, de acordo com o formalismo necessário, e os participantes, de acordo com o objetivo da
revisão. Definir o método e os tipos de participantes para os produtos de trabalho definido como
obrigatório a revisão técnica.
Planejar as atividades de revisão em pares, a alocação de recursos humanos e infraestrutura necessária

para a realização das revisões técnicas. Caso seja necessário, o Plano de Projeto e o Cronograma do
Projeto deverão ser atualizados.
Para maiores informações sobre a revisão utilizando os métodos Inspeção e Walkthrough, consulte os
Guias Operacionais PS-MCTIC_GO_Inspecao e PS-MCTIC_GO_Walkthrough.
Produtos de Entrada
 Lista de produtos definidos no caso de desenvolvimento do projeto

Produtos de Saída
 Plano de Revisões Técnicas

 Plano de Projeto (PP) – Opcional
 Cronograma do Projeto – Opcional
 Revisões técnicas planejadas conforme características do projeto
Pág. 56 de 165
Atividade: Estabelecer Critérios de Revisão
Objetivo
Estabelecer os critérios mínimos de revisão e as principais fontes de defeitos que devem ser verificadas
nos produtos de trabalho.
Papel
 Equipe Técnica
Descrição
Definir as listas de verificações (LV’s) que são instrumentos de apoio às revisões técnicas, utilizadas para
guiar os revisores durante a atividade de revisão técnica, estabelecendo os critérios mínimos de revisão
e as principais fontes de defeitos que devem ser verificadas nos produtos.
De acordo com o método de revisão técnica a ser aplicado aos produtos, a equipe técnica com o apoio
do Gerente de Projetos, viabiliza a infraestrutura necessária para a revisão, por exemplo,
disponibilização dos produtos de trabalho no repositório.
Produtos de Entrada

 Definidos os métodos e objetivos da revisão técnica de cada produto do projeto.

Produtos de Saída
 Listas de Verificação (LV’s)

 Listas de verificação estabelecidas com as principais fontes que devem ser verificadas
Atividade: Executar Revisão em Pares
Objetivo
Realizar as revisões em pares de acordo com o método a ser aplicado a cada produto a fim identificar
defeitos e sugestões de melhorias sobre os produtos.
Papel
Pág. 57 de 165
 Equipe Técnica
Descrição
Verificar se produtos de trabalho refletem adequadamente as especificações definidas, fornecendo

subsídios para identificar melhorias necessárias aos produtos, identificar e documentar defeitos,
verificar se os produtos de trabalho estão em conformidade com padrões, especificações e
requerimentos adotados.
Produtos de Entrada

 Produto de trabalho concluído para revisão técnica

Produtos de Saída
 Planilha de Resultados de Revisões Técnicas

 Revisões técnicas realizadas conforme método definido
Atividade: Analisar Resultado da Revisão
Objetivo
Avaliar resultado das revisões técnicas ocorridas no período e identificar ações corretivas.
Papel
 Equipe Técnica
Descrição
Comparar os resultados obtidos com os esperados das revisões, levando em consideração:
 Os diferentes produtos e componentes de produto;

 A composição e experiência das equipes de revisão;
 Os produtos com alta concentração de defeitos, principalmente de gravidade alta e média;
 As causas dos defeitos recorrentes.
Identificar ações a serem tomadas para quais aspectos deve ser melhorado a fim de diminuir a incidência
de erros e aumentar a qualidade dos produtos de trabalho.
Pág. 58 de 165
Produtos de Entrada

 Revisões técnicas realizadas conforme método definido

Produtos de Saída

 Ações Corretivas (como parte da Planilha de Resultados de Revisões Técnicas)
 Resultado das revisões ocorridas no período avaliado
Atividade: Monitorar Correção dos Defeitos
Objetivo
Acompanhar e atualizar os defeitos encontrados na realização das revisões.

Papel
 Equipe Técnica
Descrição
Garantir que os defeitos registrados foram solucionados, documentando a ação corretiva e mudando o
estado do defeito.
Produtos de Entrada

 Defeitos registrados corrigidos

Produtos de Saída
 Defeitos Corrigidos (como parte da Planilha de Resultados de Revisões Técnicas)

 Defeitos corrigidos ou justificativa da não correção registrada
Pág. 59 de 165
4.3.4 Solução Técnica (ST)
O objetivo do processo Solução Técnica (ST) é fornecer subsídios para projetar, desenvolver e
implementar soluções para os requisitos. Soluções, designs e implementações englobam
produtos, componentes de produto e processos de ciclo de vida relacionados ao produto, seja
de forma isolada ou em conjunto, conforme apropriado. O fluxo de trabalho deste processo está
ilustrado na Figura 7.
Pág. 60 de 165
Figura 7. Fluxo do processo Solução Técnica (ST)
Pág. 61 de 165
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Solução Técnica (ST) podem
ser verificadas em ITQ_PS_SolucaoTecnica. O detalhamento das atividades definidas para este
processo está descrito nos quadros a seguir.
Atividade: Definir Estratégias de Solução Técnica
Objetivo
Analisar e priorizar os requisitos funcionais e não funcionais do ponto de vista arquitetural e identificar
tecnologias atualmente em uso e novas tecnologias de produto.
Papel
 Projetista de Banco de Dados
 Desenvolvedor
Descrição
Propor o conteúdo técnico e a ordem das iterações sucessivas, selecionando um determinado número
de cenários e casos de uso para serem analisados e projetados. A seleção dos cenários e casos de uso
que constituem a visão do caso de uso é baseada no impacto arquitetural do cenário, nas vantagens que
o cenário oferece aos envolvidos, nos riscos a serem reduzidos, na abrangência geral da arquitetura e
outros objetivos ou restrições táticas, como por exemplo, demonstração para usuário final.
Desenvolver a listagem dos casos de uso e cenários significativos dentro de cada pacote do modelo de
casos de uso, além de propriedades significativas, como as descrições do fluxo de eventos, dos
relacionamentos, dos diagramas de casos de uso e dos requisitos especiais relacionados a cada caso de
uso. O conjunto de cenários e casos de uso que possuem cobertura arquitetural substancial (que
experimentam vários elementos de arquitetura) ou que enfatizam ou ilustram um determinado ponto
complicado da arquitetura deve ser definido.
Priorizar os requisitos significativos do ponto de vista arquitetural, que consiste em reunir um conjunto
de cenários que exercite vários elementos da arquitetura ou que enfatizam um determinado ponto
complicado da arquitetura, para definir a ordem de análise desses requisitos em busca de soluções.
Avaliar tecnologias e decisões arquiteturais aplicáveis considerando as características das soluções

associadas a componentes de produto que melhor satisfazem os critérios estabelecidos a fim de
aperfeiçoar o sistema como um todo e atender aos requisitos funcionais e não funcionais do sistema.
Produtos de Entrada

Pág. 62 de 165

 Especificações de Interfaces com o Usuário
 Arquiteturas de Referência
 Requisitos do produto documentados

Produtos de Saída
 Documento de Estratégia de Solução Técnica

 Critérios definidos para selecionar a melhor solução técnica
Atividade: Selecionar Solução
Objetivo
Desenvolver alternativas de soluções técnicas e selecionar a melhor solução com base em critérios bem
definidos.
Papel
 Desenvolvedor
Descrição
Definir os critérios de seleção considerando o custo de desenvolvimento, manufatura, aquisição,

manutenção e suporte, o desempenho, a complexidade do componente do produto e dos processos de
ciclo de vida relacionados ao produto, os riscos, as limitações de tecnologia, as capacidades e limitações
dos usuários finais e operadores, as características dos produtos já existentes no mercado, a expansão
e crescimento do produto, entre outros.
Identificar alternativas de solução, analisando as características das soluções associadas a componentes

de produto que melhor satisfazem os critérios estabelecidos a fim de aperfeiçoar o sistema como um
todo. Além disso, cada alternativa de solução deve satisfazer a alocação completa dos requisitos.
As soluções técnicas devem ser baseadas nas propostas de arquitetura de produto que tratam de
características críticas do produto e cobrem uma gama de soluções viáveis.
Pág. 63 de 165
Avaliar se os componentes do produto devem ser desenvolvidos, comprados ou reusados, com base nos
critérios estabelecidos.
Selecionar e documentar a solução associada a componentes de produto que melhor satisfaz aos
critérios estabelecidos.
A solução técnica selecionada precisa ser aprovada antes de prosseguir com as demais atividades do
projeto. Caso não seja aprovada, as atividades devem ser executadas novamente, visando sua
reformulação e adequação.
Produtos de Entrada

 Estratégia da solução técnica definida

Produtos de Saída
 Solução Identificada (como parte do Documento de Estratégia de Solução Técnica)

 Soluções, avaliações e linhas de raciocínio utilizadas documentadas

 Decisões sobre arquitetura, desenvolvimento customizado versus produto
 Alocação completa dos requisitos para cada alternativa
 Conjunto de soluções que satisfaçam os critérios de seleção estabelecidos
 Solução técnica selecionada
Atividade: Definir Arquitetura
Objetivo
Definir uma sugestão de arquitetura e restringir as técnicas de arquitetura a serem utilizadas no projeto,
considerando a experiência obtida com projetos de domínios de problemas semelhantes.
Papel
Pág. 64 de 165
 Desenvolvedor
Descrição
Desenvolver a Visão Geral da Arquitetura refletindo sobre os ambientes existentes de hardware e

software, as decisões iniciais relativas à arquitetura física e lógica, os requisitos não funcionais. Definir a
arquitetura para o sistema com base na experiência obtida com sistemas ou domínios de problema
semelhantes, a fim de evitar esforço na ‘redescoberta arquitetural’.
Separar diferentes aspectos da arquitetura em visões separadas com o objetivo de gerenciar

complexidade. Desenvolver as visões de Casos de Uso, Lógica, de Processos, de Implantação, de
Implementação e de Dados.
A Visão de Casos de Uso apresenta os casos de uso significativos do sistema, do ponto de vista da
arquitetura. Ela descreve o conjunto de cenários e/ou os casos de uso que representam alguma
funcionalidade central e significativa. Também descreve o conjunto de cenários e/ou casos de uso que
possuem cobertura arquitetural substancial (que exercita vários elementos de arquitetura) ou que
enfatizam ou ilustram um determinado ponto complicado da arquitetura. Para cada caso de uso
significativo deve-se especificar o nome do caso de uso, uma breve descrição do caso de uso, descrições
significativas do Fluxo de Eventos do caso de uso, descrições significativas dos relacionamentos que
envolvem o caso de uso, como os relacionamentos de inclusão e de extensão ou as associações de
comunicação, descrições significativas dos Requisitos Especiais do caso de uso, imagens significativas da
Interface do Usuário. As realizações desses casos de uso devem estar localizadas na visão lógica.
A Visão Lógica apresenta elementos de projeto significativos do ponto de vista da arquitetura. Ela
descreve as classes mais importantes, sua organização em pacotes e subsistemas, e a organização desses
pacotes e subsistemas em camadas. Também descreve as realizações de casos de uso mais importantes
como, por exemplo, os aspectos dinâmicos da arquitetura. As classes e os objetos são os principais
elementos nesta visão e podem ser elaborados os Diagramas de Classe, Sequência e Colaboração para
mostrarem o relacionamento entre esses elementos.
É importante identificar problemas de arquitetura comuns que podem ser expressos como mecanismos
durante a análise (mecanismos de persistência, gerenciamento de transações, gerenciamento de falhas,
mensagens e inferência).
Analisar as funcionalidades a fim de capturar informações adicionais necessárias para entender o

comportamento interno pretendido do sistema que pode estar faltando nos requisitos.
A Visão de Processos descreve os processos do sistema e como eles se comunicam. Em cada processo,
apenas os threads superficiais e significativos do ponto de vista da arquitetura precisam ser
apresentados. A visão de processos descreve as tarefas (processos e threads) envolvidas na execução
do sistema, suas interações e configurações, além da alocação de objetos e classes para tarefas. Essa
visão permite avaliar requisitos não funcionais relacionados à execução e comunicação (desempenho,
disponibilidade, escalabilidade). Para cada rede de processos deve-se especificar o nome da rede de
processos, os processos envolvidos, as interações entre os processos com as características de
Pág. 65 de 165
comunicação, a vida útil e o comportamento de cada processo. Diagramas de Atividades e de

Colaboração são úteis para representar essa visão.
A Visão de Implantação descreve uma ou mais configurações (hardware) de rede física nas quais o
software será implantado e executado. Ela também descreve a alocação de tarefas (da Visão de
Processos) para os nós físicos. Permite avaliar requisitos não funcionais tais como desempenho,
disponibilidade, confiança, escalabilidade. Nessa visão, componentes executáveis são alocados a nós
processadores e pode ser elaborado o Diagrama de Implantação. Para cada configuração da rede física
deve-se especificar o nome e o diagrama de implantação que ilustre a configuração, seguindo o
mapeamento de processos de cada processador.
A Visão de Implementação descreve a decomposição do software em camadas e subsistemas existentes

no modelo de implementação. Ela fornece uma visão geral do modelo de implementação e da sua
organização em termos de componentes existentes nos subsistemas e nas camadas de implementação,
bem como a alocação de pacotes e de classes (da Visão Lógica) para os componentes e os subsistemas
de implementação da Visão de Implementação. É normalmente usada para descrever os módulos do
sistema. Os pacotes e bibliotecas de classes são exemplos de módulos em alguns ambientes de
programação. Podem ser elaborados os Diagramas de pacote e de componente nessa visão.
A Visão de Dados descreve os elementos persistentes e significativos do ponto de vista da arquitetura

no modelo de dados. Ela fornece uma visão geral do modelo de dados e de sua organização em termos
de tabelas, visões, índices, triggers e procedimentos armazenados usados para oferecer persistência ao
sistema. Ela também descreve o mapeamento das classes persistentes (da Visão Lógica) para a estrutura
de dados do banco de dados. Deve-se apresentar elementos do modelo de dados significativos do ponto
de vista da arquitetura, descrevendo sua responsabilidade, e também alguns poucos, mas muito
importantes relacionamentos e comportamentos (triggers, procedimentos armazenados, etc.).
Definir estratégias de reuso para o projeto com base na visão geral da arquitetura, restrições e
requisitos. Identificar componentes reutilizáveis e decidir se desenvolve, adquire ou reusa.
Criar uma estrutura inicial para o Modelo de Projeto com as duas camadas de nível superior, ou seja, as
camadas de aplicativo e específicas do negócio.
Identificar abstrações-chave (representação de conceitos identificados durante as atividades de

modelagem de negócios e requisitos) para permitir a avaliação da necessidade de provas de conceito.
Realizar (projetar) os cenários significativos do ponto de vista da arquitetura.
Registrar todas as informações resultantes dessa análise no Documento de Arquitetura.

Produtos de Entrada

Pág. 66 de 165
 Arquiteturas de Referência
 Biblioteca de Componentes
 Lista de Verificação – Documento de Arquitetura de Software
 Solução técnica selecionada

Produtos de Saída
 Documento de Arquitetura de Software

 Análise arquitetural realizada
Atividade: Desenvolver Guias Técnicos
Objetivo
Definir as diretrizes a serem seguidas durante o projeto, o ambiente de implementação e os padrões de

implementação.
Papel
 Desenvolvedor
Descrição
Desenvolver as diretrizes a serem seguidas durante o projeto, especificando o ambiente de

implementação. Devem ser especificados plataforma de destino (hardware e sistema operacional),
interface do usuário, ferramentas de desenvolvimento (linguagem, IDE), sistema de gerenciamento de
banco de dados, biblioteca de componentes. Essas informações deverão ser documentadas no Guia de
Projeto. O Guia de Projeto deverá conter também o mapeamento dos pacotes de projeto para os
subsistemas de implementação, o mapeamento das entidades de projeto para o código e a
representação dos subsistemas e componentes reutilizáveis.
Especificar a apresentação do layout do código e de comentários, o uso de convenções de nomeação e

características da linguagem e outros detalhes de implementação como boas práticas. Essas
informações deverão ser documentadas no Guia de Implementação.
Produtos de Entrada
Pág. 67 de 165

 Biblioteca de Componentes
 Arquitetura de produto descrita

 Requisitos alocados nas soluções
 Componentes de produto descritos
 Características-chave do produto definidas
Produtos de Saída
 Guia de Projeto
 Guia de Implementação
 Diretrizes a serem seguidas durante o projeto, ambiente de implementação e padrões de codificação

definidos
Atividade: Projetar Interfaces Internas e Externas
Objetivo
Projetar as interfaces internas e externas, dos subsistemas e componentes do produto a partir dos
critérios estabelecidos e mantidos.
Papel
Descrição
Identificar as interfaces internas e com sistemas externos determinando quais informações devem ser
fornecidas pelo “cliente” e quais são retornadas quando a colaboração é concluída; esses conjuntos de
informações passam a ser os parâmetros de entrada e saída do subsistema.
Definir dependências entre as interfaces a fim de fornecer informações de acoplamento.
Pág. 68 de 165
Empacotar as interfaces a fim de permitir o controle das interfaces independentemente dos próprios
subsistemas.
Projetar interfaces considerando a origem, destino, estímulos e características para software,

características funcionais e não funcionais para hardware e serviços de comunicação. Essas informações
deverão ser documentadas no Documento de Arquitetura de Software.
Produtos de Entrada

 Arquitetura definida
Produtos de Saída
 Especificação de Interfaces Internas e Externas (como parte do Documento de Arquitetura de

Software)
 Interfaces internas e externas definidas
Atividade: Projetar Interfaces com o Usuário
Objetivo
Especificar o comportamento das telas, estrutura de menu e avaliar alternativas com relação às
interfaces com o usuário.
Papel
 Desenvolvedor
Descrição
Pág. 69 de 165
Refinar as Especificações de Interface com o Usuário, especificando o comportamento das telas,

estrutura de menu e avaliando alternativas com relação às interfaces com o usuário e a arquitetura
definida.
Produtos de Entrada

 Especificações de Interfaces com o Usuário definidas

Produtos de Saída
 Especificação de Interface com o Usuário

 Especificações de interface com o usuário refinadas conforme características da arquitetura definida
Atividade: Projetar Banco de Dados
Objetivo
Criar, definir e refinar o modelo de dados para dar suporte ao armazenamento e à recuperação de
entidades persistentes.
Papel

Descrição
Mapear entidades persistentes em tabelas relacionais e representar lógica e fisicamente os dados

persistentes do sistema no Modelo de Dados.
Otimizar o desempenho do Modelo de Dados e o acesso aos dados. Depois de projetar a estrutura da
tabela deve ser avaliado se entidades agregadas precisam ser recuperadas ao mesmo tempo e com
Pág. 70 de 165
frequência, quais são os tipos de consultas que serão executadas nos dados e a possibilidade do uso do
recurso de indexação.
Definir características de armazenamento, por exemplo, para estimar o número de registros que
precisam ser armazenados e o volume de espaço em disco necessário para armazenar os registros. Ao
calcular o espaço em disco, deve-se considerar o crescimento decorrente da inclusão de novos dados.
Definir as estruturas das tabelas básicas e determinar uma estratégia para preenchê-las.
Definir regras para a integridade de dados (restrições) a fim de garantir que os valores dos dados
permaneçam dentro de limites definidos. O banco de dados deve agir como um 'validador'.
Analisar a necessidade de especificar o comportamento das entidades no banco de dados. As operações

no banco de dados podem ser implementadas usando o recurso de procedimentos armazenados. Neste
caso o Projetista de Banco de Dados deverá projetar, implementar, testar e documentar os
procedimentos armazenados no Modelo de Dados, conforme diretrizes contidas no Guia de Projeto.
Descrever, negocial e conceitualmente, cada uma das entidades identificadas no Modelo de Dados,
permitindo melhor entendimento do negócio e das entidades (dados) necessárias à solução. Essas
informações devem ser consolidadas no Dicionário de Dados.
Para mais informações sobre as regras de padrões e modelagem de dados, consulte o Guia Operacional
PS-MCTIC_GO_RegrasPadroesModelagemDados.
Produtos de Entrada

 Lista de Verificação – Modelo de Dados
 Especificações de Interfaces com o Usuário definidas

Produtos de Saída
 Modelo de Dados
 Dicionário de Dados
Pág. 71 de 165
 Modelo de Dados e Dicionário de Dados refinado
Atividade: Consolidar Arquitetura
Objetivo
Consolidar a arquitetura definida, avaliando se os itens definidos em cada visão arquitetural estão
completos e consistentes.
Papel
 Desenvolvedor
Descrição
Revisar os mecanismos de arquitetura, subsistemas, pacotes e entidades que foram identificados para
se certificar de que estão completos e são consistentes.
Os cenários significativos devem ser utilizados para validar as opções arquiteturais.
A arquitetura do sistema precisa estar definida de forma completa e consistente antes de prosseguir
com as demais atividades do projeto. Caso não esteja, as atividades devem ser executadas novamente,
visando sua reformulação e adequação.
Produtos de Entrada

 Guia de Projeto
 Modelo de Dados
 Análise arquitetural concluída
Pág. 72 de 165
Produtos de Saída

 Arquitetura do sistema consolidada
Atividade: Implementar Solução
Objetivo
Implementar os componentes do sistema conforme requisitos, características e guias técnicos definidos.

Papel
 Desenvolvedor
Descrição
Implementar os componentes baseando no Modelo de Análise e Projeto, Modelo de Dados,

Especificações de Interface com o Usuário, Roteiros de Teste e Guia de Implementação que contempla
os padrões de codificação, os padrões de documentação de código e boas práticas.
Essa atividade contempla a implementação e a modificação dos componentes e interfaces com o

usuário, além da execução dos testes unitários.
Produtos de Entrada

 Guia de Projeto
 Modelo de Dados
 Lista de Verificação – Notas de Release
Pág. 73 de 165
 Produto e arquitetura definidos

 Métodos efetivos para implementar os componentes de produto
Produtos de Saída
 Código-fonte
 Notas de Release
 Testes unitários do componente de produto realizados
Atividade: Elaborar Material de Suporte
Objetivo
Elaborar e manter a documentação utilizada para instalar, operar e/ou manter o produto.
Papel
 Desenvolvedor
Descrição
Revisar requisitos, design, produto e resultados de teste para assegurar que questões críticas que
afetem a documentação de instalação, operação e manutenção sejam identificadas e tratadas.
Usar métodos efetivos para elaborar a documentação de instalação, operação e manutenção.
Elaborar a documentação utilizada para instalar, operar e manter o produto. Pode ser elaborado Manual
do Usuário, Manual para Manutenção, Help on-line e material de treinamento do usuário final.
Produtos de Entrada

 Guia de Projeto
 Modelo de Dados
 Código-fonte
Pág. 74 de 165
 Requisitos implementados
Produtos de Saída
 Manual do Usuário
 Uso de métodos efetivos para elaborar a documentação de instalação, operação e manutenção

 Revisão por pares da documentação de instalação, operação e manutenção
4.3.5 Integração do Produto (IP)
O objetivo do processo Integração de Produto (IP) é fornecer subsídios para montar o produto
a partir de componentes de produto, assegurando que o produto integrado execute as funções
de forma apropriada. A integração do produto não é somente um processo executado uma vez
para integrar os componentes em um produto, ele deve ser conduzido de forma incremental
integrando componentes, testando esses componentes de forma iterativa. O fluxo de trabalho
deste processo está ilustrado na Figura 8.
Pág. 75 de 165
Figura 8. Fluxo do processo Integração de Produto (IP)
Pág. 76 de 165
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Integração do Produto (IP)

podem ser verificadas em ITQ_PS_IntegracaoProduto. O detalhamento das atividades definidas
para este processo foi descrito nos quadros a seguir.
Atividade: Definir Estratégia de Integração
Objetivo
Identificar os componentes a serem integrados e definir a estratégia de integração.

Papel
 Integrador
Descrição
Identificar os componentes a serem integrados e definir a estratégia de integração.
Definir uma série de builds para integrar gradativamente o sistema. Geralmente, isso é feito de baixo
para cima na estrutura em camadas dos subsistemas. Para cada build definir quais subsistemas devem
ser incluídos e quais subsistemas devem estar disponíveis como stubs.
Estabelecer critérios para a seleção da melhor sequência de integração. Com base nesses critérios e na
estratégia, o Integrador e o Gerente de Projetos devem definir a melhor sequência de integração. Os
critérios e a sequência de integração devem ser registrados no Plano de Integração.
Produtos de Entrada

 Plano de Teste
 Projeto realizado
 Identificação dos componentes de produto a serem integrados
Produtos de Saída
 Plano de Integração
 Estratégia de integração definida
Pág. 77 de 165
Atividade: Estabelecer Ambiente de Integração
Objetivo
Estabelecer e manter o ambiente necessário para dar suporte à integração dos componentes do
produto.
Papel
 Integrador
Descrição
Estabelecer o ambiente necessário para a integração de produto que será desenvolvido ou adquirido.
Analisar a necessidade de recursos complementares para o Ambiente de Integração e registrar no Plano

de Integração, baseado no Plano de Projeto, Documento de Arquitetura de Software e no Plano de
Integração definidos.
Estabelecer o Ambiente de Integração, conforme especificado no Plano de Integração.
Após o estabelecimento do Ambiente de Integração, deve-se realizar uma verificação para garantir sua
aderência ao especificado. Caso tenha algum desvio que não se possa resolver, o Gerente de Projetos
deve ser comunicado para tomar as devidas providências.
Produtos de Entrada

 Estratégia de integração definida

Produtos de Saída
 Ambiente de Integração (como parte do Plano de Integração)

 Ambiente de Integração Configurado
 Ambiente verificado para integração de produto
Atividade: Estabelecer Procedimentos para Integração
Objetivo
Pág. 78 de 165
Definir os procedimentos e os critérios para integração, incluindo a sequência de integração dos

componentes do produto, os procedimentos para construção do build, os critérios para sua avaliação,
as instruções de instalação e como ele deverá ser testado.
Papel
 Integrador
Descrição
Com base no Plano de Integração e Especificações de Interfaces Internas e Externas (descritas no

Documento de Arquitetura de Software), o Integrador deve especificar para cada build a ser criado:
 Os subsistemas que deverão integrar esses builds e a sequência de integração;
 Os procedimentos para a construção do build;
 Os critérios para sua avaliação;
 As instruções de instalação; e
 As instruções de como deverá ser testado, conforme Plano de Teste.
Todas essas informações devem ser registradas no Plano de Integração.
Produtos de Entrada
 Plano de Teste
 Estratégia de integração definida no Plano de Integração

Produtos de Saída
 Plano de Integração atualizado com os procedimentos de integração
Atividade: Garantir Disponibilidade dos Componentes
Objetivo
Garantir se os componentes previstos para integração estão disponíveis.

Papel
 Integrador
Descrição
Pág. 79 de 165
Obter os Componentes de Software a serem integrados e armazená-los numa área separada da área de
desenvolvimento do sistema, que muitas vezes é chamada de área de integração. Os componentes a
serem integrados devem permanecer nesta área até que a integração seja concluída.
Sempre que possível, deve-se realizar os testes unitários dos componentes ou subsistema de
implementação a serem integrados no ambiente de integração. O objetivo é garantir que os
componentes estão em condições de serem integrados.
Se algum problema for encontrado durante esta atividade, o Integrador deve comunicar o problema
preenchendo a Lista de Ocorrências e enviando um e-mail ao Gerente de Projetos.
Produtos de Entrada
 Componentes do Sistema (Código-Fonte)
 Componentes do produto implementados

 Garantir que os componentes estejam em condições de serem integrados
Produtos de Saída
 Lista de Ocorrências
 Obter os componentes a serem integrados

 Registro das ocorrências identificadas
Atividade: Integrar os Componentes
Objetivo
Integrar os componentes do produto de acordo com a sequência de integração e com os procedimentos

definidos.
Papel
 Integrador
Descrição
Assegurar que os componentes de produto sejam integrados em componentes de produto maiores e

mais complexos, de acordo com a sequência de integração de produto e procedimentos definidos.
Pág. 80 de 165
Recuperar os códigos a serem integrados e realizar a integração dos Componentes de Software ou

subsistemas de implementação disponíveis. Deve-se garantir que os testes unitários foram realizados
com sucesso novamente.
Gerar um Build e implantá-lo no ambiente correspondente, que poderá ser o de integração (deploy).
Executar os testes de integração, conforme Plano de Teste. Se algum problema for encontrado durante
esta atividade, o Integrador deve comunicar o problema preenchendo a Lista de Ocorrências e enviando
um e-mail ao Gerente do Projeto.
Após os testes de integração, o Integrador deve criar as Notas de Release. A finalidade das Notas de
Release é descrever o release, identificando mudanças e erros conhecidos desta versão do build.
Produtos de Entrada
 Plano de Teste
 Guia de Projeto
 Componentes do Sistema (Código-Fonte)
 Plano de Integração definido

 Disponibilização do componente a ser integrado
 Ambiente de integração de produto pronto
Produtos de Saída
 Build (Código compilado)

 Build integrada
 Notas de Release geradas
Atividade: Planejar Implantação
Objetivo
Planejar a implantação e documentar como e quando o produto será disponibilizado para a comunidade
de usuários.
Papel
 Integrador
Pág. 81 de 165
Descrição
Planejar a implantação e documentar esse planejamento no Plano de Implantação. O Plano de

Implantação deve documentar como e quando o produto será disponibilizado para a comunidade de
usuários.
As atividades deverão incluir o planejamento do empacotar e da distribuição do produto, como será a

instalação do produto. Além disso, se haverá ou não migração do sistema antigo e se os dados serão
convertidos e como será o suporte aos usuários (treinamento formais, em computador, ajuda on-line,
por telefone ou pela Internet, por exemplo).
Produtos de Entrada

 Lista de Verificação – Plano de Implantação
 Componentes integrados
Produtos de Saída
 Plano de Implantação
 Implantação planejada
Atividade: Elaborar Material de Suporte e Treinamento
Objetivo
Elaborar e manter a documentação utilizada para instalar, operar e/ou manter o produto.
Papel
 Integrador
Descrição
Com base na documentação gerada e no build, consolidar o material de suporte no Manual do Produto.
Elaborar o Manual do Produto a fim de ensinar e orientar o usuário e/ou a equipe técnica a instalar,
operar e manter o produto.
Produtos de Entrada

Pág. 82 de 165

 Build
 Componente integrado
Produtos de Saída
 Manual do Produto
 Documentação gerada
Atividade: Produzir Unidade de Implantação
Objetivo
Criar o pacote da Unidade de Implantação, contendo um build, Notas de Release, Manual do Produto
para disponibilização do produto no ambiente do cliente.
Papel
 Integrador
 Analista de Gestão de Configuração
Descrição
O Analista de Gestão de Configuração, com o apoio do Integrador, cria o pacote Unidade de Implantação
contendo um build, Notas de Release e Manual do Produto, após verificar se as revisões técnicas e testes
foram realizados.
Uma Unidade de Implantação deve ser completa o suficiente para ser descarregada e executada em um
nó.
O Analista de Gestão de Configuração providencia a disponibilização do produto que possui o conteúdo

íntegro e correto e avisa o Gerente de Projetos.
Produtos de Entrada
 Build
Pág. 83 de 165
 Build gerado
Produtos de Saída
 Produto
 Unidade de implantação gerada
Atividade: Entregar Produto
Objetivo
Entregar o produto ao cliente.

Papel
 Integrador
Descrição
Conforme Plano de Implantação, o Integrador e o Gerente de Projetos executam a entrega do produto

ao cliente. O produto, neste contexto, corresponde à unidade de implantação.
Produtos de Entrada
 Produto (Build)
 Produto ou componentes de produto integrados e empacotados

Produtos de Saída
 Produto
 Implantação do produto no ambiente do cliente
Pág. 84 de 165
4.3.6 Teste (TS)
O objetivo do processo Teste (TS) é fornecer subsídios para demonstrar que um produto ou
componente de produto satisfaz ao seu uso pretendido, quando colocado em seu ambiente
alvo. O fluxo de trabalho deste processo está ilustrado na Figura 9.
Figura 9. Fluxo do processo Teste (TS)
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Teste (TS) podem ser
verificadas em ITQ_PS_Teste. O detalhamento das atividades definidas para este processo está
descrito nos quadros a seguir.
Atividade: Planejar Teste
Objetivo
Definir uma estratégia de testes para o projeto com base na avaliação das necessidades, objetivos,
abordagens e infraestrutura mais adequada para o projeto.
Papel
 Analista de Teste
 Integrador
Descrição
Pág. 85 de 165
O Gerente de Projetos e o Analista de Teste definem a missão e os motivadores para os testes que serão
realizados no projeto como a estratégia de testes definidas no Plano de Teste.
Baseados no Documento de Visão e nas Especificações de Caso de Uso, também deve ser registrada uma
lista dos principais itens que estão sujeitos a testes no Plano de Teste. Essa lista deve incluir itens
produzidos diretamente pela equipe de desenvolvimento do projeto e itens dos quais esses produtos
dependem. Por exemplo, o caso de uso, o componente de software, o hardware de processamento
básico, dispositivos periféricos, sistemas operacionais, produtos ou componentes de terceiros, entre
outros.
Baseado na missão do teste e no momento do ciclo de vida em que este é realizado, o Analista de Teste
define as abordagens de testes, identificando o nível, tipo e técnicas de testes a serem aplicadas a cada
produto ou componente de produto.
Com base no Plano de Integração e no Documento de Arquitetura de Software o Analista de Teste, o

Arquiteto de Software e o Integrador avaliam a necessidade da utilização de componentes de teste
unitário e componentes teste de integração.
Por fim, as abordagens de testes de software são registradas pelo Analista de Teste no Plano de Teste.
O Analista de Teste identifica e registra no Plano de Teste a infraestrutura de hardware e software

necessária para a execução dos testes, levando em consideração características arquiteturais do
sistema, necessidade de restauração e recuperação da configuração do ambiente de testes a um estado
conhecimento, os diversos ambientes de implantação, os requisitos de ambiente específicos.
O Gerente de Projetos estabelece as atividades de testes, de acordo com o ciclo de vida do projeto e
define os responsáveis por cada atividade do Plano de Teste, utilizando como base o gerenciamento de
recursos humanos definidos no Plano de Projeto.
O Gerente de Projetos e o Analista de Teste, através de reunião, obtêm o apoio do Analista de Requisitos
e do Arquiteto de Software para o planejamento das atividades de testes do projeto.
Com base nestas informações o Analista de Teste registra no Plano de Testes a lista de produtos ou
componentes de software que serão submetidos a testes de acordo com o ciclo de vida do projeto.
Se necessário, o Analista de Teste deve descrever o planejamento dos componentes de teste de

integração que serão utilizados para a execução dos testes no projeto. Dependendo da estratégia de
integração adotada e arquitetura do software, testes são necessários sem que se tenham disponíveis
todos os componentes de software que compõem o produto integrado. Nestes casos são criados
Componentes de Teste de Integração (Drivers e Stubs) que simulam o funcionamento e a interface do
produto de software sendo testado.
Para maiores informações sobre as Políticas de Teste, consulte o Guia Operacional PS-
MCTIC_GO_PoliticasTeste.
Produtos de Entrada

Pág. 86 de 165
 Requisitos definidos e priorizados

 Arquitetura projetada
 Sequência de integração definida
 Planejamento do desenvolvimento de produtos ou componentes de software finalizado
Produtos de Saída
 Plano de Teste
 Atividades de teste atribuídas à equipe do projeto
Atividade: Projetar Testes
Objetivo
Especificar os instrumentos utilizados para a execução de testes funcionais e não funcionais do projeto,
bem como identificar e definir as diferentes variáveis que influenciam o desempenho do sistema e as
medidas necessárias para avaliá-lo.
Papel
 Programador de Teste
Descrição
Elaborar roteiros de teste baseados na especificação de requisitos funcionais e não funcionais de forma
a identificar, formalmente, um conjunto específico de entradas, condições de execução e resultados
esperados, com a finalidade de avaliar um determinado aspecto de um produto ou componente de
software. Essas informações deverão ser registradas no documento de Roteiro de Teste.
O Analista de Teste deve identificar os dados do sistema necessários para a realização dos testes e
projetar a Massa de Teste, criando os scripts que realizarão a carga da massa de teste na base de dados
do sistema.
Pág. 87 de 165
Dependendo da complexidade do teste e da estratégia a ser adotada no Plano de Teste são necessários
testes automatizados através a execução de Scripts de Teste.
Um Script de Teste é um conjunto de instruções, representadas em linguagem de programação,

utilizadas para simular, de forma automatizada, as diferentes condições de execução e resultados
esperados de um produto de software, conforme estabelecido no Roteiro de Teste e Massa de Teste.
O Programador de Teste elabora e mantém os Scripts de Teste através de uma ferramenta de

automatização de testes, durante todo o ciclo de vida do projeto, garantindo a aderência com as
mudanças nos requisitos do software.
O Analista de Teste e o Programador de Teste mantêm a rastreabilidade do Roteiro de Teste e dos Scripts
de Teste.
Produtos de Entrada

 Guia de Projeto
 Modelo de Dados
 Plano de Teste
 Requisitos de software considerados testáveis

 Plano de Teste definido
 Lista de Verificação – Roteiro de Teste
Produtos de Saída
 Roteiro de Teste
 Massa de Teste (como parte do Roteiro de Teste)
 Scripts de Teste (Código) – Opcional
 Testes projetados
 Rastreabilidade realizada do roteiro de teste e do script de teste com as especificações funcionais e
não funcionais
Pág. 88 de 165
Atividade: Preparar Ambiente de Teste
Objetivo
Montar o ambiente para execução dos testes e preparar a massa de dados para teste.
Papel
Descrição
Oferecer um ambiente com infraestrutura similar ao de produção, com bases de dados reduzidas,
descaracterizadas e íntegras, utilizando processos automáticos de carga e validação de informações.
É imprescindível que o Ambiente de Testes esteja devidamente estabelecido, de acordo com as

estratégias de testes definidas no Plano de Teste. Sendo assim, o Gerente de Projetos trabalha no
sentido de viabilizar os recursos de infraestrutura e pessoal de forma a permitir a execução dos testes
planejados.
O Analista de Teste deve carregar a Massa de Teste na base de dados do sistema e, quando necessário,
preparar o ambiente de execução dos Scripts de Teste.
Produtos de Entrada
 Plano de Teste
 Roteiro de Teste
 Estratégia e ambiente de teste definidos no Plano de Teste

Produtos de Saída
 Ambiente de Teste Configurado

 Ambiente de Teste devidamente configurado

 Recursos de infraestrutura e pessoal de forma a permitir a execução dos testes planejados
Atividade: Executar os Testes
Objetivo
Realizar os testes, registrar o comportamento do build e avaliar o nível de qualidade no projeto

desenvolvido.
Pág. 89 de 165
Papel
 Testador
Descrição
Realizar os testes nos Builds aplicando os instrumentos específicos de cada abordagem de teste definida
a fim de avaliar não apenas as respostas geradas pelo item em teste, seu comportamento interno
também deve ser avaliado.
De acordo com a abordagem definida no Plano de Teste, o Testador realiza os testes nos Build aplicando
os instrumentos específicos de cada abordagem, como: Roteiros de Teste e Scripts de Teste.
O Testador elabora o Registro dos Resultados de Teste descrevendo o comportamento do Build frente
aos testes realizados. Ao encontrar um defeito, o Testador deve registrá-lo na ferramenta de controle
de defeitos e, opcionalmente, registrar as evidências de defeitos, contendo, por exemplo, imagens de
captura das telas que apresentam os defeitos identificados.
O Testador notifica o Gerente de Projetos dos defeitos encontrados para que este planeje as atividades
de correção.
Produtos de Entrada
 Plano de Teste
 Roteiros de Teste
 Scripts de Teste
 Build
 Ambiente de testes estabelecido

Produtos de Saída
 Registro dos Resultados de Teste

 Builds testados
 Registro dos resultados reais e comparação com os resultados esperados
Atividade: Avaliar Resultado dos Testes
Objetivo
Avaliar os resultados de teste frente aos objetivos estabelecidos e verificar se foram obtidos os
resultados esperados, quanto à cobertura e qualidade.
Papel
Pág. 90 de 165
Descrição
Apresentar os resultados do teste, a fim de avaliar a abrangência do teste, sendo expressa pelo
percentual de casos de teste executados em relação ao total de casos de teste projetados. Avaliar
também o indicador de confiabilidade, estabilidade e desempenho, refletido diretamente nos
resultados da execução dos testes.
O Gerente de Projetos e o Analista de Teste avaliam os Registros dos Resultados de Teste frente aos
objetivos estabelecidos no Plano de Teste e verificam se foram obtidos os resultados esperados, quanto
à cobertura e qualidade.
O Analista de Teste elabora o Sumário de Avaliação de Teste resumindo os resultados dos testes e o
controle de defeitos, enfatizando as principais medidas de teste para revisão e avaliação.
Produtos de Entrada

 Plano de Teste
 Build testado
Produtos de Saída
 Sumário de Avaliação de Teste

 Avaliação dos testes concluída
Atividade: Identificar Ações Corretivas
Objetivo
Identificar ações a serem tomadas para quais aspectos do desenvolvimento deve ser melhorado.
Papel
Descrição
Identificar quais os aspectos do desenvolvimento do projeto devem ser melhorados, de acordo com a
avaliação dos resultados do teste.
Produtos de Entrada
Pág. 91 de 165

 Sumário de Avaliação de Teste
 Resultados do teste avaliados frente aos objetivos estabelecidos

Produtos de Saída

 Ações corretivas identificadas e registradas
Atividade: Monitorar Correção dos Defeitos
Objetivo
Acompanhar e atualizar os defeitos encontrados na execução dos testes.

Papel
 Testador
Descrição
Garantir que os defeitos registrados foram solucionados por meio de novos testes para manter um nível
de qualidade do projeto desenvolvido. Além disso, deve ser documentada a ação corretiva e mudado o
estado do defeito.
Produtos de Entrada

 Defeitos registrados solucionados

Produtos de Saída
 Defeitos Corrigidos
 Defeitos corrigidos
 Resultados do teste avaliados
Pág. 92 de 165
4.3.7 Gestão de Configuração (GC)
O objetivo do processo Gestão de Configuração (GC) é fornecer subsídios para estabelecer e

manter a integridade dos produtos de trabalho, utilizando identificação de configuração,
controle de configuração, balanço das atividades de configuração e auditorias de configuração.
O fluxo de trabalho deste processo está ilustrado na Figura 10.
Figura 10. Fluxo do processo Gestão de Configuração (GC)
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Gestão de Configuração (GC)

podem ser verificadas em ITQ_PS_GestaoConfiguracao. O detalhamento das atividades
definidas para este processo está descrito nos quadros a seguir.
Atividade: Planejar Gestão de Configuração
Objetivo
Planejar as atividades da gestão de configuração, identificando os itens de configuração, que são os

componentes e produtos de trabalho relacionados a serem colocados sob gestão de configuração e
planejando as auditorias de configuração.
Papel

Descrição
O Analista de Gestão de Configuração em conjunto com o Gerente de Projetos planeja as atividades do

gerenciamento de configuração com base no Plano de Projeto.
Basicamente o planejamento consiste em:
 Identificar os Itens de Configuração (IC), conforme políticas, guias operacionais e critérios para
identificação dos ICs que podem ser:
o Produtos de trabalho que são passíveis de alterações, seja devido a erros ou mudanças
nos requisitos, e que devem ser mantidos sob controle de versões;
Pág. 93 de 165
o Produtos de trabalho que são dependentes de outros, de tal forma que uma mudança
em um deles implica em mudanças nos outros;
o Produtos de trabalho que podem ser utilizados por mais de um grupo;
o Produtos de trabalho que são críticos para o projeto;
o Produtos de trabalho que são entregues ao cliente;
o Produtos de uma fase que servem de insumo para outra fase do projeto.
 Atribuir identificador único, especificar características importantes e identificar o responsável
para cada item de configuração e, também, especificar quando cada item de configuração é
colocado sob gestão de configuração.
 Definir data, intenção e objetivos das auditorias no Cronograma de Gestão de Configuração. As
auditorias devem se limitar a verificar os produtos que estão presentes nas configurações base,
sem se preocupar em revisar o conteúdo.
Para maiores informações sobre as Políticas de Gestão de Configuração, consulte o Guia Operacional
PS-MCTIC_GO_PoliticasGC.
Para maiores informações sobre a Ferramenta de Gestão de Configuração, consulte o Guia Operacional
PS-MCTIC_GO_FerramentaGC.
Produtos de Entrada

 Documentos do projeto
 Plano de Projeto elaborado

Produtos de Saída
 Plano de Gestão de Configuração

 Cronograma de Gestão de Configuração (como parte do Plano de Projeto)
 Itens de Configuração identificados (como parte do Plano de Gestão de Configuração)
 Itens de configuração identificados

 Cronograma definido com as atividades de GC e de auditoria
Atividade: Estabelecer o Sistema de Gestão de Configuração
Objetivo
Definir o meio de armazenamento, os procedimentos e as ferramentas para acesso ao sistema de

configuração e disponibilizá-lo.
Papel

Descrição
Pág. 94 de 165
Estabelecer e manter um sistema de gestão de configuração para controlar os produtos de trabalho. Um

sistema de gestão de configuração inclui o meio de armazenamento, os procedimentos e as ferramentas
para acesso ao sistema de configuração.
Estabelecer um mecanismo para gerenciar vários níveis de controle de gestão de configuração. Os níveis
de controle podem variar desde um controle informal até um controle de configuração com baselines,
que só podem sofrer mudanças de acordo com o um processo formal de gestão de Configuração.
O Sistema de Gestão de Configuração deve permitir:
 Armazenar e recuperar itens de configuração;

 Compartilhar e transferir itens de configuração entre os níveis de controle;
 Armazenar e recuperar versões arquivadas de itens de configuração;
 Criar relatórios de gestão de configuração;
 Proteger o conteúdo do sistema de gestão de configuração;
 Atualizar a estrutura de gestão de configuração, quando necessário.
A criação do ambiente de Gestão de Configuração compreende:
 Instalação e configuração do ambiente de hardware e software necessários aos

desenvolvedores. Essa atividade é prevista no Plano de Projeto;
 Criação dos repositórios de desenvolvimento e atribuição de acesso aos desenvolvedores,
conforme previsto no guia operacional de GC;
 Criação de um usuário específico para o projeto que será usado exclusivamente pelo Analista de
GC, para distribuir os produtos homologados pelo cliente.
Produtos de Entrada

 Itens de configuração identificados e planejamento de GC realizado

Produtos de Saída

 Ambiente de Gestão de Configuração Configurado
 Sistema de Gestão de Configuração definido

 Ambiente necessário para a gestão da configuração disponibilizado
Atividade: Criar ou Liberar Baselines
Objetivo
Pág. 95 de 165
Definir um identificador único para um conjunto de especificações ou de produtos de trabalho que

tenham sido formalmente revistos, e que, a partir desse ponto, serve como base para desenvolvimento
ou entrega posterior, só podendo ser modificados por meio de procedimentos de controle de mudança.
Papel

Descrição
Criar ou liberar baselines para uso interno e para entrega ao cliente. Um baseline de software pode ser
um conjunto formado por requisitos, design, arquivos de código fonte e código executável associado,
arquivos de build e documentação de usuário (entidades associadas) ao qual tenha sido atribuído um
identificador único.
Os baselines somente podem ser criados a partir de itens de configuração armazenados no sistema de
gestão de configuração.
Documentar o conjunto de itens de configuração que estão contidos em um baseline.
Tornar prontamente disponível o conjunto atual de baselines.
Produtos de Entrada
 Itens de Configuração
 Itens de Configuração formalmente revistos

Produtos de Saída
 Baseline
 Baseline criado
Atividade: Controlar Itens de Configuração
Objetivo
Manter o controle sobre a configuração do baseline de produtos de trabalho, incluindo o

acompanhamento da configuração de cada item da configuração, a aprovação de uma nova
configuração, se necessário, e a atualização do baseline.
Papel

Descrição
Pág. 96 de 165
Controlar mudanças nos itens de configuração ao longo da vida do produto.
Obter autorização adequada antes de incorporar itens de configuração alterados ao sistema de gestão
de configuração.
Incorporar as mudanças, de maneira que a correção e integridade dos itens de configuração sejam
mantidas.
Realizar revisões para assegurar que as mudanças não causaram efeitos indesejáveis nos baselines.
Registrar as mudanças nos itens de configuração e os motivos das mudanças, conforme apropriado.
Produtos de Entrada
 Baseline
 Conjunto de itens de configuração definidos

Produtos de Saída
 Itens de Configuração alterados

 Baseline atualizado
 Itens de configuração controlados conforme Plano de Gestão de Configuração
Atividade: Estabelecer Registros de Gestão de Configuração
Objetivo
Estabelecer e manter registros que descrevem os itens de configuração, permitindo que o conteúdo e o
status de cada item de configuração seja conhecido e que versões anteriores possam ser recuperadas.
Papel

Descrição
Registrar ações de gestão de configuração com nível suficiente de detalhe, de forma que o conteúdo e
o status de cada item de configuração seja conhecido e que versões anteriores possam ser recuperadas.
Assegurar que as partes interessadas relevantes tenham acesso ao status dos itens de configuração e
conhecimento dele.
Identificar a versão dos itens de configuração que constituem um baseline específico.
Pág. 97 de 165
Descrever as diferenças entre baselines sucessivos e especificar a última versão dos baselines.
Atualizar o status e o histórico (isto é, mudanças e outras ações) de cada item de configuração, conforme
necessário.
Produtos de Entrada
 Baseline
 Conjunto de itens de configuração (baseline)

Produtos de Saída
 Itens de Configuração alterados

 Baseline atualizado
 Atualização do status e do histórico de cada item de configuração, conforme necessário
Atividade: Realizar Auditorias de Configuração
Objetivo
Conduzir auditoria funcional, assegurando que o baseline cumpre o que foi especificado, além de
auditoria física, assegurando que o baseline é completo, contém todos os itens de configuração
especificados.
Papel
 Auditor de Gestão de Configuração

Descrição
Confirmar se baselines e documentações resultantes estão de acordo com o padrão ou requisito

especificado.
Avaliar a integridade dos baselines.
Confirmar se os registros de gestão de configuração identificam corretamente os itens de configuração.
Revisar e confirmar a estrutura, a integridade, a completude e correção dos itens no sistema de gestão
de configuração.
Confirmar a conformidade com padrões e procedimentos aplicáveis de gestão de configuração e

definidos no Plano de Gestão de Configuração.
Pág. 98 de 165
As informações obtidas nas auditorias são registradas no Registro de Auditoria de Baseline e

comunicadas ao Gerente de Projetos.
O Auditor de Gestão de Configuração acompanha os itens de ação da auditoria, documentados no

Registro de Auditoria de Baseline, até sua conclusão. O Gerente de Projetos acompanha as ações
corretivas.
Produtos de Entrada
 Baselines
 Data de auditoria registrada no Cronograma do Projeto

Produtos de Saída
 Registro de Auditoria de Baseline

 Comunicação dos resultados da auditoria
4.3.8 Monitoramento e Controle do Projeto (MCP)
O objetivo do processo Monitoramento e Controle de Projeto (MCP) é acompanhar, analisar e

organizar o progresso e o desempenho do projeto, identificando possíveis problemas que
possam afetar a execução do projeto, bem como tomar ações preventivas e corretivas para
garantir o cumprimento dos objetivos. Inclui-se, ainda, o monitoramento e controle dos riscos,
a coleta dos dados, a análise e a interpretação dos dados resultantes das medições. O fluxo de
trabalho deste processo está ilustrado na Figura 11.
Pág. 99 de 165
Figura 11. Fluxo do processo Monitoramento e Controle do Projeto (MCP)
Pág. 100 de 165

As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Monitoramento e Controle

do Projeto (MCP) podem ser verificadas em ITQ_PS_MonitoramentoControleProjeto. O
detalhamento das atividades definidas para este processo está descrito nos quadros a seguir.
Atividade: Monitorar e Controlar o Trabalho do Projeto
Objetivo
Analisar e registrar o progresso do projeto, identificando possíveis desvios em relação ao que foi
planejado e permitindo que as partes interessadas entendam a situação atual do projeto. Nos casos de
desvios em relação ao planejado, deve-se iniciar o controle de mudanças.
Papel
Descrição
Orientar e gerenciar o trabalho do projeto é o processo de liderança e realização do trabalho definido no

plano de projeto e implementação das mudanças aprovadas para atingir os objetivos do mesmo.
O monitoramento é um aspecto do gerenciamento executado do início ao término do projeto. A maior

parte do trabalho de monitoramento se baseia na análise de variação entre os resultados coletados e as
linhas de base do projeto.
Também faz parte do monitoramento garantir que todos os envolvidos tenham a correta percepção da
situação do projeto e os passos tomados pelo gerente.
Desta atividade podem ser identificadas mudanças nas linhas de base do projeto, seja oriundo do cliente,
como também da identificação de desvios significativos do planejamento.
Produtos de Entrada

 Linha de Base do Cronograma
 Linha de Base de Custos
 Linha de Base do Escopo
 Documento de Solicitação de Mudança
 O planejamento do projeto deve estar aprovado

Produtos de Saída
Pág. 101 de 165

 Mudanças identificadas
 Documentos do Projeto atualizados
 Atualizações nos ativos de processos organizacionais
 Não se aplica
Atividade: Controlar o Cronograma
Objetivo
Monitorar o andamento das atividades do projeto, atualizando o seu progresso e gerenciando as

mudanças na linha de base do cronograma.
Papel
 Equipe Técnica
Descrição
Após a aprovação do cronograma, o gerente de projetos deve proceder com sua atualização
periodicamente, a fim de determinar a situação do projeto e identificar desvios da linha de base antes
que eles afetem os marcos do projeto.
A atualização deve ser realizada tanto das atividades executadas pela equipe do projeto, como a
atualização das subcontratações, quando existirem. A equipe do projeto pode reportar suas atividades
formal ou informalmente, de acordo com os critérios definidos na Tabela de Eventos de Comunicação do
Plano de Projeto.
As atualizações do cronograma deverão compor o Relatório de Acompanhamento do Projeto, que é uma

das ferramentas de comunicação da situação do projeto para as partes interessadas.
Desvios significativos da linha de base devem ser tratados como mudança, através do subprocesso
Controlar Mudanças.
Produtos de Entrada

 Não se aplica
Produtos de Saída
Pág. 102 de 165

 Cronograma do Projeto atualizado

 Informações de Andamento do Cronograma (como parte do Relatório de Acompanhamento do
Projeto)
 Mudanças Identificadas
 Atualizações dos documentos do projeto
 Cronograma atualizado
Atividade: Controlar os Custos
Objetivo
Monitorar a execução do orçamento do projeto, comparando os custos de cada item da solução com o
planejado.
Papel
Descrição
De posse da linha de base de custos do projeto, deve ser realizado o monitoramento dos desembolsos
do projeto, verificando se há variação do planejamento, e se os recursos previstos serão suficientes para
abarcar eventuais mudanças que estejam ocorrendo no projeto.
Os custos necessitam de monitoramento periódico a fim de que as ações sejam tomadas antes do estouro
do orçamento. Neste caso, os desvios do planejamento devem ser tratados como mudança, através do
subprocesso Controlar Mudanças.
Produtos de Entrada

 Dados Financeiros do Projeto
 Não se aplica
Produtos de Saída
 Documentos do Projeto atualizados

 Atualizações nos Ativos de Processos Organizacionais
Pág. 103 de 165

 Custos atualizados
Atividade: Controlar os Riscos
Objetivo
Acompanhar os riscos identificados, executando as ações previstas para mitigar, eliminar, transferir ou
aceitar os riscos, de acordo com a necessidade.
Papel
 Equipe Técnica
Descrição
O principal benefício desse processo é a melhoria do grau de eficiência da abordagem dos riscos no
decorrer de todo o ciclo de vida do projeto a fim de otimizar continuamente as respostas aos riscos.
As respostas planejadas aos riscos que estão incluídas na planilha de riscos são executadas durante o
ciclo de vida do projeto, mas o trabalho do projeto deve ser continuamente monitorado em busca de
riscos novos, modificados e desatualizados.
Também é necessário verificar se:
• As premissas do projeto ainda são válidas,
• A análise mostra um risco avaliado que foi modificado ou que pode ser desativado,
• O plano de gerenciamento dos riscos está sendo seguido, e
• As reservas para contingências de custo ou cronograma devem ser modificadas de acordo com a
avaliação atual dos riscos.
Durante o monitoramento dos riscos, podem ser identificadas necessidades de mudanças no

planejamento do projeto, que são tratadas com mudança, pelo subprocesso Controlar Mudança.
Produtos de Entrada

 Não se aplica
Produtos de Saída
Pág. 104 de 165

 Planilha de Riscos atualizada

 Informações de Monitoramento dos Riscos (como parte do Relatório de Acompanhamento do
Projeto)
 Riscos do projeto atualizados
Atividade: Gerar Informações de Comunicação
Objetivo
Consolidar as informações de monitoramento e controle do projeto, garantindo a produção dos

instrumentos de comunicação previstos no Plano de Projeto.
Papel
Descrição
Criar, coletar, distribuir, armazenar e recuperar as informações do projeto, possibilitando o fluxo de

comunicação eficiente e eficaz entre as partes interessadas do projeto.
Todos os instrumentos de comunicação definidos no Plano de Projeto precisam ser elaborados para
efetuar as comunicações às partes interessadas.
O principal instrumento é o Relatório de Acompanhamento do Projeto. Ele consolida as informações de

monitoramento dos custos, cronograma e riscos do projeto.
Os demais instrumentos devem ser elaborados de acordo com as periodicidades definidas no Plano de
Projeto.
As informações de desempenho do projeto podem ser apoiadas pelo Guia Operacional PS-
MCTIC_GO_IndicadoresDesempenhoProjeto.
Produtos de Entrada

 Informações de Andamento do Cronograma
 Informações de Andamento dos Custos
 Informações de Monitoramento dos Riscos
 Monitoramento de riscos atualizado

 Cronograma atualizado
Pág. 105 de 165

 Custos atualizados
Produtos de Saída
 Relatório de Acompanhamento do Projeto

 Relatórios de Comunicação (conforme definido no Plano de Projeto)
 Relatórios produzidos
Atividade: Controlar a Qualidade
Objetivo
Monitorar e registrar os resultados da execução das atividades de qualidade, auxiliando na identificação

da baixa qualidade do processo ou do projeto e na avaliação da conformidade das entregas do projeto
com os requisitos das partes interessadas.
Papel
Descrição
A fim de garantir a qualidade dos produtos resultantes do projeto, deve-se garantir a execução das
atividades de qualidade previstas no Plano de Gerenciamento da Qualidade.
As entregas do projeto devem ter as atividades de garantia de qualidade executada, com o objetivo de
analisar sua conformidade com os padrões definidos. Estas atividades podem incluir o uso de Listas de
Verificação, e os resultados desta análise compõem o Relatório de Controle de Qualidade.
Este relatório fornece informações gerais sobre a qualidade das entregas, e também podem ser utilizados
para distribuir as informações para as partes interessadas, no que tange à qualidade das entregas.
Produtos de Entrada

 Manual da Qualidade
 Documentos de Solicitação de Mudança aprovados
 Entregas
 Documentos do Projeto
Pág. 106 de 165

 Listas de Verificação produzidas

 Entregas produzidas
Produtos de Saída
 Relatório de Controle da Qualidade

 Verificações de qualidade realizadas
Atividade: Controlar as Medições
Objetivo
Monitorar os resultados da execução das atividades de medição, com objetivo de acompanhar o

desempenho em relação aos planos e objetivos estabelecidos, identificar e tratar questões críticas
relacionadas a processos e fornecer uma base para a incorporação futura de medições em outros
processos.
Papel
 Equipe Técnica
Descrição
Garantir a execução das atividades de medição previstas no Plano de Medições.
A Equipe Técnica deve coletar os dados das medidas, conforme processo especificado e periodicidade
definida.
As medições do projeto devem ter as atividades de análise dos dados executada, com o objetivo de
fornecer subsídios para a tomada de decisão. Os resultados desta análise compõem um relatório das
Medições no Relatório de Acompanhamento do Projeto.
A Equipe Técnica deve analisar, interpretar os dados resultantes da medição e chegar a conclusões
preliminares.
Os resultados das medições fornecem informações gerais para acompanhar o desempenho em relação
aos planos e objetivos estabelecidos, identificar e tratar questões críticas relacionadas a processos e
fornecer uma base para a incorporação futura de medições em outros processos.
Armazenar as informações relacionadas à medição para uso de forma eficiente. Tais informações
também são necessárias para subsidiar a interpretação dos dados, dos critérios de medição e dos
resultados das análises.
Pág. 107 de 165

Informar regularmente as partes interessadas relevantes sobre os resultados das medições.
Produtos de Entrada

 Manual da Medição
 Entregas
 Entregas produzidas
Produtos de Saída
 Medições (como parte do Relatório de Acompanhamento do Projeto)

 Análise e comunicação dos resultados das medições realizadas
Atividade: Controlar o Engajamento das Partes Interessadas
Objetivo
Monitorar os níveis de comprometimento e engajamento das partes interessadas com os objetivos do

projeto, ajustando estratégias e planos conforme a necessidade.
Papel
Descrição
Comunicar e trabalhar com as partes interessadas para atender às suas necessidades/expectativas,

promovendo o comprometimento e engajamento com os objetivos do projeto.
O controle do engajamento das partes interessadas consiste em avaliar a percepção das partes
interessadas do projeto e atualizar a Matriz de Interesse e Poder com a situação atualizada.
Durante as ações para manter o comprometimento das partes interessadas, podem ser identificadas
mudanças que devem ser tratadas pelo controle de mudanças.
Produtos de Entrada
Pág. 108 de 165


 Relatórios de Acompanhamento do Projeto
 Não se aplica
Produtos de Saída
 Matriz de Interesse e Poder atualizada

 Informações sobre o engajamento das partes interessadas atualizadas
Atividade: Controlar as Aquisições (IN04 SLTI/MP)
Objetivo
Caso exista contratação externa ao projeto, gerenciar, monitorar e controlar o desempenho dos
fornecedores de acordo com a Instrução Normativa N. 04 do Ministério do Planejamento,
Desenvolvimento e Gestão (MP).
Papel
Descrição
As atividades de gerenciamento, monitoramento e controle dos contratos devem ser conduzidas de

acordo com a IN 04 do MP.
Produtos de Entrada

 Acordos de Nível de Serviço
 Existir contratações de terceiros no projeto

Produtos de Saída
Pág. 109 de 165


 Não se aplica
Atividade: Controlar Mudanças
Objetivo
Identificar, analisar e aprovar as mudanças do projeto.
Papel
 Partes Interessadas
 Equipe Técnica
Descrição
Este subprocesso é responsável pelo tratamento de todas as mudanças na linha de base do projeto. A
sua descrição detalhada é apresentada na Seção 4.3.10.
Produtos de Entrada
 Não se aplica
 Relatório de Controle de Mudança
Produtos de Saída

 Não se aplica
Pág. 110 de 165

Atividade: Validar Entregas do Projeto
Objetivo
Formalizar o aceite das entregas concluídas do projeto.
Papel
Descrição
Esta atividade visa garantir que as entregas da fase/iteração/etapa tenham sido devidamente revisadas
pelas partes interessadas e que elas estão de acordo com as suas expectativas.
Para uma entrega ser considerada validada, é necessário emitir um Termo de Aceite, devidamente
assinado pelas partes interessadas.
Produtos de Entrada

 Documentos de Aquisição
 Entregas realizadas
Produtos de Saída
 Entrega Validada
 Termo de Aceite
 Entregas validadas formalmente
Atividade: Encerrar Fase/Iteração
Objetivo
Finalizar uma iteração ou fase do projeto, comparando os objetivos alcançados aos definidos
originalmente, promovendo possíveis ajustes no escopo das fases/iterações subsequentes, caso
necessário.
Papel
Pág. 111 de 165

Descrição
Ao término de uma fase, iteração ou etapa do projeto, é necessário verificar se os objetivos previstos
para esta etapa tenham sido atingidos. Para isso é necessário revisar a linha de base do escopo a fim de
identificar se o escopo foi todo cumprido.
Na ocorrência de não terem sido atingidos todos os objetivos, ou não ter sido cumprido parte do escopo,
é possível que a etapa seja encerrada e o escopo restante seja incluído nas fases/iterações subsequentes.
Para isto será necessário realizar o processo de Controlar Mudanças.
A avaliação da fase/iteração quanto ao cumprimento dos seus objetivos deverá ser registrada na
Avaliação de Fase/Iteração.
Caso esta seja a última fase/iteração, será necessário executar a atividade Encerrar Projeto.
Produtos de Entrada
 Entregas Validadas
 Entregas validadas
Produtos de Saída
 Avaliação de Fase ou Iteração

 Mudanças no Planejamento das Fases/Iterações
 Fase/Iteração encerrada formalmente
Atividade: Encerrar Aquisições (IN04 SLTI/MP)
Objetivo
Caso exista contratação externa ao projeto, executar os procedimentos de fechamento das etapas
contratuais, de acordo com a Instrução Normativa N. 04 do Ministério do Planejamento,
Desenvolvimento e Gestão (MP).
Papel
Descrição
Pág. 112 de 165

Nos casos de contratação de terceiros, os procedimentos de finalização do contrato e outros

procedimentos devem ser executados, conforme previsto na IN04 do MP.
Produtos de Entrada
 Entregas Validadas
 Documentos de Contratação da IN04
 Existir contratação de terceiros no projeto

Produtos de Saída

 Não se aplica
Atividade: Realizar a Contagem de PF Detalhada
Objetivo
Realizar a contagem de pontos de função detalhada do projeto.
Papel
 Analista de Métrica
Descrição
Realizar e documentar a contagem detalhada do projeto, conforme produto desenvolvido e demais

documentação do projeto.
Produtos de Entrada

 Modelo de Dados
Pág. 113 de 165


 Produto
 Contagem estimada realizada no início do projeto

 Requisitos implementados
Produtos de Saída
 Contagem Detalhada
 Resultado da contagem em pontos de função detalhada documentada
Atividade: Encerrar Projeto
Objetivo
Registrar formalmente o encerramento do projeto e liberar os recursos alocados no projeto.
Papel
 Patrocinador do Projeto
Descrição
Ao término de todas as fases do projeto, o projeto deverá ser encerrado formalmente. É necessário
revisar todas as revisões prévias de encerramento de fases, verificar se todos os Termos de Aceite foram
emitidos e que todos os objetivos para o projeto tenham sido cumpridos.
Faz parte do encerramento do projeto garantir que as atividades para transferir os produtos, serviços ou
resultados do projeto para a produção e/ou operação continuada.
O registro formal do encerramento do projeto é o Termo de Encerramento do Projeto.
Produtos de Entrada

 Termos de Aceite
 Todas as fases do projeto concluídas
Pág. 114 de 165

Produtos de Saída
 Termo de Encerramento do Projeto (TEP)

 Projeto formalmente encerrado
Atividade: Documentar Lições Aprendidas
Objetivo
Documentar as lições aprendidas do projeto, de forma a compor uma base de conhecimento que pode
ser utilizada para projetos futuros.
Papel
 Equipe Técnica
Descrição
Após o encerramento do projeto, deve-se verificar os registros de monitoramento do projeto, incluindo

o cronograma, os Relatório de Acompanhamento do Projeto, os Relatórios de Controle de Mudança e a
Planilha de Riscos, a fim de identificar informações relevantes que podem ser utilizados em projetos
futuros.
Estas informações comporão o documento organizacional Planilha de Lições Aprendidas e incluem, mas
não se limitam a:
 Riscos ocorridos e planos de respostas, que podem ser utilizados na identificação de riscos de
projetos similares;
 Técnicas gerenciais e gestão de conflitos que deram certo;
Causas das mudanças ocorridas e o tratamento dado a elas.
Para mais informações sobre as lições aprendidas, consulte o Guia Operacional PS-
MCTIC_GO_LicoesAprendidas.
Produtos de Entrada

 Relatórios de Controle de Mudança
Pág. 115 de 165

 Encerramento formal do projeto

Produtos de Saída

 Lições aprendidas documentadas
4.3.9 Garantia da Qualidade de Processo e Produto (GQ)
O objetivo do processo Garantia da Qualidade de Processo e Produto (GQ) é fornecer visibilidade

para a equipe e gerência sobre os processos e produtos de trabalho associados. O fluxo de
trabalho deste processo está ilustrado na Figura 12.
Figura 12. Fluxo do processo Garantia da Qualidade de Processo e Produto (GQ)
As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Garantia da Qualidade de

Processo e Produto (GQ) podem ser verificadas em
ITQ_PS_GarantiaQualidadeProcessoProduto. O detalhamento das atividades definidas para
este processo está descrito nos quadros a seguir.
Atividade: Avaliar Objetivamente os Processos
Objetivo
Avaliar objetivamente os processos selecionados em relação às descrições de processo, padrões e

procedimentos aplicáveis.
Papel
 Analista de Qualidade
Descrição
Pág. 116 de 165

Estabelecer e manter critérios claramente definidos para as avaliações. Deve-se fornecer critérios,
baseados nas necessidades do negócio, tais como: o que será avaliado; quando ou com que frequência
um processo será avaliado; como a avaliação será conduzida; quem precisa ser envolvido na avaliação.
Utilizar critérios definidos para avaliar a aderência dos processos executados em relação à descrição dos
processos, padrões e procedimentos.
Identificar as não conformidades encontradas durante a avaliação.
Identificar as lições aprendidas que possam ser utilizadas na melhoria de processos para produtos e
serviços futuros.
Deve-se promover um ambiente que estimule os envolvidos a participarem na identificação e relato de

questões críticas relacionadas à qualidade.
Produtos de Entrada
 Artefatos do Processo
 Evidências da Execução do Processo
 A garantia da qualidade deve ser iniciada nas fases iniciais do projeto com a finalidade de estabelecer
planos, processos, padrões e procedimentos que irão agregar valor ao projeto e satisfazer a seus
requisitos e às políticas organizacionais
Produtos de Saída
 Plano de Melhoria de Processos

 Relatório de Desvios e Oportunidades de Melhoria
 Não conformidades identificadas
Atividade: Avaliar Objetivamente Produtos de Trabalho e Serviços
Objetivo
Avaliar objetivamente os produtos de trabalho e serviços escolhidos com relação à descrição do

processo, padrões e procedimentos aplicáveis.
Papel
Descrição
Pág. 117 de 165

Selecionar produtos de trabalho a serem avaliados de acordo com critérios de amostragem

documentados, caso seja utilizada amostragem.
Estabelecer e manter critérios claramente definidos para as avaliações de produtos de trabalho. Devem-
se fornecer critérios, baseados nas necessidades do negócio, tais como: o que será avaliado; quando ou
com que frequência um processo será avaliado; como a avaliação será conduzida; quem precisa ser
envolvido na avaliação.
Utilizar os critérios definidos durante as avaliações de produtos de trabalho.
Avaliar produtos de trabalho antes que sejam entregues às partes interessadas e em marcos definidos
ao logo do seu desenvolvimento. Realizar, também, avaliações intermediárias ou incrementais de
produtos de trabalho e serviços em relação às descrições de processo, padrões e procedimentos.
Identificar não conformidades encontradas durante as avaliações.
Identificar lições aprendidas que possam ser utilizadas na melhoria de processos para produtos e
serviços futuros.
Produtos de Entrada
 Produtos de Trabalho e Serviços

 Evidências do Preenchimento dos Produtos
 Produtos de trabalho a serem avaliados de acordo com critérios definidos

Produtos de Saída

 Identificação das não conformidades encontradas durante as avaliações

 Identificação das lições aprendidas que possam ser utilizadas na melhoria de processos para
produtos e serviços futuros
Atividade: Comunicar e Assegurar a Solução de Não Conformidades
Objetivo
Comunicar as questões críticas relativas à qualidade e assegurar a solução de não conformidades com a
equipe e com o Gerente de Projetos.
Papel
Pág. 118 de 165

Descrição
Não conformidades são questões críticas identificadas durante as avaliações que refletem uma falta de
aderência a padrões, descrição dos processos ou procedimentos aplicáveis. A situação de uma não
conformidade fornece um indicador de tendência da qualidade.
Resolver cada não conformidade com os membros apropriados da equipe, sempre que possível. As não
conformidades que não puderem ser resolvidas no projeto devem ser documentadas.
Analisar as não conformidades para ver se existe alguma tendência em relação à qualidade que possa
ser identificada e tratada.
Assegurar que as partes interessadas relevantes sejam informadas em tempo hábil sobre os resultados
das avaliações e das tendências em relação à qualidade.
Revisar periodicamente as não conformidades abertas e suas tendências com o gerente designado para
recebê-las e tratá-las.
Monitorar as não conformidades até a sua solução.
Produtos de Entrada

 Lista de Ocorrências
 Registro de Auditoria de Baseline
 Não conformidades identificadas

Produtos de Saída
 Relatório de Acompanhamento de Desvios

 Partes interessadas relevantes informadas em tempo hábil sobre os resultados das avaliações e das
tendências em relação à qualidade
Atividade: Estabelecer Registros
Objetivo
Pág. 119 de 165

Estabelecer e manter registros das atividades de garantia da qualidade.
Papel
Descrição
Registrar as atividades de garantia da qualidade de processo e produto com nível de detalhe suficiente
para que tanto o status quanto os resultados sejam conhecidos.
Atualizar o status e o histórico das atividades de garantia da qualidade quando necessário.
Produtos de Entrada
 Relatórios de Desvios e Oportunidades de Melhoria

 Plano de Melhoria de Processos
 Atividades planejadas de garantia da qualidade executadas

Produtos de Saída
 Relatório de Acompanhamento de Desvios

 Status e histórico das atividades de garantia da qualidade atualizados
4.3.10 Controlar Mudanças
O subprocesso Controlar Mudanças faz parte do processo descrito na Seção 4.3.8

Monitoramento e Controle do Projeto (MCP). O seu objetivo é descrever as atividades
necessárias para a identificação, análise de impacto e aprovação das mudanças no projeto. O
fluxo de trabalho deste subprocesso está ilustrado na Figura 13.
Pág. 120 de 165

Figura 13. Subprocesso Controlar Mudanças
Normalmente as mudanças são identificadas durante o processo de monitoramento e controle

do projeto, mas elas podem surgir a qualquer momento do projeto. É fundamental que toda
mudança seja analisada quanto ao seu impacto e aprovada antes de sua implementação.
As Instruções de Trabalho e Qualidade (ITQ) do subprocesso Controlar Mudanças podem ser

verificadas em ITQ_PS_ControlarMudancas. O detalhamento das atividades definidas para este
subprocesso está descrito nos quadros a seguir.
Atividade: Identificar e Solicitar Mudança no Projeto
Objetivo
Identificar e formalizar as alterações motivadas pelas necessidades de mudanças nas restrições de

escopo, prazo e custo do projeto.
Papel
 Equipe Técnica
Descrição
Pág. 121 de 165

Durante o curso do projeto, as necessidades e expectativas das partes interessadas podem mudar e
alterar o planejamento do projeto. Sempre que forem identificadas quaisquer necessidades de mudança
no projeto, é necessário formalizá-las em um Documento de Solicitação de Mudança.
Este documento deverá conter com detalhes toda a mudança, incluindo a sua origem e urgência para
atendimento. Nenhuma mudança pode ser incorporada ao projeto antes da devida Análise de Impacto e
aprovação.
Apesar da maior parte das mudanças serem oriundas das partes interessadas (cliente), podem surgir
mudanças oriundas do Monitoramento e Controle do projeto, quando são identificados desvios do
planejamento.
Produtos de Entrada

 Mudanças identificadas
 Lista de Verificação – Documento de Solicitação de Mudança
 Mudança identificada
Produtos de Saída

 Mudança formalizada
Atividade: Realizar Análise de Impacto da Mudança
Objetivo
Detalhar a mudança, descrevendo os seus impactos nas outras restrições do projeto de forma qualitativa,
a fim possibilitar a avaliação pelas partes interessadas.
Papel
 Equipe Técnica
Descrição
Pág. 122 de 165

Após identificada a mudança, a equipe do projeto, juntamente com o gerente, deve analisar todos os
aspectos da mudança, a fim de identificar os impactos de sua inclusão.
Devem ser analisados os impactos sobre todas as restrições do projeto (escopo, prazo, custo e qualidade)
e o quanto eles mudam a linha de base do projeto.
Podem ser incluídas informações auxiliares que permitam um entendimento melhor da demanda pelas
partes interessadas, tais como diagramas e cronogramas propostos.
O registro da análise de impacto é realizado no Relatório de Controle de Mudança. Este relatório deve
ser apresentado às partes interessadas para apreciação.
Produtos de Entrada

 Lista de Verificação – Relatório de Controle de Mudança
 Mudança descrita
Produtos de Saída

 Análise de impacto realizada
Atividade: Aprovar Mudança
Objetivo
Apresentar a análise do impacto da mudança para as partes interessadas, a fim de obter a sua aprovação
ou não. Deve-se verificar e obter todos os níveis de aprovação necessários de acordo com escopo e
tamanho do impacto da mudança.
Papel
Pág. 123 de 165

Descrição
O Relatório de Controle de Mudança deverá ser levado para todas as partes interessadas para avaliação
e aprovação. O Registro das Partes Interessadas deve ser consultado a fim de verificar se todas as partes
interessadas pertinentes foram envolvidas. Algumas mudanças precisam ser levadas para instâncias
superiores para aprovação.
O registro do resultado desta aprovação ou reprovação deve atualizar o Relatório de Controle de

Mudança.
Produtos de Entrada

 Análise de impacto realizada

Produtos de Saída
 Relatório de Controle de Mudança atualizado

 Resultado da aprovação registrado
Atividade: Informar às Partes Interessadas sobre a Mudança
Objetivo
Informar às partes interessadas do projeto sobre a aprovação ou reprovação da mudança,

principalmente àquelas que não participaram do processo de decisão.
Papel
 Equipe Técnica
Descrição
Após a aprovação ou reprovação de uma mudança, todas as partes interessadas precisam ser informadas.
Nem todas as partes interessadas estão envolvidas no processo de aprovação, mas todas precisam saber
das mudanças.
Caso a mudança tenha sido aprovada, o processo de Planejamento deve ser efetuado novamente,
aplicando-se as mudanças e gerando uma nova linha de base.
Pág. 124 de 165

Produtos de Entrada

 Mudança avaliada pelas partes interessadas

Produtos de Saída
 Comunicação realizada
 Comunicação realizada
4.3.11 Desenvolvimento de Serviço
O objetivo do processo Desenvolvimento de Serviço (DS) é desenvolver peças de negócio

reutilizáveis, especificadas separadamente, catalogadas e disponibilizadas de forma global. O
fluxo de trabalho deste processo está ilustrado na Figura 124.
Figura 14. Fluxo do processo Desenvolvimento de Serviço (DS)
Pág. 125 de 165

O detalhamento das atividades definidas para este processo está descrito nos quadros a seguir.
Atividade: Implementar serviço
Objetivo
Produzir o produto de workflow seguindo o BPM para complementar o processo.
Papel
 Desenvolvedor
Descrição
O desenvolvedor pode implementar funcionalidades internas do serviço que complementam o processo

de negócio, utilizando as tecnologias e linguagens inerentes à arquitetura e padrões dos sistemas
envolvidos, assim como as rotinas de testes unitário, funcional e/ou aceitação.
Exemplo: Código Java/XML que reproduza o comportamento do fluxo em JBPM, quando aplicado.
Produtos de Entrada
 Documento de Visão;
 Documento de Arquitetura;
 Guia de Implementação;
 Caso Uso;
 Documento de regra de negócio;
 Especificação de Negócio.
 N/A
Produtos de Saída
 Código-fonte;
 Nota de release.
 N/A
Pág. 126 de 165

4.3.12 Analisar Serviço (AS)
O subprocesso Analisar Serviço (AS) integra o processo descrito na Seção 4.3.811 Desenvolvimento de Serviço (DS). Tem por objetivo analisar os processos de
negócio e os requisitos de software para identificar e categorizar os serviços de acordo com o tipo de lógica encapsulada, da extensão do potencial de reuso
que a lógica possui e de como essa lógica de serviço se relaciona com os domínios existentes, conceituando os serviços e suas capacidades antes de sua
definição e desenvolvimentos físicos reais. O fluxo de trabalho deste subprocesso está ilustrado na Figura 135.
Figura 15. Subprocesso Analisar Serviço (AS)
Pág. 127 de 165

O detalhamento das atividades definidas para este subprocesso está descrito nos quadros a
seguir.
Atividade: Identificar sistemas afetados
Objetivo
Definir a fronteira e todos os sistemas que interagem com o processo.
Papel
 Analista de Serviço.
Descrição
A partir da análise do processo de negócio redesenhado (TO BE) ou dos requisitos levantados, o analista
de serviço deve levantar os sistemas:
 Que estão sendo desenvolvidos;

 Integrados;
 Legados, cujas informações são utilizadas;
 Integrados para satisfazer requisitos não funcionais.
Neste momento a atividade de Manter Rastreabilidade de Serviço do processo Realizar Governança de

Serviço poderá ser acionada, a fim de manter atualizada todas as dependências dos serviços.
Produtos de Entrada
 Especificação de negócio; e
 Serviços candidatos.
 N/A
Produtos de Saída
 Lista de sistemas afetados.

 N/A
Atividade: Identificar serviços candidatos
Pág. 128 de 165

Objetivo
Avaliar se os requisitos levantados devem ser implementados em forma de serviço.
Papel
Descrição
Caso o processo execute um fluxo independente, reutilizável e passível de ser aplicado em outros
sistemas ou processos sem afetar a estrutura dos mesmos, este serviço pode ser incluído no catálogo de
serviços como um serviço candidato.
A análise realizada deve levar em consideração, apenas o ponto de vista de negócio, e não a lógica de
serviços para atender finalidades técnicas. A etapa de avaliação técnica só é possível na etapa de projetar
serviço.
Caso não seja um serviço candidato, este será desenvolvido seguindo processo de software tradicional.
Neste momento as atividades Manter Rastreabilidade de Serviço e Catalogar Serviço do processo Realizar
Governança de Serviço poderão ser acionadas.
Produtos de Entrada
 Especificação de negócio; e
 Artefatos de requisitos.
 N/A
Produtos de Saída
 Inclusão no catálogo de serviço e serviços candidatos.

 N/A
Atividade: Identificar lógica específica do processo
Objetivo
O objetivo dessa atividade é identificar as regras de negócio e ordem de execução das atividades internas.
Papel
Pág. 129 de 165

Descrição
O analista de serviço deve identificar o fluxo interno de execução do serviço conforme a execução do
caso de uso, dos requisitos de negócio e dos requisitos de integração apresentados no documento de
visão. Deve-se elaborar um diagrama de processo em notação BPMN contendo todas as atividades do
serviço interligadas de acordo com as regras de negócio e ordem de execução do caso de uso. Todos os
subfluxos e fluxos alternativos do caso de uso devem ser representados no diagrama.
Produtos de Entrada
 Especificação de negócio;
 Caso de uso; e
 Modelo de dados.
 N/A
Produtos de Saída
 Diagrama do serviço.
 N/A
Atividade: Identificar serviços de entidade
Objetivo
Identificar serviço global de base, que não necessariamente representa uma solução para um requisito
de negócio.
Papel
Descrição
O analista de serviço realiza a análise do caso de uso e do modelo de dados com o objetivo de identificar
serviços de entidade. Caso o serviço defina uma representação global e estrutural da instituição ou setor,
este deve ser categorizado como serviço entidade. (Exemplo: entidade de CEP, cidade, departamentos).
Levando como base os serviços de entidade identificados, o analista de serviço identifica os recursos. Por
exemplo, um serviço de entidade denominado Usuário poderá ter os seguintes recursos (nome,
endereço, telefone, CPF).
Pág. 130 de 165

Produtos de Entrada
 Especificação de negócio;
 Caso de uso; e
 Modelo de dados.
 N/A
Produtos de Saída
 Serviços de entidade e recursos.

 N/A
Atividade: Associar capacidades dos serviços com os recursos e métodos
Objetivo
Definir todas as possíveis operações aplicadas nos dados da entidade.
Papel
Descrição
O analista de serviço deve associar todas as capacidades do serviço com os recursos existentes, tais como,
recursos REST e conectividade externa. Para cada capacidade deve ser identificada a origem do recurso,
o protocolo do recurso, o método de execução e qual a respectiva operação deve ser associada a
capacidade em análise.
Produtos de Entrada
 Caso de uso;
 Modelo de dados,
 Diagrama do processo,
 Lista dos contratos existentes na ferramenta de governança; e
 Lista de recursos.
 N/A
Pág. 131 de 165

Produtos de Saída
 Tabela de associação.
 N/A
Atividade: Identificar serviços utilitários
Objetivo
Identificar serviços de natureza genérica e reutilizáveis, não relacionados a regras de negócio ou

entidades.
Papel
Descrição
O analista de serviço deve identificar os serviços que não atendem ao requisito de negócio do processo,
porém representam uma necessidade genérica, tal como Horário Corrente, Conversão de Moeda, etc.
Estes serviços serão considerados utilitários.
Produtos de Entrada
 Caso de uso;
 Modelo de dados; e
 Diagrama do Processo.
 N/A
Produtos de Saída
 Serviços utilitários.
 N/A
Atividade: Consolidar modelagem
Pág. 132 de 165

Objetivo
Levantar todos os recursos, operações, serviços, diagramas, documentações e especificações necessários

para a criação dos serviços
Papel
Descrição
O Analista de Serviço revisa e consolida no Documento de modelagem de serviços, todos os artefatos

gerados com o objetivo de ter os recursos e capacidades bem definidos para os serviços de entidade,
utilitários e compostos.
Produtos de Entrada
 Artefatos da análise do serviço.

 N/A
Produtos de Saída
 Modelo de serviço; e
 N/A
4.3.13 Projetar Serviço (PS)
O subprocesso Projetar Serviço (PS) compõe o processo descrito na Seção 4.3.811

Desenvolvimento de Serviço (DS). O objetivo deste serviço é adequar a arquitetura de serviços,
conforme os requisitos não-funcionais, bem como desenvolver os contratos de serviço
conforme os requisitos funcionais. O fluxo de trabalho deste subprocesso está ilustrado na
Figura 136.
Pág. 133 de 165

Figura 16. Subprocesso Projetar Serviço (PS)
Pág. 134 de 165

seguir.
Atividade: Analisar requisitos
Objetivo
Identificar o impacto na arquitetura.
Papel
 Arquiteto
Descrição
O analista de serviço deve detalhar todas as informações necessárias para a composição da estrutura de
dados do serviço, destacando os dados de entrada, saída, comportamentos e mudança de estado do
sistema. Também deve ser verificado se todos os requisitos de entrada estão com informações
suficientes para implementação e decomposição do serviço em menor granularidade. Feita esta
verificação deve ser criado um diagrama BPMN do processo utilizando a mesma granularidade, pois o
mesmo será utilizado como referência nas ferramentas de desenvolvimento e implementação do
processo. Exemplo WSO2 Developer Studio.
O analista de serviço em conjunto com o arquiteto avalia os requisitos não funcionais e os recursos
disponibilizados pela arquitetura, a fim de identificar possíveis alterações na arquitetura.
Produtos de Entrada
 Documento de Visão;
 Casos de Uso;
 Processo de Negócio.
 N/A
Produtos de Saída
 Diagrama do serviço;
 Decisão de alteração da arquitetura.
 N/A
Pág. 135 de 165

Atividade: Alterar arquitetura
Objetivo
Garantir que a arquitetura do sistema atende aos requisitos não funcionais.
Papel
 Arquiteto
Descrição
O arquiteto responsável pela atividade deve alterar a arquitetura com o escopo de atender aos requisitos
funcionais do processo.
As alterações devem ser devidamente registradas e versionadas na arquitetura. O código da arquitetura

versionado no GitLab(repositório de código-fonte) e binários disponibilizados no nexus(repositório de
bibliotecas e dependências).
O arquiteto também deve registrar possíveis impactos caso alguma interface de comunicação seja
modificada.
Produtos de Entrada
 Caso de uso;
 Documento de visão;
 Modelo de dados;
 N/A
Produtos de Saída
 Documento de arquitetura;
 Guia de implementação.
 N/A
Atividade: Efetuar teste integrado da arquitetura
Objetivo
Garantir que as alterações da arquitetura mantiveram todo o sistema íntegro, consistente e estável.
Pág. 136 de 165

Papel
 Arquiteto
Descrição
Testar a arquitetura com a aplicação que a utiliza a mesma para validar se o requisito não funcional
implementado atende sem impactar os requisitos funcionais.
Avaliar também o indicador de confiabilidade, estabilidade e desempenho, refletido diretamente nos

resultados da execução dos testes.
O arquiteto avalia os Registros dos Resultados de Teste frente aos objetivos estabelecidos e verificam se
foram obtidos os resultados esperados, quanto à qualidade e atendimento aos requisitos.
O código fonte que utiliza a arquitetura na nova versão, deve ter seus testes automatizados executados
pelo DevOps (Jenkins, Sonar, JUnit, etc.)
Produtos de Entrada
 Documento de arquitetura;
 Guia de implementação;
 Casos de teste.
 N/A
Produtos de Saída
 Registros dos resultados de teste

 N/A
Atividade: Avaliar possibilidade de utilizar algum serviço do catálogo
Objetivo
Reutilizar serviço existente quando o mesmo for totalmente aderente aos requisitos de negócio.
Papel
 Desenvolvedor
Descrição
O analista de serviço, com base nos requisitos para a formação do contrato, deverá consultar, munido
das informações técnicas, a existência de um contrato com as mesmas características, tanto funcional
Pág. 137 de 165

quanto não funcional. Havendo um contrato igual deve-se avaliar a regra de execução interna, a fim de
reutilizar algum serviço. Caso não exista um contrato com as mesmas características, um novo contrato
será criado. O analista de serviço pode acionar o desenvolvedor para uma validação de contrato de
serviço existente, assim como poderá acionar o arquiteto para validar se o serviço atende aos requisitos
não-funcionais.
Produtos de Entrada
 Caso de uso;
 Documento de visão;
 Modelo de dados;
 N/A
Produtos de Saída
 Possibilidade de utilizar um serviço existente avaliada

 N/A
Atividade: Elaborar contratos de serviços
Objetivo
Criar o contrato formal do serviço.
Papel
 Desenvolvedor
Descrição
Após avaliar a possibilidade de utilizar algum serviço, o desenvolvedor de serviço poderá optar por alterar
um que já exista ou criar um novo contrato.
Para criar o contrato de serviço de entidade, utilitário e composto, utiliza-se a linguagem declarativa
YAML.
Um exemplo: A criação do contrato seguindo a Open API Specification disponível em

http://swagger.io/specification/. Exemplo de ferramenta para criação e elaboração do contrato é o
Swagger Editor.
Pág. 138 de 165

Para cada serviço identificado (entidade, utilitários e compostos) é preciso definir sua dimensão,
descrever o que o serviço faz e padronizar. Com o contrato de serviço é possível traduzir de forma
detalhada as funcionalidades dos serviços especificados. Todo serviço deve ter um contrato formal.
Após a criação do contrato de serviço, o processo de governança deve ser sinalizado para que os serviços
sejam governados.
Neste momento as atividades Versionar Contrato, Catalogar Serviço e Manter Rastreabilidade de Serviço
do processo Realizar Governança de Serviço poderão ser acionadas, bem como a atividade de Manter
Modelo Canônico poderá ser executada, caso o novo contrato provoque alteração no modelo canônico.
Produtos de Entrada
 Contrato de serviços.
 N/A
Produtos de Saída
 Contrato de serviço
 Registro do serviço na ferramenta de governança.
Atividade: Avaliar necessidade de implementação
Objetivo
Identificar no projeto dos serviços as atividades que requerem implementação utilizando linguagens de
programação.
Papel
Descrição
O desenvolvedor ao analisar o projeto de serviço descrito em seu diagrama e contrato, é avaliada a

necessidade de implementação específica aos requisitos do projeto em linguagem de programação.
Exemplo: necessidade de implementações específicas em JBPM, utilizando a linguagem Java com XML.
Produtos de Entrada
 Contrato de Serviço.
Pág. 139 de 165

 N/A
Produtos de Saída
 Necessidade de implementação identificada.

 Diagrama BPMN na ferramenta de desenvolvimento de software utilizada para implementação.
4.3.14 Realizar Governança de Serviço (GS)
O subprocesso Realizar Governança de Serviço (GS) compõe o processo descrito na Seção

4.3.811 Desenvolvimento de Serviço (DS). O objetivo desse processo é governar e dar suporte a
todo o ciclo de vida dos serviços, isto é, pretende-se estimular e medir o reuso de serviços,
garantir o desempenho e estabilidade dos serviços em operação e facilitar a evolução e
manutenção dos serviços existentes. O fluxo de trabalho deste subprocesso está ilustrado na
Figura 137.
Figura 17. Subprocesso Realizar Governança de Serviço (GS)
seguir.
Atividade: Monitorar serviço
Objetivo
Pág. 140 de 165

Gerar métricas que são necessárias para medir o uso dos serviços visando uma manutenção evolutiva
(tais como escalabilidade, confiabilidade e etc.).
Papel
 Administrador de serviço
Descrição
O monitoramento dos serviços é realizado via ferramentas disponíveis no ESB. O Administrador de

serviço deve acompanhar de forma constante e permanente as estatísticas e logs gerados pelo
barramento de serviços. A atividade deve ser realizada acessando o console administrativo, aba de
monitoramento, no caso da utilização do WSO2 ESB, por exemplo.
Produtos de Entrada
 Console Administrativo do ESB.

 N/A
Produtos de Saída
 Relatórios e gráficos estatísticos gerados pela ferramenta.

 N/A
Atividade: Manter rastreabilidade de serviço
Objetivo
Identificar de forma fácil e rápida todos os consumidores de determinado serviço.
Papel
Descrição
Sempre que um serviço for catalogado na ferramenta de governança (Exemplo G-REG WSO2), o
administrador de serviço deve se atentar em cadastrar e manter atualizada todas as dependências dos
serviços (quem consome o serviço e quais serviços são consumidos por ele no caso de serviços
compostos). No caso da utilização do G-REG por exemplo, a visualização das dependências de um serviço
pode ser realizada de duas formas. Uma é via Governance Center - Store e outra via Governance Center -
Publisher.
Pág. 141 de 165

Produtos de Entrada
 Cadastro das dependências do serviço.

 N/A
Produtos de Saída
 Gráfico de Rastreabilidade/Dependências.
 N/A
Atividade: Versionar contrato de serviço
Objetivo
Manter diferentes versões de um mesmo contrato de serviços possibilitando que diferentes versões do
mesmo possam conviver de forma harmônica.
Papel
 Arquiteto
Descrição
Realizar o versionamento do contrato de serviços, podendo ser realizado de duas formas:
 Arquiteto de Serviço realiza o versionamento utilizando o controlador de revisões (SVN/GIT); e ou

 Administrador de Serviço realiza o versionamento utilizando a ferramenta de governança (Exemplo:
G-REG WSO2).
Produtos de Entrada
 Contrato a ser versionado.

 N/A
Produtos de Saída
 Nova versão do contrato criada.

 N/A
Pág. 142 de 165

Atividade: Manter modelo canônico
Objetivo
Manter o modelo canônico sempre atualizado e disponível para ser utilizado na atividade de Design de
um novo serviço ou na evolução dos serviços já existentes.
Papel
 Administrador de serviço/Arquiteto de serviço

Descrição
A construção ou evolução de um contrato de serviços provoca ou pode provocar, inclusão, alteração ou

até mesmo remoção de entidades do canônico, onde o mesmo é representado por meio de um modelo
construído utilizando a linguagem YAML, seguindo os padrões para criação de objetos JSON. A
ferramenta que poderá ser utilizada para a construção é o Swagger Editor. A medida que os contratos
são entregues pelo Arquiteto de Serviços, o Administrador de Serviço é o responsável por sensibilizar as
alterações nesse modelo que estará importado na ferramenta de governança. Exemplo: G-REG.
Produtos de Entrada
 Contratos de Serviço.
 N/A
Produtos de Saída
 Modelo Canônico sensibilizado/atualizado.

 N/A
Atividade: Catalogar e publicar serviço
Objetivo
Manter o catalogo de serviços "público" sempre atualizado e categorizado de forma que seja possível
que um serviço seja descoberto facilmente.
Papel
 Administrador de Serviço
Descrição
Pág. 143 de 165

O analista de serviço classifica, cataloga e publica o serviço na ferramenta de governança. Associa ao seu
contrato, também de preferência, dentro da ferramenta de governança.
Produtos de Entrada
 Serviço a ser catalogado;

 Tela de cadastro de serviço.
 N/A
Produtos de Saída
 Catalogo de serviços atualizado

 N/A
Atividade: Descobrir serviço
Objetivo
Garantir que serviços reutilizáveis sejam realmente reutilizados.
Papel
 Administrador de serviço/Analista de requisitos

Descrição
A forma de descobrir serviços é estar sempre analisando o catálogo de serviços disponibilizado na

ferramenta de governança. Exemplo: G-REG WSO2. Neste caso por meio de pesquisas realizadas no
Governance Publisher Store é possível identificar quais os serviços estão disponíveis para utilização. O
papel de analista de requisitos irá executar essa atividade sempre que estiver levantando os requisitos
de uma aplicação dentro do PS.
Produtos de Entrada
 Parâmetros para a busca do serviço.

 N/A
Produtos de Saída
 Resultado da busca pelo serviço.
Pág. 144 de 165

 N/A
Atividade: Versionar serviço
Objetivo
Manter diferentes versões de um mesmo serviço possibilitando que diferentes versões do mesmo
possam conviver de forma harmônica, visando atender o maior número possível de consumidores.
Papel
Descrição
O administrador de serviço versiona o artefato na ferramenta de governança. Esse versionamento deve

ser realizado após o término do desenvolvimento, teste e implantação de uma nova release para o
serviço. A versão do serviço deve estar, preferencialmente, associada a versão do seu contrato também
dentro da ferramenta.
Produtos de Entrada
 Nova release do serviço.

 N/A
Produtos de Saída
 Nova versão incluída.

 N/A
4.4 Método de Estimativa do Software
No PS-MCTIC as estimativas e contagens de Pontos de Função de software acompanham toda a

vida útil da demanda. No ciclo de vida da demanda, há duas interações entre a disciplina de
Estimativas de Software e os Processos de Desenvolvimento de Software, conforme descrito na
Tabela 2. Aferição do volume no PS-MCTIC.
Pág. 145 de 165

Nome da Grupos de Marcos Faturados Responsável Observações

Estimativa Processo sob a estimativa pela
Estimativa
Contagem Planejamento de “Desenvolvimento, Analista de A mudança de
Estimada Projeto (PP) Homologação e Métricas status da demanda
Testes” de “Requisitos-
Aprovação” para
Contagem Monitoramento e “Implantação em Analista de
“Em
Detalhada Controle do Produção” Métricas
Desenvolvimento”,
Projeto (MCP)
aciona os
contadores de
tempo destas duas
contagens.
Tabela 2. Aferição do volume no PS-MCTIC
Pág. 146 de 165

4.5 Papéis e Responsabilidades
O PS-MCTIC contempla os papéis que executam, cada um, atividades e responsabilidades

específicas no processo de software, conforme descrito na Tabela 3:
Disciplina Papel Descrição

Essa função tem como objetivo
mensurar o tamanho das
funcionalidades por meio de técnica de
análise de ponto de função. Mensurar o
esforço (horas) e a duração de
desenvolvimento de sistemas
Analista de Métrica baseando-se no tamanho dos sistemas
em pontos por função. Coletar e
analisar indicadores de desempenho do
processo de desenvolvimento.
Estudo e definição de novos modelos e
técnicas para medição de projetos de
software.
Conjunto de pessoas responsáveis pela
parte técnica no processo de software,
que pode incluir o responsável pelas
implantações de GCM, atualização de
Gestão de Projetos ambiente, desenvolvedores,
Equipe Técnica
testadores, arquiteto de software,
revisores, entre outros. Dependendo da
etapa que se encontra pode-se ter
Equipe Técnica para cada grupo de
processo.
É a pessoa alocada pela organização
executora para liderar a equipe
responsável por alcançar os objetivos
do projeto. Suas responsabilidades
incluem o planejamento das atividades,
o monitoramento e o controle do
Gerente de Projetos
projeto, a gestão da equipe, a
comunicação com as partes
interessadas, a gestão dos contratos
com fornecedores, a gestão da tripla
restrição de escopo, qualidade e custo,
entre outras.
Pág. 147 de 165

Todas as pessoas ou organizações que

podem ser afetadas pelo projeto e
documentação das informações
Partes Interessadas
relevantes relacionadas aos seus
interesses, envolvimento e impacto no
sucesso do projeto.
Parte interessada responsável por
fornecer os recursos e suporte para o
Patrocinador do Projeto projeto. Ele promove o projeto desde a
sua concepção inicial até o seu
encerramento.
Essa função coordena o design da
interface com o usuário e as interfaces
com os demais sistemas. Isso inclui
Analista de Design reunir os requisitos de utilidade e
executar os protótipos de sugestões de
designs de interface com o usuário para
atender a esses requisitos.
Realiza as atividades pertinentes à
definição e à gerência dos requisitos do
sistema. É responsável pela análise do
problema dos usuários e gestores do
negócio, pela definição das
Requisitos
Analista de Requisitos necessidades dos mesmos, das
características funcionais e não
funcionais do sistema, pela
identificação, organização,
documentação e gerência das
mudanças nos requisitos.
Responsáveis pelas informações que os
requisitos do sistema terão e como os
Fornecedores de mesmos deverão se comportar após a
Requisitos sua implantação, este papel pode ser
representado pelo interessado no
sistema.
Pág. 148 de 165

Responsável por orientar o

desenvolvimento da arquitetura de
software do sistema, que inclui
promoção e criação de suporte para as
principais decisões técnicas que limitam
o produto e a implementação gerais
Arquiteto de Software
para o projeto. Também estabelece a
estrutura geral de cada visão de
arquitetura: a decomposição da visão, o
agrupamento dos elementos e as
interfaces entre esses principais
agrupamentos.
Responsável por desenvolver e testar
componentes de acordo com os
padrões adotados para o projeto, para
fins de integração com subsistemas
maiores. Quando é necessário criar
Desenvolvedor componentes de teste, como drivers ou
Implementação
stubs, para possibilitar a realização dos
testes, o implementador também é
responsável por desenvolver e testar
esses componentes e os subsistemas
correspondentes.
Responsável pela integração dos
componentes na fase de construção do
Integrador software, papel fundamental quando se
trabalha com o processo iterativo e
incremental.
Responsável pela definição de tabelas,
índices, visões, restrições, triggers,
procedimentos armazenados,
Projetista de Banco de parâmetros de armazenamento ou
Dados tablespaces e outras construções
específicas de um banco de dados
necessárias para armazenar, recuperar
e excluir objetos persistentes.
Responsável por identificar e definir os
testes exigidos, monitorar o processo de
Analista de Teste teste em detalhes e os resultados em
cada ciclo de teste e avaliar a qualidade
geral.
Testes
Responsável pela codificação dos scripts
Programador de Teste de teste ao longo do ciclo de vida do
software.
Essa função conduz os testes e registra
Testador
os resultados dos testes.
Pág. 149 de 165

Responsável por disponibilizar o

ambiente e a infraestrutura geral de
Gestão de Configuração (GC) para a
equipe de desenvolvimento do produto.
Oferece suporte à atividade de
desenvolvimento de produtos para que
Analista de Gestão de
os desenvolvedores e integradores
Configuração
tenham espaços de trabalho adequados
Gestão de
para criar e testar seus trabalhos e,
Configuração
dessa forma, permite que todos os
artefatos fiquem disponíveis para
inclusão na unidade de implantação,
conforme necessário.
Responsável pela realização da
Auditor de Gestão de auditoria na área de gestão de
Configuração configuração e mudanças, este papel
mede e fiscaliza o processo de GC.
Responsável pelo planejamento,
Controle da
Analista de Qualidade supervisão, registro, análise e relato da
Qualidade
garantia da qualidade.
Responsável por orientar o
desenvolvimento da arquitetura de
serviço do sistema, que inclui promoção
e criação de suporte para as principais
decisões técnicas que limitam o produto
Analista de Serviço e a implementação gerais para o
projeto. Também estabelece a estrutura
geral de cada visão de arquitetura: a
decomposição da visão, o agrupamento
dos elementos e as interfaces entre
esses principais agrupamentos.
Responsável por acompanhar e
monitorar o desenvolvimento da
arquitetura de serviços e software do
sistema, que inclui promoção e criação
de suporte para as principais decisões
técnicas que limitam o produto e a
Administrador de Serviço
implementação gerais para o projeto.
Também estabelece a estrutura geral de
cada visão de arquitetura: a
decomposição da visão, o agrupamento
dos elementos e as interfaces entre
esses principais agrupamentos.
Tabela 3. Papéis envolvidos no PS-MCTIC
Pág. 150 de 165

4.6 Artefatos de Saída
Esta seção destina-se a listar todos os artefatos de saída das atividades envolvidos no PS-MCTIC.
A Tabela 4 descreve esta relação de artefatos apresentando o seu objetivo e agrupados pelo
Processo que está relacionado.
Grupo de
Artefato Objetivo
Processo
Registro das principais informações
 Ata de Reunião discutidas e decisões tomadas na
reunião.
Registro de como os processos existentes
 Caso de
na organização foram customizados para
Desenvolvimento
o projeto.
Estimativa do tamanho funcional do
produto, em pontos de função.
Apresentação estruturada das atividades
do projeto com datas, durações, marcos
e recursos planejados, além de suas
conexões e ordens de precedência.
Representação gráfica da decomposição
hierárquica do escopo do trabalho a ser
 Estrutura Analítica do executado pela equipe do projeto. Cada
Projeto (EAP) nível descendente da EAP representa
uma definição detalhada do trabalho do
projeto.
Lista dos riscos identificados com sua
PP
análise qualitativa, assim como os planos
 Planilha de Riscos de respostas aos riscos, com ações de
mitigação, aceitação, eliminação ou
transferência.
Registro das políticas e padrões de
 Plano de Gerenciamento
qualidade da organização que são
de Qualidade
aplicáveis ao projeto.
Registro das metodologias de gestão de
riscos, tais como critérios de avaliação
qualitativa, escalas de probabilidade de
de Riscos
impacto e critérios para definição de
respostas aos riscos.
Registro dos objetivos de medição, as
medidas, procedimentos de coleta e
armazenamento dos dados, além dos
 Plano de Medições procedimentos de análise dos
indicadores do projeto e identificar as
necessidades de outras medições
específicas para o projeto.
Pág. 151 de 165

Consolidação de todos os planos

auxiliares e linhas de base a fim de
 Plano de Projeto (PP) manter a descrição de como o projeto
será executado, monitorado e
controlado.
Contém a descrição em alto nível do
escopo do projeto, incluindo suas
premissas e restrições iniciais, a
 Termo de Abertura do
designação do gerente do projeto e os
Projeto (TAP)
níveis de autoridade que ele possui para
aplicar os recursos às atividades do
projeto.
Contém a visão completa do sistema de
software em desenvolvimento e serve de
suporte ao contrato entre às partes
 Documento de Visão interessadas. É escrito com base na
perspectiva dos clientes, focalizando as
características essenciais do sistema e os
níveis aceitáveis de qualidade.
Registro do comportamento do sistema
 Especificação de Caso de
sob diversas condições, de acordo com a
Uso
solicitação de um gestor de negócio.
Contém a sequência de execução de cada
 Especificação de cenário operacional do sistema, com os
Cenários Operacionais requisitos, descrição e restrições de
ER ambiente.
Registro das interfaces com o usuário,
 Especificação de
descrevendo todas as ações, controles,
Interface com o Usuário
regras e exceções.
Registro dos requisitos não funcionais do
 Especificação sistema, tais como usabilidade,
Suplementar confiabilidade, desempenho,
suportabilidade.
Lista alfabética de termos de um
 Glossário determinado domínio de conhecimento
com a definição destes termos.
Lista de mensagens utilizadas na
 Lista de Mensagens aplicação, por exemplo, de informação,
de erro, de confirmação.
Pág. 152 de 165

Registro dos requisitos, sua origem e,

ainda, como esses requisitos se associam
a outros componentes do projeto. É a
representação do relacionamento dos
 Matriz de requisitos e suas origens, rastreados
durante todo o ciclo de vida do projeto.
Rastreabilidade
Rastreabilidade bidirecional pode ser
Bidirecional
entendida como a capacidade de se
iniciar do topo e rastrear todo o caminho
até chegar aos seus casos de testes, ou
começar por um determinado caso de
testes e segui-lo até o topo.
Modelo das funções pretendidas do
sistema e seu ambiente além de servir
como um contrato estabelecido entre o
demandante e os desenvolvedores.
Registro da documentação de requisitos,
dos tipos de requisitos e seus respectivos
atributos de requisitos, especificando as
informações e os mecanismos de
de Requisitos
controle que devem ser coletados e
usados para avaliar, relatar e controlar
mudanças nos requisitos do produto.
Lista das ações corretivas identificadas,
podendo incluir nesse registro os
responsáveis e o prazo para
 Registro de Ações
atendimento. Pode-se entender por ação
Corretivas
corretiva, uma ação para eliminar a causa
de uma não-conformidade, defeito ou
situação indesejável detectada.
Registro de como o negócio funciona,
podem abranger diversos assuntos como
suas políticas, interesses, objetivos,
 Regras de Negócio compromissos éticos e sociais,
obrigações contratuais, decisões
estratégicas, leis e regulamentações
entre outros.
Instrumentos de apoio às revisões
técnicas, utilizadas para guiar os revisores
 Listas de Verificação durante a atividade de revisão técnica,
RT
(LVs) estabelecendo os critérios mínimos de
revisão e as principais fontes de defeitos
que devem ser verificadas nos produtos.
Pág. 153 de 165

Registro de todas as revisões técnicas, os

defeitos identificados, gravidade, as
ações que foram dadas aos defeitos,
 Planilha de Resultados
justificativas da não correção,
de Revisões Técnicas
consolidação da eficácia das revisões
técnicas. Além disso, contém o registro
de ações corretivas.
Registro do planejamento, dos recursos,
 Plano de Revisões dos métodos e dos procedimentos a
Técnicas serem utilizados na condução de revisões
no projeto.
Código-fonte construído conforme as
 Código-fonte especificações de casos de uso e
requisitos definidos pelo usuário.
Descreve, negocial e conceitualmente,
cada uma das entidades identificadas no
 Dicionário de Dados Modelo de Dados, permitindo melhor
entendimento do negócio e das
entidades (dados) necessárias à solução.
Registra a visão geral arquitetural
abrangente do sistema, usando diversas
visões arquiteturais para representar
 Documento de diferentes aspectos do sistema. O
Arquitetura de Software objetivo deste documento é capturar e
comunicar as decisões arquiteturais
significativas que foram tomadas em
relação ao sistema.
Registro das soluções técnicas possíveis e
ST
 Documento de aplicáveis ao projeto, considerando
Estratégia de Solução tecnologias, decisões arquiteturais, as
Técnica características do produto e os critérios
de seleção estabelecidos para o projeto.
Registro dos padrões de layout do código
e de comentários, uso de convenções de
 Guia de Implementação nomeação e características linguagem e
outros detalhes de implementação como
boas práticas.
Registro das diretrizes a serem seguidas
durante o projeto além de conter
informações sobre ferramentas de
desenvolvimento, sistema de
 Guia de Projeto
gerenciamento de banco de dados,
hardware e sistema operacional,
bibliotecas de componentes, entre
outros.
Pág. 154 de 165

Registro da visão geral de todo o

documento como, finalidade, objetivos e
 Manual do Usuário funcionamento do produto de software.
Serve de base para a utilização do
produto pelo usuário final.
Registro de um subconjunto do modelo
de implementação que descreve a
 Modelo de Dados
representação lógica e física dos dados
persistentes no sistema.
Registro das mudanças e erros
conhecidos em uma versão de um build
ou em uma unidade de implantação que
tenha sido disponibilizada para uso.
Registro dos problemas encontrados
durante as atividades para tratamento
posterior do Gerente de Projetos. As
 Lista de Ocorrências ocorrências podem resultar em
providências como, por exemplo,
melhorar a lista de verificação do projeto,
implementação e testes.
Descreve os procedimentos e as
informações necessárias para que a
transição do produto para operação
ocorra da melhor forma possível.
IP Registro do conjunto de tarefas
necessárias para instalar e testar o
 Plano de Implantação produto desenvolvido de modo que ele
possa ser efetivamente transferido para a
comunidade de usuários.
Fornece um plano detalhado para
integração em uma iteração. Descreve o
conjunto de tarefas necessárias para
 Plano de Integração instalar e testar o produto desenvolvido
de modo que ele possa ser efetivamente
transferido para a comunidade de
usuários.
Fornece a visão das atividades de testes,
escopo, cobertura dos testes,
funcionalidades do sistema que serão e
as que não serão testadas, premissas,
TS  Plano de Teste
restrições, requisitos de ambiente,
rastreabilidade dos casos de teste,
critérios de validação e os responsáveis
pelas tarefas de teste.
Pág. 155 de 165

Registro dos resultados dos testes

executados, independentemente de
terem sido encontrados erros ou não. Os
 Registro dos Resultados registros devem conter informações
de Teste sobre a massa de testes utilizada e o
roteiro de testes executado. Um registro
pode conter cópias das telas do sistema,
caso seja pertinente.
Contém as ações que deverão ser
executadas no sistema para que o caso de
teste seja executado. O nível de
 Roteiro de Teste detalhamento deste roteiro é
influenciado diretamente pelo perfil dos
testadores que executarão os testes no
sistema.
Fornece uma análise resumida dos
resultados do teste e as principais
 Sumário de Avaliação de medidas do teste, para permitir uma
Teste avaliação objetiva da qualidade,
geralmente executadas pelos principais
envolvidos na questão de qualidade.
Contém todas as atividades da Gestão de
Configuração que serão executadas
durante o ciclo de vida do produto ou do
projeto. Ele detalha os itens de
 Plano de Gestão de
configuração, o cronograma de
Configuração
atividades, as responsabilidades
atribuídas e os recursos necessários,
como equipes, ferramentas e
GC computadores.
Registro da identificação de um baseline,
qualquer artefato necessário ausente e
requisitos reprovados ou testados de
 Registro de Auditoria de forma incompleta. Relata se o
Baseline desempenho do software desenvolvido
está em conformidade com seus
requisitos e se os artefatos necessários
estão fisicamente presentes.
Registro dos resultados de uma fase ou
 Avaliação de Fase ou
iteração, comparando-os com os
Iteração
objetivos definidos inicialmente.
Medida do tamanho funcional do
MCP  Contagem Detalhada
produto, em pontos de função.
Descrição detalhada da mudança
 Documento de
identificada no projeto, com informações
Solicitação de Mudança
suficientes que possibilitem sua análise.
Pág. 156 de 165

Documento corporativo que contém as

 Planilha de Lições lições aprendidas dos projetos que
Aprendidas podem ser utilizadas no planejamento
dos projetos futuros.
Registro das informações sobre o
 Relatório de desempenho do projeto em relação ao
escopo, custo, recursos, qualidade e
Acompanhamento do
riscos, de forma a manter os interessados
Projeto
no projeto atualizados sobre seu
andamento.
Registro da análise de impacto das
mudanças sobre as restrições do projeto,
 Relatório de Controle da incluindo também os produtos e
Qualidade artefatos impactados. Neste artefato
também constam as devidas aprovações
das mudanças no projeto.
Registro da análise de impacto das
mudanças sobre as restrições do projeto,
 Relatório de Controle de incluindo também os produtos e
Mudança artefatos impactados. Neste artefato
também constam as devidas aprovações
das mudanças no projeto.
Relatórios de Comunicação previstos na
 Relatórios de
Tabela de Eventos de Comunicação do
Comunicação
Plano de Projeto.
Registro formal do aceite de um produto
 Termo de Aceite
por uma ou mais partes interessadas.
Registro das informações de
 Termo de Encerramento
encerramento do projeto, com a
do Projeto
aprovação das partes interessadas.
Contém as etapas de análise de processos
 Plano de Melhoria de
para identificar as atividades que
Processos
agregam valor ao processo.
Registro da situação dos desvios
 Relatório de identificados, o responsável por
Acompanhamento de tratamento e a avaliação da quantidade
GQ Desvios de desvios por fase, por grupo de
processo, por situação.
Registro das não conformidades
 Relatório de Desvios e encontradas pelo processo de garantia da
Oportunidades de qualidade de processo e produto (GQ) e
Melhoria das oportunidades de melhoria
identificadas.
Pág. 157 de 165

Apresenta a consolidação de todas as

tarefas anteriores que podem ser
representadas em um documento em
forma de arquivo (Exemplo: Planilha de
 Modelo de serviços
Excel) ou configurado como sendo um
artefato customizado em uma
ferramenta de governança (Artefato RXT
do G-REG WSO2).
Registra a visão geral arquitetural
abrangente do sistema, usando diversas
visões arquiteturais para representar
 Documento de diferentes aspectos do sistema. O
arquitetura objetivo deste documento é capturar e
comunicar as decisões arquiteturais
PS significativas que foram tomadas em
relação ao sistema.
Registro dos padrões de layout do código
e de comentários, uso de convenções de
 Guia de implementação nomeação e características linguagem e
outros detalhes de implementação como
boas práticas.
Registro dos resultados dos testes
executados, independentemente de
terem sido encontrados erros ou não. Os
 Registro dos resultados registros devem conter informações
de teste sobre a massa de testes utilizada e o
roteiro de testes executado. Um registro
pode conter cópias das telas do sistema,
caso seja pertinente.
Tabela 4. Conjunto de artefatos do PS-MCTIC
Os artefatos a serem entregues são ponderados conforme o tamanho da demanda “Tipo 1” (até
100 Pontos de Função), “Tipo 2” (entre 101 e 400 Pontos de Função) e “Tipo 3” (acima de 400
Pontos de Função) e fase do ciclo de vida, ou seja, dependendo do porte do projeto um
subconjunto específico de artefatos deve ser entregue durante a execução do projeto, conforme
observado na Tabela 5.
Concepção Elaboração Construção Transição
Artefato Observação
Tipo 1
Tipo 2
Tipo 3
Tipo 1
Tipo 2
Tipo 3
Tipo 1
Tipo 2
Tipo 3
Tipo 1
Tipo 2
Tipo 3
PLANEJAMENTO DE PROJETO (PP)

Ata de Reunião X X X X X X X X X X X X
Tipo 1: Como parte do
Caso de Desenvolvimento + X X
Plano de Projeto
Contagem Estimada X X X
Pág. 158 de 165

Cronograma de Projeto X X X
Estrutura Analítica do Projeto
X X X
(EAP)
Planilha de Riscos + X X
Plano de Projeto
Plano de Gerenciamento de Tipo 1: Como parte do
+ X X
Qualidade Plano de Projeto
+ X X
Riscos Plano de Projeto
Plano de Medições + X X
Plano de Projeto
Plano de Projeto (PP) X X X
Termo de Abertura do
X X X
Projeto (TAP)
ENGENHARIA DE REQUISITOS (ER)
Documento de Visão X X X
Especificação de Caso de Uso X X X
Especificação de Cenários
X X
Operacionais
Especificação de Interface
X X X
com o Usuário
Especificação Suplementar X X X
Glossário X X X
Lista de Mensagens X X X
+ X X
Requisitos Plano de Projeto
Matriz de Rastreabilidade X X X
Modelo de Casos de Uso X X X
Regras de Negócio X X X
Registro de Ações Corretivas X X X
REVISÃO TÉCNICA (RT)
Listas de Verificação (LVs) X X X X X X
Planilha de Resultados de
X X X
Revisões Técnicas
Plano de Revisões Técnicas + X X
Plano de Projeto
SOLUÇÃO TÉCNICA (ST)
Código-fonte X X X
Dicionário de Dados X X X
Documento de Arquitetura
X X X
de Software
Documento de Estratégia de
X
Solução Técnica
Guia de Implementação X X X
Guia de Projeto X X X
Manual do Usuário X X
Modelo de Dados X X X
Pág. 159 de 165

Notas de Release X X X
INTEGRAÇÃO DO PRODUTO (IP)
Lista de Ocorrências X X X
Manual do Produto X X X
Notas de Release X X X
Plano de Implantação X X
Plano de Integração X X
TESTE (TS)
Plano de Teste X X X
Registro dos Resultados de
X X X
Teste
Roteiro de Teste X X X
Sumário de Avaliação de
X X X
Teste
GESTÃO DE CONFIGURAÇÃO (GC)
Plano de Gestão de Tipo 1: Como parte do
+ X X
Configuração Plano de Projeto
Registro de Auditoria de
X X X
Baseline
MONITORAMENTO E CONTROLE DO PROJETO (MCP)
Avaliação de Fase ou Iteração X X
Contagem Detalhada X X X
Documento de Solicitação de
X X X
Mudança
Planilha de Lições Aprendidas X X X
Relatório de
X X X
Acompanhamento de Projeto
Relatório de Controle da Relatório de
+ X X
Qualidade Acompanhamento do
Projeto
Relatório de Controle de
X X X
Mudança
Relatórios de Comunicação X X
Termo de Aceite X X X
Termo de Encerramento do
X X X
Projeto
GARANTIA DA QUALIDADE DE PROCESSO E DE PRODUTO (GQ)
Plano de Melhoria de Tipo 1: Como parte do
+ X X
Processos Plano de Projeto
Relatório de
Acompanhamento de X X X
Desvios
Relatório de Controle da Tipo 1: Como parte do
+ X X
Qualidade Relatório de
Pág. 160 de 165

Acompanhamento do
Projeto
Relatório de Desvios e
X X X
Oportunidades de Melhoria
Tabela 5. Conjunto de artefatos a serem entregues por tamanho de demanda e fase do ciclo de vida
Obs.: O símbolo “+” significa que, para o tipo de demanda, o artefato será parte de um artefato central
do projeto, por exemplo, o Plano de Medição fará parte do Plano de Projeto.
Pág. 161 de 165

4.7 Listas de Verificação (LVs)
Esta seção destina-se a listar todas as listas de verificação envolvidas no PS-MCTIC. Listas de
Verificação são instrumentos de apoio às revisões técnicas, utilizadas para guiar os revisores
durante a atividade de revisão técnica, estabelecendo os critérios mínimos de revisão e as
principais fontes de defeitos que devem ser verificadas nos produtos. A Tabela 6 descreve esta
relação de LVs. Para os artefatos que não possuem uma Lista de Verificação específica, deve-se
utilizar a Lista de Verificação – Geral.
Listas de Verificação
Documento de Arquitetura de Software
Documento de Visão
Especificação de Caso de Uso
Especificação de Cenários Operacionais
Especificação de Interface com o Usuário
Especificação Suplementar
Geral
Glossário
Lista de Mensagens
Modelo de Casos de Uso
Modelo de Dados
Notas de Release
Plano de Implantação
Plano de Projeto
Regras de Negócio
Relatório de Controle de Mudança
Tabela 6. Lista de Verificação do PS-MCTIC
4.8 Premissas no Atendimento de Demandas de Software
Cabe unicamente à Coordenação Geral de Tecnologia da Informação de coordenar e executar

os projetos de software que atendam ao MCTIC em âmbito nacional. A Coordenação Geral de
Sistemas (CGSI) considera que as seguintes regras básicas deverão ser consideradas
irrestritamente no Desenvolvimento de Software:
Pág. 162 de 165

• Qualquer novo desenvolvimento e/ou correção de sistema/módulo/funcionalidade

somente se dará mediante registro de demanda ou ordem de serviço, conforme descrito no
Processo de Gestão de Demandas (PGD-MCTIC).
• Não é permitido o desenvolvimento de sistemas sem o prévio conhecimento da CGTI e
seu consentimento formal.
• Nenhuma atividade fora do escopo previsto neste processo ou nos processos e
metodologias a este relacionados devem ser executadas sem expressa autorização da CGTI.
Cabe a CGTI a análise da viabilidade de implantação de qualquer novo sistema ou ambiente
tecnológico, conforme previsto no Processo de Gestão de Projetos (PGP-MCTIC), podendo a
CGTI vetar, alterar ou redimensionar qualquer sistema desde que em comum acordo com o
requisitante da demanda e devidamente justificado.
Pág. 163 de 165

5 Referências
PS-MCTI. Processo de Software do Ministério da Ciência, Tecnologia e Inovação. Boletim de serviço
do MCTI, Nº 1 de 15 de Janeiro de 2014.
SOFTEX. MPS.BR, Melhoria de Processo de Software Brasileiro - Guia Geral MPS de

Software:2012. Rio de Janeiro: Softex, 2012
PDTI. Plano Diretor de Tecnologia da Informação (PDTI) do MCTIC
PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) – Quinta

Edição. Pennsylvania: Project Management Institute (PMI), 2013.
Kruchten, Philippe. The Rational Unified Process : Addison Wesley, 1999.
ISO/IEC 12207:. ISO/IEC 12207 Information technology - Software life cycle processes.
Genebra: ISO: International Organization for Standardization and International Electrotechnical
Commission., 1995.
ISO/IEC 15504-2. ISO/IEC 15504-2: Information Technology - Process Assessment - Part 2 -

Performing an Assessment. Genebra: ISO: International Organization for Standardization and
International Electrotechnical Commission, 2003.
CMMi Product Team; CMMi for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software
Engineering Institute, Carnegie Mellon University, 2010. Disponível em:
<http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm>
IN 04. Instrução Normativa MP/SLTI Nº 04, de 12 de novembro de 2010. Disponível em: <
http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04-de-12-
de-novembro-de-2010>. Acesso em: Novembro de 2014.
IFPUG. Function Point Counting Practices: Manual Release 4.0. Blendonview Office Park, 5008-
28 Pine Creek Drive, Westerviell, OHZ 43001-4899: Internation Function Point Users Group, 1994.
TMMi. Test Maturity Model Integration. Release 1.0, 2012. Disponível em:
<http://www.tmmi.org/pdf/TMMi.Framework.pdf>. Acesso em: Novembro de 2014.
RUP. Rational Unified Process – RUP. Rational Software Corporation, 2006. Disponível em: <
http://www.wthreex.com/rup/v711_ptbr/index.htm> Acesso em: Novembro de 2014.
Pág. 164 de 165

6 Apêndice
1. Guias Operacionais
2. Instruções de Trabalho
3. Modelos (Templates)
4. Listas de Verificação (LVs)
Pág. 165 de 165

PS DocumentoDescritivo

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PS DocumentoDescritivo

Enviado por

Direitos autorais:

Formatos disponíveis

MINISTÉRIO DA CIÊNCIA, TECNOLOGIA, INOVAÇÕES E COMUNICAÇÕES

Processo de Gestão de Demandas do

Ministério da Ciência, Tecnologia, Inovações e Comunicações - MCTIC

Diretoria de Tecnologia da Informação

Equipe Técnica da CGSI:

Rev. Nº Data Descrição Autor

4.3.3 Revisão Técnica (RT) ........................................................................................... 54

2 Conceitos Básicos e Definições

Entende-se por demanda (“chamado” ou “ticket”) como sendo o registro, na Ferramenta de

2.2 APF – Análise por Pontos de Função

2.3 Sustentação de Aplicações

São as atividades de suporte necessárias para a manutenção do funcionamento correto da

2.4 Unified Modeling Language (UML)

Traduzida como Linguagem de Modelagem Unificada, destina-se à especificação,

2.5 Sistema em Desenvolvimento

2.6 Sistema em Homologação

2.7 Sistema em Produção

4 O Processo de Software do MCTIC

4.1 Fases do ciclo de vida

Do ponto de vista do gerenciamento, o ciclo de vida de software do PS-MCTIC é dividido em

Figura 1. Visão geral do ciclo de vida de desenvolvimento de software

4.1.1 Fase de Concepção

4.1.2 Fase de Elaboração

 Estabelecer um ambiente de suporte.

4.1.3 Fase de Construção

Na fase de Construção o objetivo é esclarecer os requisitos restantes e concluir o

4.1.4 Fase de Transição

O PS-MCTIC está organizado através de disciplinas da engenharia de software que agrupam

Disciplina Grupos de Processo

Gestão de Projetos Planejamento de Projeto (PP)

Gestão de Configuração Gestão de Configuração (GC)

Implantação Integração do Produto (IP)

Desta forma, os processos de desenvolvimento e manutenção de software do MCTIC seguem

4.2.1 Gestão de Projetos

A Gestão de Projetos concentra-se principalmente sobre os aspectos importantes de um

Nesta direção, as atividades da disciplina de gestão de projetos, que no PS-MCTIC engloba os

Figura 3. Grupos de Processos de Gerenciamento de Projetos do PGP-MCTIC

4.2.2 Modelagem de Negócios

A disciplina de Modelagem de Negócios, que no PS-MCTIC inclui o grupo de processo

 Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma

A disciplina de Requisitos, que no PS-MCTIC inclui o grupo de processo Engenharia de Requisitos

4.2.4 Gestão de Configuração

A disciplina de Gestão da Configuração, que no PS-MCTIC inclui o grupo de processo Gestão de

gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e

 Gerenciamento de configuração: A gestão de configuração é responsável pela

4.2.5 Análise e Design

A disciplina de Análise e Design, que no PS-MCTIC engloba os grupos de processo Solução

A disciplina de Implementação, que no PS-MCTIC engloba os grupos de processo Solução Técnica

 Definir a organização do código em termos de subsistemas de implementação

 Localizar e documentar defeitos na qualidade do software;

4.2.8 Controle de Qualidade

A disciplina de Controle da Qualidade, que no PS-MCTIC engloba o processo de Garantia da

A disciplina de Implantação, que no PS-MCTIC engloba o processo de Integração do Produto (IP),

A disciplina Implantação está relacionada a outras disciplinas da seguinte maneira:

 A disciplina Requisitos produz os requisitos funcionais, o modelo de caso de uso e

A disciplina de Ambiente, que engloba atividades previstas nos processos de Engenharia de

A disciplina de Desenvolvimento de Serviço, que engloba atividades previstas nos processos

4.3 Grupos de Processo

4.3.1 Planejamento de Projeto (PP)

O objetivo do processo Planejamento de Projeto (PP) é fornecer subsídios para estabelecer e

Figura 4. Fluxo do processo Planejamento do Projeto (PP)

As Instruções de Trabalho e Qualidade (ITQ) do grupo de processo Planejamento de Projeto (PP)

Atividade: Iniciar Projeto

 Avaliação Técnica aprovada