2021 02 Processo Desenvolvimento Fabrica

Universidade Federal de Goiás
Instituto de Informática
Fábrica de Software
Processo para Desenvolvimento de

Software
Padrão de Processo para projetos da Fábrica de
Software
Goiânia
2021
Agradecimentos
O presente processo para desenvolvimento de software foi elaborado insti-

tucionalmente pela Fábrica de Software do INF a partir de experiências e lições
aprendidas em diversos projetos de desenvolvimento e manutenção de software con-
duzidos nesta Fábrica.
A Fábrica de Software agradece a todos os professores, servidores e discentes
do Instituto de Informática da Universidade Federal de Goiás que colaboraram
nos projetos da Fábrica e que contribuíram para a síntese de boas práticas de
desenvolvimento de software que foram compiladas no processo definido no presente
documento.
"Adding manpower to a late software project makes it later".
Frederick Brooks Jr.,

The Mythical Man-Month, 1975.
Resumo
Fábrica de Software do Instituto de Informática da UFG. Processo para

Desenvolvimento de Software. Goiânia, 2021. 80p. Relatório Técnico.
Instituto de Informática, Universidade Federal de Goiás.
Objetivo: Este trabalho descreve o processo para desenvolvimento de software
utilizado como padrão institucional em projeto de desenvolvimento de software
realizado pela Fábrica de Software do INF.
Conceitos chave: O processo de desenvolvimento de software traduz necessidades
de usuários em um produto de software. Sua execução envolve: identificação das
necessidades das partes interessadas; especificação de requisitos do software; design
arquitetural e detalhado de elementos de software que atendem os requisitos;
implementação e integração de código fonte correspondente ao design; validação
do código por meio de testes que demonstram a sua efetividade.
Estrutura: O processo definido segue as diretrizes e contempla as mesmas fases do
Rational Unified Process (RUP) [Kruchten 2004]. Cada fase (Concepção, Elabora-
ção, Construção e Transição) é definida em termos de propósito, resultados esperados
da execução, atividades e itens de informação gerados. Esta definição é estendida com
orientações metodológicas, incluindo sugestões de templates e ferramentas. Embora
não contemplem todos os detalhes de um processo de desenvolvimento de software,
essas orientações representam um primeiro passo em direção a uma metodologia
para desenvolvimento de software na Fábrica de Software do INF.
Especificidades: O processo de desenvolvimento de software é orientado para o
contexto da Fábrica de Software do INF e atende duas principais características
deste contexto: (1) a necessidade de atender diferentes perfis de desenvolvedor que
atuam em projetos da Fábrica, incluindo a capacitação de discentes com pouca
experiência em atividades práticas da Engenharia de Software; e (2) a possibilidade
de execução isolada e independente de cada fase do processo.
Palavras–chave
Processos de Engenharia de Software, Processo de Desenvolvimento de
Software, Metodologia de Desenvolvimento de Software, Fábrica de Software.
Abstract
Fábrica de Software do Instituto de Informática da UFG. Software De-

velopment Process. Goiânia, 2021. 80p. Technical Report. Instituto de
Informática, Universidade Federal de Goiás.
Objective: This work describes the process for software development used as an
institutional standard in software development project carried out by the INF
Software Factory.
Key concepts: The software development process translates user needs into a
software product. Its execution involves: identification of the needs of the interested
parties; specification of software requirements; architectural and detailed design
of software elements that meet the requirements; implementation and integration
of source code corresponding to the design; code validation through tests that
demonstrate its effectiveness.
Structure: The defined process follows the guidelines and includes the same stages
of the Rational Unified Process (RUP) [Kruchten 2004]. Each stage (Conceptio,
Elaboration, Construction and Transition) is defined in terms of purpose, expected
results of the execution, activities and information items generated. This definition
is extended with methodological guidelines, including suggestions for templates
and tools. Although they do not include all the details of a software development
process, these guidelines represent a first step towards a methodology for software
development at the INF Software Factory.
Specificities: The software development process is oriented to the INF’s Software
Factory context and meets two main characteristics of this context: (1) the need
to support different developer profiles who work on Factory’s projects, including
the training of students with little experience in practical activities of Software
Engineering; and (2) the possibility of isolated and independent execution of each
stage of the process
Keywords
Software Engineering Process, Software Develompent Process, Software
Develompent Methodology, Software Factory.
Sumário
Lista de Figuras 8
1 Visão Geral do Processo de Desenvolvimento de Software 9

1.1 Sobre este Documento 9
1.1.1 Objetivo e Escopo deste Documento 9
1.1.2 Estrutura deste Documento 9
1.1.3 Melhoria Contínua do Processo 10
1.2 Conceitos Fundamentais para o Processo 11
1.3 Características Essenciais do Processo 12
1.3.1 Contexto de Execução do Processo 12
1.3.2 Execução Completa ou Separada por Fase 13
1.3.3 Perfis de Membros da Equipe Técnica 14
1.3.4 Papéis e Responsabilidades no Projeto 15
1.3.5 Duração de um Projeto 17
1.3.6 Marcos de Projeto 17
1.3.7 Desenvolvimento Iterativo 18
1.3.8 Desenvolvimento Incremental e Entrega Contínua 18
1.3.9 Disciplinas e Domínios do Processo 19
2 Gestão do Projeto – Atividades Transversais ao Projeto de Software 20

2.1 Síntese das Atividades Transversais 20
2.1.1 Propósito 20
2.1.2 Resultados Esperados 20
2.1.3 Atividades 21
2.1.4 Produtos de Trabalho 22
2.2 Orientações Metodológicas 22
2.2.1 Planejamento do Projeto 22
2.2.2 Ciclo de Vida de um Pacote de Trabalho no Projeto 23
2.2.3 Execução do Projeto 24
2.2.4 Garantia da Qualidade na execução dos pacotes de trabalho 25
2.2.5 Atraso, Recusa e Cancelamento de Pacote de Trabalho 25
2.2.6 Iniciação do Projeto 26
2.2.7 Monitoramento Periódico e Marcos de Projeto 27
2.2.8 Ativos de Processo para Garantia de Qualidade 27
2.2.9 Controle de Mudanças no Projeto 27
3 Fase de Concepção do Software 29
3.1 Síntese da Fase 29
3.1.1 Propósito 29
3.1.3 Atividades 30
3.2.1 Escopo preliminar 33
3.2.2 Equipe preliminar do projeto 34
3.2.3 Riscos preliminares do projeto 34
3.2.4 Aprovação do início do projeto 35
3.2.5 Definição dos Conceitos Operacionais do Sistema 35
3.2.6 Definição do Ambiente Operacional do Projeto 36
3.2.7 Modelagem da Arquitetura do Software 36
3.2.8 Planejamento do Projeto de Software 37
4 Fase de Elaboração do Software 38

4.1 Síntese da fase 38
4.1.1 Propósito 38
4.1.3 Atividades 39
4.2.1 Requisitos de Sistema/Negócio e Requisitos de Software 41
4.2.2 Eliciação de Requisitos 41
4.2.3 Análise, Modelagem e Negociação de Requisitos 42
4.2.4 Especificação de Requisitos 43
4.2.5 Verificação e Validação de Requisitos 43
4.2.6 Componente Operacional da Arquitetura 44
4.2.7 Arquitetura de Software e Riscos Técnicos do Projeto 45
4.2.8 Preparação para Aceitação do Software 46
5 Fase de Construção do Software 47

5.1 Síntese da fase 47
5.1.1 Propósito 47
5.1.3 Atividades 48
5.2.1 Boas Práticas em Programação 49
5.2.2 Controle de Evolução do Código 50
5.2.3 Verificação e Validação de Código 50
5.2.4 Design de Componente de Software 51
5.2.5 Planejamento de Testes de Software 52
5.2.6 Execução de Testes de Software 53
6 Fase de Transição do Software 55
6.1.1 Propósito 55
6.1.3 Atividades 56
6.2.1 Encerramento do Projeto 57
6.2.2 Lições Aprendidas no Projeto 58
6.2.3 Planejamento da Transição 58
6.2.4 Execução da Transição 59
Referências Bibliográficas 61
A Templates de Documentos do Processo 63

A.1 Termo de Abertura de Projeto 64
A.2 Especificação de Requisitos de Software (ERS) 66
A.3 Termo de Encerramento de Projeto 71
B Ferramentas de Apoio ao Processo 73

B.1 Git, GitHub e Gitflow 73
B.2 Jenkins 74
B.3 SonarQube 75
C Glossário do Processo 77
Lista de Figuras
1.1 Processo de Desenvolvimento de Software 14

1.2 Papéis definidos no PDS e suas especializações 16
2.1 Atividades Transversais 20

2.2 Ciclo de Vida de um Pacote de Trabalho 23
2.3 Componentes gerados em cada fase do processo 25
3.1 Atividades de Concepção do Software 29

3.2 Atividades de Abertura do Projeto 35
4.1 Atividades de Elaboração do Software 38

4.2 Atividades de Especificação de Requisitos de Software 40
5.1 Atividades de Construção do Software 47
6.1 Atividades de Transição do Software 55

CAPÍTULO 1
Visão Geral do Processo de
Desenvolvimento de Software
1.1 Sobre este Documento

Este documento especifica o Processo de Desenvolvimento de Soft-
ware – PDS definido para a Fábrica de Software do Instituto de Informática da
UFG.
1.1.1 Objetivo e Escopo deste Documento

O objetivo do PDS é orientar a execução dos trabalhos em projetos de
desenvolvimento de software conduzidos na Fábrica de Software.
O PDS facilita a gestão do projeto, contribuindo para o planejamento do
trabalho a ser realizado no projeto e provendo transparência sobre os aspectos mais
relevantes da execução do projeto: recursos, escopo, valor agregado, custo, prazo,
qualidade e riscos.
O PDS inclui algumas orientações metodológicas que complementam as
definições do PDS. Todavia, a definição de uma metodologia de desenvolvimento de
software completa está fora do escopo deste documento.
1.1.2 Estrutura deste Documento

Este Capítulo 1 introduz os conceitos chave e as bases teóricas do PDS,
apresentando um panorama geral das fases em que o PDS é organizado. Cada
capítulo subsequente (2 a 6) descreve uma das fases do PDS e todos eles estão
organizados em duas partes:
1. Síntese da fase: contempla propósito, resultados esperados, atividades e itens

de informação (produtos de trabalho) da fase.
1.1 Sobre este Documento 10
2. Orientações metodológicas: discute e propõe boas práticas que podem ser

usadas para realizar as atividades da fase.
Assim, o restante deste documento está organizado da seguinte forma:
• O Capítulo 2 descreve atividades transversais que ocorrem de forma concor-

rente com todas as fases do PDS.
• O Capítulo 3 descreve a fase de concepção do software, que estabelece o
escopo do projeto, atribui responsabilidades e define requisitos e arquitetura
do software.
• O Capítulo 4 descreve a fase de elaboração do software, que analisa requisitos
para criar o design detalhado dos elementos arquiteturais que realizam esses
requisitos.
• O Capítulo 5 descreve a fase de construção do software, que implementa e
integra os elementos de código fonte, em conformidade com o design detalhado.
• O Capítulo 6 descreve a fase de transição do software, que realiza testes
para assegurar a confiabilidade e a prontidão para executar em ambiente de
produção.
Os apêndices complementam e ajudam na compreensão do PDS:
• O Apêndice A apresenta templates para alguns itens de informação do pro-

cesso.
• O Apêndice B discute ferramentas de apoio para algumas atividades do
processo.
• O Apêndice C traz o glossário de termos empregados na definição do processo.
1.1.3 Melhoria Contínua do Processo

Visando a melhoria contínua do PDS definido, a Fábrica de Software solicita
ao leitor deste documento que envie suas críticas, comentários, sugestões ou dúvidas
sobre o processo para o e-mail institucional da Fábrica: fabrica@inf.ufg.br . Todas
as opiniões sobre o PDS são importantes e serão analisadas pela Fábrica.
Novas versões deste documento, contemplando as considerações feitas pe-
los leitores e julgadas pertinentes pela equipe técnica da Fábrica, serão dis-
ponibilizadas no sítio da Fábrica na Web, que pode ser acessado pela URL
www.inf.ufg.br/fabrica.
1.2 Conceitos Fundamentais para o Processo 11
1.2 Conceitos Fundamentais para o Processo

A Fábrica de Software do INF, ou simplesmente Fábrica, é um órgão
do Instituto de Informática (INF) da Universidade Federal de Goiás (UFG). Ela
mantém um ambiente profissional de produção de software, alojado em um ambiente
educacional, visando a contribuir, principalmente, para atividades de ensino prático
de Engenharia de Software nos cursos de graduação do INF. Para isso, a Fábrica
necessita definir processos que orientem a execução de suas atividades.
Um Processo de Engenharia de Software, ou simplesmente Processo
de Software, é um conjunto de atividades inter-relacionadas que colaboram para
realizar produtos ou serviços baseados em software.
Um Processo de Desenvolvimento de Software (PDS) é um Processo
de Software que constrói um produto de software para atender necessidades de
usuários e outras partes interessadas [ISO/IEC/IEEE 2017].
As partes interessadas em um software, também conhecidas como sta-
keholders, abrangem os indivíduos, grupos ou organizações cujas necessidades de-
vem ser satisfeitas pelo software ou que são potencialmente afetados pelos resultados
do desenvolvimento, da implantação, da operação e da sustentação do software ao
longo do seu ciclo de vida.
Um PDS típico define propósito, resultados, atividades e itens de informação
(documentos e outros artefatos de software) que abrangem:
1. Especificação: identificação e modelagem de requisitos dos stakeholders;

2. Design: criação de elementos de arquitetura/design que atendem os requisitos;
3. Implementação: escrita e integração de código fonte, seguindo o design;
4. Validação: demonstração, via testes, da prontidão do software para o uso.
As atividades de um PDS podem ser organizadas segundo diversos Modelos

de Ciclo de Vida de Desenvolvimento de Software, tais como o Cascata e
o Iterativo [Munassar e Govardhan 2010]. Estes modelos, também conhecidos como
Paradigmas de Desenvolvimento de Software, definem fases (ou estágios) do processo
e estabelecem restrições e dependências entre fases e atividades do processo (tais
como iterações de atividades ou sobreposição de fases) de modo a orientar a forma
como o trabalho de desenvolvimento de software é realizado.
O modelo de ciclo de vida de desenvolvimento de software subjacente ao
PDS tem quatro fases sequenciais e uma fase transversal ao projeto, executada de
forma concorrente com as fases sequenciais, focada na gestão do projeto. As fases
sequenciais são as mesmas definidas pelo Processo RUP (Rational Unified Process)
[Kruchten 2004]: Concepção, Elaboração, Construção e Transição.
Uma Metodologia de Desenvolvimento de Software (MDS) compre-

ende um sistema de práticas, técnicas, procedimentos e regras usados para desen-
volver software. Além de uma especificação do processo a seguir, uma MDS deve
detalhar os produtos de trabalho a serem usados e gerados no processo, além das
pessoas envolvidas, ferramentas utilizadas e métodos aplicados durante um esforço
de desenvolvimento de software [ISO/IEC/IEEE 2017]. Logo, uma MDS contém um
PDS, mas precisa ter descrições muito mais detalhadas e endereçar questões que não
são tratadas em um PDS.
1.3 Características Essenciais do Processo

Esta seção apresenta os princípios norteadores que orientaram a elaboração
do PDS. O documento foi escrito com base nas diretrizes e recomendações para
definição de processos propostos em [IEEE 2012].
O processo é definido por cinco grandes fases (ou subprocessos), sendo
quatro delas sequenciais e uma transversal às demais. A definição de cada fase
contempla o propósito da fase dentro do PDS, os resultados esperados da execução
bem sucedida da fase em um projeto, as atividades e tarefas executadas na fase e os
itens de informação (artefatos) produzidos por estas atividades.
Esta definição da fase é estendida com algumas orientações metodológicas
que representam um primeiro passo em direção a uma MDS para a Fábrica de
Software do INF.
1.3.1 Contexto de Execução do Processo

Todos os projetos da Fábrica devem seguir as diretrizes do PDS. Desvios
ou variações relacionadas a essas diretrizes devem ser explicitamente documentadas
no projeto e formalmente aprovadas pela Coordenação Geral da Fábrica.
As atividades da Fábrica são desenvolvidas por equipes técnicas heterogê-
neas e multidisciplinares. Além disso, a Fábrica pode atuar tanto em projetos de ciclo
de desenvolvimento de software completo quanto em projetos cujo escopo envolve
apenas uma fase do ciclo de vida de desenvolvimento de software (especificação,
design, construção ou validação).
Este contexto de execução de projetos de desenvolvimento de software na
Fábrica impõe dois requisitos essenciais para o PDS: (1) baixo acoplamento entre
as fases do PDS; e (2) adequação a diferentes perfis de membros da equipe técnica
do projeto.
Logo, a adequação do processo aos propósitos da Fábrica deve ser avaliada

em termos de capacidade de execução separada e independente de cada fase do
processo; e de atendimento de necessidades dos diferentes perfis de participantes da
equipe técnica de desenvolvimento que atuam nos projetos da Fábrica.
1.3.2 Execução Completa ou Separada por Fase

A Fábrica tem capacidade para atuar em todo o ciclo de vida de desen-
volvimento de software, mas também pode executar projetos de menor escopo, que
abrangem uma única fase, ou um subconjunto das fases daquele ciclo de vida.
A possibilidade de execução parcial de fases do ciclo de vida de desenvolvi-
mento impõe ao PDS um requisito de modularidade, ou seja, o processo precisa ser
definido em termos de fases que podem ser executadas de forma isolada ou de forma
coordenada com outras fases.
Neste sentido, o processo precisa contemplar a execução, na forma de
projeto, das seguintes fases do desenvolvimento de software:
• Fase de Concepção: foco na especificação do software por meio da Enge-

nharia de Requisitos. Um projeto que envolve apenas esta fase gera, como
principais resultados, uma definição de conceitos operacionais do sistema de
software e uma especificação de requisitos do software.
• Fase de Elaboração: foco no design arquitetural e detalhado do software. Um
projeto que envolve apenas esta fase recebe como entrada uma especificação
de requisitos e gera, como principais resultados, uma definição de arquitetura
de software e um design detalhado de cada elemento desta arquitetura.
• Fase de Construção: foco na implementação (codificação) e integração
do software. Um projeto que envolve apenas esta fase recebe como entrada
uma especificação de requisitos, uma definição arquitetural e um conjunto de
designs detalhados do software e gera, como principais resultados, um conjunto
de elementos de código que implementam o design especificado.
• Fase de Transição: foco na validação (homologação) e na transferência do
software para um ambiente operacional distinto do ambiente de desenvolvi-
mento. Um projeto que envolve apenas esta fase recebe como entrada uma
configuração de software contendo requisitos, design e código fonte, e gera,
como principais resultados, um plano de testes de software e um relato de
execução deste plano de testes.
Um projeto de desenvolvimento de software completo compreende a execu-

ção coordenada de todas essas fases, como ilustra a Figura 1.1.
Figura 1.1: Processo de Desenvolvimento de Software
A fase de Concepção visa obter um acordo entre a organização adquirente e

a organização fornecedora do software em relação aos principais requisitos do sistema
e do software e sobre o processo que deve ser executado para realizar o projeto.
O propósito da fase de Elaboração é aprofundar a compreensão sobre os re-
quisitos (domínio do problema) e sobre a forma de atender as necessidades (domínio
da solução) das partes interessadas no projeto. Para isso deve ser construída uma
linha de base arquitetural para orientar a implementação do software, corroborando
o acordo entre adquirente e fornecedor para continuar o projeto.
A fase de Construção tem como objetivo desenvolver e integrar, iterativa e
incrementalmente, componentes e serviços relacionados ao software, em conformi-
dade com a linha de base arquitetural estabelecida para o projeto.
O foco da fase de Transição é avaliar e assegurar a maturidade de uma ba-
seline do software gerada no projeto para ser utilizada em um ambiente operacional
de produção.
1.3.3 Perfis de Membros da Equipe Técnica

O PDS existe para orientar a equipe técnica da Fábrica na condução
de projetos de desenvolvimento de software. Para isso, o PDS precisa atender
as necessidades e expectativas de pessoas com diferentes graus de conhecimento,
habilidade e experiência em desenvolvimento de software, com destaque para:
1. Estudantes dos cursos do INF: para esses participantes do projeto, o PDS

precisa ter um caráter didático, visando a facilitar aos iniciantes uma rápida
familiarização com os conceitos essenciais das fases do processo: propósito,
resultados esperados, atividades e produtos gerados. Além disso, o PDS deve
orientar os estudantes em relação a formas de aplicar os conceitos, ou seja,
sobre metodologias que podem ser aplicadas para implementar os conceitos

definidos no processo.
2. Servidores da Fábrica: a Fábrica conta com uma equipe própria de profissionais
experientes que se dedicam no dia-a-dia ao desenvolvimento de software e
conhecem bem o PDS da Fábrica. Para esses profissionais, o PDS precisa
prover informações sintéticas, priorizando a rapidez e facilidade no acesso às
informações, em detrimento da completude ou de detalhamento metodológico.
3. Docentes do INF: em alguns projetos da Fábrica há participação de docentes,
seja no papel de membro da equipe técnica, ou como orientador de discentes
que atuam como membros da equipe técnica do projeto. O perfil do docente
que participa de projetos na Fábrica é definido por um profundo conhecimento
sobre aspectos teóricos do desenvolvimento de software, mas pouca experiência
na execução do PDS específico da Fábrica. O desafio para este perfil é apre-
sentar orientações metodológicas de forma prática e objetiva, sem sobrecarga
de explicações relacionadas às teorias que embasam a metodologia.
4. Membros externos: em projetos realizado em convênio com outras organiza-
ções, a equipe técnica da Fábrica trabalha em conjunto com profissionais vin-
dos destas organizações. O perfil destes profissionais é, em geral, de técnicos
com boa experiência prática, mas pouco embasamento teórico sobre Engenha-
ria de Software. Para este perfil, o processo precisa apresentar as teorias que
embasam as orientações metodológicas e as atividades previstas no processo,
de forma a deixar clara a importância de realizar cada tarefa prevista no pro-
cesso.
O PDS da Fábrica precisa contemplar as necessidades de todos esses perfis

de participantes da equipe técnica da Fábrica em cada projeto.
1.3.4 Papéis e Responsabilidades no Projeto

Todo projeto deve identificar explicitamente as pessoas que participam da
equipe técnica e aquelas que atuam desempenhando outros papéis no projeto. A
Figura 1.2 apresenta os papéis predefinidos no PDS.
O projeto de desenvolvimento de software é conduzido por uma equipe téc-
nica da Fábrica, composta por profissionais com formação em uma ou mais disci-
plinas da Engenharia de Software. Esta equipe deve ter pelo menos um profissional
que é servidor do INF vinculado à Fábrica e pode contar com membros externos,
tais como docentes e discentes da UFG, ou mesmo pessoas não vinculadas à UFG
que possuam competências úteis para o projeto.
Figura 1.2: Papéis definidos no PDS e suas especializações
A organização adquirente (Cliente) e a organização fornecedora (Fábrica)

são partes interessadas obrigatórias em qualquer projeto. Pode haver outras entida-
des indicadas como partes interessadas no projeto, tais como órgãos governamentais
ou entidades regulamentadoras, por exemplo.
Cada parte interessada deve indicar pelo menos uma pessoa como sua
representante no projeto. Essa pessoa deve ter autoridade para tomar decisões em
nome da parte interessada no projeto e um mesmo indivíduo pode representar mais
de uma parte interessada.
O papel representante do Cliente é uma especialização de representante de
parte interessada que designa um ou mais indivíduos que decidem em nome da
organização adquirente do projeto. Os clientes não podem exercer outros papéis
no projeto. Cabe aos indivíduos alocados ao papel de cliente a participação nos
marcos do projeto e a tomada de decisões em nome da organização adquirente do
projeto. Havendo mais de uma pessoa designada ao papel de cliente, deve haver uma
declaração explícita no projeto para definir como as decisões dos clientes podem
ser tomadas. Por exemplo, as decisões poderiam ser tomadas individualmente, por
maioria ou por unanimidade, dentre outras formas.
O papel representante da Fábrica também é uma especialização de represen-
tante de parte interessada que define uma única pessoa que representa a Coordenação
da Fábrica no projeto. O executor desse papel monitora o projeto na perspectiva

do portfólio de projetos da Fábrica, deve participar dos marcos do projeto e faz a
tomada de decisões em nome da organização fornecedora do projeto. O Represen-
tante da Fábrica é designado pelo Coordenador Geral da Fábrica e não pode exercer
qualquer outro papel no projeto.
Os membros da equipe técnica desempenham um ou mais papéis técnicos no
projeto. Cada papel técnico define um conjunto de responsabilidades e competências
necessárias para realizar algum tipo de trabalho no projeto e está diretamente
relacionado a um dos domínios de disciplinas previstos neste processo.
Uma especialização notável de membro da equipe técnica é o papel Líder
de Projeto, que deve ser exercido por um colaborador que é servidor vinculado à
Fábrica. Em qualquer ponto do ciclo de vida do projeto, um único indivíduo deve
estar associado a esse papel. Esse indivíduo deve representar a equipe técnica em
todas as interações com elementos externos ao projeto.
1.3.5 Duração de um Projeto

A duração de cada fase do projeto pode variar livremente, mas o ciclo de
vida completo para um projeto que executa o presente processo deveria ser concluído
em um período de dois a seis meses.
Projetos com duração estimada inferior a dois meses poderiam ser execu-
tados com uma variante do processo voltada a projetos de pequeno porte (embora
o presente PDS ainda não tenha definido esta variante). Já projetos com duração
estimada superior a seis meses poderiam ser decompostos em subprojetos com du-
ração no intervalo de dois a seis meses, para mitigar riscos relativos a projetos de
longa duração.
1.3.6 Marcos de Projeto

A conclusão de cada fase do projeto deveria ser validada por meio de
um marco de projeto, que é um ponto no tempo em que determinadas decisões
críticas devem ser tomadas com base nos objetivos alcançados no projeto até aquele
momento.
Ao final de cada fase do projeto deveria ocorrer um marco de projeto a fim
de analisar os resultados obtidos e reavaliar a viabilidade do projeto, considerando
os riscos existentes.
A participação de representantes das partes interessadas nos marcos do
projeto é obrigatória para assegurar a transparência sobre o progresso do projeto e
para que os marcos sejam efetivos em termos de decisões tomadas e de avaliação de

riscos.
1.3.7 Desenvolvimento Iterativo

Cada fase do projeto é dividida em iterações, que são intervalos de tempo
fixos, tipicamente de duas a quatro semanas, em que se planeja atingir um objetivo
bem definido.
Uma iteração representa uma execução completa de um trabalho pertinente
ao desenvolvimento de software. Esse trabalho deveria resultar na liberação (interna
ou externa) de um subconjunto do software em desenvolvimento. Desta forma, o
software cresce incrementalmente a cada iteração até se tornar o produto final
definido para o projeto.
Cada iteração dentro de uma fase deve orientar e conduzir os envolvidos
no projeto a concentrar seus esforços, de uma maneira previsível, em determinadas
disciplinas para cumprir o objetivo da iteração e agregar o valor planejado ao projeto.
1.3.8 Desenvolvimento Incremental e Entrega Contínua

Ao final de cada iteração do projeto deveria ser entregue um ou mais
componentes (ou produtos de trabalho) planejados, devidamente validados de forma
independente dos autores do componente[ISO/IEC/IEEE 2015]. A produção de um
componente envolve o uso de uma disciplina principal à qual o componente está
associado.
Um componente pode ser composto por outros subcomponentes; analoga-
mente, um componente pode fazer parte, como subcomponente, de outro compo-
nente maior do software. O conjunto de componentes gerados em todas as iterações
forma a configuração do software que é construída ao longo do projeto.
A entrega contínua de componentes após o esforço de alguns dias em
um pacote de trabalho visa promover o compartilhamento frequente do status do
trabalho entre os membros do projeto, melhorando a visibilidade do progresso e
aumentando a confiança no trabalho em equipe.
Embora os componentes produzidos em uma iteração sejam validados e
estejam prontos para uso, eles podem ser evoluídos em iterações subsequentes do
projeto. Dessa forma, o desenvolvimento de componentes pode ser feito de maneira
incremental.
1.3.9 Disciplinas e Domínios do Processo

Cada iteração do PDS utiliza conhecimentos provenientes de várias disci-
plinas, ou áreas de conhecimento, da Engenharia de Software, tais como Requisitos,
Arquitetura e Testes de software.
Cada disciplina aborda competências sobre Engenharia de Software neces-
sárias para trabalhar um determinado aspecto do desenvolvimento de software. As
disciplinas em um projeto são organizadas em dois domínios:
• Domínio do problema: processos de modelagem de negócio e engenharia de

requisitos.
• Domínio da solução: processos de arquitetura, design, implementação, integra-
ção, verificação, validação e transição.
Um terceiro domínio envolve os processos de gestão técnica necessários à

condução do PDS em um projeto. Esses processos compreendem a gerência de
projeto como um todo, incluindo preparação e disponibilidade do ambiente de
desenvolvimento, gerência de configuração, garantia de qualidade, medição, controle
de riscos e gestão de mudanças no projeto.
CAPÍTULO 2
Gestão do Projeto – Atividades
Transversais ao Projeto de Software
2.1 Síntese das Atividades Transversais

2.1.1 Propósito
Atividades transversais (Figura 2.1) ocorrem ao longo de todas as fases do
projeto e estão relacionadas, principalmente, ao gerenciamento do projeto, no que
concerne a: 1) definição, planejamento e organização do trabalho a ser realizado;
e 2) monitoramento e controle da execução dos trabalhos, envolvendo avaliação e
medição da qualidade de produtos e processos, correção de desvios e realização de
marcos do projeto.
Figura 2.1: Atividades Transversais
2.1.2 Resultados Esperados

Como consequência da execução bem sucedida das atividades transversais
ao projeto são gerados os seguintes resultados:
2.1 Síntese das Atividades Transversais 21
1. O processo padrão é adaptado, se necessário, instanciado e executado no

projeto.
2. A infraestrutura necessária para o projeto é estabelecida, disponibilizada e
mantida.
3. A execução do processo é planejada e monitorada, e ajustes são realizados.
4. As pessoas são preparadas e alocadas às suas responsabilidades no projeto .
5. A execução e resultados do projeto são revistos e tratados pelas partes
interessadas.
6. A aderência de trabalhos e produtos gerados a processos e padrões definidos é
avaliada, e não conformidades são tratadas.
7. Os produtos de trabalho do projeto são identificados, avaliados e controlados.
8. Dados são coletados e analisados para entender o comportamento do projeto
e identificar oportunidades de melhoria.
2.1.3 Atividades
As atividades transversais ao projeto podem ser consideradas como um
subprocesso do PDS que é executado ao longo de todo o projeto, como ilustra a
Figura 1.1. Há dois tipos básicos de atividades transversais, cada um envolvendo a
execução de diversas tarefas no projeto:
1. Planejar cada iteração do projeto.

(a) Definir objetivo e escopo da iteração.
(b) Revisar riscos do projeto para a iteração.
(c) Revisar e ajustar, se necessário, equipe e ambiente de trabalho à iteração.
(d) Definir tarefas da iteração.
(e) Alocar tarefa da iteração a Membro da Equipe ou a Fornecedor.
(f) Planejar, se necessário, tarefas de retrabalho e ajuste na execução da
iteração.
(g) Preparar para o marco, se houver marco previsto para a iteração.
2. Executar cada iteração do projeto.
(a) Executar tarefa da iteração.
(b) Monitorar execução de tarefas da iteração.
(c) Avaliar e medir qualidade de execução de tarefa.
(d) Verificar, validar e medir qualidade de produto: resultados de tarefa
executada.
(e) Monitorar e controlar riscos do projeto.
(f) Monitorar e controlar mudanças em requisitos do projeto.
(g) Realizar, se houver, marco de projeto previsto para esta iteração.
2.1.4 Produtos de Trabalho

Os produtos de trabalho gerados ou modificados em atividades transversais
ao projeto de software são:
1. DefTar - Definição de tarefa do projeto

2. CtrlTar - Controle de tarefas do projeto
3. LMP - Laudo de Monitoramento do Projeto
4. LAQ - Laudo de Avaliação da Qualidade do Projeto
5. CtrlPrj - Controle do Projeto
6. RelMarc – Relatório de Execução de Marco do Projeto.
2.2 Orientações Metodológicas

2.2.1 Planejamento do Projeto
O trabalho a ser realizado no projeto deve ser organizado como um conjunto
de atividades (ou subprocessos). Cada atividade é detalhada em um conjunto de
tarefas (pacotes de trabalho). Algumas atividades são realizadas em fases específicas
do projeto; outras são transversais, ou seja, ocorrem ao longo de todo o ciclo de vida
do projeto.
Uma atividade deve identificar eventuais dependências entre as tarefas
que a compõem, definindo a sequência em que o trabalho deve ser realizado e as
oportunidades para paralelismo nesse trabalho.
Toda tarefa do projeto envolve a produção, modificação ou avaliação de
um ou mais componentes, ou produtos de trabalho, do projeto. A definição de cada
tarefa do projeto especifica, detalhadamente, o objetivo da tarefa, a responsabilidade
pela sua execução e os produtos ou resultados esperados dessa execução. Uma tarefa
do projeto está associada a um papel e a uma disciplina específicos.
O planejamento do trabalho do projeto é feito para cada iteração e envolve a
definição de atividades (tarefas do projeto) que devem ser realizadas nessa iteração.
O plano da primeira iteração é gerado no início do projeto. A partir daí uma nova
iteração só pode ser iniciada no projeto quando o plano desta próxima iteração
estiver pronto e disponível para consulta de todos os interessados. Portanto, cada
iteração do projeto (exceto a primeira iteração) deve ser planejada antes do final da
iteração anterior.
2.2.2 Ciclo de Vida de um Pacote de Trabalho no Projeto

A Figura 2.2 mostra os estados de um pacote de trabalho ao longo de sua
existência no projeto. Cada pacote de trabalho é criado na atividade de planejamento
do projeto com status novo e contém uma definição da tarefa a ser feita e dos
componentes a serem produzidos, além de uma estimava de complexidade dos
componentes e de esforço necessário para realizar o trabalho. Opcionalmente, o novo
pacote pode ter a indicação da iteração em que ele deve ser realizado.
Figura 2.2: Ciclo de Vida de um Pacote de Trabalho
Os pacotes de trabalho criados devem ser avaliados quanto à qualidade

antes de serem usados no planejamento do projeto. Qualquer defeito detectado na
definição do pacote muda o seu status para defeituoso. O pacote permanece com
esse status até todos os defeitos serem corrigidos.
Após a qualidade da definição do pacote de trabalho ser validada, ele passa
a ter status definido e aguarda sua inclusão em alguma iteração do projeto.
Ao ser incluído no objetivo de uma iteração, ou se já tiver sido criado com
a indicação da iteração em que ele deve ser realizado, o status do pacote muda para
previsto. O conjunto de pacotes previstos compõe o backlog da iteração. Antes de
poder mudar seu status, todo pacote de trabalho previsto deve ser atualizado com
duas datas limites: data para alocação da responsabilidade pela execução do pacote
e data para realização (entrega) do pacote pelo executor alocado.
Quando o pacote é atribuído (em geral, pelo Líder de Projeto) a um membro
da equipe de projeto na iteração, o status deste pacote passa a ser proposto. Ao
receber a proposta de um pacote de trabalho, o membro do projeto deve avaliar a
definição do pacote e decidir sobre a aceitação ou não dessa proposta. Durante essa
avaliação o membro do projeto pode interagir com o responsável pela definição do

pacote a fim de esclarecer eventuais dúvidas.
Há dois tipos de razões para a recusa de um pacote: impedimento do membro
do projeto, como por exemplo, falta de competência, ou impossibilidade de assumir
o compromisso; e defeito na definição do pacote. Se decidir recusar a atribuição, o
membro do projeto deve indicar as razões para não aceitar o pacote de trabalho.
Se a recusa é por um impedimento do membro do projeto o pacote volta ao status
previsto. Se o motivo da recusa for um defeito do pacote, o seu status passa a ser
defeituoso.
Ao aceitar a atribuição do pacote de trabalho, o membro da equipe de
projeto valida a estimativa de esforço para realizar o trabalho e a data limite para
a entrega do pacote, afirmando o seu comprometimento com aquela unidade de
trabalho do projeto. Além disso, o membro da equipe de projeto deve declarar que
tem a competência necessária ao desempenho do papel previsto na definição do
pacote e que está apto a realizar o trabalho, conforme essa definição, dentro do
esforço e prazos estimados. Se o membro da equipe de projeto não puder fazer essas
declarações, ele deve indicar o seu impedimento e recusar o pacote de trabalho. Um
pacote de trabalho aceito pelo membro da equipe de projeto passa ao status alocado.
Após executar o pacote de trabalho o membro da equipe de projeto faz
a entrega do pacote e seus respectivos componentes produzidos para o projeto.
O pacote de trabalho passa a ter status produzido e é submetido para avaliação
da qualidade. Se essa avaliação aprova o pacote produzido, seu status passa a ser
pronto, que é o estado final do pacote de trabalho no projeto.
2.2.3 Execução do Projeto

A realização (execução) de uma tarefa (pacote de trabalho) do projeto
consiste em cumprir as especificações da tarefa definida, empregando a disciplina
do processo, a fim de gerar um ou mais componentes necessários para completar
o objetivo da iteração. A Figura 2.3 ilustra os principais tipos de componentes
(produtos de trabalho) gerados na execução de um projeto de desenvolvimento de
software.
O componente resultante de cada tarefa do projeto deve ser produzido com
um esforço que pode variar de algumas horas a alguns dias de trabalho, individual
ou em grupo, conforme a alocação da responsabilidade pela execução da tarefa do
projeto seja para um indivíduo ou para um grupo de indivíduos.
Figura 2.3: Componentes gerados em cada fase do processo
2.2.4 Garantia da Qualidade na execução dos pacotes de

trabalho
Os componentes gerados em um pacote de trabalho com status produzido
passam do ambiente de desenvolvimento para o ambiente de homologação do projeto,
onde ocorrem as atividades de verificação e validação desses componentes.
A avaliação da qualidade deve ser feita por um membro da equipe de projeto
que não atuou na construção do componente ou na execução da atividade que é
alvo da avaliação. Caso esta avaliação identifique a necessidade de correções nos
componentes entregues, o status do pacote volta a ser alocado ao membro do projeto,
para que sejam providenciados os ajustes indicados na avaliação da qualidade ainda
na iteração corrente.
Se os ajustes efetuados forem suficientes para garantir a qualidade dos
componentes entregues, o pacote passa a ter status final pronto. Caso contrário,
o Líder de Projeto deve decidir entre a exigência de novas correções ou a recusa
definitiva do pacote.
A avaliação da qualidade contempla a verificação da qualidade da constru-
ção do componente e a validação de sua adequação ao propósito definido para o
componente no projeto. Tipicamente a verificação é feita por meio de algum tipo de
inspeção do componente, inclusive em relação à conformidade com templates e dire-
trizes. A validação de componentes executáveis deve incluir o teste do componente.
2.2.5 Atraso, Recusa e Cancelamento de Pacote de Trabalho

Pode haver recusa definitiva de um pacote de trabalho, e as razões para essa
decisão devem ser registradas. Por exemplo, quantidade ou criticidade de defeitos
nos produtos, número de recusas consecutivas de entregas do mesmo pacote ou

impossibilidade de corrigir o pacote na iteração atual.
O pacote com recusa definitiva é retirado do membro do projeto para o qual
foi alocado, voltando a ter status definido, ou seja, o pacote fica disponível para nova
alocação em alguma iteração do projeto.
Eventualmente o Líder de Projeto pode decidir cancelar um pacote de
trabalho que não é mais necessário. Por exemplo, uma redução no escopo do projeto
pode eliminar os requisitos associados a determinados pacotes. Nesse caso, o pacote
recebe status final cancelado.
Um pacote pode ser cancelado em qualquer estado de seu ciclo de vida. Se o
pacote já tiver sido atribuído a algum membro da equipe de projeto, o cancelamento
deve ser comunicado a todos os que estiveram envolvidos com o respectivo pacote.
Cada atividade que muda o status do pacote de trabalho deve ter uma data
estimada para conclusão. Assim, deve haver, por exemplo, data estimada para a
validação de um novo pacote criado no projeto. O pacote de trabalho é considerado
atrasado se a atividade que trata o estado em que ele se encontra não for concluída
até a data estimada para sua realização.
O Líder de Projeto deve registrar as ações tomadas para o tratamento de
cada pacote em atraso. Entre as ações possíveis estão a retirada do pacote de trabalho
em atraso do membro do projeto para o qual foi atribuído e a realocação desse
pacote para outro membro da equipe de projeto. Se o Líder de Projeto for também
o responsável pelo atraso, essa situação deve ser detectada e relatada nas atividades
de garantia da qualidade do monitoramento do projeto.
2.2.6 Iniciação do Projeto

Antes de iniciar um projeto é preciso fazer a adaptação do presente processo
a situações específicas do projeto, tais como a integração com disciplinas do INF
e a aplicação do processo em projetos muito curtos ou longos. Também deve ser
feita a definição de infraestrutura e ambiente de trabalho, incluindo ferramentas de
apoio, para executar o processo. Nesse sentido, um ambiente de trabalho padrão
para projetos de desenvolvimento de software precisa ser definido pela Fábrica.
O início de cada projeto deve ser formalizado por um Termo de Confiden-
cialidade assinado pelos participantes do projeto. Ao aceitar um papel no projeto, o
participante precisa se comprometer com o plano do projeto e com as suas respon-
sabilidades nele definidas.
2.2.7 Monitoramento Periódico e Marcos de Projeto

A elaboração periódica de laudos de monitoramento da execução do projeto
e de avaliação da qualidade do processo e dos produtos realizados no projeto é um
dos fatores críticos para o sucesso de um projeto.
Monitoramentos periódicos permitem um controle efetivo do projeto, en-
volvendo avaliação e medição de diversos aspectos do projeto, com destaque para:
conformidade da execução dos trabalhos (tarefas do projeto, ajustes e retrabalho)
com o processo definido, qualidade dos produtos gerados, controle de riscos do pro-
jeto, controle de mudanças em requisitos do projeto, controle de retrabalho e ajustes
na execução de cada iteração do projeto; controle de recursos e operações para atingir
um grau de paralelismo adequado ao projeto; avaliação e otimização de indicadores
de qualidade, cronograma, custos e riscos do projeto.
Todo projeto precisa realizar marcos de projeto em pontos predefinidos no
planejamento do projeto. Um Relatório de Execução de Marco do Projeto formaliza a
realização de um marco e faz uma análise ampla da situação do projeto, comparando
o previsto e o realizado em termos de custo, prazo e qualidade.
A Fábrica precisa estabelecer métodos para monitorar essas e outras variá-
veis que definem a efetividade do projeto, usando uma definição organizacional de
métricas e indicadores de projetos de desenvolvimento de software.
2.2.8 Ativos de Processo para Garantia de Qualidade

Para cada componente construído no projeto deve haver um modelo (tem-
plate ou diretriz) que define o padrão de qualidade a ser observado no componente.
Para ser considerado pronto, ou seja, aprovado para uso, um componente gerado no
projeto deve ser avaliado quanto à sua conformidade em relação ao seu modelo de
referência.
Ativos de processo que apoiem as atividades de inspeção da qualidade de
tarefas e de componentes gerados no projeto devem ser elaborados. Cada tipo de
tarefa e cada categoria de componente deveria ter recursos específicos para apoiar
a avaliação de sua qualidade. Um dos recursos mais úteis é a lista de verificação
(checklist) que se aplica tanto para a inspeção de produtos de trabalho quanto para
a garantia de qualidade de processos executados.
2.2.9 Controle de Mudanças no Projeto

Todo componente pronto (aprovado para uso) fica sujeito ao controle de
mudanças do projeto, que define os seguintes estados para uma solicitação de
mudança: nova, analisando, modificando, reprovada e realizada.
A solicitação de mudança deve ser avaliada quanto a natureza da mudança

(defeito ou evolução), a sua causa raiz (tipo de defeito ou motivo da evolução)
e a prioridade (impacto de realizar e de não realizar a mudança). Esses estados e
atributos deveriam ser armazenados em um banco de dados do projeto para produzir
relatórios úteis sobre a situação de mudanças no projeto.
CAPÍTULO 3
Fase de Concepção do Software
3.1 Síntese da Fase

3.1.1 Propósito
A fase de Concepção (Figura 3.1) visa obter um acordo entre a organização
adquirente e a organização fornecedora do software em relação aos principais
requisitos do sistema e do software e sobre o processo que deve ser executado para
realizar o projeto.
Figura 3.1: Atividades de Concepção do Software

Como consequência da execução bem sucedida da fase de Concepção do
Software são gerados os seguintes resultados:
1. O início do projeto é autorizado, com definição do responsável pela sua

gerência.
2. As partes interessadas no projeto são identificadas e seus representantes são
designados.
3. As responsabilidades pelo desenvolvimento, implantação e sustentação do
sistema e do software são definidas.
4. Os recursos necessários para desenvolvimento, implantação e sustentação do
sistema e do software são estimados e aprovados pelas partes interessadas.
5. O conceito do produto de software é aprovado, contemplando objetivos,
escopo, características e riscos do sistema e do software; e principais requisitos,
restrições, prioridades e critérios de sucesso das partes interessadas em relação
ao software.
6. O ambiente de trabalho da equipe técnica e o paradigma arquitetural do
software são definidos e aprovados.
7. O plano geral do projeto é aprovado, contemplando objetivos, escopo, carac-
terísticas e riscos do projeto; requisitos, restrições, prioridades e critérios de
sucesso das partes interessadas em relação ao projeto; e recursos necessários e
cronograma com marcos do projeto.
3.1.3 Atividades
A fase de Concepção do Software é definida como um subprocesso do PDS.
As atividades e tarefas desta fase do processo estão representadas na Figura 3.1:
1. Elaborar Termo de Abertura para o projeto.

(a) Identificar partes interessadas no sistema e suas expectativas para o
projeto.
(b) Delimitar o escopo do trabalho a ser realizado no projeto.
(c) Planejar responsabilidades pela implantação e sustentação do software.
(d) Definir objetivos, prioridades e critérios de sucesso para o software.
(e) Avaliar riscos, estimar recursos necessários e planejar os marcos do
projeto.
2. Definir os Conceitos Operacionais do Sistema.
(a) Identificar entidades externas (atores) que precisam interagir com o
software e definir a natureza dessa interação em cenários (casos de uso)
de alto nível.
(b) Estabelecer consenso sobre as características chave do software e do
projeto.
(c) Propor alternativas de solução e selecionar a solução de software mais

adequada ao sistema.
3. Definir o ambiente de trabalho para o projeto.
(a) Definir e configurar repositórios de desenvolvimento e de homologação
para os elementos de software (código fonte e demais tipos de elementos).
(b) Definir e configurar a infraestrutura tecnológica (linguagens, frameworks
e ferramentas CASE) a ser utilizada no projeto.
4. Definir a arquitetura do software.
(a) Especificar requisitos e restrições arquiteturais do software.
(b) Definir visão externa, mostrando as relações entre o software e o seu
ambiente operacional.
(c) Definir visão interna, mostrando as relações entre os elementos que
compõem o software.
5. Planejar o Projeto de Desenvolvimento do software.
(a) Definir, estabelecer e disponibilizar o ambiente de trabalho para o projeto.
(b) Instanciar o processo para o projeto.
(c) [Opcional] Adaptar o processo instanciado às especificidades do projeto
(ciclo de vida, fases, marcos e baselines).
(d) Definir Escopo Global do Projeto: Estrutura Analítica de Projeto (EAP)
abstrata, com pacotes de trabalho (produtos e serviços a entregar) de
granularidade alta.
(e) Estimar tamanho e complexidade do escopo e esforço/custo do projeto.
(f) Definir cronograma, com prazos e dependências entre iterações.
(g) Definir orçamento, com valor de recursos (humanos ou materiais).
(h) Criar Plano de Riscos, com mapeamento de ameaças e oportunidades
do projeto e suas respectivas probabilidades e estimativa de impacto no
projeto.
(i) Criar Plano de Pessoal, com papéis e calendário de disponibilidades de
cada pessoa, e agenda de treinamentos.
(j) Contratar Fornecedor, se necessário.
(k) Criar Plano de Comunicação, com emissor, destinatários, assunto (obje-
tivo da comunicação),anexos e meio (canal) para cada comunicação rele-
vante.
(l) Criar Plano de Medição/Qualidade, com definição de responsabilidade e
periodicidade (ou evento deflagrador) para cada ação de avaliação e/ou
medição.
(m) Criar Plano de Configuração, com definição de estrutura de repositórios

e atribuição de responsabilidade pela sua segurança e disponibilidade.

Os produtos de trabalho gerados ou modificados na fase de Concepção do
Software são:
1. TrmAbr - Termo de Abertura do Projeto

2. ConOps - Conceitos Operacionais do Sistema
3. AmbPrj - Ambiente do Projeto
4. ArqSw - Arquitetura do Software
5. PlanProj - Plano Integrado de Projeto

A fase de Concepção do Software é caracterizada por uma intensa colabo-
ração entre as duas principais organizações, ou unidades organizacionais, envolvidas
no projeto: a organização adquirente, ou cliente do projeto; e a organização forne-
cedora, ou desenvolvedora, do software. Essa colaboração tem por objetivo obter
consenso sobre (a) os principais requisitos do software e do sistema de informação
em que ele será utilizado; e (b) sobre os processos a serem empregados para realizar
o projeto.
O Termo de Abertura deveria ser o primeiro documento gerado como
resultado dos esforços do projeto, pois ele sintetiza informações preliminares sobre
o projeto e identifica os responsáveis pelo detalhamento dessas informações durante
a condução do projeto.
Na Fábrica de Software do INF, o início de um projeto de desenvolvimento
de software é determinado pelo Processo de Gestão de Portfólio de Projetos. O
gestor deste processo envia um comunicado, geralmente por e-mail, a um colaborador
da Fábrica, designando-o como responsável pela liderança do projeto, descrevendo
sucintamente o objetivo do projeto e, possivelmente, alocando colaboradores para
compor a equipe preliminar do projeto.
O colaborador designado como líder do projeto deveria iniciar os trabalhos
com a criação do Termo de Abertura do Projeto (Project Charter ), que é o
documento que formaliza o início do projeto de desenvolvimento de software.
O Termo de Abertura contém definições preliminares de escopo, cronograma,
orçamento, riscos, equipe e entregas planejadas para o projeto.
3.2.1 Escopo preliminar

A definição do escopo envolve a descrição detalhada dos principais resul-
tados (produtos e serviços) esperados do projeto. Um projeto de desenvolvimento
de software contempla duas definições de escopo: o escopo do projeto, que define
produtos e serviços a entregar e premissas e restrições a cumprir; e o escopo do
software, que define e justifica objetivos e não objetivos do produto de software que
deve ser desenvolvido no projeto.
Em projetos de grande complexidade, poderia ser criado um Plano de Ge-
renciamento do Escopo, que descreve como será realizada a definição, o desenvolvi-
mento, o monitoramento, os controles e a análise (verificação) do escopo. Este plano,
quando utilizado no projeto, deve ser um dos planos auxiliares que compõem o plano
principal de gerenciamento do projeto. Segundo o Guia PMBOK® [PMI 2013], o
gerenciamento do escopo do projeto abrange as seguintes atividades:
• Planejar o gerenciamento do escopo: documentar como o escopo será definido,

validado e controlado;
• Coletar os requisitos: definir e documentar as necessidades das partes interes-
sadas para atingir os objetivos do projeto;
• Definir o escopo: realizar uma descrição detalhada do projeto e do produto;
• Criar uma Estrutura Analítica do projeto (EAP): subdividir os produtos e o
trabalho em componentes mais gerenciáveis;
• Validar o escopo: formalizar a aceitação dos produtos do projeto;
• Controlar o escopo: monitorar o escopo e gerenciar alterações na linha de base
do escopo.
A definição do escopo do projeto de software deve ser isenta de ambiguidades

e deve ser inteligível para os níveis gerenciais e técnicos. O escopo deve ser definido
a partir dos requisitos coletados das partes interessadas e precisa ser detalhado
o suficiente para orientar o desenvolvimento do software de forma consistente e
completa.
Uma declaração de escopo de software deve ser delimitada, ou seja, conter
dados quantitativos declarados explicitamente, restrições e/ou limitações e fatores
facilitadores, bem como o registro dos responsáveis pelas informações registradas.
Uma boa definição de escopo de software deve responder questões como:
• Contexto - Como o software a ser construído se encaixa no contexto de um
sistema maior, do produto ou do negócio? De que maneira ele colabora para o
desempenho ou a lucratividade do negócio? Que restrições sua implementação
pode oferecer à flexibilidade que é necessária para adequar-se às situações de
mercado?
• Objetivos da informação - Que dados serão necessários para seu perfeito fun-
cionamento? Como devem ser obtidos e organizados? Quem será responsável
por mantê-los atualizados?
• Funções e desempenho - Que funções o software deve desempenhar para trans-
formar dados em vantagem competitiva para a empresa? Existem característi-
cas especiais de desempenho do sistema que possam ser críticas para o negócio
da empresa?
3.2.2 Equipe preliminar do projeto

Uma equipe de desenvolvimento de software deve ser definida com base nos
papéis necessários, levando em consideração aspectos como: liderança, organização
(estrutura da equipe) e coordenação. Deve-se levar em conta o tamanho da equipe.
Quanto maior o número de membros da equipe, maior a quantidade de caminhos
possíveis de comunicação, o que pode ser um problema, uma vez que o número de
pessoas que podem se comunicar com outras pode afetar a qualidade do produto
resultante.
No ambiente da Fabrica de Software há a equipe de desenvolvimento,
composta pelo Representante da Fábrica, Líder de Projeto e Equipe de Projeto.
É preciso também destacar que os Clientes tem o seu papel de extrema importância
e que outras partes interessada ou seu representantes também poderão atuar no
projeto.
3.2.3 Riscos preliminares do projeto

O mapeamento de riscos é muito importante, principalmente sob o ponto
de vista de negócio. As seguintes ferramentas para identificação de riscos podem
ser utilizadas (em separado ou em conjunto) durante a execução de um projeto
[PMI 2013]:
• Revisão da documentação: análise da documentação existente em projetos
similares;
• Técnicas de reunião de informação: brainstorming, Delphi, entrevista com
especialistas e matriz SWOT;
• Checklists: elaborados a partir de dados históricos de projetos similares;
• Análise de premissas: identificar as premissas adotadas na concepção do
projeto e levantar os riscos de não cumprimento dessas premissas;
• Técnicas de diagramação: diagrama de Causa-e-Efeito e de Influência.
A atividade de identificar riscos e o seu plano de ação são dinâmicos,
sendo assim fundamental a constante monitoração do processo para evitar surpresas
indesejadas. Na escolha de quais riscos devem ser gerenciados, modelos de gestão de

riscos são úteis, porém sua aplicação deve ser muito criteriosa. Os riscos podem
ser categorizados, por exemplo, em riscos técnicos, gerenciais, organizacionais e
externos. Esta divisão dos riscos tem o objetivo de focar os esforços nos riscos certos.
3.2.4 Aprovação do início do projeto

Pelo fato do Termo de Abertura ser o documento que formaliza o início de
um projeto, confere autoridade ao gerente de projeto e agrupa todas as informações
necessárias para a execução das atividades envolvidas, é necessário o preenchimento e
assinatura do documento pelo Cliente, pelo Representante da Fábrica e pelos outros
Representantes de Partes Interessadas (se houver). A Figura 3.2 mostra as principais
atividades necessárias para elaboração do Termo de Abertura de um projeto.
Figura 3.2: Atividades de Abertura do Projeto
3.2.5 Definição dos Conceitos Operacionais do Sistema

Definir conceitos operacionais do sistema significa descrever, em alto nível
e na perspectiva do usuário, as principais características do software e do sistema
em que ele atuará, considerando todo o ciclo de vida: desenvolvimento, implantação
e sustentação do software.
Deve-se elaborar o documento de Conceitos Operacionais do Sistema (Co-
nOps), que descreve sucintamente o Sistema de Informação que existe na organi-
zação, destacando as necessidades ou oportunidades que servem de motivação ou
justificativa para a modificação desse Sistema de Informação. Uma parte dessa mo-
dificação decorre da inclusão ou alteração de um componente de software, que é
objeto do projeto. O principal objetivo do ConOps é mostrar como o Sistema de

Informação funcionará a partir da integração do novo componente de software.
3.2.6 Definição do Ambiente Operacional do Projeto

A Definição do Ambiente Operacional do Projeto deve estabelecer e dispo-
nibilizar um ambiente de trabalho para o projeto, com base no sistema de gerência
de configuração padrão da Fábrica (a ser definido).
• Repositório de componentes definido e configurado para o projeto.

• Ferramentas CASE instaladas e configuradas para o projeto.
• Permissões de acesso ao repositório e às ferramentas configuradas para os
membros da equipe de projeto com base nos seus respectivos papéis definidos
no projeto.
O ambiente de trabalho do projeto, que inclui linguagens e ferramentas

usadas no desenvolvimento do software, deveria ser definido para garantir a compa-
tibilidade entre o produto de software gerado pelo projeto e o ambiente operacional
utilizado pelo Sistema de Informação, que é definido no ConOps; e facilitar a imple-
mentação da arquitetura do software, definida em ArqSw.
3.2.7 Modelagem da Arquitetura do Software

Este estágio tem como propósito definir as características essenciais do soft-
ware, de seu ambiente operacional e a forma de integração entre os macrocompo-
nentes do software.
• Componentes internos e suas interdependências.

• Relacionamentos com componentes externos.
• Aspectos de Segurança do Software.
• Aspectos de Confiabilidade (tolerância a falhas).
• Aspectos de Portabilidade.
• Aspectos de Desempenho.
• Aspectos de Manutenibilidade.
• Aspectos de Usabilidade.
• Aspectos de Compatibilidade (coexistência e interoperabilidade).
• Protótipo operacional da arquitetura.
O documento de Arquitetura do Software (ArqSw) deve ser elaborado para

identificar alternativas de solução para implementar o software descrito no ConOps,
selecionando a alternativa arquitetural de software mais adequada para atender os
requisitos e restrições do Sistema de Informação e do software subjacente.
3.2.8 Planejamento do Projeto de Software

Esta etapa busca documentar as estimativas de software a serem usadas no
planejamento e acompanhamento do Projeto de Software, planejar e documentar
as atividades e os compromissos do projeto de desenvolvimento de software e
obter concordância das pessoas envolvidas quanto a compromissos no projeto de
desenvolvimento de software.
As seguintes atividades são necessárias para obter um Planejamento do
Projeto de Software adequado: Elaboração de Plano de Projeto de Software e Planos
de Iteração, contendo estimativas de esforço, e recurso para o desenvolvimento de
software. Plano de Projeto de Software,Planos de Iteração, Lista de Riscos, Avaliação
de Iterações e Fases. Gerentes de projeto e demais profissionais envolvidos participam
do planejamento bem como do desenvolvimento iterativo e incremental, no qual os
compromissos de projeto são revisados e validados com o cliente ao final de cada
iteração e fase do processo. Só após o gerente de projeto obter a concordância dos
grupos envolvidos, é que a iteração seguinte será iniciada.
CAPÍTULO 4
Fase de Elaboração do Software
4.1 Síntese da fase

4.1.1 Propósito
A fase de Elaboração (Figura 4.1) visa aprofundar a compreensão sobre o
domínio do problema e sobre a forma de atender as necessidades dos usuários e
demais partes interessadas no projeto. Para isso deve ser construída uma linha de
base arquitetural para orientar a implementação do software, corroborando o acordo
entre adquirente e fornecedor para continuar o projeto.
Figura 4.1: Atividades de Elaboração do Software

Como consequência da execução bem sucedida da fase de Elaboração do
1. Requisitos funcionais e não funcionais são especificados.

2. Esquema conceitual de banco de dados do software é modelado e dicionarizado.
3. Modelo da interação entre usuário e software é definido.
4. Componente executável da arquitetura do software é construído e validado.
5. Riscos do projeto são revisados e atualizados.

6. Requisitos de software são aprovados pelo cliente e aceitos pela equipe técnica
do projeto.
4.1.3 Atividades
A fase de Elaboração do Software é definida como um subprocesso do PDS.
1. Identificar ou refinar funcionalidades do software.

2. Identificar ou refinar requisitos de qualidade do software.
3. Identificar ou refinar base de dados lógica do software.
4. Identificar ou refinar requisitos de usabilidade.
5. Verificar e validar a especificação de requisitos do software.
6. Estabelecer uma base arquitetural sólida para o sistema e o software.
7. Instanciar e validar a arquitetura do software.

Os produtos de trabalho gerados ou modificados na fase de Elaboração do
Software são:
1. Especificação de Requisitos de Software, composta de:

• Cenários operacionais do software
• Protótipo de interface com o usuário
• Esquema conceitual de banco de dados
2. Componente operacional da Arquitetura do Software

A especificação de requisitos de software estabelece a base para um acordo
entre clientes e fornecedores/contratados sobre como o produto de software deve
funcionar [ISO/IEC/IEEE 2018]. Ela permite uma avaliação rigorosa dos requisitos
antes de iniciar os esforços de construção (isto é, projeto, implementação e integra-
ção) do software com o objetivo de reduzir o retrabalho no projeto. A Figura 4.2
ilustra as principais atividades relacionadas à especificação de requisitos em um
projeto de desenvolvimento de software.
O documento de especificação de requisitos de software lista requisitos
suficientes e necessários para o desenvolvimento do projeto. A equipe técnica de
Figura 4.2: Atividades de Especificação de Requisitos de

Software
projeto precisa ter um entendimento claro e completo dos requisitos para que os
produtos do projeto sejam consistentes com esses requisitos. Todavia, o documento
de especificação de requisitos não contempla todos os detalhes e expectativas das
partes interessadas. Além disso, requisitos podem ser alterados ao longo do projeto.
Por isso, é necessário manter comunicações contínuas entre clientes e a equipe do
projeto durante todo o ciclo de vida de desenvolvimento de software.
Nem todos os requisitos precisam ser especificados na fase de Elaboração, já
que requisitos podem ser adicionados, modificados e excluídos, mediante negociação
entre as partes interessadas, em qualquer fase do projeto. A fase de Elaboração tem
como meta especificar pelo menos 70% dos requisitos de maior prioridade para as
partes interessadas no projeto.
4.2.1 Requisitos de Sistema/Negócio e Requisitos de Soft-

ware
Requisitos de software são modelados após a especificação de requisitos do
negócio, que definem o sistema de informação em que o software deve atuar. Esses
requisitos do sistema são geralmente definidos em um documento à parte, denomi-
nado Conceitos Operacionais do Sistema (ConOps), que descreve os requisitos sob
o ponto de vista das partes interessadas no negócio. Enquanto o ConOps usa a ter-
minologia do domínio do negócio, o documento de Especificação de Requisitos de
Software (ERS) descreve os requisitos das partes interessadas sob o ponto de vista
do desenvolvedor e do mantenedor do software, usando terminologia de Engenharia
de Software.
Tipicamente o sistema de informação é definido no ConOps por meio de um
conjunto de funcionalidades, ou cenários operacionais, que definem interações entre
o usuário e o sistema. Algumas dessas funcionalidades são realizadas pelo software,
ou seja, parte dos requisitos funcionais e não funcionais do sistema são alocados
ao software. O escopo da ERS é restrito a estes requisitos do sistema alocados ao
software. Assim, o documento ERS descreve o subconjunto dos requisitos do sistema
de informação que deve ser atendido pelo software e especifica detalhadamente os
cenários operacionais identificados para o sistema.
4.2.2 Eliciação de Requisitos

O processo de Engenharia de Requisitos é iniciado com a eliciação, ou
identificação, de necessidades e expectativas das partes interessadas em relação
ao sistema e ao software. A eliciação de requisitos é um processo de observação
e descoberta de elementos do ambiente de negócio em que o software atuará.
Devem-se identificar as pessoas que terão contato direto com o software, isto
é, usuários, e também aquelas que são afetadas pelo sistema em que o software se
insere, como gestores e clientes do negócio. Todas essas pessoas precisam contribuir
para o fornecimento de informações relevantes para a especificação dos requisitos
do software. Para isso são usadas técnicas como etnografia, oficinas de trabalho,
prototipagem, entrevistas, questionários e brainstorming.
Inicialmente é preciso definir um escopo preliminar, em uma página, descre-
vendo o problema ou situação em que o software deve atuar e as partes interessadas
em resolver o problema ou abordar a situação descrita (conhecidas como stakehol-
ders). Devem ser identificadas pessoas que podem representar cada parte interessada
e envolver essas pessoas no processo de Engenharia de Requisitos, visando a garantir
que o sistema atenda as necessidades de todas as suas partes interessadas. Os repre-
sentantes dos stakeholders devem ajudar a equipe técnica na eliciação dos requisitos,
identificando todas as atividades que estão envolvidas no sistema e definindo os de-
tlhes dessas atividades: quem faz, por que faz, como faz, quando faz, quantas vezes
faz, quais dados usa e identificando, ainda, possíveis exceções e caminhos alternativos
na realização de cada atividade do sistema de informação.
4.2.3 Análise, Modelagem e Negociação de Requisitos

Após a identificação de necessidades e expectativas das partes interessadas
em relação ao sistema de informação, é necessário analisar as informações obtidas
na eliciação de requisitos e transformá-las em um conjunto de modelos de requisitos
de software. Cada modelo representa uma determinada perspectiva dos requisitos
do software, como por exemplo:
• O modelo de requisitos funcionais envolve a criação e refinamento de cenários

operacionais do sistema, definindo como os usuários interagem com o sistema.
• O modelo de banco de dados conceitual pode ser construído a partir da análise
dos cenários operacionais, identificando classes de entidades, atributos dessas
classes e relacionamentos entre os dados que elas representam.
• O modelo de interface usuário-sistema define a forma como as informações são
obtidas e apresentadas ao usuário durante a execução dos cenários operacio-
nais.
• O modelo de segurança do sistema indica formas para identificação e auten-
ticação de usuários e para definição de permissão de acesso de cada tipo de
usuário às funcionalidades do software.
•
A modelagem de requisitos envolve a negociação de requisitos, que é a ativi-

dade responsável por conciliar conflitos que podem surgir entre partes interessadas
nos mesmos requisitos. Por exemplo, clientes e usuários podem pedir mais do que
pode ser alcançado com os recursos limitados do projeto de desenvolvimento de soft-
ware. Ou ainda, clientes ou usuários podem propor necessidades conflitantes. Todos
os conflitos identificados na modelagem de requisitos devem ser conciliados por meio
de negociação entre as partes interessadas. Após a negociação alguns requisitos po-
dem ser eliminados, combinados ou modificados, de forma que cada uma das partes
fiquem satisfeitas.
4.2.4 Especificação de Requisitos

A Especificação de Requisitos de Software (ERS ou Software Requirements
Specification - SRS) é um termo geral que designa a documentação criada para
detalhar os requisitos que o software precisa atender. Esta especificação (ou docu-
mentação) de requisitos pode ser feita de diversas formas e com diferentes níveis de
formalismo. Neste sentido, uma Especificação de Requisitos de Software (ERS) pode
ser:
• um único documento escrito, contendo requisitos funcionais e não funcionais

(ou requisitos de qualidade) do software, classificados e organizados para
facilitar a leitura e a compreensão do software como um todo;
• um conjunto de documentos independentes, contendo modelos textuais, gráfi-
cos e matemáticos, que definem diferentes componentes e aspectos dos requi-
sitos do software;
• um hipertexto, wiki ou sítio Web contendo páginas que definem requisitos
funcionais e não funcionais do software;
• um simples protótipo da interface do software com o usuário, mostrando o
formato de telas e os fluxos de navegação entre elas.
De fato, uma ERS pode ser qualquer combinação dessas diversas alternativas
para documentação de requisitos. Qualquer que seja a forma adotada para especi-
ficação dos requisitos, é importante que essa especificação seja clara e demonstre
(a) a necessidade do cliente; e (b) a solução conceitual acordada para atender essa
necessidade.
Dessa forma, a especificação de requisitos deve ser flexível o suficiente para
que cada equipe, projeto ou organização defina a melhor maneira de realizá-la. Em
geral sistemas grandes são especificados por documentos textuais complementados
por descrições e modelos gráficos, enquanto sistemas menores são definidos apenas
por meio de casos de uso ou histórias de usuário do software e protótipos de interface
com o usuário.
A Especificação de Requisitos de Software pode ser documentada com base
no template proposto no Apêndice A.2.
4.2.5 Verificação e Validação de Requisitos

Verificação e validação de requisitos são atividades relacionadas à garantia
da qualidade da especificação de requisitos. A verificação de requisitos avalia se
a especificação dos requisitos foi construída corretamente, segundo as normas e
padrões de Engenharia de Requisitos, enquanto a validação de requisitos avalia
se o produto de software correto foi definido na especificação de requisitos, em

conformidade com as necessidades do negócio e das partes interessadas.
A verificação envolve, por exemplo, a análise de que todos os tipos de re-
quisitos de software foram considerados, tais como requisitos funcionais e não funci-
onais, requisitos de qualidade, restrições e características do ambiente operacional.
Já a validação envolve a análise de que o software especificado atende as necessida-
des e expectativas do cliente, do sistema e do negócio. Embora tenham propósitos
diferentes, a execução das atividades de verificação e validação podem utilizar as
mesmas técnicas, tais como a leitura e inspeção de requisitos e a análise baseada em
perspectivas.
É natural que atividades de revisão de requisitos apontem alterações nos
documentos de requisitos. Essas alterações devem ser realizadas e novas revisões
precisam ser executadas, de forma que no final da fase de Elaboração seja estabele-
cida uma compreensão sólida dos requisitos mais críticos que impactam as decisões
de arquitetura do software e de planejamento do projeto.
Algumas alterações podem impactar a baseline de plano de projeto, por
isso as alterações devem ser confrontadas como o plano e ajustes devem ser feitos
conforme necessário, por exemplo, para estimar o esforço de novos requisitos ou para
adequar o projeto a mudanças na definição do ambiente operacional. É essencial que
o plano defina, no final de cada iteração, a entrega de um produto de trabalho que
forneça o valor para as partes interessadas no projeto.
As partes interessadas precisam concordar que os requisitos definidos po-
derão ser atendidos se o plano atual do projeto for executado para desenvolver o
software, usando a arquitetura de software selecionada. A quantidade de alterações
deve diminuir durante as iterações da fase de Elaboração, mas é necessário alocar
algum tempo em cada iteração para o gerenciamento de mudanças em requisitos.
4.2.6 Componente Operacional da Arquitetura

Além da especificação de requisitos do software, a fase de Elaboração tem
como objetivo a criação de uma base arquitetural sólida para o software. O conceito
de arquitetura do software é fundamental para o presente processo e por isso é
necessário identificar boas práticas de projeto arquitetural de software de modo
que o esforço investido na definição inicial de uma arquitetura mais detalhada
seja compensado pela mitigação de riscos associados a deficiências arquiteturais do
software.
O termo componente operacional da arquitetura significa um elemento
de software, incluindo obrigatoriamente código fonte, que: (a) implementa uma fun-
cionalidade típica do software; e (b) segue fielmente as recomendações da arquitetura

de software definida.
A ideia de implementar este componente ainda na início do projeto é
estabelecer uma base arquitetural sólida para a construção do software, por meio de
uma prova de viabilidade e adequação do paradigma arquitetural selecionado.
A criação de uma prova de conceito para a arquitetura do software estabelece
uma base estável para o início do trabalho de design e de implementação, que é o
foco da fase de Construção. A arquitetura do software é selecionada ainda na fase de
Concepção, mas pode ser ajustada e detalhada com base nos requisitos identificados
na fase de Elaboração, notadamente nos requisitos não funcionais, que têm grande
impacto na arquitetura do sistema, e na avaliação de riscos identificados para o
projeto. A implementação de um componente operacional valida a estabilidade
da arquitetura e serve como um modelo de referência para o trabalho da fase de
Construção.
4.2.7 Arquitetura de Software e Riscos Técnicos do Projeto

Construir um componente executável da arquitetura, a partir do qual seja
possível construir outros componentes seguindo as mesmas diretrizes, reduz os riscos
associados ao atendimento de requisitos não funcionais que impactam a arquitetura,
como por exemplo desempenho, confiabilidade e portabilidade.
Vale observar que a construção de um componente operacional da arquite-
tura não significa criar e disponibilizar toda a infraestrutura arquitetural do software
antes de sua necessidade no projeto. Isso poderia levar a esforços de produção de
soluções complexas e de capacidades que não agregam valor para o cliente em um
primeiro momento de utilização do software.
É preciso, portanto, diferenciar a arquitetura do software, que é um con-
junto de diretrizes que orientam a organização dos componentes, da infraestrutura
necessária para aplicar todo o conjunto de diretrizes estabelecidas pela arquitetura.
O foco na arquitetura é para evitar riscos associados a requisito não
funcionais desconhecidos ou mal compreendidos e a aplicação de tecnologias que
não são consistentes com as recomendações arquiteturais. O componente operacional
deve mostrar a viabilidade de implementação de uma arquitetura suficientemente
compreendida, viável de ser implementada e robusta em relação aos riscos técnicos
identificados para o projeto, tais como o risco de ser necessário escalar a solução
para um número significativamente maior de usuários.
É necessário prover orientações metodológicas para definir, validar e criar
a linha de base da arquitetura, utilizando a lista de riscos do projeto para ajustar
a arquitetura selecionada na fase de Concepção. Essas atividades podem incluir a
seleção de componentes reutilizáveis já desenvolvidos e a tomada de decisões sobre

compra, construção e reutilização de componentes.
4.2.8 Preparação para Aceitação do Software

A fase de Elaboração define o produto de software que deverá ser construído.
Logo, é possível estabelecer o ambiente de teste para o software e iniciar o desen-
volvimento de testes. Apesar do código fonte ainda não existir, é possível projetar e
até implementar os primeiros testes de aceitação e alguns testes de integração. De
fato, muitas metodologias de desenvolvimento de software, como o XP, recomendam
definir testes antes de escrever o código a ser testado.
Os desenvolvedores precisam estar aptos para criar os testes de unidade e
devem saber como utilizar as ferramentas de teste selecionadas para o projeto. É
importante ter um ambiente de teste organizacional e padronizado, para minimizar
o esforço de cada projeto no sentido de criar e disponibilizar ativos de teste.
CAPÍTULO 5
Fase de Construção do Software
5.1 Síntese da fase

5.1.1 Propósito
A fase de Construção (Figura 5.1) visa desenvolver, integrar, verificar e
validar, de forma iterativa e incremental, os elementos (componentes e serviços) que
compõem o software, em conformidade com a linha de base arquitetural estabelecida
e com os requisitos especificados no projeto.
Figura 5.1: Atividades de Construção do Software

Como consequência da execução bem sucedida da fase de Construção do
1. Design detalhado de componentes do software é elaborado.

2. Código fonte funcional é desenvolvido e integrado.
3. Qualidade de componentes de design e código é avaliada e aprovada.
4. Ambientes e ativos de processo adequados para testes são disponibilizados.
5. Testes de unidade e de integração do software são planejados e executados.
6. Resultados de testes do software são avaliados e aprovados.
5.1.3 Atividades
A fase de Construção do Software é definida como um subprocesso do PDS.
1. Projetar componente para atender requisitos.

2. Desenvolver componente projetado.
3. Integrar componentes.
4. Testar componentes.
5. Validar solução integrada.
6. Verificar, validar e liberar componentes de software completos e prontos para
uso.
7. Controlar evolução e mudanças em múltiplas versões da configuração.

Os produtos de trabalho gerados ou modificados na fase de Construção do
Software são:
1. Design de Componente do Software

2. Código Fonte de Componente do Software
3. Registro de mudança em configuração (Commit)
4. Plano de Teste do Software
5. Resultado de Execução de Teste do Software

A fase de Construção implementa o código fonte de cada componente do
software e consome grande parte do tempo de desenvolvimento do projeto. Boas
práticas de programação e de controle do código ajudam a garantir qualidade e
efetividade no trabalho desta fase.
5.2.1 Boas Práticas em Programação

Para se ter um código de qualidade, não basta que ele funcione corre-
tamente. A literatura de Engenharia de Software descreve inúmeras práticas que
contribuem para a qualidade no desenvolvimento de software [McConnell 2004,
Sommerville 2011, Aéce 2020]. Destacamos algumas delas que ajudam a manter o
código mais legível e fácil de compreender e de modificar.
Uma prática simples, mas que se não observada dificulta muito a compre-
ensão do código, é a endentação, ou seja, o espaço que se deixa entre a margem e o
começo da linha escrita.
Em algumas linguagens de programação, endentar é tão importante que faz
parte de sua sintaxe; para iniciar e fechar blocos de códigos, não é necessário usar
separadores como chaves ou colchetes, pois o compilador da linguagem consegue
interpretar a endentação para identificar o início e o fim do bloco de código. Na
maioria das linguagens, porém, a endentação não é considerada pelo compilador,
servindo apenas para facilitar a leitura do código por humanos. É importante ter
um padrão de endentação uniforme ao longo de todo o código de um software.
A inclusão de comentários e documentação sobre o código é outra prática
que pode contribuir para a qualidade do software. No momento em que se está
programando fica clara a finalidade de cada classe, método ou variável. No entanto,
à medida que o tempo passa, essa finalidade pode se tornar menos clara. Assim
comentários podem ser usados para ajudar na compreensão do código, explicando
o algoritmo ou a lógica usada e mostrando o objetivo de cada construto do código
(variável, método ou classe, por exemplo).
Neste sentido, a documentação complementar do projeto também pode des-
crever especificidades do código, de maneira que uma pessoa possa compreender vá-
rios aspectos do código apenas pela análise de arquivos de documentação. Exemplos
desses arquivos incluem descrições arquiteturais e de design detalhado do software.
Outra prática que contribui para a legibilidade e analisabilidade do código
é o uso de convenções de nomes. O uso de nomes adequados e padronizados passa
informações que ajudam na compreensão do código, indicando, por exemplo, o tipo
de dado que uma variável pode armazenar ou o que um determinado método faz.
Além da qualidade relacionada à leitura do código, as boas práticas de
programação requerem o devido tratamento de possíveis erros que podem ocorrer
durante a execução do software. Este tratamento de erro é de responsabilidade do
programador e precisa garantir que o código vai ter um tratamento adequado para
cada situação que possa ocorrer em tempo de execução [McConnell 2004].
Ao detectar um erro, é recomendável que a função faça o lançamento de uma
exceção em vez de retornar um código de erro. Este tipo de retorno sobrecarrega a
chamada do método e a função chamadora pode facilmente esquecer de verificá-lo.

Logo, o método que detecta o erro deve acionar o seu tratamento. Uma boa prática
é definir o fluxo do método separando as regras de negócio do tratamento de erros
exceções. Para cada erro deve haver uma mensagem informativa mencionando a
operação que falhou e o tipo de falha. Por exemplo: "Erro na leitura do arquivo X.
Rede de comunicação indisponível".
5.2.2 Controle de Evolução do Código

Controle do código-fonte é a prática de monitoramento e gerenciamento de
alterações no código [Fowler]. Os sistemas de Source Control Management (SCM
– Gerenciamento de Controle do Código) disponibilizam um histórico de execuções
de desenvolvimento de código, assim como ajudam a resolver conflitos durante a
mesclagem de contribuições de várias origens.
Este tipo de sistema permite rastrear as alterações no software, observar
como ele se desenvolve ao longo do tempo e, se necessário, recriar as versões
anteriores do software. Essas capacidades são fundamentais para a coordenação de
uma equipe de vários programadores, todos trabalhando em uma base de código
comum. Registrando as alterações que cada desenvolvedor faz, é possível acompanhar
muitas linhas de trabalho de uma só vez e ajudar os desenvolvedores a descobrir como
mesclar essas linhas de trabalho.
O fluxo de trabalho de desenvolvimento de software depende muito do
contexto, em particular da estrutura social da equipe e das práticas de construção
de software que a equipe segue. Existem vários padrões que permitem que as equipes
usem a ramificação de maneira eficaz, concentrando-se na integração do trabalho de
vários desenvolvedores e organizando o caminho para os lançamentos de produção.
O Apêndice B.1 descreve uma ferramenta muito utilizada para controle de código e
um possível fluxo de trabalho baseado nesta ferramenta.
Além dos sistemas de SCM, outro tipo de ferramenta é essencial para o
gerenciamento do código são os sistemas de integração e/ou entrega contínua de
software (CD/CI - continuous delivery/ continuous integration). O Apêndice B.2
destaca a ferramenta Jenkins, que ajuda a automatizar as partes do desenvolvimento
de software relacionadas à construção, teste e implantação, facilitando a integração
contínua e a entrega contínua do código.
5.2.3 Verificação e Validação de Código

O objetivo da Validação e da Verificação é assegurar que o software seja
adequado e que atende às necessidades, ou seja, a confirmação de que este cumpra
suas especificações [Sommerville 2011].

A Verificação é uma atividade, a qual envolve a análise de um sistema para
certificar se este atende aos requisitos funcionais e não funcionais. Já a Validação, é
a certificação de que o sistema atende as necessidades e expectativas do cliente. O
processo de Validação e Verificação, não são processos separados e independentes.
Além do teste de software, o processo de verificação e validação possui
inspeções e revisões de software. As inspeções e revisões analisam e verificam os
requisitos do sistema, os modelos de design, o código-fonte e até mesmo os testes
propostos. Essas são as técnicas ditas “estáticas”, nas quais não é preciso executar o
software para verificá-lo; enquanto os testes são as técnicas dinâmicas, nas quais só
é possível efetuar quando há um protótipo ou versão executável.
As inspeções concentram-se principalmente no código-fonte de um sistema,
mas qualquer representação legível do software (como seus requisitos ou um modelo
de design) pode ser inspecionada.
Ambientes de inspeção automática (análise estática) de código, como por
exemplo SonarQube (Apêndice B.3), fazem a inspeção contínua da qualidade do có-
digo, executando revisões automáticas com análise estática do código para detectar
defeitos, odores de código e vulnerabilidades de segurança.
5.2.4 Design de Componente de Software

O termo design está relacionado ao desenho ou projeto de um artefato de
engenharia. Este termo pode significar tanto a atividade de projetar quanto o resul-
tado desta atividade. O design de componente de software projeta as características
essenciais de um componente de software e especifica a forma de construção do
código que implementa este componente. O objetivo do design de componente é ori-
entar a implementação do código, reduzindo a complexidade de análises e decisões
que precisam ser feitas durante a codificação propriamente dita.
O design de componente deve ser feito em conformidade com a linha de
base arquitetural selecionada para o software, e abrange, tipicamente, o design de
três tipos de objetos: (1) de interface com o usuário; (2) de serviços (ou objetos
funcionais); e (3) de persistência de dados. Esses três tipos básicos de objetos criados
nas atividades de design refletem as macroestruturas típicas de uma arquitetura de
software, representadas em diferentes tipos de modelos de referência arquiteturais,
como por exemplo o padrão Model-View-Controller (MVC) [Apple Inc.] e o modelo
de arquitetura em camadas [Avgeriou e Zdun 2005].
Além da conformidade com as decisões arquiteturais, o design de compo-
nente de software deve atender os requisitos definidos para o software na ERS, com
destaque para os requisitos funcionais, de interação com o usuário e de banco de
dados conceitual. Estes requisitos definem conceitualmente o software, cabendo ao

design a definição de como a solução conceitual proposta nos requisitos pode ser
implementada de forma eficiente.
Na perspectiva de requisitos funcionais, o design deve especificar os objetos
de código que atuam em cada cenário operacional, alocando responsabilidades a
cada objeto proposto de forma a cobrir todos os passos daquele cenário. As regras
de negócio e os algoritmos que validam e transformam dados para atender as
necessidades de negócio são responsabilidades típicas destes objetos de código.
Na interação com o usuário o design deve especificar os objetos de código
que implementam a aparência e o comportamento definidos no protótipo de inter-
face. Em geral, isto inclui o uso de frameworks de interface humano-computador.
Finalmente, no ponto de vista de dados, o design deve especificar os objetos de
código responsáveis pelo armazenamento de dados de forma segura e permanente,
tipicamente envolvendo interoperabilidade com sistemas externos de gerenciamento
de dados, como por exemplo, um Sistema Gerenciador de Bancos de Dados (SGBD).
A atividade de design é de suma importância para garantir a qualidade
do software, principalmente no que diz respeito à consistência arquitetural e ao
atendimento dos requisitos. No entanto, é uma tarefa complexa, que exige muito
conhecimento de Engenharia de Software e que precisa, portanto, ter orientações
metodológicas mais precisas e detalhadas para guiar a sua execução.
5.2.5 Planejamento de Testes de Software

Teste de software é a atividade de executar o software de uma maneira
controlada com o objetivo de avaliar se ele se comporta conforme o especificado. O
planejamento de testes pode ter início com a especificação de requisitos, na fase de
Elaboração, já que o teste deve demonstrar que esta especificação é atendida pelo
software.
Testar software não é uma atividade trivial, pois exige conhecimentos,
habilidades e infraestrutura específicos para lidar com combinações de situações que
crescem exponencialmente com o tamanho do software. Por essa razão, é necessário
definir uma metodologia para teste de software, envolvendo o planejamento e a
execução de diferentes tipos e níveis de testes, tais como testes de regressão,
funcional, estrutural, de desempenho, de segurança, de usabilidade, de portabilidade,
de interoperabilidade, de confiabilidade, entre outros.
Para elaborar um Plano de Teste de Software deve-se realizar diferentes ati-
vidades, como por exemplo, selecionar a estratégia de testes; definir os casos de teste,
considerandos os cenários (requisitos funcionais) a testar; definir procedimentos e ro-
teiros de teste, dados de entrada e respectivos resultados esperados; e elaborar um

cronograma de testes.
Uma estratégia de teste define minimamente, para cada nível de teste, as
técnicas de teste a utilizar; os critérios de teste adotados; e os tipos de teste a aplicar
no software. O nível de teste depende da fase do desenvolvimento do software em que
o teste será aplicado. Na codificação dos componente aplica-se Testes de Unidade; na
integração de componentes ocorrem Testes de Integração; na integração do sistema
usa-se Testes de Qualificação; e na homologação do sistema pelo usuário emprega-se
Testes de Aceitação. Existe, ainda, o nível de teste de Regressão, que é aplicado
quando a configuração já testada sofre alguma mudança.
A escolha de técnicas de teste depende do nível de teste que será aplicado.
Existem, basicamente, duas técnicas de teste: o Teste Estrutural, que adota critérios
para a geração dos casos de teste com a finalidade de identificar defeitos nas
estruturas internas do software, usando estímulos que exercitem adequadamente
todas as estruturas da codificação; e o Teste Funcional, que adota critérios para a
geração dos casos de teste com a finalidade de garantir que os requisitos do software
sejam avaliados, independentemente da estrutura interna do código.
Ao se adotar uma técnica de teste (Funcional ou Estrutural) é necessário
definir critérios para a elaboração dos casos de teste que exercitam os elementos
do software. Tipicamente esses elementos são as linhas de comando; as funções
implementadas; as variáveis definidas no software; os laços (estruturas de repetição)
existentes no código; os ramos (fluxos de execução) após uma decisão; e os próprios
requisitos do software. Cada critério de teste orienta a geração de um tipo de caso
de teste. Os elementos requeridos por um critério de teste são aqueles que deverão
ser exercitados quando o software for testado.
Os tipos de teste referem-se às características do software que podem ser
testadas, e abrangem teste de: Funcionalidade; Interoperabilidade; Desempenho;
Capacidade (Carga ou Stress); Usabilidade; e Segurança. Para cada tipo de teste
podem ser definidos ativos de processo para apoio ao teste, que incluem: padrão
para instrumentação de código com testes de unidade, bases de dados de teste;
ferramentas e sistemas de apoio ao teste; e scripts de teste.
5.2.6 Execução de Testes de Software

A execução de testes deve seguir o plano de testes definido e deve ser
registrada para que se possa observar a evolução do código com base nos resultados
das diferentes execuções de testes ao longo do projeto.
Um documento de Resultado de Execução de Teste do Software deve ser
criado em cada execução de teste para relatar os principais aspectos da execução
de um determinado teste realizado sobre o código fonte. Como discutido na seção

anterior, há vários tipos de teste e a execução de qualquer tipo de teste deve registrar:
• Identificador do teste: identificador único.

• Versão testada: identificador do software/componente/unidade.
• Tipo de teste: um dos tipos definidos de teste, que indica o objetivo do teste.
• Responsável pela execução do teste: deve haver um único responsável, e mais
de um participante.
• Período de execução do teste: data inicial e final de execução dos testes.
• Plataforma usada no teste: ambiente operacional, bases de dados, ativos de
testes.
• Análise quantitativa de resultados: estatísticas como quantidade de defeitos
por tipo, densidade de defeitos por componente testado, percentual de cober-
tura do teste em relação ao código testado, entre outras.
• Análise qualitativa: tipo e criticidade dos defeitos; status final (aprovado,
reprovado, aprovado com restrições, por exemplo).
• Contexto: informações úteis para compreensão dos resultados do teste.
O principal objetivo das atividades de teste é identificar falhas no software.

Todavia, os registros de execução de testes, quando devidamente organizados, servem
de base para a prevenção de problemas que podem gerar defeitos no software.
Um exemplo disso seria a aplicação de um modelo de classificação de falhas
detectadas no teste do software. Para cada tipo de falha poderia ser conduzida uma
análise de causa-raiz, de forma a identificar a atividade do processo que deu origem
ao defeito e que, por sua vez, provocou a falha detectada pelo teste.
Outro exemplo seria a análise de falhas no software detectadas após a
liberação para o usuário, visando a identificação das razões da não detecção da
falha pela atividade de teste e, a partir disso, melhorar esta atividade.
CAPÍTULO 6
Fase de Transição do Software
6.1 Síntese da Fase

6.1.1 Propósito
A fase de Transição (Figura 6.1) visa avaliar e assegurar a maturidade
de uma baseline de configuração do software gerada no projeto, garantindo um
adequado nível de confiança de que esta configuração está pronta para ser utilizada
no domínio de produção.
Figura 6.1: Atividades de Transição do Software

Como consequência da execução bem sucedida da fase de Transição do
1. Transição do software para ambiente de produção é planejada, com identifica-
ção de restrições e de recursos para a execução da transição.
2. O ambiente operacional é preparado para a transição, com sistemas habilita-

dores disponíveis e bases de dados operacionais convertidas para o software a
ser implantado.
3. Software é instalado e configurado conforme planejado e está apto para
executar suas funções em ambiente de produção.
4. Usuários, técnicos de suporte e mantenedores necessários para o funcionamento
do sistema são capacitados no novo software.
5. Software e sistema são validados por testes feitos pelas partes interessadas,
com resultados e anomalias registrados.
6. Rastreabilidade da configuração implantada é estabelecida.
7. Todos os compromissos do projeto são cumpridos.
6.1.3 Atividades
A fase de Transição do Software é definida como um subprocesso do PDS.
1. Planejar transição do software.

2. Instalar e configurar versão do software.
3. Capacitar operadores, pessoal de suporte técnico e mantenedores do software.
4. Validar versão do software, conduzindo testes de aceitação.
5. Disponibilizar software para a comunidade de usuários.
6. Corrigir defeitos e completar recursos do software adiados no projeto.
7. Encerrar projeto, obtendo concordância das partes interessadas.

Os produtos de trabalho gerados ou modificados na fase de Transição do
Software são:
1. PlnImp – Plano de Implantação do Software

2. ResImp – Resultado de Implantação do Software
3. TrmEnc – Termo de Encerramento do Projeto

A fase de Transição deve garantir que o software esteja disponível para
seus usuários finais e que ele satisfaz as necessidades e expectativas das partes
interessadas. Logo, é importante que representantes legítimos de usuários e demais
partes interessadas utilizem o software no ambiente operacional e forneçam sua

opinião sobre o software.
Eventuais ajustes sugeridos ou defeitos identificados devem ser analisados
e priorizados, para orientar o trabalho de ajuste fino do produto de software, uma
vez que todos os problemas estruturais graves devem ter sido solucionados nas fases
anteriores do ciclo de vida do projeto de desenvolvimento de software. Na fase de
Transição, os objetivos devem ter sido atendidos e o projeto deve estar pronto para
o encerramento.
6.2.1 Encerramento do Projeto

Os projetos de desenvolvimento de software geralmente terminam por um de
quatro motivos [Heldman 2018]: absorção, esgotamento, integração ou extinção. A
absorção ocorre quando os projetos transformam-se em uma unidade de negócios
independente. O esgotamento, quando o projeto tem seus recursos cortados. A
integração ocorre quando os recursos são retirados do projeto existente e devolvidos
à organização, ou alocados em outros projetos. E a extinção é o melhor término, em
que o projeto é concluído, aceito e encerrado.
O encerramento envolve fechar as contas do projeto, terminar a aceitação
final das entregas do projeto, arquivar a documentação necessária, liberar a equipe
do projeto e transferir a configuração do software para os responsáveis pela sua
manutenção.
É importante definir requisitos que possam ser objetivamente avaliados para
que seja executada a atividade de encerramento do projeto. Fatores críticos para o
sucesso desta atividade incluem:
• Aceitação do software por representantes dos usuários finais.

• Aprovação do alcance dos objetivos de negócio e benefícios planejados por
representantes das partes interessadas no negócio.
• Validação do cumprimento de todos os objetivos e compromissos do projeto.
• Arquivamento e armazenamento em local adequado de todo o material desen-
volvido no projeto.
Quando o projeto é concluído, o gestor do projeto deve finalizar todos

relatórios e documentar a experiência do projeto, incluindo informações sobre os
produtos do projeto, sobre o atendimento de seus requisitos, sobre o desempenho
dos membros da equipe e sobre as lições aprendidas no projeto.
Ao concluir a documentação de encerramento do projeto, o gestor do projeto
deve submeter os relatórios finais para aprovação das pessoas indicadas no plano de
comunicação do projeto.
A equipe gestora do projeto deve ter um cuidado especial ao encerrar o

projeto ou uma fase de modo a garantir que os critérios de sucesso do projeto sejam
satisfeitos, as entregas sejam verificadas e documentadas, a aceitação das entregas
seja formalizada, além de os produtos e serviços do projeto sejam transferidos para
próxima fase ou para o ambiente de produção.
É importante que o resultado do projeto (sucesso ou fracasso) seja auditado
de forma independente da equipe gestora do projeto. Em particular, quando ocorre
o cancelamento do projeto, as razões devem ser investigadas e documentadas pelos
auditores externos.
A aceitação da entrega formaliza o aceite do cliente ou patrocinador do
projeto, indicando que todos os requisitos do cliente e especificações do produto,
serviço ou resultado foram satisfatoriamente atendidos. Isso requer a aprovação
explícita do cliente ou patrocinador do projeto.
6.2.2 Lições Aprendidas no Projeto

É importante assegurar que as lições aprendidas e informações do projeto
sejam registradas para o uso futuro da organização, e que toda a documentação
gerada ao longo do projeto seja arquivada para futura referência.
Os registros do projeto devem ser arquivados de modo que outros projetos
possam usá-los para futura referência e também para objetivos de subsidiar a
melhoria do próprio PDS, mediante a análise de sucessos e/ou fracassos do projeto e
das lições aprendidas. Essa análise pode evitar que os erros e problemas encontrados
se repitam em futuros projetos e serve de base para o aperfeiçoamento contínuo da
metodologia de desenvolvimento de software.
As lições aprendidas devem conter as seguintes informações:
• Oportunidades aproveitadas e desperdiçadas.

• Riscos conhecidos e emergentes no projeto.
• Problemas enfrentados no projeto e soluções implementadas.
• Recomendações para melhoria do processo.
6.2.3 Planejamento da Transição

O plano de transição deve definir, entre outros aspectos, como será feita
a implantação do software. Naturalmente, como qualquer plano de engenharia de
software, esse plano precisa ser aprovado e confirmado por toda a equipe envolvida,
alcançando o comprometimento necessários para atingir todos os objetivos propos-
tos.
Um Plano de implantação de software pode se referir à configuração

completa do software, ou a uma parte da configuração, como por exemplo, em um
projeto piloto ou em uma implantação incremental do software. De qualquer forma,
este plano contempla, tipicamente, os seguintes assuntos:
• Instalação e configuração do ambiente operacional de produção: hardware,

infraestrutura de comunicação de dados, plataforma de software e qualquer
outro sistema habilitador do software.
• Conversão e carga de dados definitiva para o ambiente de produção.
• Instalação e configuração do software no ambiente de produção.
• Capacitação dos envolvidos: usuários, suporte técnico, mantenedores.
• Validação da implantação do software e confirmação de cumprimento dos
compromissos do projeto.
• Liberação para uso do software em ambiente de produção.
• Acompanhamento do uso do software em ambiente de produção.
6.2.4 Execução da Transição

O documento de Resultado da Implantação do Software relata a execução
das atividades de transição do software para o ambiente de produção e de liberação
do software para uso nesse ambiente. Essa execução produz, tipicamente, resultados
que incluem:
1. Instalação e configuração do ambiente operacional de produção.

2. Conversão e da carga de dados para o ambiente de produção.
3. Instalação e configuração do software no ambiente de produção.
4. Capacitação dos envolvidos com a sustentação do software.
5. Validação do software pelos usuários em ambiente de produção.
6. Acompanhamento do uso do software em ambiente de produção.
Atividades de Validação e Verificação são muito utilizadas para garantir

a qualidade dos resultados gerados pelo processo de transição de software. Neste
contexto, a verificação busca certificar que o software atende aos requisitos funcionais
e não funcionais especificados, enquanto a validação busca garantir que o software
atende as necessidades e expectativas do cliente quando utilizado no ambiente de
negócio.
A inspeção de software por auditores independentes também é uma ativi-
dade comumente executada no contexto de transição de software do fornecedor para
o adquirente. A auditoria envolve análise dos documentos que formam a configu-
ração do software (tais como requisitos, diagramas e código-fonte) e pode incluir
análise estática automatizada por meio de ferramentas que avaliam a qualidade dos
artefatos.
Testes de aceitação do software são obrigatórios na execução da transição
de software e devem ser feitos em ambiente análogo ao de produção, utilizando
uma massa de dados realista e envolvendo a participação ativa de representantes da
organização adquirente do software.
Esses testes servem para avaliar a capacidade do software de cumprir suas
responsabilidades quanto usado em ambiente de produção, executando suas funções
corretamente e com o nível de desempenho e qualidade especificado para o software.
Eles devem estabelecer a confiança de que o sistema é adequado ao seu propósito,
atendendo as necessidades dos seus usuários, e que será útil para realizar as tarefas
planejadas e atingir os objetivos pretendidos.
Se houver um sistema legado que está sendo substituído a partir da
implantação do novo software, pode ser necessário conduzir uma operação paralela
do sistema legado e do novo sistema, comparando os resultados para assegurar que
o novo sistema apresenta, de fato, ganhos em relação ao sistema legado.
Referências Bibliográficas
[Apple Inc.]Apple Inc. The Model-View-Controller design pattern.

https://developer.apple.com/library/archive/documentation/
General/Conceptual/CocoaEncyclopedia/Model-View-Controller/
Model-View-Controller.html#//apple_ref/doc/uid/TP40010810-CH14-SW14.
[Avgeriou e Zdun 2005]AVGERIOU, P.; ZDUN, U. Architectural patterns revisited – a

pattern language. In: 10th European Conference on Pattern Languages of Programs
(EuroPlop). Irsee, Germany: ACM Digital Library, 2005. Disponível em: <http:
//eprints.cs.univie.ac.at/2698/1/ArchPatterns.pdf>.
[Aéce 2020]AéCE, I. Boas Práticas de Programação. 2020. www.linhadecodigo.com.

br/artigo/1310/boas-praticas-de-programacao.aspx. Portal Linha de Código.
[Driessen]DRIESSEN, V. A successful Git branching model. https://nvie.com/posts/

a-successful-git-branching-model/.
[Fowler]FOWLER, M. Patterns for Managing Source Code Branches. https://

martinfowler.com/articles/branching-patterns.html.
[GIT]GIT. Git - a free and open source distributed version control system. https:
//git-scm.com/.
[Github 2020]Github. Github - Where the world builds software. 2020. Disponível em:
<https://github.com/>.
[Heldman 2018]HELDMAN, K. Project Management Professional Study Guide. 9. ed.

[S.l.]: Sybex, 2018.
[IEEE 2012]IEEE. TR 24774 – Systems and Software Engineering – Life Cycle Manage-
ment – Guidelines for Process Description. [S.l.], 2012.
[ISO/IEC/IEEE 2015]ISO/IEC/IEEE. International Standard 15289 – Systems and soft-

ware engineering – Content of life-cycle information items (documentation). 2015.
1-95 p.
Referências Bibliográficas 62

ware engineering – Life cycle processes – Vocabulary. 2017.

ware engineering – Requirements engineering. 2018.
[Jenkins Community]Jenkins Community. Jenkins - Build great things at any scale.

https://www.jenkins.io/.
[Kruchten 2004]KRUCHTEN, P. The Rational Unified Process: an Introduction. 3. ed.

[S.l.]: Addison-Wesley, 2004.
[McConnell 2004]MCCONNELL, S. Code Complete. 2. ed. [S.l.]: Microsoft Press, 2004.
[Munassar e Govardhan 2010]MUNASSAR, N. M. A.; GOVARDHAN, A. A comparison

between five models of software engineering. IJCSI International Journal of Computer
Science Issues, v. 7, n. 5, set. 2010. ISSN 1694-0814.
[PMI 2013]PMI. PMBOK - A Guide to Project Management Body of Knowledge. 5. ed.

[S.l.]: Project Management Institute, 2013.
[Sommerville 2011]SOMMERVILLE, I. Engenharia de Software. 9. ed. [S.l.]: Pearson

Education, 2011.
[SonarSource S.A]SonarSource S.A. SonarQube - Code Quality and Security. https:

//www.sonarqube.org/.
Apêndice A 64
APÊNDICE A
Templates de Documentos do Processo
A.1 Termo de Abertura de Projeto
TERMO DE ABERTURA DO PROJETO
Identificação do Projeto
Projeto
{Nome do projeto}
Unidade Demandante
{Unidade que solicitou o projeto}
Gestor do Projeto
{Nome do Gestor do projeto}
Patrocinador
{Pessoa que fornece os recursos necessários para implementação do projeto}
Histórico de Registro
Versão Data Autor Descrição
Data do histórico: {Autor da
1.0 Elaboração do documento
dd/mm/aaaa} elaboração/modificação}
{1.1} {Motivo da modificação}
1. Justificativa
{Descrever o problema ou a oportunidade que justifica o desenvolvimento deste projeto. Pode
conter uma breve descrição da situação atual. Lembre-se de contextualizar a importância do
projeto para organização e, caso julgue necessário, explique os impactos deste projeto não
seja executado. Se o projeto é derivado de demanda legal ou solicitado pela alta administração,
essa informação deve ser ressaltada, pois impacta na prioridade do projeto.
A justificativa do projeto deve responder às seguintes questões:
● Por que o projeto é necessário?
● Quais os motivos que geraram a sua necessidade?
● Quais os benefícios?}
2. Objetivo do Projeto
{Descrever o que se pretende realizar para resolver o problema central ou explorar a
oportunidade identificada.
Para a correta definição do objetivo específico siga a regra “SMART”:
● Specífic (específico): Deve ser redigido de forma clara, concisa e compreensiva;
● Measurable (mensurável): O objetivo específico deve ser mensurável, ou seja, possível
de ser medido por meio de um ou mais indicadores;
● Agreed (acordado): Deve ser acordado com as partes interessadas (Stakeholders);
● Realistic (realista): Deve estar centrado na realidade, no que é possível de ser feito
considerando as premissas e restrições existentes;
● Time Bound (Limitado no tempo): Deve ter um prazo determinado para sua finalização}
3. Alinhamento Estratégico
{Relacionar com quais objetivos do Planejamento Estratégico vigente o projeto está
contribuindo. Podem ser citados objetivos estratégicos corporativos ou setoriais desde que
identificados.}
4. Responsabilidades e Partes Interessadas

{Descrever quais as unidades administrativas estão envolvidas na execução do projeto com um
breve relato das responsabilidades de cada uma. Todas as áreas informadas receberão cópia
deste documento.}
Apêndice A 65
5. Escopo
{Descrever os resultados esperados e produzidos no projeto como, por exemplo, os produtos e
serviços a serem entregues, a documentação elaborada.}
6. Não-Escopo
{O que não será atendido pelo projeto: produtos e serviços não incluídos no escopo, o que não
será implementado pelo projeto.}
7. Premissas
{Premissas são previsões que são feitas e assumidas como verdadeiras para viabilizar a
continuidade do planejamento do projeto. Normalmente implicam em risco para a execução do
projeto, por isso devem ser monitoradas ao longo do projeto. Devem ser descritas em tópicos.}
8. Restrições
{Restrições são condições ou situações que limitam seu planejamento e desenvolvimento e
não podem ser eliminadas ou alteradas no decorrer do projeto. Devem ser descritas em tópicos
e acompanhadas de metas valoradas. Ex.: Orçamento predefinido ou datas impostas.}
9. Projetos Inter-relacionados
{Relacionar outros projetos que, de alguma forma, dependem ou fornecem dados, produtos
e/ou serviços para o projeto.}
10. Riscos Iniciais

{Relacionar em tópicos os riscos iniciais identificados no projeto.}
11. Tempo Estimado

{Estimar o tempo necessário para a conclusão do projeto.}
12. Custo Estimado

{Estimar o custo necessário para a execução do projeto.}
13. Gerente do Projeto

Nome Cargo
Telefone Endereço Eletrônico Lotação
14. Aprovação do Termo de Abertura

Unidade Demandante Data Assinatura
Unidades Envolvidas Data Assinatura
Secretário-Geral/Diretor-Geral Data Assinatura

Apêndice A 66
A.2 Especificação de Requisitos de Software (ERS)
Especificação dos Requisitos do Software

_NOME DO PROJETO_
Versão _XX.xx_
Aprovação
Aprovamos a Especificação dos Requisitos 1.0 do projeto _NOME DO PROJETO_.
<Data>
<Data>
<Data>
<Data>
Histórico de Revisões
Data Versão Descrição Autor
Apêndice A 67
Tabela de Conteúdo
1. Introdução 4
1.1 Propósito 4
1.2 Escopo 4
1.3 Público-alvo 4
1.4 Definições, Acrônimos e Abreviações 4
1.5 Referências 4
1.6 Identificação e Localização do Documento 4
1.7 Organização do Documento 4
2. Visão Geral do Sistema 5

2.1 Classes e Características dos Usuários 5
2.2 Premissas 5
2.3 Restrições 5
3. Chamada 5
3.1 Requisitos Funcionais 5
4. Requisitos Não-Funcionais 6
4.1 Usabilidade 6
4.2 Confiabilidade 6
4.3 Desempenho 6
4.4 Reusabilidade 6
4.5 Segurança 6
4.6 Acessibilidade 6
5. Requisitos de Interface 6
5.1 Interfaces com o Usuário 6
5.2 Interfaces de Hardware 7
5.3 Interfaces de Software 7
5.4 Interfaces de Comunicação 7
6. Requisitos de Documentação 7
6.1 Manual de Usuário 7
6.2 Ajuda On-line 7
7. Requisitos de Licença 7
8. Informações para Suporte 7
9. Mapeamento de Requisitos com Casos de Uso 7

Apêndice A 68
Especificação de Requisitos de Software
1. Introdução
1.1 Propósito
Este documento especifica os requisitos contemplados pela ferramenta, fornecendo todas as informações
necessárias para o projeto, implementação em software, testes e aprovação do sistema.
1.2 Escopo
O documento descreve os casos de uso de uma ferramenta. Os requisitos especificados neste documento estão
relacionados com os casos de uso contidos no documento de especificação de casos de uso.
Explicitar o que o produto faz (e o que não faz). Descrever a aplicação (pontos relevantes, objetivos e metas).
1.3 Público-alvo
Incluir público alvo
1.4 Definições, Acrônimos e Abreviações

Fornecer as definições de todos os termos necessários à adequada interpretação do Documento de Requisitos
1.5 Referências
Listar todos os documentos referenciados em qualquer outra parte do DR. Identificar cada documento por
título, número, data, autor e etc. Especificar a fonte a partir da qual o documento pode ser obtido
1.6 Identificação e Localização do Documento

Identificação e Localização do Documento
1.7 Organização do Documento

Descrever a estrutura/organização do restante do DR
2. Visão Geral do Sistema
2.1 Classes e Características dos Usuários

Descrever as características gerais dos usuários do produto
2.2 Premissas
2.3 Restrições
Descrever quais itens podem limitar as possibilidades do desenvolvedor.
Políticas organizacionais, criticalidade da aplicação, considerações sobre segurança, ...
3. Chamada
Apêndice A 69
3.1 Requisitos Funcionais

[R1]
[R2]
[R3]
[R4]
…
4. Requisitos Não-Funcionais
4.1 Usabilidade
[R14]
4.2 Confiabilidade
[R15]
[R16].
4.3 Desempenho
4.4 4.4Reusabilidade
A ser definido.
4.5 Segurança
A ser definido.
4.6 Acessibilidade
[R17]
5. Requisitos de Interface
5.1 Interfaces com o Usuário

[R18]
5.2 Interfaces de Hardware
Apêndice A 70
5.3Interfaces de Software
5.4Interfaces de Comunicação
6. Requisitos de Documentação
7. Requisitos de Licença
[R24]
8. Informações para Suporte

Na ocorrência de possíveis problemas com este documento entre em contato com algum dos desenvolvedores deste
projeto.
Relação de e-mails:
Nome Cargo E-mail
9. Mapeamento de Requisitos com Casos de Uso
Requisitos Casos de Uso

[R2] [R9]
[R4]
[R5] [R8]
[R3]
[R6]
[R7] [R8]
[R11]
[R12]
[R9]
[R11]
[R10] [R13]
Apêndice A 71
A.3 Termo de Encerramento de Projeto
TERMO DE ENCERRAMENTO DO PROJETO
Identificação do Projeto
Projeto
{Nome do projeto}
Unidade Demandante
{Unidade que solicitou o projeto}
Gestor do Projeto
{Nome do Gestor do projeto}
Patrocinador
{Pessoa que fornece os recursos necessários para implementação do projeto}
Histórico de Registro
Versão Data Autor Descrição
1.0 Elaboração do documento
{1.1} {Motivo da modificação}
1. Justificativa
{Descrever o problema ou a oportunidade que justificou o desenvolvimento deste projeto. Pode
conter uma breve descrição da situação atual. Lembre-se de contextualizar a importância do
projeto para organização e, caso julgue necessário, explique os impactos causados.
A justificativa deve responder às seguintes questões:
● Por que o projeto foi necessário?
● Quais os motivos que geraram a sua necessidade?
● Quais os benefícios gerados?
2. Objetivo do Projeto - Planejado X Realizado

[Responda as questões e comente os pontos mais relevantes]
Os objetivos foram atingidos?
Projeto foi entregue dentro do prazo?
No orçamento?
Atendeu o escopo?
3. Avaliação pelo Cliente

{Avaliação do projeto pelo Cliente.}
4. Avaliação pelo Representante da Fábrica

{Avaliação do projeto pelo Representante da Fábrica.}
5. Avaliação pelo Líder de Projeto

{Avaliação do projeto pelo Líder de Projeto}
6. Avaliação pela Equipe de Projeto

{Avaliação do projeto pela Equipe de Projeto}
7. Avaliação pelos Representantes de Partes Interessadas

{Avaliação do projeto pelos Representantes de Partes Interessadas.}
Apêndice A 72
8. Estatísticas (previsto X realizado) do projeto

{custo, prazo, escopo, qualidade.}
9. Síntese de lições aprendidas

{Documentar as Lições aprendidas de modo a aperfeiçoar os processos e evitar que os erros e
problemas encontrados se repitam em futuros projetos.}
10. Declaração de quitação

{Declaração de quitação de todos os compromissos em relação à outra parte pelo Cliente e
pelo Representante da Fábrica}
11. Gerente do Projeto

Nome Cargo
Telefone Endereço Eletrônico Lotação
12. Aprovação do Termo de Encerramento

Unidade Demandante Data Assinatura
Unidades Envolvidas Data Assinatura
Secretário-Geral/Diretor-Geral Data Assinatura

APÊNDICE B
Ferramentas de Apoio ao Processo
B.1 Git, GitHub e Gitflow

Uma categoria de ferramentas essencial para o processo de desenvolvimento
de software é a que contempla as plataformas de gestão do controle de código
fonte (Source Control Management). A ferramenta GitHub [Github 2020] é uma
plataforma de software que pertence a esta categoria.
GitHub faz hospedagem de código-fonte e arquivos com controle de versão,
usando como base o sistema de controle de versões distribuído Git [GIT]. A
plataforma facilita o compartilhamento e o trabalho colaborativo de programadores
em projetos de desenvolvimento de software, independentemente de sua localização
geográfica. Ela mantém o código seguro, controla o histórico de versões e garante
rastreabilidade de mudanças. A plataforma GitHub organiza o código-fonte do
software em diretórios (repositórios), de modo que a estrutura e o conteúdo sejam
compartilhados pela equipe de desenvolvimento de software.
A gestão de código fonte propriamente dita é feita pelo Git [GIT], um
sistema de gerenciamento de código-fonte distribuído de código aberto que permite
criar cópias (ramificações) dos repositórios de software. Ao usar uma ramificação,
é possível trabalhar no código independentemente da versão estável da baseline de
código.
Depois de finalizar as alterações, é possível armazená-las como um conjunto
de diferenças, conhecido como uma confirmação (commit). É possível extrair confir-
mações de outros colaboradores para o repositório, enviar confirmações para outras
pessoas e mesclar confirmações de volta para a versão principal do repositório.
Gitflow [Driessen] é um fluxo de trabalho baseado na ferramenta Git que
define um modelo de ramificação rigoroso e oferece uma estrutura robusta para
gerenciar projetos de maior porte. O Gitflow é uma ideia abstrata de fluxo de
trabalho sobre o Git. Isto significa que ele dita que tipos de ramificações configurar
e como fazer a mesclagem.
Apêndice B 74
O fluxo é ideal para projetos que têm um ciclo de lançamento agendado.

Este fluxo de trabalho não adiciona novos conceitos ou comandos além do necessário
para o fluxo de trabalho de ramificação de recurso. Em vez disso, ele atribui funções
bem específicas para diferentes ramificações e define quando elas devem interagir.
Além das ramificações de recurso, ele utiliza ramificações individuais para preparar,
manter e registrar lançamentos. Os principais benefícios do fluxo de trabalho de
ramificação de recurso incluem solicitações pull, experimentos isolados e colaboração
mais eficiente.
B.2 Jenkins
Jenkins é uma ferramenta de auxílio à construção de software que permite
automatizar as etapas de compilação e teste de software e estabelece uma base para a
integração e a entrega contínua do código [Jenkins Community]. A entrega contínua
de software trata de implementações e alterações contínuas no código, ou seja, um
conjunto de práticas cujo objetivo é garantir que alterações ou novas versões de
software sejam colocadas no ambiente de produção a qualquer momento.
A ferramenta Jenkins permite empregar histórias de usuários, testes de
unidade e atividades de garantia da qualidade, visando automatizar a preparação de
uma nova versão do software e realizar a integração e entrega contínua do código,
disponibilizando-o para uso. As principais características desta ferramenta são: builds
periódicos; testes automatizados; análise de código; identificação precoce de erros;
participação ativa da comunidade; e integração com outras ferramentas (via plugins).
Jenkins é um mecanismo de automação que oferece suporte a vários padrões
de automação. Para utilizar os recursos do Jenkins dentro de um fluxo de entrega
automatizada de software, primeiramente é preciso definir as etapas de construção. É
importante que o processo de desenvolvimento e entrega de software esteja definido
antes da construção do pipeline, identificando todas as etapas e atividades pelo qual
o produto passa desde o requisito definido pelo cliente até a entrega final do software
em ambiente de produção.
Um conceito essencial para uso de Jenkins em um projeto de software é o
de (pipeline), que é um conjunto de plugins que oferece suporte à implementação e
integração de entrega contínua. Um pipeline de entrega contínua é uma expressão au-
tomatizada do processo que obtém o software do controle de versão e o disponibiliza
para seus usuários e clientes. Cada mudança no software (comprometida no sistema
de gestão de código fonte) passa por este processo complexo para ser liberada, en-
volvendo a construção do software de maneira confiável e repetível, encaminhando
o software em "construção" por vários estágios de teste e implantação.
Apêndice B 75
Jenkins fornece um conjunto extensível de ferramentas para modelar este

processo de integração e entrega, chamado de pipeline, usando a sintaxe de uma
linguagem específica de domínio (DSL). A definição de um pipeline é escrita em um
arquivo de texto chamado Jenkinsfile que, por sua vez, pode ser armazenado em um
repositório de código fonte e colocado sob gestão do sistema de controle de código do
projeto. Dessa forma, o pipeline (processo) de integração e entrega contínua torna-se
uma parte do próprio software que está sendo desenvolvido, podendo ser versionado
e revisado como qualquer outra unidade de código fonte.
B.3 SonarQube
A análise estática de código é um processo de avaliação da qualidade
de um software ou componente, considerando sua forma, estrutura, conteúdo ou
documentação. A inspeção de código é uma técnica de análise estática que se baseia
no exame visual dos produtos de desenvolvimento para detectar erros, violações dos
padrões de desenvolvimento e outros problemas. Apesar de comprovadamente eficaz
na detecção de defeitos, a inspeção é uma técnica que consome muitos recursos,
notadamente o tempo de profissionais treinados e experientes. Ferramentas para
apoio à inspeção de software contribuem para a eficiência desta técnica.
SonarQube [SonarSource S.A] é uma plataforma de código aberto desenvol-
vida para realizar inspeção contínua da qualidade do código. Ela permite executar
revisões automáticas, com análise estática do código, para detectar defeitos e odores
de código em mais de vinte linguagens de programação.
A plataforma disponibiliza relatórios sobre código duplicado, padrões de
codificação não contemplados, cobertura de código de testes de unidade, comple-
xidade de código, comentários, bugs e vulnerabilidades de segurança. Ela permite,
ainda, registrar o histórico de métricas e fornece gráficos de evolução da qualidade
do código.
A ferramenta tem integração automatizada com diversos tipos de sistemas
de apoio ao desenvolvimento de software, como ferramentas para gestão de depen-
dências (como Maven, Ant, Gradle e MSBuild) e ferramentas de integração contínua
de código (como Jenkins, Bamboo e Hudson).
Em um processo de desenvolvimento apoiado por SonaQube, os desenvol-
vedores implementam e mesclam código fonte em seus respectivos ambientes de
trabalho e fazem check-in de seu código no repositório de gestão de código fonte. A
ferramenta de integração contínua (Jenkins, por exemplo) verifica, constrói e executa
testes de unidade, acionando a ferramenta SonarQube integrada para analisar os re-
sultados. Esta ferramenta posta os resultados no servidor SonarQube que fornece
Apêndice B 76
feedback aos desenvolvedores por diferentes meios, tais como a interface SonarQube,
e-mail ou notificações no IDE, dependendo do tipo de versão da ferramenta utili-
zada. O SonarQube está disponível gratuitamente sob a licença GNU Lesser General
Public License, mas existe versões corporativas, com licenciamento pago.
APÊNDICE C
Glossário do Processo
Ativo de Processo Organizacional: artefato utilizados para definição, implemen-

tação ou melhoria dos processos em uma organização. Exemplos: templates, macro-
fluxos, lições aprendidas, indicadores de projetos anteriores, métodos, código-fonte.
Baseline de Software: configuração de software que foi avaliada e aprovada em
um determinado ponto do ciclo de vida do projeto, passando a representar uma base
segura e estável do software desenvolvido até aquele ponto.
Biblioteca de Ativos de Software: repositório onde serão armazenados todos os
ativos da organização para permitir que consultados e recuperados quando forem
necessários.
Ciclo de Vida de Desenvolvimento de Software: conjunto de todos os processos
que ocorrem com o software durante o projeto de desenvolvimento, desde a abetura
até o encerramento do projeto. É uma parte do Ciclo de Vida do Sofware.
Ciclo de Vida de Software: conjunto de todos os processos que ocorrem com
o software, desde a identificação de uma necessidade que pode ser atendida por
software até a descontinuação do software pela sua retirada do ambiente de produção.
Componente de Software: vide Elemento de Software.
Comunicar: verbo usado para representar comunicações nas tarefas descritas nas
atividades. Uma comunicação em uma atividade deve sempre definir: “O quê é
comunicado” e “Para quem se destina a comunicação”. O “Meio preferencial de
comunicação” é opcional, e quando não informado deve ser usado o meio padrão
de comunicação no projeto (e-mail, por exemplo).
Concepção de Software: fase do desenvolvimento de software que define o escopo
do projeto e estabelece um acordo entre as organizações adquirente e fornecedora
sobre os principais requisitos do sistema e do software e sobre o processo que deve
ser executado para realizar o projeto.
Configuração de Software: conjunto de componentes, cada um com um identi-
ficador de versão bem definido, gerado ou modificado no projeto e que funciona de
forma integrada como um sistema.
Apêndice C 78
Construção de Software: fase do desenvolvimento de software que implementa e

integra o produto de software, de forma iterativa e incremental, em conformidade
com a linha de base arquitetural estabelecida para o projeto.
Disciplina de Software: área de conhecimento da Engenharia de Software, como
por exemplo, Requisitos, Arquitetura e Testes de software. Uma disciplina aborda
competências sobre Engenharia de Software necessárias para trabalhar um determi-
nado aspecto do desenvolvimento de software.
Elaboração de Software: fase do desenvolvimento de software que aprofunda a
compreensão sobre os requisitos do software e do projeto, definindo uma linha de
base arquitetural para o software.
Elemento de Software: produto de trabalho, artefato ou documento gerado ou
modificado no projeto de desenvolvimento de software. Pode ser composto por outros
subcomponentes e pode fazer parte, como subcomponente, de um componente maior.
Fábrica de Software: uma organização que utiliza um conjunto de pessoas,
recursos materiais, processos e metodologias para desenvolver e sustentar software.
O termo tem origem na analogia com fábricas tradicionais, que utilizam práticas
padronizadas e otimizadas para criar seus produtos.
GPS: sigla para Grupo de Processo de Software, que é uma equipe responsável pela
definição, adaptação, evolução e monitoramento da aplicação de um processo de
software em uma organização.
Homologação de Software: atividades de um projeto de desenvolvimento de
software que envolvem o planejamento e a execução de trabalhos relacionados com
a avaliação e a garantia da qualidade do software gerado no projeto. As atividades
de homologação incluem, tipicamente, verificação, validação e testes de software.
Implantação de Software: compreende a instalação do software no ambiente do
usuário. O que inclui os manuais do sistema, importação dos dados para o novo
sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em
alguns casos quando da existência de um software anterior, também é realizada a
migração de dados anteriores desse software.
Incremento de Software: Diferença entre duas baselines do software ao longo do
ciclo de vida do projeto de desenvolvimento de software.
Instalação de Software: processo (ou seu resultado) quando todos os arquivos
necessários são colocados num computador para que o programa (por exemplo,
sistema operacional, driver de dispositivo, software aplicativo, módulo de extensão,
patch, etc.) possa ser executado.
Iteração de Projeto: um intervalo de tempo fixo, variando entre duas e quatro
semanas, em que se planeja atingir um objetivo bem definido dentro de um projeto
de desenvolvimento de software.
Apêndice C 79
Laudo: documento que contém um parecer técnico refletindo uma opinião espe-
cializada sobre um determinado assunto. No processo de software, laudos são ti-
picamente emitidos nas atividades de monitoramento da execução do projeto de
desenvolvimento de software.
Liberação de Software: disponibilização de uma baseline de software para uso
em ambiente de produção (liberação externa) ou em ambiente de desenvolvimento
(liberação interna).
Linha de Base: vide Baseline.
Manter: verbo usado para representar ações de criar, consultar, excluir ou alterar
alguma entidade ou informação, de modo a manter esta entidade ou informação
atualizada e consistente com o mundo real representado.
Metodologia de desenvolvimento de software: uma especificação de processo,
associada aos produtos de trabalho a serem usados e gerados, além da designação
de papéis de pessoas e definição de ferramentas e padrões aplicados em um esforço
de desenvolvimento de software [ISO/IEC/IEEE 2017].
Parte Interessada no Projeto: indivíduos, grupos ou organizações cujas neces-
sidades devem ser satisfeitas pelo projeto ou que são potencialmente afetados pelos
resultados do projeto de desenvolvimento de software. Deve haver uma definição
explícita de representante para cada parte interessada no projeto.
Processo de Desenvolvimento de Software: um processo de Engenharia de
Software que identifica necessidades de usuários e constrói um produto de software
visando ao atendimento destas necessidades [ISO/IEC/IEEE 2017].
Processo Padrão: ativo de processo organizacional que compreende um conjunto
de definições básicas obrigatórias que orientam os trabalhos de uma organização,
garantindo a homogeneidade na realização desses trabalhos.
RUP: sigla para Processo Unificado da Rational (ou Rational Unified Process). Pro-
cesso de desenvolvimento de software criado pela empresa Rational [Kruchten 2004]
e que se tornou uma das principais referências para definição deste tipo de processo.
Software: um sistema de documentos que define, para um dado problema computa-
cional, uma solução executável em (pelo menos) uma máquina alvo. Cada elemento
(programas, dados e especificações) que compõe o software é um documento que des-
creve ou prescreve algum aspecto do sistema formado pelo software. Um documento
necessário em qualquer software é o seu código fonte.
Stakeholder do projeto: vide parte interessada no projeto.
Transição de Software: fase do desenvolvimento de software que avalia a maturi-
dade de uma baseline de configuração de software gerada no projeto, determinando
a sua adequação para ser utilizada no ambiente de produção.
Apêndice C 80
Usuário de Software: também chamado de operador ou usuário final, é pessoa

que efetivamente interage com o software por meio da manipulação da interface de
usuário provida pelo software. Nem todas as partes interessadas no software são
usuários, mas todos os usuários são partes interessadas.

2021 02 Processo Desenvolvimento Fabrica

Enviado por

Dados do documento

Título original

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

2021 02 Processo Desenvolvimento Fabrica

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Goiás

Processo para Desenvolvimento de

O presente processo para desenvolvimento de software foi elaborado insti-

Frederick Brooks Jr.,

Fábrica de Software do Instituto de Informática da UFG. Processo para

Fábrica de Software do Instituto de Informática da UFG. Software De-

1 Visão Geral do Processo de Desenvolvimento de Software 9

2 Gestão do Projeto – Atividades Transversais ao Projeto de Software 20

4 Fase de Elaboração do Software 38

5 Fase de Construção do Software 47

A Templates de Documentos do Processo 63

B Ferramentas de Apoio ao Processo 73

1.1 Processo de Desenvolvimento de Software 14

2.1 Atividades Transversais 20

3.1 Atividades de Concepção do Software 29

4.1 Atividades de Elaboração do Software 38

5.1 Atividades de Construção do Software 47

6.1 Atividades de Transição do Software 55

1.1 Sobre este Documento

1.1.1 Objetivo e Escopo deste Documento

1.1.2 Estrutura deste Documento

1. Síntese da fase: contempla propósito, resultados esperados, atividades e itens

2. Orientações metodológicas: discute e propõe boas práticas que podem ser

Assim, o restante deste documento está organizado da seguinte forma:

• O Capítulo 2 descreve atividades transversais que ocorrem de forma concor-

Os apêndices complementam e ajudam na compreensão do PDS:

• O Apêndice A apresenta templates para alguns itens de informação do pro-

1.1.3 Melhoria Contínua do Processo

1.2 Conceitos Fundamentais para o Processo

1. Especificação: identificação e modelagem de requisitos dos stakeholders;

As atividades de um PDS podem ser organizadas segundo diversos Modelos

Uma Metodologia de Desenvolvimento de Software (MDS) compre-

1.3 Características Essenciais do Processo

1.3.1 Contexto de Execução do Processo

Logo, a adequação do processo aos propósitos da Fábrica deve ser avaliada

1.3.2 Execução Completa ou Separada por Fase

• Fase de Concepção: foco na especificação do software por meio da Enge-

Um projeto de desenvolvimento de software completo compreende a execu-

Figura 1.1: Processo de Desenvolvimento de Software

A fase de Concepção visa obter um acordo entre a organização adquirente e

1.3.3 Perfis de Membros da Equipe Técnica

1. Estudantes dos cursos do INF: para esses participantes do projeto, o PDS

sobre metodologias que podem ser aplicadas para implementar os conceitos

O PDS da Fábrica precisa contemplar as necessidades de todos esses perfis

1.3.4 Papéis e Responsabilidades no Projeto

Figura 1.2: Papéis definidos no PDS e suas especializações

A organização adquirente (Cliente) e a organização fornecedora (Fábrica)

da Fábrica no projeto. O executor desse papel monitora o projeto na perspectiva

1.3.5 Duração de um Projeto

1.3.6 Marcos de Projeto

para que os marcos sejam efetivos em termos de decisões tomadas e de avaliação de

1.3.7 Desenvolvimento Iterativo

1.3.8 Desenvolvimento Incremental e Entrega Contínua

1.3.9 Disciplinas e Domínios do Processo

• Domínio do problema: processos de modelagem de negócio e engenharia de

Um terceiro domínio envolve os processos de gestão técnica necessários à

2.1 Síntese das Atividades Transversais

Figura 2.1: Atividades Transversais

2.1.2 Resultados Esperados

1. O processo padrão é adaptado, se necessário, instanciado e executado no

1. Planejar cada iteração do projeto.

2.1.4 Produtos de Trabalho

1. DefTar - Definição de tarefa do projeto