Metodologia de Desenvolvimento de Software

EB80-MT-78.
001
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
MANUAL TÉCNICO
PARA METODOLOGIA DE DESENVOLVIMENTO
DE SOFTWARE DO EXÉRCITO
1ª Edição
2012
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
CENTRO DE DESENVOLVIMENTO DE SISTEMAS
MANUAL TÉCNICO
PARA METODOLOGIA DE DESENVOLVIMENTO
DE SOFTWARE DO EXÉRCITO
1ª Edição
2012
Separata do Boletim do Exército nº 17, 26 de abril de 2013.
FOLHA DE REGISTRO DE MODIFICAÇÕES
NÚMERO DE ORDEM ATO DE APROVAÇÃO PÁGINAS AFETADAS DATA

ÍNDICE DE ASSUNTOS
CAPÍTULO I -
DAS DISPOSIÇÕES PRELIMINARES
1. INTRODUÇÃO..................................................................................................................... 1-1
2. FINALIDADE....................................................................................................................... 1-2
3. OBJETIVOS......................................................................................................................... 1-2
4. PAPÉIS E RESPONSABILIDADES...................................................................................1-3
4.1 Cliente.................................................................................................................................. 1-3
4.2 Gerente de Projeto..............................................................................................................1-3
4.3 Analista de Sistemas............................................................................................................ 1-4
4.4 Arquiteto.............................................................................................................................. 1-5
4.5 Projetista.............................................................................................................................. 1-5
4.6 Desenvolvedor..................................................................................................................... 1-6
4.7 Administrador de Banco de Dados....................................................................................1-6
4.8 Testador............................................................................................................................... 1-6
4.9 Projetista de Infraestrutura...............................................................................................1-7
5. MODELO DE DESENVOLVIMENTO DE SOFTWARE ................................................1-8
CAPÍTULO II -
DAS FASES DO PROJETO
1. FASES DO PROJETO........................................................................................................... 2-1

1.1 FASE DE INICIAÇÃO........................................................................................................2-2
1.2 FASE DE ELABORAÇÃO................................................................................................2-15
1.3 FASE DE CONSTRUÇÃO................................................................................................2-34
1.4 FASE DE TRANSIÇÃO....................................................................................................2-36
CAPÍTULO III -
DAS DISPOSIÇÕES FINAIS
1. PRODUTOS DE TRABALHO............................................................................................3-1
1.1 PLANO DE PROJETO......................................................................................................3-3
1.2 PLANO DE ITERAÇÃO....................................................................................................3-4
1.3 RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO...........................................................3-4
1.4 VISÃO.................................................................................................................................. 3-4
1.5 GLOSSÁRIO....................................................................................................................... 3-4
1.6 MODELO DE CASO DE USO..........................................................................................3-5
1.7 ESPECIFICAÇÕES SUPLEMENTARES .......................................................................3-5
1.8 LISTA DE REGRAS DE NEGÓCIO................................................................................3-5
1.9 LISTA DE REQUISITOS FUNCIONAIS.........................................................................3-5
1.10 CASO DE USO DETALHADO.......................................................................................3-6
1.11 DOCUMENTO DE ARQUITETURA.............................................................................3-6
1.12 TERMO DE HOMOLOGAÇÃO.....................................................................................3-6
1.13 CÓDIGO FONTE.............................................................................................................3-6
1.14 BUILD (CONSTRUÇÃO)................................................................................................3-6
1.15 MODELO DE DESIGN....................................................................................................3-7
1.16 MODELO DE DADOS.....................................................................................................3-7
1.17 CASO DE TESTE.............................................................................................................3-7
1.18 REGISTRO DE TESTE...................................................................................................3-8
1.19 PLANO DE IMPLANTAÇÃO.........................................................................................3-8
1.20 MANUAL DO USUÁRIO................................................................................................3-8
1.21 MANUAL DO SISTEMA.................................................................................................3-8
1.22 MANUAL DE TREINAMENTO.....................................................................................3-8
1.23 RELATÓRIOS DA INFRAESTRUTURA......................................................................3-8
1.24 TERMO DE ENCERRAMENTO DO PROJETO.........................................................3-9
2. DIAGRAMAS DA UML.......................................................................................................3-9
3. UTILIZAÇÃO DE OUTRAS METODOLOGIAS...........................................................3-10
ANEXOS:
ANEXO A – MODELO DE PLANO DE ITERAÇÃO
ANEXO B – MODELO DE RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO
ANEXO C – MODELO DE VISÃO DO PROJETO
ANEXO D – MODELO DE GLOSSÁRIO
ANEXO E – MODELO DE CASO DE USO
ANEXO F – MODELO DE ESPECIFICAÇÕES SUPLEMENTARES
ANEXO G – MODELO DE REGRAS DE NEGÓCIO
ANEXO H – MODELO DE LISTA DE REQUISITOS
ANEXO I – MODELO DE CASO DE USO DETALHADO
ANEXO J – MODELO DE DOCUMENTO DE ARQUITETURA
ANEXO K – MODELO DE TERMO DE HOMOLOGAÇÃO
ANEXO L – MODELO DE DESIGN
ANEXO M – MODELO DE CASO DE TESTE
ANEXO N – MODELO DE PLANO DE IMPLANTAÇÃO
ANEXO O – MODELO DE TERMO DE ENCERRAMENTO DE PROJETO
GLOSSÁRIO..................................................................................................................... 1
REFERÊNCIAS................................................................................................................ 4
EB80-MT-78.001
CAPÍTULO I -
DAS DISPOSIÇÕES PRELIMINARES
1. INTRODUÇÃO
O ciclo de vida de um software, de acordo com as Instruções Gerais (IG) do

Ciclo de Vida de Software do Exército, compreende os seguintes processos: aquisição,
fornecimento, desenvolvimento, produção e manutenção. O processo de
desenvolvimento contém as atividades e tarefas do desenvolvedor, o qual, ainda de
acordo com essas normas, contém as atividades para análise de requisitos, projeto,
codificação, integração, testes, instalação e aceitação relacionadas aos produtos de
software. Essas atividades foram detalhadas e, em alguns casos, fracionadas para
comporem o processo de desenvolvimento de software apresentado neste documento.
A existência de processos definidos é necessária para a maturidade das
organizações que produzem software. Com a padronização dos seus processos, a
organização poderá ter sua forma de trabalho reprodutível. Isso facilita as operações e
torna a organização menos dependente da atuação individual das pessoas. Porém, não
basta que os processos estejam definidos, mas que eles sejam aderentes à realidade
da organização.
Pretende-se que este documento seja um roteiro que padronize os processos
de desenvolvimento de software, que deverá ser utilizado e avaliado por
desenvolvedores, no âmbito do Exército. O mesmo possui caráter dinâmico, para que
seja periodicamente revisado e aperfeiçoado, de forma a refletir as melhores práticas,
adequadas à realidade e características do Exército, para a obtenção de sistemas de
informação de qualidade.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-1

EB80-MT-78.001
A metodologia ora apresentada toma por base os processos e boas práticas do

Rational Unified Process (RUP), que se trata de metodologia consolidada, descrita na
literatura de engenharia de software, além de amplamente utilizada pelos
desenvolvedores de software. Porém, não se exclui a inclusão e utilização de práticas
advindas de outras metodologias, no processo de revisão e aperfeiçoamento deste
trabalho.
Vale ressaltar que, seja qual for o processo utilizado, o proposto por esta MDS
ou outro adotado pela Organização Militar (OM), o desenvolvimento de um software
deve ser documentado, para que seja possível sua futura manutenção. Ao final deste
documento, consta uma relação de documentos mínimos que devem ser gerados
em um projeto de desenvolvimento de software.
2. FINALIDADE
Esta Metodologia de Desenvolvimento de Sistemas (MDS) visa descrever e

padronizar os processos para o desenvolvimento de sistemas no âmbito do Centro de
Desenvolvimento de Sistemas (CDS) e, posteriormente, servir como orientação às
demais Organizações Militares do Exército.
3. OBJETIVOS
a. Definir os papéis e responsabilidades dentro do processo de desenvolvimento de

sistemas;
b. Descrever o fluxo de atividades a serem desenvolvidas para o desenvolvimento
de sistemas;
c. Definir os produtos de trabalho gerados durante o processo de desenvolvimento
de sistemas; e
d. Padronizar os documentos gerados durante o processo de desenvolvimento de
sistemas.

EB80-MT-78.001
4. PAPÉIS E RESPONSABILIDADES
Um papel define o comportamento e responsabilidades de um profissional ou

grupo de profissionais que participam do desenvolvimento do projeto. O
comportamento é representado através das atividades que cada papel deve
desempenhar ao longo do projeto. As responsabilidades normalmente estão
associadas aos produtos de trabalho que cada papel deve produzir, modificar ou
controlar ao longo das atividades que realiza. Na prática, um mesmo papel pode ser
desempenhado por mais de uma pessoa ao longo do projeto.
Os principais papéis levantados nesta MDS são os que se seguem:
4.1 Cliente
Representa as pessoas que conhecem ou utilizam o processo para o qual o

sistema será desenvolvido. É responsável por fornecer as informações que permitam o
levantamento dos requisitos do sistema, validar os produtos gerados no processo, bem
como receber o sistema desenvolvido.
Este papel:
• Informa os requisitos do sistema
• Homologa os produtos do projeto
• Testa o sistema desenvolvido
• Dá o aceite final ao produto desenvolvido
4.2 Gerente de Projeto
Conduz o planejamento do projeto, coordena as interações com os Clientes e

mantém a equipe de projeto focada em alcançar os objetivos do projeto.
Este papel:

EB80-MT-78.001
• Planeja, coordena e controla o andamento das atividades do projeto

• Instrui a equipe para conduzir um resultado de êxito no projeto e aceitação do
produto pelo cliente.
• É responsável pelo resultado do projeto e pela aceitação do produto pelo
cliente.
• É responsável pela avaliação dos riscos do projeto e pelo controle destes
riscos através de estratégias de atenuação.
• Aplica conhecimentos, habilidades, ferramentas e técnicas de gestão em uma
grande quantidade de tarefas a fim entregar o resultado desejado para o
projeto dentro dos prazos estabelecidos, recursos planejados e com os
padrões de qualidade estabelecidos.
4.3 Analista de Sistemas
Responsável por capturar as regras de negócio e os requisitos do sistema a ser

desenvolvido, analisá-los e especificá-los por meio de linguagem de modelagem
apropriada. Elabora e mantém um conjunto de documentos que descrevem os
requisitos a serem atendidos pelo sistema.
Este papel:
• Efetua o levantamento e documentação de informações, junto ao cliente e
demais interessados, para a geração dos produtos que especificam os
requisitos do sistema, considerando ainda aspectos do ambiente de
produção, tais como: necessidade de processamento, armazenamento de
dados, largura de banda e tipos de informação que trafegarão pela rede de
comunicações.
• Elabora os documentos do projeto sob sua responsabilidade, conforme os
prazos estabelecidos e em conformidade com a Metodologia de
Desenvolvimento de Sistemas.

EB80-MT-78.001
• Valida junto ao cliente e gerente de projetos todos os documentos de

requisitos gerados sob sua responsabilidade
4.4 Arquiteto
Define a arquitetura dos elementos do software. Coordena o desenho técnico

do projeto junto ao projetista.
Este papel:
• Identifica e documenta os aspectos arquiteturalmente significativos do
sistema como visões que descrevem requisitos, design, implementação e
distribuição.
• Reduz os riscos técnicos e assegura que as decisões sejam eficazmente
comunicadas, validadas e seguidas.
• Trabalha junto ao Gerente de Projeto na alocação da equipe e no
planejamento do projeto.
4.5 Projetista
Desenvolve o design de forma que ele atenda a arquitetura e a prototipagem

da interface de usuário.
Este papel:
• Define e cria soluções técnicas de acordo com a tecnologia utilizada no
projeto.
• Compreende a arquitetura.
• Comunica o design, por meio de modelos, de forma que os outros membros
da equipe o compreendam.

EB80-MT-78.001
4.6 Desenvolvedor
Implementa e integra os componentes que são parte da solução e, também,

executa testes de unidade.
Este papel:
• Transforma o design em código, implementa a estrutura do sistema na
linguagem fonte escolhida.
• Implementa o comportamento do sistema definido nos requisitos funcionais.
• Escreve o código que permita às diferentes partes da aplicação (classes ou
componentes) colaborarem para a realização do comportamento do sistema.
• Identifica e constrói os testes de desenvolvedor que verificam o
comportamento desejado dos componentes técnicos.
• Integra e constrói o incremento da solução na qual esteja trabalhando.
4.7 Administrador de Banco de Dados
Define tabelas, índices, visões, restrições, triggers, procedimentos

armazenados, parâmetros de armazenamento ou tablespaces e outras construções
específicas de um banco de dados necessárias para armazenar, recuperar e excluir
objetos persistentes.
Este papel:
• Identifica possibilidades de reuso de dados.
• Integra os modelos de dados do projeto com o modelo de dados corporativo.
• Implementa o modelo físico de dados
4.8 Testador

EB80-MT-78.001
Identifica, define, implementa e conduz os testes necessários, bem como

registra e analisa os resultados dos mesmos.
Este papel:
• Identifica os testes que necessitam ser executados.
• Identifica a abordagem de implementação mais apropriada para um
determinado teste.
• Implementa testes individuais.
• Prepara e executa os testes.
• Registra a execução e resultados para os testes.
• Analisa e recupera os erros de execução.
• Comunica os resultados do teste à equipe.
4.9 Projetista de Infraestrutura
Analisa os impactos dos requisitos não funcionais com a infraestrutura

disponível para produção e propõe medidas de adequação, quando for o caso.
Atua como elemento de ligação entre a equipe responsável pelo
desenvolvimento do sistema e o órgão responsável pela hospedagem e produção do
sistema.
Este papel:
• Estabelece as possibilidades e limitações do ambiente de produção para o
projeto.
• Analisa, junto à equipe do projeto, as necessidades não funcionais,
requeridas pelo ´produto, e as possibilidades do ambiente de produção.
• Propõe mudanças nos requisitos do projeto e/ou na infraestrutura existente,
para atender as necessidades do projeto.
• Atua como elemento de ligação entre o órgão desenvolvedor e o de
produção.

EB80-MT-78.001
5. MODELO DE DESENVOLVIMENTO DE SOFTWARE
Este modelo de processo de desenvolvimento de software descreve o fluxo de

atividades e tarefas a serem executadas, para transformar requisitos de usuários e de
sistemas em produto final de software.
O modelo proposto neste documento foi dividido em fases. Em cada fase, o
trabalho a ser realizado é composto por iterações. Cada iteração compreende um ciclo
completo de atividades que, uma vez realizadas, levam à construção de um conjunto
de produtos de trabalho significativos, os quais, somados, permitem que seja atingido o
escopo da fase.
Dentro de cada fase, o trabalho pode ser dividido em tantas iterações quantas
forem necessárias. A cada ciclo da iteração, são agregados novos valores ou
funcionalidades ao sistema, de maneira que o desenvolvimento torna-se incremental.
Dessa forma, o processo proposto incorpora duas características fundamentais
do processo unificado de engenharia de software, quais sejam: ser iterativo e
incremental.

EB80-MT-78.001
CAPÍTULO II -
DAS FASES DO PROJETO
1. FASES DO PROJETO
Do ponto de vista do gerenciamento, o ciclo de vida do projeto de

desenvolvimento de software desta MDS está dividido em quatro fases sequenciais:
iniciação, elaboração, construção e transição. Cada uma dessas fases é concluída por
um marco principal. Tais fases, portanto, representam, basicamente, um intervalo de
tempo entre dois marcos principais. Os marcos são os seguintes (Tabela 1.): para a
fase de iniciação, o escopo do projeto definido e aprovado; para a fase de elaboração,
a arquitetura definida e validada; para a fase de construção, o sistema codificado e
testado; e para a fase de transição, o projeto homologado pelo demandante. A cada
final de fase, é feita uma avaliação para determinar se os objetivos da fase foram
alcançados. Caso a avaliação seja satisfatória, o projeto poderá avançar para a
próxima fase. Os trabalhos, dentro das fases, são estruturados na forma de ciclos de
iterações, os quais realizados, permitem que seja alcançado o marco da fase.
Iniciação Elaboração Construção Transição

Escopo definido e Arquitetura definida Software codificado e Software homologado
aprovado e validada testado
Tabela 1: Marcos do ciclo de vida do desenvolvimento de software

EB80-MT-78.001
1.1 FASE DE INICIAÇÃO
Os projetos no Exército, de acordo com a NEGAPEB, devem ser precedidos

por um estudo de viabilidade, a fim de investigar a sua exequibilidade. Concluindo-se
pelo prosseguimento do projeto, deve ser expedida a Diretriz de Implantação do Projeto
pela autoridade que determinou a ação.
A complexidade do estudo de viabilidade depende de cada projeto, mas,
normalmente, devem ser levantados aspectos legais, técnicos, econômicos, gerenciais
e de riscos que permitam avaliar as reais possibilidades de sucesso do projeto. Em seu
FASE DE INICIAÇÃO
item “Estudo Técnico”, no caso de projetos de desenvolvimento de software, deverá
considerar também eventuais restrições ou limitações do ambiente de produção.
A fase de iniciação marca o início do processo de desenvolvimento, após a
aceitação do projeto.
O foco principal nesta fase é obter o consenso em relação ao escopo do
projeto, o qual será detalhado pela equipe do projeto.
Os principais objetivos da fase são:
a) Estabelecer o escopo do software do projeto e as condições limite, incluindo
uma visão operacional, critérios de aceitação e o que deve ou não estar no
produto;
b) Discriminar os casos de uso críticos do sistema e os principais cenários de
operação;
c) Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para
alguns cenários básicos;
d) Estimar o custo geral e a programação para o projeto inteiro (e estimativas
detalhadas para a fase de elaboração);
e) Identificar as características do ambiente de produção e seus impactos
quanto aos requisitos não funcionais, requeridos pelo produto, de forma a
equilibrar às necessidades do sistema.

EB80-MT-78.001
f) Levantar e planejar o controle dos riscos em potencial (as fontes de

imprevistos); e
g) Preparar o ambiente (físico e lógico) de suporte para o projeto.
FASE DE INICIAÇÃO

EB80-MT-78.001
1.1.1 FLUXO DE ATIVIDADES DA FASE DE INICIAÇÃO
FASE DE INICIAÇÃO
Figura 1: Fluxo de trabalho de uma iteração na fase de iniciação

EB80-MT-78.001
FASE DE INICIAÇÃO
Figura 2: Subprocesso Identificar e Refinar Requisitos
1.1.2 ATIVIDADES, TAREFAS E ENVOLVIDOS
Atividade : Planejar o Projeto

A equipe deve planejar o escopo, objetivos, riscos, duração inicial e os entregáveis do projeto. O Plano
do Projeto será atualizado à medida que o projeto progredir, com base nas informações colhidas sobre
o andamento dos trabalhos e mudanças no ambiente. O Gerente do Projeto deve garantir que todos
estejam comprometidos com o plano elaborado.
Tarefas Descrição
Identificar os Identificar os usuários, conhecedores do domínio, responsáveis pela validação
envolvidos dos artefatos e descrever suas responsabilidades no projeto.
Alocar a equipe A equipe deve ser alocada e definidos os papéis e responsabilidades.
Estimar tamanho e Aplicar técnica de mensuração de tamanho de projeto de software para estimar o
duração do projeto tamanho do sistema a ser desenvolvido.
A equipe deve esboçar uma duração inicial para cada item da lista de requisitos.
Documentar a estimativa de tamanho e duração no Plano do Projeto.
Organizar o projeto Identificar as premissas e restrições do projeto;
Documentar os papéis, responsabilidades e nomear as pessoas responsáveis por
cada papel;

EB80-MT-78.001
O Gerente do Projeto deve avaliar a necessidade de definir os planos para o

acompanhamento do projeto, comunicação, mudanças, aceitação do produto e
outros conforme avaliação.
Descrever o ciclo Analisar o escopo do projeto e seus principais requisitos para descrever quais
de vida do projeto características serão implementadas em quais iterações, colocando os itens de
trabalho de maior prioridade primeiro, incluindo respostas planejadas para os
maiores riscos ou oportunidades.
Definir a duração das iterações e utilizá-las para avaliar a duração do projeto.
Documentar um breve resumo dos marcos do projeto e de um a três objetivos
para cada iteração
Identificar e avaliar A equipe deve identificar os riscos, avaliar e atualizar a lista de riscos.
riscos O Gerente do Projeto deve tomar a decisão de quais riscos serão inicialmente
tratados (mitigados ou evitados), quais serão apenas observados e aqueles que
serão aceitos.
Priorizar requisitos Os requisitos do Projeto devem ser priorizados em conjunto com a área cliente.
FASE DE INICIAÇÃO
O Plano do Projeto deve ser aprovado pelo cliente para garantir o seu
comprometimento.
Relacionamentos
Papéis Responsável: Gerente de Projeto
Participantes:
• Arquiteto
• Analista de Sistemas
• Cliente
Entradas Estudo de viabilidade do projeto
Termo de abertura do projeto
Saídas Plano do Projeto
Atividade: Planejar a Iteração

Esta atividade tem o objetivo de planejar como serão realizadas as iterações dentro da fase. Cada
iteração consiste em um ciclo de atividades que envolvem as principais tarefas da fase e que têm por
objetivo gerar um produto de valor. Tal planejamento visa dividir os trabalho, de forma que o escopo da
fase possa ser alcançado.
Tarefas Descrição
Selecionar os Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para
trabalhos e compor o escopo da iteração com base nos cenários e valores adicionados. Os
objetivos de cada itens selecionados definem a meta da iteração.
iteração para a Determinar quais requisitos dentre os selecionados para a iteração atual
fase. necessitam de maior detalhamento.
Detalhar trabalho Uma vez detalhados os requisitos selecionados para a iteração, a equipe os
da Iteração divide em tarefas conforme sua própria experiência e estima o esforço necessário
para completar cada tarefa. A equipe discute com o Gerente do Projeto a melhor
alocação das tarefas aos membros da equipe.
Documentar o Documentar os requisitos selecionados para a iteração (meta).
planejamento da Documentar o planejamento acordado na reunião.
Iteração

EB80-MT-78.001
Relacionamentos
Papéis Responsável: Gerente do Projeto
Participantes:
• Arquiteto
• Testador
• Desenvolvedores
• Cliente
Entradas • Plano do Projeto
Saídas • Plano da Iteração
Observações
É importante notar que a reunião de planejamento é de suma importância para garantir a comunicação
e comprometimento da equipe e do cliente com o planejamento. Quando o projeto estiver na 1ª
FASE DE INICIAÇÃO
iteração do projeto (Iniciação), esta atividade é dividida em dois momentos. No primeiro momento são
selecionados os requisitos da iteração e realizada uma primeira avaliação dos riscos. Após, em um
segundo momento, é feito o detalhamento dos requisitos prioritários.
Atividade: Definir a Visão

Esta atividade tem por objetivo principal elaborar o documento “Visão”, o qual define a visualização de
envolvidos com o produto a ser desenvolvido e especifica suas necessidades e recursos mais
importantes. Ele contém uma descrição dos requisitos centrais pretendidos e, portanto, proporciona a
base contratual dos requisitos técnicos mais detalhados do sistema
Tarefas Descrição
Identificar os Identificam-se os envolvidos, clientes e usuários que farão parte do
Clientes/Usuários desenvolvimento, orientando e descrevendo as regras dos processos para a
entrega do sistema.
Obter consenso Adquirir consenso entre todos os envolvidos no trabalho a ser realizado e na
sobre o problema a maneira como será gerenciado o projeto.
ser resolvido
Capturar um Termos que contemplam o negócio devem ser definidos para terem significado
vocabulário comum definido ao longo do desenvolvimento do projeto.
Obter os requisitos Serão base para elucidar os requisitos para desenvolver o produto. Deve-se
solicitados pelos realizar reuniões para discutir as solicitações do cliente.
Clientes
Definir os limites do Delimitar o escopo é importante para que funcionalidades não especificadas não
sistema sejam construídas sem planejamento.
Relacionamentos
Papéis Responsável: Analista de Sistemas
Participantes:
• Arquiteto
• Gerente de Projeto
• Cliente

EB80-MT-78.001
Saídas • Documento de Visão

• Glossário
Observações
A solução é proposta para um problema que todos identificam. Os Clientes colaboram com a equipe de
desenvolvimento para expressar e documentar seus problemas, necessidades e potenciais
características para o sistema de forma que a equipe de projeto possa compreender melhor o que tem
de ser feito.
Atividade: Gerenciar a Iteração

Essa atividade contém as tarefas que permitem o início, o acompanhamento, a coordenação, o
controle, a finalização e a revisão de cada iteração.
Tarefas Descrição
Capturar e O gerente de projeto necessita:
FASE DE INICIAÇÃO
comunicar o • monitorar continuamente o projeto para assegurar que esteja progredindo
andamento das corretamente.
Iterações • permitir à equipe reagir o mais cedo possível a qualquer mudança.
Muitas formas alternativas podem ser usadas para acompanhar o andamento,
dentre elas, rápidas reuniões diárias, com a equipe do projeto, as quais são úteis
para compreender o que os membros da equipe realizaram desde a última
reunião, e o que planejam realizar antes da próxima reunião. Essas reuniões,
também, permitem que a equipe identifique problemas e tome medidas corretivas.
Tratar as exceções Identifique a causa e o impacto dos problemas e exceções assim que eles
e os problemas aparecerem, as soluções possíveis que têm impacto imediato nos objetivos e
metas de curto prazo, bem como quem necessita ser envolvido na execução da
solução. A seguir, defina as ações corretivas e coordene sua execução.
Identificar e Identifique os riscos assim que o projeto inicie. A Lista de Riscos será incluída no
gerenciar os riscos documento Plano de Projeto, de acordo com a NEGAPEB. Deve ser revisada
semanalmente, ou no mínimo uma vez por iteração.
Gerenciar os Altere o escopo do trabalho, caso necessário, para assegurar que a equipe
objetivos entregue um incremento útil do produto no fim da iteração, maximizando o valor
aos Clientes, quando uma equipe estiver atrasando de forma significativa, ou
problemas críticos ocorrerem, que impeçam a equipe de alcançar os objetivos da
iteração.
Trabalhe com a equipe e os Clientes para revisar o Plano de Iteração e, se
necessário, reduzir a ênfase nas tarefas menos críticas adiando-as para uma
iteração subsequente. Em casos raros, se os objetivos da iteração ainda
parecerem impossíveis de serem cumpridos, a equipe pode considerar o
encerramento ou a reformulação da iteração para um novo objetivo.
Relacionamentos
Participantes:
• Arquiteto
• Desenvolvedor
• Cliente

EB80-MT-78.001
• Testador
Entradas Plano de Iteração
Plano de Projeto
Saídas Plano de Iteração revisado
Plano de Projeto revisado
Atividade: Planejar Próxima Iteração

Esta atividade tem o objetivo de planejar como serão realizadas as iterações da próxima fase. Cada
iteração consiste em um ciclo de atividades que envolvem as principais tarefas da fase e que têm por
objetivo gerar um produto de valor. Tal planejamento visa dividir os trabalho, de forma que o escopo da
fase possa ser alcançado.
Tarefas Descrição
Selecionar os Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para
FASE DE INICIAÇÃO
trabalhos e compor o escopo da iteração com base nos cenários e valores adicionados. Os
objetivos de cada itens selecionados definem a meta da iteração.
iteração para a Determinar quais requisitos dentre os selecionados para a iteração atual
fase. necessitam de maior detalhamento.
Detalhar trabalho Uma vez detalhados os requisitos selecionados para a iteração, a equipe os
da Iteração divide em tarefas conforme sua própria experiência e estima o esforço necessário
para completar cada tarefa. A equipe discute com o Gerente do Projeto a melhor
alocação das tarefas aos membros da equipe.
Documentar o Documentar os requisitos selecionados para a iteração (meta).
planejamento da Documentar o planejamento acordado na reunião.
Iteração
Relacionamentos
Participantes:
• Arquiteto
• Analista de Teste
• Desenvolvedor
• Cliente
Entradas Plano de Projeto
Plano de Iteração
Saídas Plano de Iteração
Atividade: Encerrar a Iteração

No encerramento da iteração o Gerente do Projeto coordena a revisão da estimativa do projeto, em
função das alterações e conhecimento adquirido com a implementação das funcionalidades da iteração.
Caso seja a última iteração do projeto prossegue com o encerramento do mesmo e dos contratos a ele
associados.
Tarefas Descrição

EB80-MT-78.001
Revisar os Avalie em conjunto com a equipe do projeto, ao final da iteração, se os objetivos e

resultados da os critérios de avaliação estabelecidos no Plano de Iteração foram alcançados, e
iteração se a equipe aderiu ao plano da iteração e concluiu todos os itens de trabalho
atribuídos à iteração
Avaliar a estimativa Avaliar se as estimativas de tempo iniciais foram atingidas.
do tamanho do
produto
Demonstrar valor e Demonstre o produto ao cliente, aos usuários finais e aos outros clientes para
obter retorno obter seu retorno de informações (feedback). Isto deve ser feito durante a
iteração, ou pelo menos em uma sessão separada próxima ao fim da iteração.
Realizar Proceda com o pagamento de acordo com o valor calculado do tamanho
procedimentos desenvolvido, em pontos de função, em caso de desenvolvimento feito por
administrativos empresa contratada:
Divulgue a todos os envolvidos via e-mail, atualização do andamento do projeto e
a conclusão da iteração.
FASE DE INICIAÇÃO
Realizar Se aplicável, encerrar os contratos vigentes para o término do projeto.
procedimentos
contratuais
Relacionamentos
Participantes:
Entradas Especificação de Requisitos
Plano de Iteração
Plano de Projeto
Saídas Relatório de Avaliação da Iteração
Plano de Iteração revisado
Observações
O termo de homologação deverá ser assinado pelo gerente de projetos e pelo cliente, firmando as
decisões que foram tomadas.
Atividade: Identificar e Refinar os Requisitos / Encontrar e descrever os requisitos

O propósito desta atividade é a identificação e refinamento dos requisitos para posterior aprovação do
cliente. O objetivo é adquirir consenso entre todos os envolvidos do trabalho a ser realizado e o
detalhamento das funcionalidades do sistema.
Tarefas Descrição
Encontrar requisitos Através de reuniões com o cliente, levantam-se os requisitos (funcionais e não
funcionais) do sistema.
Refinar Requisitos Especificar os requisitos na forma de casos de uso e especificações
suplementares.
Relacionamentos

EB80-MT-78.001
Papéis Responsável:
Participantes:
• Gerente do Projeto
• Analistas de Sistemas
• Arquiteto
• Cliente/Usuário
Entradas • Plano de Iteração
• Plano de Projeto
• Visão
• Glossário
Saídas • Modelo de Caso de Uso
• Especificação de Requisitos Suplementares
• Lista de Regras de Negócio
• Lista de Requisitos Funcionais
FASE DE INICIAÇÃO
Atividade: Identificar e revisar os requisitos / Detalhar os requisitos
Detalhar os requisitos para validar o entendimento dos requisitos, assegurar consenso na área cliente
e permitir que o desenvolvimento do sistema comece.
Tarefas Descrição
Detalhar requisitos • Identificar os atores e os cenários dos casos de uso e detalhar.
• Criar esboços de tela para garantir o entendimento do fluxo de navegação
e disposição dos elementos de interface por parte do cliente e
desenvolvedores.
• Atualizar o Modelo de Casos de Uso e obter o consenso dos envolvidos.
Relacionamentos
Participantes:
• Cliente
• Gerente do Projeto
• Desenvolvedor
Entradas • Lista de Requisitos Funcionais
• Modelo de Caso de Uso
Saídas • Caso de Uso detalhado
• Descrição de Interfaces
Atividade: Homologar requisitos

O propósito desta atividade é coletar a aprovação da área cliente dos requisitos detalhados e, dessa
forma, adquirir consenso entre todos os envolvidos do trabalho a ser realizado e da maneira como será
gerenciado o projeto.
Tarefas Descrição
Aprovar requisitos Avaliar se a Especificação de Requisitos contempla todas as especificidades

EB80-MT-78.001
funcionais e não funcionais para os requisitos selecionados para a Iteração.

Avaliar os esboços de tela para garantir o entendimento do fluxo de navegação e
disposição dos elementos de interface.
Emitir aprovação.
Relacionamentos
Participantes:
Entradas Especificação de Requisitos
Especificações Suplementares
Plano do Projeto
Modelo de Casos de Uso
Especificação de Casos de Uso
Descrição de interfaces
FASE DE INICIAÇÃO
Saídas Termo de Homologação
Atividade: Preparar ambiente de desenvolvimento

O objetivo desta atividade é garantir que tecnicamente todos da equipe tenham condições de iniciar a
implementação dos requisitos selecionados para realização da iteração. As ferramentas de
desenvolvimento devem ser instaladas e configuradas, conforme as necessidades do projeto.
Tarefas Descrição
Identificar Verificar as ferramentas necessárias para o desenvolvimento, nas devidas
ferramentas versões.
Mapear servidores Definir os servidores que serão utilizados como ambiente de teste, homologação e
produção e instalar os sistemas necessários.
Criar Bases de Instalar sistema gerenciador de banco de dados e base de dados do projeto, se
Dados for o caso.
Configurar Deixar os computadores dos desenvolvedores prontos para a implementação
ambiente prevista na iteração.
Instalar ferramentas, plug-ins e acessórios.
Criar a estrutura de diretório do projeto e configurar o software de controle de
versionamento.
Relacionamentos
Papéis Responsável: Arquiteto
Participantes:
• Gerente de projeto
• Desenvolvedor
• DBA
Entradas • Plano do Projeto e Plano de Iteração
Saídas • Repositório Configurado
• Ambiente de Desenvolvimento Configurado

EB80-MT-78.001
Atividade: Descrever a Arquitetura

Descrever a arquitetura através da análise dos requisitos arquiteturalmente significantes e pela
identificação de restrições, decisões e objetivos arquiteturais.
Tarefas Descrição
Identificar as metas Trabalhe com a equipe, especialmente com os Cliente e o Analista, para
arquiteturais descrever as metas da arquitetura restantes e identificar quais são adequadas
para a iteração. Examine a Visão e os requisitos. Estas metas irão priorizar e guiar
a abordagem para decisões técnicas importantes. Será importante revisar
periodicamente o status dessas metas em todo o projeto para certificar que elas
ainda são válidas e que o sistema está no caminho certo para entregá-las.
FASE DE INICIAÇÃO
Identificar os Identifique quais dos requisitos atuais são arquiteturalmente significantes. Explore
requisitos e refine aqueles que devem ser implementados para alcançar as metas
arquiteturalmente arquiteturais da iteração atual.
significantes
Identificar as Liste quaisquer restrições na arquitetura e eventuais conflitos entre os requisitos e
restrições na os recursos concorrentes. Decida como a arquitetura irá resolver essas questões.
arquitetura Justifique cada decisão tomada e capture essas informações. Revise
periodicamente a lista de restrições para certificar que elas ainda são válidas e
que não apareceram outras novas.
Examinar, avaliar e Identifique os recursos de outras áreas que podem ser reutilizados na arquitetura
selecionar os atual. Podem ser: frameworks arquiteturais, mecanismos arquiteturais, decisões
recursos arquiteturais, restrições, aplicações e componentes.
disponíveis
Definir a Decida como estruturar o software em termos lógicos e físicos. No mínimo defina:
abordagem para • Como decompor o software ao gerenciar o desenvolvimento (o uso de
estruturar o sistema divisão em camadas como uma estratégia de decomposição, por
exemplo).
• Como o software será composto em tempo de execução.
Para cada decomposição do software, descreva resumidamente:
• Seu nome e finalidade.
• Seus relacionamentos com outras decomposições.
Estas definições irão construir a base para estruturar o Design e a
Implementação.
Definir a Descreva como o software será distribuído nos nós da rede. Trabalhe com os
abordagem para clientes bem como com as equipes de implantação e de suporte de rede para
implantar o sistema assegurar que a abordagem proposta seja uma boa opção para todo o ambiente
técnico.
Identificar os Faça uma lista dos serviços técnicos que o sistema precisa fornecer e capture
mecanismos algumas informações básicas sobre cada item na lista. Normalmente, é uma boa
arquiteturais ideia fazer uma lista inicial de todos os mecanismos necessários ao projeto e, em
seguida, priorizar o desenvolvimento dos que devem ser entregues, para alcançar
as metas da iteração atual

EB80-MT-78.001
Verificar a Trabalhe com o Desenvolvedor e o Gerente de Projeto, para verificar se a

coerência arquitetura está consistente com os requisitos e se as descrições da arquitetura
arquitetural estão claras, significativas e completas.
Capturar as Capture decisões importantes sobre a arquitetura para referência futura.
decisões Considere o uso dos templates fornecidos para o Documento de Arquitetura. Os
arquiteturais Desenvolvedores em particular, devem compreender claramente o estado atual da
arquitetura em cada iteração antes do desenvolvimento da arquitetura.
Relacionamentos
Participantes:
• Desenvolvedor
• Cliente
Entradas Visão
FASE DE INICIAÇÃO
Glossário
Saídas Documento de Arquitetura

EB80-MT-78.001
Atividade: Analisar ambiente de Produção

O objetivo desta atividade é analisar a infraestrutura do ambiente de produção, para se verificar a sua
adequabilidade às exigências do sistema.
Tarefas Descrição
Identificar as Identificar as características do ambiente de produção relevantes para o sistema
características em desenvolvimento, tais como: servidores, capacidades de processamento,
técnicas do memória, armazenamento de dados, de banda de rede e backup, sistemas
ambiente de operacionais e softwares existentes e suas licenças de uso, bem como
produção, suas capacitação do pessoal. Verificar, também, a projeção de utilização dessas
possibilidades e capacidades pelos sistemas atuais e futuros (previstos).
limitações.
Verificar as Verificar as necessidades do sistema, em virtude dos requisitos não-funcionais,
necessidades do levantados nas especificações suplementares.
FASE DE ELABORAÇÃO
sistema decorrentes
dos requisitos
não-funcionais
Verificar se a Verificar se a infraestrutura atual e/ou futura atende os requisitos não-funcionais
infraestrutura atual do sistema.
atende o sistema
Propor ajustes no Propor ajustes na infraestrutura de produção, para atender aos requisitos
ambiente de não-funcionais do sistema. Propor, também, reserva de recursos de infraestrutura,
produção e/ou visando atender o sistema em desenvolvimento. Consolidar todo o estudo em um
reservas de relatório.
capacidades.
Relacionamentos
Papéis Responsável: Projetista de Infraestrutura
Participantes:
• Arquiteto
Entradas Especificação de Requisitos Suplementares
Documento de Arquitetura
Saídas Relatório
1.2 FASE DE ELABORAÇÃO
Na fase de elaboração, busca-se estabelecer a linha de base (baseline) para a

arquitetura do sistema, a fim de fornecer uma base estável para o esforço da fase de
construção.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-15

EB80-MT-78.001
Esta fase envolve uma análise detalhada sobre as necessidades e problemas

gerais do projeto e a definição de como o sistema será desenvolvido em termos
tecnológicos, considerando os requisitos (funcionais e não funcionais), limitações e
restrições identificadas durante a fase de iniciação.
a) Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o
suficiente e que os riscos sejam suficientemente diminuídos a fim de
determinar com segurança o custo e a programação para a conclusão do
desenvolvimento;
b) Tratar todos os riscos significativos do ponto de vista da arquitetura do
projeto;
c) Estabelecer uma arquitetura de baseline derivada do tratamento dos
cenários significativos do ponto de vista da arquitetura, que normalmente
expõem os maiores riscos técnicos do projeto;
d) Implementar e testar um ou mais casos de uso que representam os maiores
riscos técnicos do projeto,para demonstrar que a arquitetura proposta
suportará os requisitos do sistema a um custo e tempo viáveis; e
e) Configurar o ambiente de suporte para o projeto. Isso inclui adaptar o
processo para o projeto, preparar gabaritos, diretrizes e configurar
ferramentas.

EB80-MT-78.001
1.2.1 FLUXO DE ATIVIDADES DA FASE DE ELABORAÇÃO
Figura 3: Fluxo de trabalho de uma iteração na fase de elaboração / construção

EB80-MT-78.001
Figura 4: Subprocesso Desenvolver Incremento da Solução
Figura 5: Subprocesso Testar a Solução

EB80-MT-78.001
1.2.2 ATIVIDADES, TAREFAS E ENVOLVIDO
As atividades “Gerenciar a Iteração”, Planejar Próxima Iteração”, “Encerrar a

Iteração”, “Identificar e Refinar Requisitos” e “Homologar Requisitos”, por se repetirem
nas fases de Iniciação e de Elaboração, já foram detalhadas na fase de Iniciação.
Atividade: Revisar a Iteração

Essa atividade tem o objetivo de avaliar o Plano de Iteração elaborado anteriormente, confrontar com
as iterações realizadas até o momento e, a partir disso, revisar o planejamento das iterações da fase
que se inicia.
Tarefas Descrição
Verificar os Verificar se os objetivos da iteração da fase anterior foram atingidos.
requisitos da Avaliar o trabalho a ser realizado dentro da fase atual e confrontar com o
iteração planejado no Plano de iteração realizado anteriormente.
Selecionar os requisitos a serem implementados na iteração. Os requisitos
selecionados definem a meta da iteração.
Confirmar ou redefinir a prioridade dos itens de trabalho da iteração, conforme
definições do cliente e, com base nesta prioridade, selecionar requisitos a serem
detalhados para as próximas iterações.
Determinar quais requisitos dentre os selecionados para a iteração atual
necessitam de maior detalhamento.
Identificar e revisar Identificar e revisar os riscos e seus planos de resposta.
riscos
Revisar o Revisar ou confirmar as tarefas necessárias para realizar os requisitos
detalhamento do selecionados para a iteração. Estimar o esforço necessário para completar cada
trabalho da Iteração tarefa.
O Gerente do Projeto realiza a distribuição das tarefas para os membros da
equipe.
Documentar a Documentar as alterações nos requisitos selecionados para a iteração (meta).
revisão do Documentar as alterações no planejamento acordado.
planejamento da
iteração, caso
necessário.
Relacionamentos
Participantes:
• Arquiteto
• Desenvolvedor
• Testador
Visão do Projeto Plano da Iteração

EB80-MT-78.001
Relatório de Avaliação de Iteração anterior

Saídas Plano da Iteração revisado
Observações
1. Durante o planejamento do projeto, as iterações são identificadas, mas as estimativas possuem
uma incerteza aceitável devido à falta de detalhes na concepção do projeto.
2. Esta atividade é repetida em cada iteração durante uma entrega. Isto permite que a equipe
aumente a precisão das estimativas para uma iteração, visto que mais detalhes sobre o projeto
serão conhecidos.
3. O Gerente de Projeto tem a responsabilidade de garantir que a equipe comprometa-se com
uma quantidade razoável de trabalho para a iteração, baseado no desempenho da equipe e
nas iterações anteriores.
4. O foco de uma iteração na fase de elaboração é validar a arquitetura.
5. O foco de uma iteração na fase de construção é a implementação dos requisitos funcionais.
6. O foco de uma iteração na fase de transição é assegurar que o software esteja disponível para
seus usuários finais.
7. Avaliar a clareza dos critérios de avaliação para a iteração.
8. Assegurar-se de que os produtos planejados podem ser construídos com o esforço e tempo
disponível.
9. Assegurar-se de que os resultados da iteração serão passíveis de verificação.
Atividade: Refinar a arquitetura

A arquitetura, inicialmente esboçada, na fase de iniciação, será, durante a fase de elaboração, refinada
em um nível apropriado de detalhe para suportar o desenvolvimento.
Tarefas Descrição
Identificar os Refine as principais abstrações em elementos concretos de design (tais como
elementos de design classes e subsistemas) e forneça pelo menos um nome e uma descrição
arquiteturalmente resumida para cada um.
significantes
Refinar os Refine cada mecanismo arquitetural priorizado em um estado de design.
mecanismos Revise os requisitos da iteração atual para identificar quais mecanismos
arquiteturais precisam realmente ser entregues no software. Trabalhe com os
desenvolvedores para que eles refinem os mecanismos para um estado de
implementação.
Definir métricas de Defina as métricas e os parâmetros que serão utilizados para avaliar a
qualidade de código qualidade e a segurança do código produzido
Associar o software ao Associe os elementos de design arquiteturalmente significantes ao ambiente
hardware definido para implantação. Trabalhe com os especialistas de rede e hardware
para assegurar que o hardware seja adequado para atender as necessidades
do sistema; e que qualquer hardware novo esteja disponível oportunamente.
Definir a arquitetura de Assegure-se de que as arquiteturas de desenvolvimento e de teste estejam
desenvolvimento e a definidas. Identifique qualquer diferença arquiteturalmente significante entre
arquitetura de teste estes ambientes e trabalhe com a equipe para planejar estratégias para
atenuar qualquer risco que eles possam gerar.
Atualizar a arquitetura Atualize o Documento de Arquitetura para refletir qualquer mudança feita

EB80-MT-78.001
durante o desenvolvimento.
Validar a arquitetura Assegure-se de que a arquitetura suporte os requisitos e as necessidades do
projeto. Desenvolva alguns casos de uso importantes para o projeto para
produzir uma versão que mostre que a arquitetura de software é viável. Isto
deve fornecer a base definitiva para validar a viabilidade da arquitetura. Como
o software deve ser desenvolvido de forma iterativa, mais de um incremento
pode ser necessário para validar a arquitetura. Durante os estágios iniciais do
projeto pode ser aceitável que o software tenha uma aparência incompleta ou
prototípica, porque será considerado inicialmente como linha base da
arquitetura para fornecer uma base estável para o trabalho de desenvolvimento
restante.
Comunicar as Assegure-se de que aqueles que necessitam agir sobre o trabalho arquitetural
decisões compreendam-no e possam trabalhar com ele. Certifique-se de que a
descrição da arquitetura explica claramente não somente a solução, mas
também a motivação e os objetivos relacionados às decisões que foram
tomadas na elaboração da arquitetura. Isto tornará mais fácil aos outros a
compreensão da arquitetura e sua adaptação no tempo.
Relacionamentos
Participantes:
• Desenvolvedor
Entradas Visão
Glossário
Saídas Documento de Arquitetura revisado
Observações
O arquiteto deve executar esta tarefa com a colaboração de toda a equipe para promover consenso e
compreensão comum de toda a solução. O arquiteto deve trabalhar para coordenar e guiar as
atividades técnicas da equipe. O arquiteto deve colocar ênfase no envolvimento dos desenvolvedores
durante toda esta tarefa.
Atividade: Projetar a solução

A finalidade desta tarefa é descrever os elementos do sistema de modo que suportem o
comportamento necessário, sejam de alta qualidade, e adaptem-se a arquitetura.
Tarefas Descrição
Compreender os Examine os Caso de Uso relevantes e a Especificação de Requisitos
detalhes dos Suplementares para compreender o escopo da tarefa de design e as
requisitos expectativas sobre o Design
Compreender a Revise o Documento de Arquitetura para identificar mudanças e adições à
arquitetura arquitetura
Este passo pode ser ignorado, se não houve alterações na arquitetura proposta
na iteração anterior.

EB80-MT-78.001
Identificar Identifique os elementos que colaboram entre si para fornecer o

elementos de comportamento desejado. Isto pode começar com as principais abstrações
design identificadas no Caderno de Arquitetura, no design, na análise de domínio e na
análise clássica dos requisitos (filtragem de substantivo) para derivar os
elementos que serão necessários para cumpri-los
O Padrão Entidade-Controle-Fronteira fornece um bom começo para identificar
elementos
Determinar como Percorra o cenário distribuindo as responsabilidades aos elementos
os elementos participantes e assegurando que eles têm os relacionamentos necessários para
colaboram para colaborar.
realizar o cenário Estas responsabilidades podem ser simples declarações do comportamento
atribuídas aos elementos; não necessitam ser especificações detalhadas de
operações com parâmetros.
Verifique o Documento de Arquitetura e o trabalho de design prévio para criar
uma colaboração consistente.
Trabalhe com o Arquiteto para entender os detalhes e as motivações da
arquitetura.
Procure reutilizar relações e comportamentos existentes ou aplique estruturas
similares para simplificar o design de todo o sistema.
Refinar as decisões Refine o design até um nível apropriado de detalhe para orientar a
de design implementação e assegurar que se adapta à arquitetura.
Nesta etapa o design pode levar em consideração a linguagem de
implementação real e outras decisões técnicas
Discuta questões sobre teste, tais como os elementos de design que são
difíceis de testar ou áreas críticas de desempenho, com o Testador e o
Arquiteto.
Projetar o interior Projete elementos grandes ou complexos ou algum comportamento interno
complexo mais detalhadamente.
Pode ser útil descrever uma máquina de estado para os elementos com
estados complexos.
Comunicar o Comunique o design do sistema para aqueles que necessitam compreendê-lo.
Design Embora isto esteja descrito daqui até o fim da tarefa, a comunicação deve
acontecer em todas as etapas. Trabalhar colaborativamente é sempre melhor
do que revisar o trabalho depois dele estar completo.
Avaliar o Design Avalie o design de objeto para acoplamento, coesão e outras medidas de
qualidade de design.
Relacionamentos
Papéis Responsável: Projetista
Participantes:
• Arquiteto
• Desenvolvedor
• Testador
Entradas Documento de Arquitetura
Caso de Uso Detalhado
Especificação de Requisitos Suplementares
Saídas Modelo de Design

EB80-MT-78.001
Observações
1. Esta atividade serve para projetar parte do sistema, não o sistema inteiro. Deve ser aplicada
com base em um pequeno grupo dos requisitos. O design é mais bem executado em
pequenas partes.
2. Aplique padrões durante toda esta tarefa. Os padrões representam designs aprovados e seu
uso promove qualidade e consistência em todo o Design.
3. Os requisitos que orientam o Design podem ser requisitos funcionais baseados em cenários,
requisitos não-funcionais ou uma combinação destes.
4. Se esta tarefa estiver sendo executada em um elemento arquiteturalmente significante, os
resultados deste design devem ser referenciados pelo Documento de Arquitetura
5. Aqui estão alguns exemplos dos indivíduos que precisarão entender o design do sistema:
• Os desenvolvedores que implementarão uma solução baseados no design.
• Os arquitetos que podem revisar o design para assegurar que se conforma com a
arquitetura ou que possa examinar o design para oportunidades de melhoria na
arquitetura.
• Outros projetistas que podem examinar o design para aplicabilidade em outras partes
do sistema.
• Desenvolvedores ou outros projetistas que estarão trabalhando em outras partes do
sistema que dependerão dos elementos projetados nesta tarefa.
• Outros revisores que revisarão o design em relação à qualidade e aderência aos
padrões.
Atividade: Validar e implementar o modelo de dados

O objetivo desta atividade é analisar as regras de negócio em relação aos dados e implementar
fisicamente um modelo de dados lógico
Tarefas Descrição
Verifique a aderência do modelo de dados às normas para definição de dados e
Validar o modelo
metadados (IR 14-06).
Identificar reuso Identifique oportunidades para reutilização de dados
Definir tipos reutilizáveis definidos pelo usuário.
Criar as tabelas e relações iniciais do banco de dados.
Definir tabelas de referência
Definir uma ou mais colunas que identifiquem exclusivamente uma linha na tabela
(chave primária).
Definir limites sobre as colunas que garantam a exclusividade dos dados ou da
coleta de dados.
Implementar o
Definir regras de cumprimento de integridade referencial e dados (Chaves
modelo de dados
estrangeiras).
Desnormalizar o modelo de dados para otimizar o desempenho.
Otimizar acesso a dados por meio de indexação.
Projetar a alocação de espaço e a organização de página de disco do banco de
dados.
Projetar procedimentos armazenados para distribuir comportamento de classe ao
banco de dados.

EB80-MT-78.001
Relacionamentos
Papéis Responsável: DBA
Participantes:
• Arquiteto
• Projetista
• Desenvolvedor
Entradas Modelo de dados
Saídas Modelo de dados validado
Atividade: Aprovar Projeto da Solução

O objetivo desta atividade é o de avaliar o design e garantir que está de acordo com a arquitetura
proposta para o projeto antes de liberar para a implementação da iteração.
Tarefas Descrição
Avaliar o Design Verificar se o design está coerente com a arquitetura definida
Revisar o Modelo Revise o modelo de design como um todo para detectar problemas complexos na
de Design disposição das camadas e no particionamento de responsabilidades. A finalidade
da revisão do modelo como um todo é detectar problemas que poderiam passar
despercebidos em uma revisão menos detalhada.
Revisar as Verifique se todos os cenários da iteração atual foram completamente abordados
realizações de pelas realizações de casos de uso. Todos os comportamentos dos sub fluxos
Casos de Uso relevantes de caso de uso devem ser descritos nas realizações de casos de uso
concluídas.
Avaliar a aderência Verificar se os diagramas dos modelos de design estão completos e aderentes
aos padrões para aos padrões estabelecidos para análise e design de sistemas.
os diagramas
Relacionamentos
Participantes:
• Projetista
• DBA
Entradas Documento de arquitetura
Modelo de Design
Saídas Modelos de Design aprovados
Documento de Arquitetura revisado
Atividade: Desenvolver Incremento da Solução / Implementar a Solução

A finalidade desta tarefa é produzir uma implementação para uma parte da solução (tal como uma
classe ou um componente), ou reparar um ou mais defeitos. Normalmente o resultado é um código
fonte novo ou modificado, que normalmente é referenciado pela implementação.
Tarefas Descrição
Determinar uma Determine uma estratégia, baseada no design e nos teste de desenvolvedor,

EB80-MT-78.001
estratégia indicando como você irá implementar a solução. As opções fundamentais são:
1. Aplique recursos reutilizáveis existentes.
2. Modele o design detalhadamente e gere o código fonte (pela
transformação do modelo).
3. Escreva o código fonte.
4. Qualquer combinação das opções descritas.
Identificar Identifique algum código existente ou elementos de implementação que possa
oportunidades para ser reutilizado em parte da Implementação que você esteja criando ou
reuso alterando.
Uma compreensão detalhada de todo o design é muito útil porque é mais fácil
encontrar oportunidades de reuso quando se tem uma completa compreensão
da solução proposta.
Transformar o design Se você estiver usando ferramentas de modelagem sofisticadas, poderá gerar
em implementação uma parte do código fonte necessário a partir do modelo. Note que a
programação é comumente necessária para terminar a implementação, após o
modelo de design ter sido transformado em código.
Mesmo sem ferramentas, pode existir uma quantidade de código a ser criado
pela verificação do design e dos testes de desenvolvedor.
Escrever o código fonte Escreva o código fonte de forma que a implementação esteja em
conformidade com o design e o comportamento desejados. Você deve tentar a
reutilização ou a geração de código sempre que possível, mas ainda
necessitará de alguma programação. Para isso, considere o seguinte:
1. Examine os requisitos. Pelo fato de algumas informações dos
requisitos não se traduzirem diretamente em seu design você deve
examinar os requisitos para se assegurar que eles estejam
inteiramente contemplados na implementação.
2. Refatore o código para melhorar o design. A Refatoração é uma
técnica onde a qualidade do código é melhorada através de
mudanças pequenas e seguras.
3. Ajuste os resultados da implementação existente melhorando o
desempenho, a interface de usuário, a segurança, e outras áreas
não funcionais.
4. Adicione detalhes faltantes, tais como a conclusão da lógica das
operações ou a adição de classes de suporte e estruturas de dados.
5. Cuide das condições limítrofes.
6. Trate as circunstâncias incomuns ou os estados de erro.
7. Restrinja o comportamento (impedindo que os usuários ou funções
externas executem fluxos, cenários ou combinações de opções
ilegais).
8. Adicione seções críticas para código multi-thread ou reentrante.
9. Mantenha o código simples
Embora diversas considerações estejam listadas aqui, existe um caminho
claro para saber quando o código fonte está pronto. A solução foi
implementada quando ela passa pelos testes de desenvolvedor. Outras
considerações podem cuidar da refatoração do código para melhorá-lo quando
ele estiver completo e correto.
Avaliar a Verifique se a implementação está ajustada à sua finalidade. Examine o
implementação código para determinar se ele executa a função desejada. Esta é uma etapa
de garantia da qualidade que é executada além dos testes e está descrita em
outras tarefas. Considere estas estratégias:

EB80-MT-78.001
1. Leia o código para encontrar erros comuns. Considere manter uma

lista de verificação dos erros encontrados para servir como uma
memória de referência.
2. Use ferramentas para verificar erros de implementação e código
impróprio. Por exemplo, use um verificador de regras de código
estático ou ajuste o compilador para o nível mais detalhado de
advertências.
3. Use ferramentas que possam visualizar o código. A visualização de
código, tal como as visualizações UML na IDE Eclipse, ajudam os
desenvolvedores a identificar questões tais como acoplamento
excessivo ou dependências circulares.
4. Execute inspeções informais direcionadas ao código. Peça aos
colegas para revisar pequenas seções críticas do código e código
com funcionalidades significativas. Evite a revisão de grandes
seções de código.
5. Use um Testador para assegurar que a implementação é
compreensível e testável pelos recursos de teste.
Melhore a implementação baseada nos resultados destas avaliações.

Comunicar decisões Comunique o impacto de mudanças inesperadas no design e nos requisitos.
significantes
As questões e as restrições descobertas durante a implementação do sistema
devem ser comunicadas à equipe. O impacto das questões descobertas
durante a implementação deve ser incorporado nas decisões futuras.
Se for apropriado, atualize os requisitos para refletir as ambiguidades

identificadas e resolvidas na implementação de modo que possam ser
testadas, tornando possível controlar as expectativas dos Clientes.
Similarmente, atualize o design para refletir novas restrições e questões
descobertas durante a implementação para ter certeza que a nova informação
será comunicada para os outros desenvolvedores.
Normalmente, não há necessidade de efetuar uma solicitação de mudança se

a mudança requerida for pequena e a mesma pessoa estiver projetando e
implementando o elemento de código. Esse indivíduo pode fazer a mudança
no design diretamente. Se a mudança requerida tiver um grande impacto,
pode ser necessário comunicar essa mudança aos outros membros da equipe
através de uma solicitação de mudança.
Relacionamentos
Papéis Responsável: Desenvolvedor
Participantes:
• Arquiteto
• Projetista
• Testador
Entradas Modelo Design
Casos de Uso Detalhado
Especificação de Requisitos Suplementares
Saídas Código-fonte
Observações

EB80-MT-78.001
1. Geralmente, esta tarefa é focada em um elemento específico, tal como uma classe ou um
componente, mas não necessariamente precisa ser.
2. Uma parcela do design é implementada ao executar esta tarefa. Esta tarefa pode ser executada
várias vezes durante uma iteração. Na verdade, é melhor executar esta tarefa no menor escopo
possível para estreitar o ciclo entre ela e as tarefas relacionadas com os testes de
desenvolvedor e considerações sobre o design
3. É melhor quando os testes de desenvolvedor já existem, de forma que haja uma definição
inequívoca do que é considerado comportamento correto. A implementação deverá ser testada
imediatamente.
Atividade: Desenvolver Incremento da Solução / Implementar Testes de Desenvolvedor

O objetivo desta atividade é preparar os testes para validar um componente de software (por exemplo,
uma operação, uma classe, uma stored procedure) através do teste de unidade. O resultado será um
ou mais testes de desenvolvedor novos.
Tarefas Descrição
Refinar o escopo e Selecione o incremento de trabalho a ser testado e identifique os testes de
identificar os testes desenvolvedor necessários para verificar se a Implementação que está sendo
desenvolvida se comporta corretamente. Uma boa fonte para identificar o
comportamento esperado de um componente de software é o Design.
Na identificação dos testes ou em qualquer outra parte desta tarefa, considere a
colaboração de um testador.
Escrever a Para executar um teste com sucesso o sistema deve estar em um estado
instanciação do conhecido de modo que o comportamento correto possa ser definido. Implemente
teste a lógica de instanciação que deva ser executada como parte do teste de
desenvolvedor.
Definir os Defina os resultados esperados de cada teste de modo que eles possam ser
resultados verificados.
esperados
Escrever a lógica Escreva as etapas de execução dos testes.
do teste
Definir a resposta Defina as informações que os testes devem produzir para indicar se houve
do teste sucesso ou falha. Considere se uma resposta do tipo “Verdadeiro” ou “Falso” é
suficiente, ou se uma mensagem detalhada deva também ser registrada.
Escrever o código Identifique e implemente os passos necessários para restaurar o ambiente de
para limpeza teste ao estado inicial antes do início de cada teste. O objetivo é assegurar que
não haja nenhum efeito colateral quando da execução dos testes.
Validar o teste Verifique que cada teste de desenvolvedor funcione corretamente. Para isto:
• Execute os testes, observe seu comportamento e conserte qualquer
erro encontrado nos testes.
• Assegure-se de que os resultados previstos estejam definidos
corretamente e que estejam sendo verificados corretamente.
• Verifique a lógica do código de limpeza para cada teste.
• Assegure-se que cada teste de desenvolvedor funcione no seu
framework de suíte de teste.
Relacionamentos

EB80-MT-78.001

Participantes:
• Arquiteto
• Testador
Entradas Código-fonte
Saídas Teste de Desenvolvedor
Atividade: Desenvolver Incremento da Solução / Executar os Testes de Desenvolvedor

Execução de testes nos componentes individuais de software para verificar que suas estruturas
internas funcionam de acordo com o especificado.
Tarefas Descrição
Executar os Testes Configure o ambiente de teste para assegurar que todos os elementos
de Desenvolvedor necessários (como hardware, software, ferramentas, dados, etc.) foram
implementados e estão no ambiente de teste.
Inicialize o ambiente de teste para assegurar que todos os componentes estejam
no estado inicial correto para o início do teste.
Execute os procedimentos de teste.
Acompanhar e Determine a ação corretiva apropriada para recuperar-se de uma execução de
corrigir a execução teste de desenvolvedor que tenha falhado.
dos testes. Se o elemento de implementação sob teste estiver defeituoso, repare o problema
e execute novamente os testes.
Se o teste de desenvolvedor estiver defeituoso, repare-o e o execute novamente.
Se houver um problema com o ambiente, resolva-o e execute novamente os
testes.
Quando os testes de desenvolvedor executarem com sucesso, comunique os
resultados.
Verificar os Examine os resultados do teste para assegurar que eles sejam confiáveis e que
Resultados do as falhas, avisos ou resultados inesperados não tenham sido causados por
Teste influências externas (ao objetivo do teste), como configuração ou dados
inadequados.
Relacionamentos
Participantes:
• Testador
Entradas Implementação
Teste de Desenvolvedor
Saídas Testes de Desenvolvedor executados com sucesso
Observações
1. É necessário que o código passe por todos os testes de Desenvolvedor antes que possa ser
entregue em uma build integrada
2. Trabalhe integrado ao Testador em todas as etapas desta tarefa para melhorar os processos de
teste e de qualidade.

EB80-MT-78.001
Atividade: Desenvolver Incremento da Solução / Integrar e Criar a Construção.

EB80-MT-78.001
O objetivo desta atividade é integrar todas as mudanças feitas no código base pelos desenvolvedores e
realizar os testes mínimos no incremento de sistema para validar a construção ( build). A meta é
identificar problemas na integração, o mais rápido possível de forma que possam ser facilmente
corrigidos pela pessoa certa e no momento certo.
Tarefas Descrição
Integrar elementos No seu ambiente de desenvolvimento, combine todos as mudanças concluídas e
implementados que não estejam na última linha de base. Resolva qualquer conflito nas versões
dos artefatos removendo um dos conjuntos de mudança que criou o conflito ou
criando um novo conjunto de mudança que inclua versões fundidas dos artefatos
conflitantes.
Criar a construção Os detalhes deste passo dependem da linguagem de implementação e do
(build) ambiente de desenvolvimento
Executar Testes Execute os Testes de Desenvolvedor nos elementos integrados para verificar se
eles se comportam da mesma forma que quando estavam isolados.
Torne as mudanças Disponibilize a construção (build) para a aprovação do arquiteto assim que os
disponíveis testes terminarem com sucesso e o build for considerado estável.
Relacionamentos
Participantes:
• Arquiteto
Entradas Código-fonte
Saídas Construção (Build)
Observações
Para ser eficaz na aplicação da prática de Integração Contínua, o tempo para integrar, construir e testar
o incremento deve ser curto o bastante de forma que ele possa ser executado várias vezes por dia. As
alterações devem ser subdivididas em conjuntos de mudanças, relativamente pequenos, que possam
ser implementados, integrados e testados rapidamente.
Atividade: Aprovar Implementação

O objetivo desta atividade é avaliar o design e a implementação antes de liberar uma versão para teste
de sistema
Tarefas Descrição
Avaliar a Analise os artefatos de código produzidos pelos desenvolvedores, verificando:
implementação • Compatibilidade com as métricas de avaliação de qualidade de código;
• Aderência ao Padrão de Codificação;
• Seguimento das normas para desenvolvimento de código seguro
Esta tarefa deve ser realizada preferencialmente com a utilização de ferramentas
de análise automatizadas de código
Criar uma linha de Crie uma linha de base que identifique inequivocamente a versão que esteja
base pronta para os testes de sistema. Identifique a versão de cada elemento de
implementação e de cada artefato de suporte que foram usados para criar esta
versão.
Este tarefa deverá ser realizado apenas quando conjuntos de mudança forem

EB80-MT-78.001
entregues para satisfazer os requisitos da iteração.

Liberar a versão Implante a versão no ambiente de homologação para e execução de testes de
sistemas e avaliação dos clientes.
Relacionamentos
Participantes:
• Projetista
• Desenvolvedor
Entradas Modelo de Design
Construção
Saídas Versão operacional
Notas de Release
Observações
Deve buscar o maior grau de automatização possível das tarefas dessa atividade
Atividade: Testar a Solução da Iteração/ Criar os Casos de Teste

O objetivo desta atividade é desenvolver os casos de teste e os dados de teste para os requisitos a
serem testados.
Tarefas Descrição
Revisar os Trabalhe com o Analista e o Desenvolvedor para identificar quais cenários
requisitos a serem necessitam de casos de teste novos ou adicionais.
testados
Identifique os cenários como condições únicas de teste. Considere os fluxos
alternativos ou de exceções com perspectivas positivas e negativas.
Identificar Casos de
Discuta o requisito com o Cliente para identificar outras condições de satisfação
Teste relevantes
para os requisitos.
Relacione cada caso de teste com um nome único que identifique a condição que
ele avalia ou o resultado esperado.
Escreva uma descrição resumida com o resultado esperado.
Descrever os Casos
Anote as pre-condições e pós-condições lógicas que se aplicam a cada caso de
de Teste
teste
Revise cada caso de teste e anote onde os dados de entrada ou de saída possam
Identificar os dados
ser necessários.
de teste
Identifique o tipo, quantidade e singularidade do dado necessário e adicione essas
necessários
observações no caso de teste.
Compartilhar e Percorra os casos de teste com o Analista e o Desenvolvedor responsáveis pelo
avaliar os Casos de cenário relacionado.
Teste
Relacionamentos
Papéis Responsável: Testador
Participantes:

EB80-MT-78.001
• Desenvolvedor
• Cliente
Entradas Lista de Requisitos Funcionais
Modelo de Caso de Uso
Caso de Uso detalhado
Saídas Casos de Teste
Observações
1. Desenvolva os casos de teste paralelamente aos requisitos, de forma que o Analista e o Cliente
possam concordar com as condições específicas de satisfação para cada requisito;
2. Os casos de teste agem como critérios de aceitação, refletindo os cenários reais de utilização.
Isto permite aos membros da equipe medir o progresso em termos de casos de teste
executados com sucesso.
Atividade: Testar a Solução / Implementar os Scripts de Teste
O objetivo desta atividade é implementar scripts de teste para validar a implementação de uma parte da
solução
Tarefas Descrição
Selecione um conjunto de Casos de Teste para desenvolver Script de Teste
Selecionar os
detalhados e executáveis.
Casos de Teste a
Trabalhe com o Gerente de Projeto e o Desenvolvedor para determinar quais
implementar
Casos de Teste precisam de Scripts de Teste detalhados durante a iteração atual.
Determine se o Script de Teste será manual ou automático
Se o Caso de Teste estiver bem compreendido, é melhor implementar um Script
Projetar o Script de
de Teste automatizado sem antes escrever um procedimento manual.
Teste
Se o Caso de Teste for novo, escrever um Script de Teste manual pode ajudar a
validar o design do teste e ajudar na colaboração com outros membros da equipe.
Desenvolva um Script de Teste procedural e detalhado baseado no seu projeto.
Implementar o Use um estilo solicitação/resposta que declara uma entrada exata, e espera uma
Script de Teste saída exata.
executável Especifique valores de dados que sejam específicos para o Script de Teste ou
referencie dados de teste existentes
Organizar os Agrupe os testes em grupos relacionados.
Scripts de Teste em Crie suas suítes de teste para facilitar os testes de regressão, bem como a
suítes identificação da configuração do sistema.
Execute o Script de Teste para verificar que ele implementa o Caso de Teste
corretamente.
Verificar a
Para testes manuais, percorra o Script de Teste. Para testes automatizados,
implementação
verifique se o Script de Teste executa corretamente e produz o resultado
esperado.
Relacionamentos

EB80-MT-78.001
Participantes:
• Desenvolvedor
• Cliente
Entradas Casos de Teste
Saídas Script de Teste
Atividade: Testar a Solução / Executar os Testes

O objetivo desta atividade é executar os Scripts de testes, analisar os resultados e comunicar os
resultados para a equipe
Tarefas Descrição
Selecionar os Selecione os Scripts de Teste relacionados aos itens de trabalho concluídos na
Scripts de Teste iteração.
Teste manual:
• Execute os testes seguindo o passo-a-passo definido no Script de Teste
Executar Scripts de • Registre o resultado no registro de teste
Teste Teste automatizado
• Inicie a execução do teste nas suítes na sequência correta
• Grave os resultados do teste no Registro de Teste.
Resuma e forneça feedback para a equipe sobre quanto a construção satisfaz os
Fornecer feedback
requisitos previstos para a iteração. Focalize na medição do progresso em termos
para a equipe
de testes executados com sucesso.
Relacionamentos
Entradas Caso de Teste
Script de Teste
Saídas Registro de Testes Funcionais
Atividade: Testar a Solução / Testar requisitos não-funcionais

O objetivo desta atividade é testar os requisitos não-funcionais do sistema.
Tarefas Descrição
Verificar os Verificar os requisitos não-funcionais que devem ser atendidos pelo sistema no
requisitos não ambiente de produção.
funcionais
Instalar o sistema Instalar o sistema em um ambiente que seja mais próximo possível das condições
em ambiente similar de infraestrutura de produção.
ao de produção
Testa os requisitos Executar testes que permitam avaliar os requisitos não-funcionais exigidos pelo
não-funcionais sistema.
Relacionamentos

EB80-MT-78.001

Participantes: Projetista de Infraestrutura
Saídas Registro de Teste
Atividade: Ajustar a Infraestrutura

O objetivo desta atividade é ajustar a infraestrutura, para atender os requisitos não-funcionais do
sistema.
Tarefas Descrição
Identificar não Identificar quais os requisitos não funcionais não foram atendido, bem como aferir
conformidades a medida do não atendimento.
Avaliar possíveis Avaliar as possíveis causas que contribuem para que os requisitos não funcionais,
causas não sejam atendidos.
Caso seja possível, ajustar os parâmetros do ambiente de produção, para atender
Ajustar e/ou propor
os requisitos não-funcionais. Caso isso não seja possível ou não resolva a
medidas de ajuste
situação, propor medidas de ajustes no ambiente de produção. Consolidar todo
na infraestrutura.
esse estudo em um relatório.
Relacionamentos
Papéis Responsável: Projetista de Infraestrutura
Participantes: Arquiteto
Registro de Teste
Saídas Relatório

EB80-MT-78.001
Atividade: Avaliar a versão da Iteração

O objetivo desta atividade é a avaliação da versão operacional produzida ao final de uma iteração
Tarefas Descrição
Avaliar Utilize a versão operacional disponibilizada para validar as funcionalidades
funcionalidades implementadas
Avaliar requisitos Verifique se os requisitos definidos para a iteração foram implementados
Relacionamentos
Papéis Responsável: Cliente
Participantes:
• Gerente
FASE DE CONSTRUÇÃO
Entradas Casos de Uso Detalhados
Registro de Teste
Saídas Termo de Aceite
1.3 FASE DE CONSTRUÇÃO
Na fase de construção, ocorre o processo de desenvolvimento de sistema em

que um produto é desenvolvido de maneira iterativa até que esteja pronto para ser
avaliado.
Ocorrerá o desenvolvimento do código fonte, componentes e consultas e
chamadas à base de dados. Serão efetuados testes de componentes e integração,
conforme especificados na documentação do sistema.
Essa fase exige a integração entre desenvolvedor, analista de sistemas,
analista de requisitos, analista de testes e administrador de dados para a análise,
construção e testes do sistema.
a) Construir as versões úteis (alfa, beta e outros releases de teste) com rapidez
e eficiência;
b) Concluir a análise, o design, o desenvolvimento e o teste de todas as
funcionalidades necessárias;

EB80-MT-78.001
c) Desenvolver de modo iterativo e incremental um produto completo que

esteja pronto para a transição para a sua comunidade de usuários. Isso
implica na descrição dos casos de uso restantes e de outros Requisitos,
atualizando o design, concluindo a Implementação e testando o software;
d) Decidir se o software, os locais e os usuários estão prontos para que o
aplicativo seja implantado; e
e) Atingir um adequado grau de paralelismo no trabalho das equipes de
f) desenvolvimento.
FASE DE CONSTRUÇÃO
1.3.1 FLUXO DE ATIVIDADES DA FASE DE CONSTRUÇÃO
O fluxo de atividades de uma iteração para fase de construção é mesmo da

fase de elaboração.
As atividades e tarefas da fase de construção são as mesmas da fase de

elaboração.
A diferença entre as duas fases são os objetivos com que as iterações são
realizadas. Na fase de elaboração o objetivo é construir protótipos, a partir dos casos
de uso mais críticos e que possam testar a viabilidade da arquitetura proposta. Esses
protótipos poderão evoluir e tornarem-se partes do sistema em desenvolvimento. Na
fase de construção, o objetivo é construir o sistema, uma vez que a arquitetura foi
definida e validada.

EB80-MT-78.001
1.4 FASE DE TRANSIÇÃO
Na fase de transição, o software é testado no geral, com todos os módulos

integrados e avaliados, para verificar se os resultados foram atendidos.
O foco da fase de transição é assegurar que o sistema esteja disponível para
seus usuários finais, buscando a homologação junto ao cliente.
Quando os objetivos da fase de transição são alcançados, o projeto está pronto
para ser encerrado.
FASE DE TRANSIÇÃO
a) Realizar teste beta para validar o novo sistema em confronto com as
expectativas do usuário;
b) Realizar e organizar a documentação de suporte ao sistema.
c) Realizar treinamento de usuários e equipe de manutenção;
d) Homologar o software junto ao cliente;
e) Ajustar o software, incluindo-se: correção de erros, melhoria no desempenho
e usabilidade; e
f) Preparar e distribuir o software.

EB80-MT-78.001
1.4.1 FLUXO DE ATIVIDADES DA FASE DE TRANSIÇÃO
FASE DE TRANSIÇÃO
Figura 6: Fluxo de trabalho de uma iteração na fase de transição

EB80-MT-78.001
As atividades “Gerenciar a Iteração”, Planejar Próxima Iteração”, “Encerrar a

Iteração”, “Identificar e Refinar Requisitos” e “Homologar Requisitos”, por se repetirem
nas fases de Iniciação e de Elaboração, já foram detalhadas na fase de Iniciação. A
atividade “Revisar a Iteração” encontra-se definida na fase de Elaboração.
Atividade: Planejar Implantação

O Plano de Implantação documenta como e quando o produto será disponibilizado para a comunidade
de usuários. Ele inclui empacotamento e distribuição do software. Ele inclui também a instalação do
FASE DE TRANSIÇÃO
software, migração para o novo software, assim como ajuda e treinamento de novos usuários. O Plano
de Implantação fornece uma agenda detalhada de eventos, pessoas responsáveis e dependências de
evento necessárias para garantir a mudança bem-sucedida para o novo sistema.
Tarefas Descrição
Planejar a O resultado da implementação e das atividades de teste são programas
implantação do executáveis testados. Esses programas executáveis devem ser associados a
software em outros produtos de trabalho para constituírem uma unidade ou um produto de
produção implantação completo, contendo:
• Scripts de instalação
• Documentação do usuário
• Dados de configuração
• Programas adicionais para migração e/ou conversão de dados.
Planejar como Os vários produtos de trabalho que compõem o produto liberado são
Empacotar o empacotados na mídia adequada, tais como: CD-ROM, DVD, arquivos de servidor
Software arquivados, manuais, fitas de vídeo e assim por diante e devem ser identificados e
etiquetados apropriadamente. As tarefas geralmente envolvem o trabalho com
organizações externas para que empacotem o software.
Planejar como Com o advento da distribuição pela Internet, a instalação de software é, cada vez
Instalar o Software mais, um processo controlado pelo usuário. Apesar disso, é preciso ter o suporte
de ferramentas e procedimentos de instalação oferecidos com o produto. Em
alguns casos mais raros (grandes sistemas técnicos complexos), a instalação é
executada pelo fornecedor do software.
Como parte da instalação, surge, com frequência a questão da migração, como:
• A substituição de um sistema antigo por um novo, com ou sem restrições
de continuidade de operações.
• A conversão de dados existentes para um novo formato.
Planejar Ajuda e Pode assumir várias formas:
Assistência aos • Cursos de treinamento formais
Usuários • Treinamento baseado em computador
• Ajuda e orientação on-line
• Suporte por telefone
• Suporte pela Internet

EB80-MT-78.001
Relacionamentos
Participantes:
• Arquiteto
Plano de Projeto
Saídas Plano de Implantação
Atividade: Desenvolver Material de Suporte

O material de suporte abrange o pacote completo de informações que serão necessárias ao usuário
final para instalar, operar, utilizar e manter o sistema fornecido. Também inclui material de treinamento
para todas as diversas posições que serão necessárias para utilizar o novo sistema de modo eficaz.
FASE DE TRANSIÇÃO
Tarefas Descrição
Desenvolver Materiais de suporte para o usuário destinam-se a descrever a utilização do
material de suporte sistema. Para a maioria dos produtos, projetados profissionalmente, são
produzidos como aplicativos próprios, como os sistemas de ajuda ou sites da
Web.
Desenvolver Produzir materiais necessários para treinar os usuários do sistema.
materiais de Definir os objetivos do treinamento.
treinamento Determinar como o material deverá ser produzido.
Definir o tipo de treinamento adequado. Sugerem-se as seguintes opções:
• Tutoriais on-line.
• Treinamento em sala de aula.
• Treinamento estilo workshop.
Especificar Consiste em especificações de softwares e em instruções documentadas
requisitos de necessárias para instalar o sistema.
software para
instalação do
sistema.
Desenvolver Organizar e elaborar a documentação para manutenção descrevendo os
material para principais erros e soluções que podem ocorrer na utilização do sistema.
manutenção
Relacionamentos
Participantes:
• Arquiteto
Plano de Projeto
Plano de Implantação
Especificação de Requisitos
Unidade de Implantação (Build)
Saídas Manual do Usuário (Materiais de Treinamento e Material de Suporte do Usuário)

EB80-MT-78.001
Manual do Sistema (Material de Suporte do Sistema e Especificação de

Requisitos de Software)
Atividade Treinar Usuários

Esta atividade foca a preparação e execução dos treinamentos que serão dados, caso necessário, aos
usuários e equipe de manutenção para passagem de conhecimento do sistema.
Tarefas Descrição
Preparar Elaborar apresentação sobre operação do sistema, baseado nos manuais.
treinamentos Elaborar apresentação sobre manutenção do sistema, baseado nos manuais.
Planejar e dimensionar turmas de treinamento.
Agendar Reservar sala, infra-estrutura (projetor, computadores, etc).
treinamentos Convocar envolvidos para os treinamentos.
Ministrar os Apresentar procedimentos de operação do sistema para os usuários.
FASE DE TRANSIÇÃO
treinamentos Apresentar procedimentos de manutenção do sistema para equipe responsável.
Registrar Recolher assinaturas na lista de presença dos treinamentos realizados.
treinamento
Relacionamentos
Participantes:
• Usuários
• Arquiteto
Materiais de Treinamento
Material de Suporte do Usuário
Saídas Material de Treinamento
Treinamento Executado
Lista de Presença
Observações
Coletar sugestões dos usuários relacionadas às funcionalidades do sistema.
Aplicar pesquisa de opinião dos usuários.
Controlar a presença dos participantes do treinamento.
Atividade: Implantar Produto em Produção

Todos os produtos de trabalho de projetos são fisicamente organizados no repositório do projeto e são
logicamente organizados de acordo com a estrutura de diretórios do produto. A unidade de implantação
contém todos os itens de entrega, que estão listados na Lista de Materiais.
Nessa atividade, deve ser criada uma cópia dos itens distribuíveis, com baseline e controle de versão
no repositório do projeto.
Tarefas Descrição
Criar unidade de Gerar versão do sistema para implantação em ambiente de produção.
implantação Criar cópia dos itens distribuíveis na mídia necessária para implantação no

EB80-MT-78.001
ambiente de destino. A mídia necessária pode ser um CD-ROM ou, no caso de

um produto que pode ser transferido por download na Web, uma cópia
compactada disponível para download.
Preparar plano de Elaborar plano de recuperação do servidor e volta da versão anterior em caso de
contingência problema na instalação.
Preparar servidores Executar scripts de banco de dados, carga inicial de dados, instalação de plug-ins
e complementos no servidor e outras medidas necessárias.
Implantar a versão Implantar versão no servidor de produção.
Comunicar aos envolvidos.
Relacionamentos
Participantes:
FASE DE TRANSIÇÃO
• Desenvolvedor
Plano de Projeto
Unidade de Implantação (Build)
Saídas Unidade de Implantação (Build) instalada.
Observações
Uma boa prática é criar Notas sobre o Release para a Avaliação de Iteração no final de cada iteração.
Entretanto, as Notas sobre o Release podem ser atualizadas e mantidas para cada unidade de
implantação e depois atualizadas para o release formal do produto.
Atividade: Validar Produto em Produção

Valida um módulo ou fase do projeto (versão beta) fornecendo ao produto um teste controlado e de
mundo real, para que o feedback de usuários potenciais possa ser utilizado para formação do produto
final. Fornece também uma visualização do próximo release (quando versão beta).
Tarefas Descrição
Preparar e Distribuir Disponibilizar aos revisores a unidade de implantação (formada por um build,
a Unidade de notas sobre o release, materiais de suporte e materiais para instalação.
Implantação
Relatar resultado Preparar um Resumo de Avaliações de Resultados e resumir o projeto com base
nas especificações do feedback da validação.
Reúne e revisa o feedback e ativa controles de mudança com base no feedback.
Reunião de Obter aprovação do Termo de Aceite do módulo (versão beta) ou projeto final.
validação com
clientes.
Relacionamentos
Participantes:

EB80-MT-78.001
Entradas Unidade de Implantação (Build)
Saídas Termo de Aceite
Atividade: Encerrar Projeto

O Gerente de Projetos elabora o Termo de Encerramento do Projeto e o envia para aprovação do
Cliente, identificando todos os produtos e fases homologadas, de acordo com os Termos de
Homologação de Produtos.
Tarefas Descrição
Homologar sistema Obter aprovação do Termo de Encerramento do Projeto.
com cliente Encaminhar e obter a resposta do Cliente ao Questionário de Satisfação do
Cliente, contendo a avaliação do serviço prestado até o momento.
FASE DE TRANSIÇÃO
Encerrar processos Conclui o fechamento do projeto, finaliza a aplicação dos recursos, encerra
administrativos. contratos e realoca equipe.
Avaliar o projeto e o Realiza uma avaliação geral e o registro das lições aprendidas.
processo de
desenvolvimento
Relacionamentos
Participantes:
• Cliente
Todos os termos de homologação anteriores
Saídas Termo de Aceite do Produto

EB80-MT-78.001
CAPÍTULO III -
DAS DISPOSIÇÕES FINAIS
1. PRODUTOS DE TRABALHO
A execução das atividades, nas fases do processo, gera produtos de trabalho,
os quais se constituem de produtos tangíveis do projeto. Tais produtos são resultado da
realização das atividades pelos papéis, servindo, também, como insumo para algumas
das atividades.
A tabela a seguir lista os produtos de trabalho gerados durante o ciclo de vida
de desenvolvimento proposto nesta metodologia, bem como as fases em que são
gerados e revisados, com os papeis responsáveis.

EB80-MT-78.001
fases
Produto de Trabalho Responsável
I E C T
Plano de Projeto G R R -
Plano de Iteração G R R R Gerente de Projeto
Relatório de Avaliação da Iteração G G G G
Visão G R R -
Glossário G R - -
Modelo de Caso de Uso G R R -
Especificações Suplementares G R R - Analista de Sistemas
Lista de Regras de Negócio G R R -
Lista de Requisitos Funcionais G R R -
Caso de Uso Detalhado G R R -
Documento de Arquitetura G R - - Arquiteto
Termo de Homologação G G G G Gerente de Projeto
Código Fonte - G G R Desenvolvedor
Build (Construção) - G G R Desenvolvedor
Modelo de Design - G R -
Projetista
Modelo de Dados - G R -
Caso de Teste - G G G Testador
Registro de Teste - G G G Testador
Plano de Implantação - - - G
Manual do Usuário - - - G
Analista de Sistemas
Manual do Sistema - - - G
Manual de Treinamento - - - G
Relatórios da Infraestrutura G G G - Projetista de
Infraestrutura
Termo de Encerramento do Projeto - - - G Gerente de Projeto
Tabela 2: Produtos de Trabalho Gerados (resumo)
Legenda:
I – Iniciação
E – Elaboração
C – Construção
T – Transição
G – Gerado
R – Revisado

EB80-MT-78.001
Nesta MDS classificamos os produtos de trabalho em duas categorias: aqueles

que dão sustentação ao processo e aqueles que documentam o sistema. Os primeiros
são gerados com a função de possibilitarem o controle das atividades do processo. São
produtos de apoio e específicos da metodologia adotada. Os segundos são gerados
para documentar o sistema e possibilitar a comunicação interna da equipe do projeto
ou desta com o cliente, além de possibilitarem o entendimento do sistema para
operações de manutenção.
A tabela a seguir relaciona os produtos de trabalho de acordo com as duas
categorias anteriormente mencionadas.
Produtos de sustentação do processo Produtos que documentam o sistema

Plano de projeto Visão
Plano de iteração Glossário
Relatório de Avaliação da Iteração Modelo de Casos de Uso
Termo de homologação Especificações Suplementares
Caso de Teste Lista de regras de negócio
Registro de Teste Lista de Requisitos Funcionais
Plano de Implantação Casos de Uso Detalhados
Manual de Treinamento Documento de Arquitetura
Termo de Encerramento do Projeto Código Fonte
Relatórios da Infraestrutura Build
Modelo de Design
Modelo de Dados
Manual de Usuários
Manual de Sistemas
Tabela 3: Produtos de Trabalho por Categoria
Segue-se uma breve descrição de cada produto de trabalho:
1.1 PLANO DE PROJETO
Esse artefato reúne todas as informações necessárias ao gerenciamento do

projeto. Ele consolida vários documentos que detalham como as atividades do projeto
serão desenvolvidas. É mantido e atualizado durante todo o projeto. Esse documento

EB80-MT-78.001
poderá ser elaborado de acordo com modelo previsto nas Normas para Elaboração,
Gerenciamento e Acompanhamento de Projetos no Exército Brasileiro (NEGAPEB).
1.2 PLANO DE ITERAÇÃO
Esse documento detalha as iterações que serão realizadas dentro de cada fase
considerada. Por meio dele, o sistema é decomposto em funcionalidades que serão
disponibilizadas. Ao final de cada iteração, um produto de valor significativo é gerado.
Ao final de cada fase, planeja-se a iteração da próxima fase. No anexo I, consta
modelo deste documento.
1.3 RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO
Por meio desse relatório, é feita comparação entre o que foi previsto no plano
de iteração e o que foi, efetivamente realizado. A partir dessa avaliação, pode-se
replanejar o prosseguimento do projeto. No anexo II, consta modelo deste documento.
1.4 VISÃO
Esse artefato define a visualização de envolvidos com o produto a ser

desenvolvido, além da especificação das necessidades e recursos mais importantes.
Ele contém uma descrição dos requisitos centrais pretendidos e, portanto, constitui-se
de uma base contratual para o desenvolvimento do produto do projeto. No anexo III,
consta modelo deste documento.
1.5 GLOSSÁRIO

EB80-MT-78.001
Esse artefato procura elucidar termos e palavras utilizadas no negócio do

cliente e que devam ser bem esclarecidos, para que o sistema seja utilizado
corretamente. No anexo IV, consta modelo deste documento.
1.6 MODELO DE CASO DE USO
Esse artefato é um modelo das funções pretendidas pelo sistema e seu

ambiente e serve como um contrato estabelecido entre o cliente e os desenvolvedores.
É utilizado como fonte de informações essencial para atividades de análise, design e
teste. No anexo V, consta modelo deste documento.
1.7 ESPECIFICAÇÕES SUPLEMENTARES
Esse artefato captura os requisitos do sistema que não são prontamente

capturados nos artefatos de requisitos comportamentais, como as especificações de
casos de uso. No anexo VI, consta modelo deste documento.
1.8 LISTA DE REGRAS DE NEGÓCIO
Esse artefato detalha as regras do negócio do cliente que possuem influência

sobre o software em desenvolvimento. No anexo VII, consta modelo deste documento.
1.9 LISTA DE REQUISITOS FUNCIONAIS
Esse artefato discrimina as funcionalidades que o sistema deverá atender.

Essas funcionalidades expressam o que o sistema fará, para atender seus objetivos.
No anexo VIII, consta modelo deste documento.

EB80-MT-78.001
1.10 CASO DE USO DETALHADO
Esse documento visa detalhar as atividades a serem executadas em cada caso

de uso, por meio de fluxos principais, alternativos e de exceção, além da descrição
completa dos atores que interagem com o sistema. No anexo IX, consta modelo deste
documento.
1.11 DOCUMENTO DE ARQUITETURA
O documento de arquitetura de software fornece uma visão geral de arquitetura

abrangente do sistema de software. Serve como um meio de comunicação entre o
arquiteto de software e outros membros de equipe de projeto, com relação a decisões
arquiteturalmente significativas tomadas sobre o projeto. No anexo X, consta modelo
deste documento.
1.12 TERMO DE HOMOLOGAÇÃO
Esse artefato formaliza a aceitação de um produto elaborado durante o

processo de desenvolvimento. Por meio dele é acordado entre as partes o
entendimento de partes do projeto. No anexo XI, consta modelo deste documento.
1.13 CÓDIGO FONTE
Este artefato contém o resultado da implementação das realizações dos casos

de uso.
1.14 BUILD (CONSTRUÇÃO)

EB80-MT-78.001
Esse artefato produz uma versão operacional como parte de um sistema que
demonstra um subconjunto de recursos a serem fornecidos no produto final. Uma
versão é constituída por um ou mais elementos de implementação (geralmente
executáveis), cada um construído a partir de outros elementos, normalmente por um
processo de compilação e link de código fonte.
1.15 MODELO DE DESIGN
Esse produto de trabalho é um modelo de objeto que descreve a realização

dos casos de uso e serve como uma abstração do modelo de implementação e seu
código-fonte. O modelo de design é usado como base para atividades de
implementação e teste. No anexo XII, consta modelo deste documento.
1.16 MODELO DE DADOS
Esse artefato descreve as representações lógicas e físicas dos dados

persistentes utilizados pelo aplicativo. Nos casos em que o aplicativo utilizará um
RDBMS (Relational Database Management System), o modelo de dados poderá incluir
também elementos de modelo para procedimentos armazenados, gatilhos, restrições,
etc, que definem a interação dos componentes de aplicativo com o RDBMS.
1.17 CASO DE TESTE
Este artefato é a especificação de um conjunto de entradas de teste, condições

de execução e resultados esperados, identificados com a finalidade de fazer a
avaliação de algum aspecto particular de um cenário. No anexo XIII, consta modelo
deste documento.

EB80-MT-78.001
1.18 REGISTRO DE TESTE
Por meio dele, registram-se os resultados dos testes realizados sobre o

produto em desenvolvimento.
1.19 PLANO DE IMPLANTAÇÃO
Descreve todo o planejamento, feito em acordo com o cliente, para a

implantação do sistema no ambiente de produção. No anexo XIV, consta modelo deste
documento.
1.20 MANUAL DO USUÁRIO
Esse artefato descreve os procedimentos de utilização do sistema pelo usuário.
1.21 MANUAL DO SISTEMA
Esse artefato reúne toda a documentação produzida durante o ciclo de

desenvolvimento do software, a qual permite o entendimento dos detalhes do sistema
necessários à sua manutenção.
1.22 MANUAL DE TREINAMENTO
Esse artefato serve de apoio às instruções de treinamento ao usuário para que

o mesmo utilize o sistema.
1.23 RELATÓRIOS DA INFRAESTRUTURA

EB80-MT-78.001
Documentam as análises realisadas pelo Projetista de Infraestrutura,

relacionadas à infraestrutura de produção do sistema e o atendimento aos seus
requisitos não funcionais.
1.24 TERMO DE ENCERRAMENTO DO PROJETO
Esse artefato é utilizado para formalizar o encerramento do projeto. Contém as

informações básicas para entendimento do projeto, tais como: escopo resumido,
clientes, período de realização e principais finalidades do sistema. No anexo XV, consta
modelo deste documento.
2. DIAGRAMAS DA UML
Uma das práticas adotadas por esta MDS é a modelagem visual do software.
Para isso, são utilizados diagramas da Unified Modeling Language (UML). Os
diagramas utilizados por esta metodologia são: Casos de Uso, Sequência, Classes,
Componentes, Implantação e Pacotes.
Além dos diagramas citados anteriormente, outros podem ser definidos e
criados, de acordo com as características de cada projeto.
Esses diagramas documentam o sistema e, nesta MDS, são inseridos em
produtos de trabalhos. A tabela a seguir relaciona os diagramas da UML, assim como
os produtos de trabalho onde estão inseridos.
Diagramas da UML - Produtos de Trabalho

- Casos de Uso - Modelo de Casos de Uso
- Sequência - Modelo de Design
- Classes
- Componentes - Documento de Arquitetura
- Implantação
- Pacotes
Tabela 4: Diagramas da UML e Produtos de Trabalho

EB80-MT-78.001
3. UTILIZAÇÃO DE OUTRAS METODOLOGIAS
A MDS proposta foi elaborada com base nos princípios apregoados pelo RUP.
Entretanto, a organização desenvolvedora poderá, a seu critério, optar pela utilização
de processos de desenvolvimento de software que se apoiem em outras metodologias
– por exemplo, as chamadas “metodologias ágeis de desenvolvimento”. Vale ressaltar
que, para a adoção dessas outras metodologias, devem ser considerados, sobretudo,
os aspectos referentes às características do projeto a ser desenvolvido (isto é, a
aplicabilidade da metodologia escolhida à dimensão do projeto e à sua consequente
execução), à cultura e à experiência de desenvolvimento de software presente na OM.
De qualquer forma, torna-se necessária a produção e atualização da
documentação do sistema durante todo o seu ciclo de desenvolvimento, de tal forma
que haja subsídios a futuras manutenções. Para tanto, os documentos/artefatos a
serem gerados, obedecendo os modelos anexos a esta Metodologia, são os seguintes:
• Diagrama de Casos de Uso
• Documento de Visão
• Lista de Requisitos Funcionais e não Funcionais (Caso essas informações já
não constem do Documento de Visão)
• Lista de Regras de Negócio (Caso essas informações já não constem do
Documento de Visão)
• Glossário de Termos Utilizados
• Código Fonte
• Build (Construção)
• Diagrama de Classes
• Modelo de Dados (caso seja utilizada uma base de dados relacional)
• Documento de Arquitetura
• Diagrama de Componentes (Caso esse diagrama já não conste do
Documento de Arquitetura)

EB80-MT-78.001
• Diagrama de Implantação (Caso esse diagrama já não conste do Documento

de Arquitetura)
• Diagrama de Pacotes (Caso esse diagrama já não conste do Documento de
Arquitetura)
• Manual do Usuário
• Manual do Sistema
Outros documentos podem ser gerados para melhor compreensão do sistema.
Sugerem-se adicionalmente os seguintes:
• Diagrama de Sequência (utilizado para auxiliar o entendimento de Casos
de Uso mais Complexos)
• Diagrama de Atividades (utilizado para auxiliar o entendimento de Casos
de Uso mais Complexos)

EB80-MT-78.001
ANEXO A
MODELO DE PLANO DE ITERAÇÃO
SIGLA DO PROJETO
<Nome do Projeto>
Plano de Iteração
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - A-1

EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto> Versão:<Número_Versão>

Plano de Iteração Data: 23/04/2013
Histórico de Revisões
Data Versão Descrição Autor
<Classificação> Centro de Desenvolvimento de Sistemas Página 2 /4

EB80-MT-78.001

SUMÁRIO
1 TAREFAS E MARCOS CHAVE.........................................................................4

1.1Tarefas.......................................................................................................................... 4
1.2Marcos da Iteração......................................................................................................4
2 OBJETIVOS DA ITERAÇÃO............................................................................4
<Classificação> Centro de Desenvolvimento de Sistemas Página 3 / 4

EB80-MT-78.001

1. TAREFAS E MARCOS CHAVE
1.1 Tarefas
Serão discriminadas as tarefas que serão executadas na iteração.
Tarefa Data Início Data Final
1.2 Marcos da Iteração

Serão discriminados os principais marcos que serão atingidos na iteração.
Marco Data
2. OBJETIVOS DA ITERAÇÃO
Listar os objetivos a serem cumpridos para cada iteração de cada fase do projeto.
Podemos particionar a iteração e designar os responsáveis por cada objetivo.
Exemplo:
I1 (1ª Iteração – Iniciação)
Objetivo/Tarefa Responsável Data Início Data Fim

Entrega do Documento de Analista
Visão
Entrega do Modelo de Analista 1
Casos de Uso visão geral
Entrega do Glossário Analista 2

EB80-MT-78.001
ANEXO B
MODELO DE RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO
<SIGLA DO PROJETO>
<Nome do Projeto>
Relatório de Avaliação da Iteração
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-1

EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto> Versão: <Número_Versão>

Relatório de Avaliação da Iteração Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO...............................................4

1 INTRODUÇÃO....................................................................................................4
1.1 Finalidade...................................................................................................................4
1.2 Escopo......................................................................................................................... 4
1.3 Definições, Acrônimos e Abreviações........................................................................4
1.4 Referências.................................................................................................................. 4
1.5 Visão Geral.................................................................................................................. 4
2 OBJETIVOS DA ITERAÇÃO ATINGIDOS.....................................................4
3 ADESÃO AO PLANO..........................................................................................5
4 CASOS DE USO E CENÁRIOS IMPLEMENTADOS....................................5
5 RESULTADOS EM RELAÇÃO AOS CRITÉRIOS DE AVALIAÇÃO..........5
6 RESULTADOS DO TESTE.................................................................................5
7 MUDANÇAS EXTERNAS OCORRIDAS.........................................................5
8 RETRABALHO NECESSÁRIO.........................................................................5

EB80-MT-78.001

RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO

1. INTRODUÇÃO

EB80-MT-78.001

A introdução da Avaliação de Iteração deve fornecer uma visão geral de todo o
documento. Ela deve incluir a finalidade, o escopo, as definições, os acrônimos, as abreviações,
as referências e a visão geral desta Avaliação de Iteração.
1.1 Finalidade
O objetivo da Avaliação de Iteração é capturar o resultado da iteração, o grau de
cumprimento dos critérios de avaliação, as lições aprendidas e as mudanças a serem feitas.
1.2 Escopo
Uma breve descrição do escopo desta Avaliação de Iteração; a que Projeto(s) ela está
associada e tudo o mais que seja afetado ou influenciado por este documento.
1.3 Definições, Acrônimos e Abreviações

Esta subseção deve fornecer as definições de todos os termos, acrônimos e abreviações
necessárias à adequada interpretação da Avaliação de Iteração. Essas informações podem ser
fornecidas mediante referência ao Glossário do projeto.
1.4 Referências
Esta subseção deve fornecer uma lista completa de todos os documentos mencionados
em qualquer outra parte da Avaliação de Iteração. Cada documento deverá ser identificado por
título, número do relatório (se aplicável), data e organização de publicação. Especifique as
fontes a partir das quais as referências podem ser obtidas. Essas informações podem ser
fornecidas por um anexo ou outro documento.
1.5 Visão Geral

Esta subseção descreve o que o restante da Avaliação de Iteração contém e explica
como o documento está organizado.


EB80-MT-78.001
2. OBJETIVOS DA ITERAÇÃO ATINGIDOS

Reconheça o êxito alcançado na iteração.
3. ADESÃO AO PLANO
A iteração foi executada de acordo com o plano elaborado? Descrever aqui as
diferenças entre o planejado e executado.
4. CASOS DE USO E CENÁRIOS IMPLEMENTADOS
Liste os casos de uso e cenários que foram implementados.
5. RESULTADOS EM RELAÇÃO AOS CRITÉRIOS DE AVALIAÇÃO
Avalie os resultados da iteração em relação aos critérios de avaliação que foram
estabelecidos para o plano de iteração: funcionalidade, desempenho, capacidade e medidas de
qualidade.
6. RESULTADOS DO TESTE
Mencione os resultados dos testes, quando houver.
7. MUDANÇAS EXTERNAS OCORRIDAS
Por exemplo, mudanças nos requisitos, necessidades de novos usuários e plano do
concorrente.
8. RETRABALHO NECESSÁRIO
Identifique as áreas de problemas que precisam ser retrabalhadas nas próximas
iterações.
Local , Data e Assinatura dos Principais Envolvidos e Equipe de Projeto.

EB80-MT-78.001
ANEXO C
MODELO DE VISÃO DO PROJETO
<SIGLA DO PROJETO>
<Nome do Projeto>
Visão do Projeto
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-1

EB80-MT-78.001

Visão do Projeto Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 INTRODUÇÃO....................................................................................................4
2.1 Posicionamento...........................................................................................................4
2.2 Instrução do Problema...............................................................................................4
2.3 Instrução sobre a posição do Produto.......................................................................4
3 DESCRIÇÕES DOS ENVOLVIDOS.................................................................5
3.1 Resumo do Envolvido.................................................................................................5
3.2 Ambiente do Usuário..................................................................................................5
4 VISÃO GERAL DO PRODUTO.........................................................................5
4.1 Perspectiva do Produto..............................................................................................5
4.2 Premissas e Dependências..........................................................................................6
4.3 Necessidades e Recursos............................................................................................6
4.4 Alternativas e Competição.........................................................................................6
5 OUTROS REQUISITOS DO PRODUTO.........................................................6

EB80-MT-78.001

1. PROPÓSITO
Esse documento tem por objetivo, detalhar a visão completa do desenvolvimento.
2. INTRODUÇÃO
2.1 Posicionamento
2.2 Instrução do Problema

Forneça uma instrução que resume o problema sendo resolvido por esse projeto. Pode ser
utilizado o seguinte formato:
O problema de [descreva o problema]

Afeta [dos interessados afetados pelo problema]
O impacto do qual é [qual é o impacto do problema?]
uma solução bem-sucedida seria [liste alguns dos principais benefícios de uma solução
bem-sucedida]
2.3 Instrução sobre a posição do Produto
Forneça uma instrução geral que resuma, no nível mais alto, a posição exclusiva que o produto
pretende ocupar no mercado. Pode ser utilizado o seguinte formato:
Para [Cliente alvo]
Que [Instrução da necessidade ou da oportunidade]
O (Nome do Produto) é uma [categoria do produto]
Qu [A razão principal para o desenvolvimento do produto ]
A Menos Que [Alternativa competitiva principal ]
Nosso Produto [Instrução da diferenciação principal]

EB80-MT-78.001

Uma instrução de posição do produto comunica o propósito do aplicativo e a importância do

projeto à toda a equipe interessada.
3. DESCRIÇÕES DOS ENVOLVIDOS
3.1 Resumo do Envolvido
Nome Descrição Responsabilidades
[Nomeie o tipo [Descreva [Resuma as responsabilidades principais do envolvido em
de envolvido.] resumidamente o relação ao sistema sendo desenvolvido; ou seja, seus
envolvido.] interesses como envolvido. Por exemplo, esse envolvido:
assegura que o sistema será passível de manutenção
assegura que haverá uma demanda de mercado para os
recursos do produto monitora o progresso do projeto
aprova o financiamentoe assim por diante]
3.2 Ambiente do Usuário

Detalhe o ambiente de trabalho do usuário alvo. Seguem algumas sugestões:
Número de pessoas envolvidas na conclusão da tarefa? Isso está mudando?
Quanto tempo dura um ciclo de tarefas? Período de tempo gasto em cada atividade? Isso está
mudando?
Há quaisquer restrições ambientais exclusivas: móveis, externas, internas e assim por diante?
Quais plataformas do sistema estão em uso atualmente? Futuras plataformas?
Quais outros aplicativos estão em uso? O seu aplicativo precisa se integrar a eles?
É onde os extratos do Modelo de Negócios poderiam ser incluídos para descrever a tarefa e as
funções envolvidas e assim por diante.

EB80-MT-78.001

4. VISÃO GERAL DO PRODUTO

4.1 Perspectiva do Produto
4.2 Premissas e Dependências
4.3 Necessidades e Recursos
Necessidade Prioridade Recursos Liberação Planejada
4.4 Alternativas e Competição

5. OUTROS REQUISITOS DO PRODUTO

Em um alto nível, liste os padrões aplicáveis, o hardware ou os requisitos de plataforma;
requisitos de desempenho; e requisitos ambientais.
Defina as faixas de qualidade para desempenho, robustez, tolerância a falhas, utilidade e
características semelhantes que não sejam capturadas no Conjunto de Recursos.
Observe quaisquer restrições de design, restrições externas ou outras dependências.
Defina qualquer requisito específico da documentação, incluindo manuais do usuário, ajuda
on-line, instalação, identificação e requisitos de embalagem.
Defina a prioridade desses outros requisitos do produto. Se útil, inclua atributos como
estabilidade, benefício, esforço e risco.

EB80-MT-78.001
ANEXO D
MODELO DE GLOSSÁRIO
<SIGLA DO PROJETO>
<Nome do Projeto>
Glossário
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - D-1

EB80-MT-78.001

Glossário Data: 23/04/2013
<Classificação> Centro de Desenvolvimento de Sistemas Página 2/5

EB80-MT-78.001

SUMÁRIO
1 INTRODUÇÃO....................................................................................................4
1.1 Finalidade...................................................................................................................4
1.2 Escopo......................................................................................................................... 4
1.3 Referências.................................................................................................................. 4
1.4 Visão Geral .................................................................................................................4
2 DEFINIÇÕES.......................................................................................................4
2.1 <Termo>...................................................................................................................... 4

EB80-MT-78.001

1. INTRODUÇÃO
A introdução do Glossário fornece uma visão geral de todo o documento. Apresente todas as
informações que poderão ser necessárias para que o leitor compreenda o documento nesta
seção. Este documento é usado para definir a terminologia específica do domínio do problema,
explicando termos que podem ser desconhecidos do leitor, das descrições de caso de uso ou de
outros documentos do projeto. Frequentemente, este documento poderá ser usado como um
dicionário de dados informal, capturando definições de dados para que as descrições de caso de
uso e outros documentos do projeto possam concentrar-se no que o sistema deve fazer com as
informações. Este documento deverá ser salvo em um arquivo denominado Glossário.
1.1 Finalidade
Especifique a finalidade deste Glossário.
1.2 Escopo
Uma breve descrição do escopo deste Glossário; a que Projeto(s) ele está associado e tudo o
mais que seja afetado ou influenciado por este documento.
1.3 Referências
Esta subseção fornece uma lista completa de todos os documentos mencionados em qualquer
outra parte do Glossário. Identifique cada documento por título, número do relatório (se
aplicável), data e organização de publicação. Especifique as fontes a partir das quais as
referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro
documento.
1.4 Visão Geral

[Esta subseção descreve o que o restante do Glossário contém e explica como o documento está
organizado.]
2. Definições
[Os termos definidos aqui são a essência do documento. Eles poderão ser definidos na ordem
desejada, mas geralmente a ordem alfabética propicia maior acessibilidade.]
Classificação> Centro de Desenvolvimento de Sistemas Página 4/5

EB80-MT-78.001

2.1 <Termo>
[A definição do Termo é apresentada aqui. Você deverá apresentar quantas informações forem
necessárias para que o leitor compreenda o conceito.]

EB80-MT-78.001
ANEXO E
MODELO DE CASO DE USO
<SIGLA DO PROJETO>
<Nome do Projeto>
Modelo de Caso de Uso
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - E-1

EB80-MT-78.001

Modelo de Caso de Uso Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 MODELO DE CASO DE USO...........................................................................4

EB80-MT-78.001

3. PROPÓSITO
Este documento descreve ...
4. MODELO DE CASO DE USO
(Exemplo de Diagrama de Casos de Uso)

EB80-MT-78.001
ANEXO F
MODELO DE ESPECIFICAÇÃO SUPLEMENTAR
<SIGLA DO PROJETO>
<Nome do Projeto>
Especificação Suplementar
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-1

EB80-MT-78.001

Especificação Suplementar Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 INTRODUÇÃO....................................................................................................4
1.1 Objetivo....................................................................................................................... 4
1.2 Escopo......................................................................................................................... 4
1.4 Referências.................................................................................................................. 4
1.5 Visão Geral.................................................................................................................. 4
2 UTILIDADE.........................................................................................................4
2.1 <Requisito de Utilidade Um>....................................................................................5
3 CONFIABILIDADE.............................................................................................5
3.1 <Requisito de Confiabilidade Um>...........................................................................5
4 DESEMPENHO....................................................................................................5
4.1 <Requisito de Desempenho Um>..............................................................................6
5 SUPORTABILIDADE..........................................................................................6
5.1 <Requisito de Suportabilidade Um>.........................................................................6
6 RESTRIÇÕES DE DESIGN...............................................................................6
6.1 <Restrição de Design Um>.........................................................................................6
7 DOCUMENTAÇÃO DO USUÁRIO ON-LINE E REQUISITOS DO
SISTEMA DE AJUDA............................................................................................6
8 COMPONENTES COMPRADOS......................................................................6
9 INTERFACES.......................................................................................................7
9.1 Interfaces com o usuário............................................................................................7
9.2 Interfaces de Hardware.............................................................................................7
9.3 Interfaces de Software................................................................................................7
9.4 Interfaces de Comunicações......................................................................................7
10 REQUISITOS DE LICENÇA...........................................................................7
11 OBSERVAÇÕES LEGAIS, SOBRE DIREITOS AUTORAIS E OUTRAS
OBSERVAÇÕES......................................................................................................7
12 PADRÕES APLICÁVEIS..................................................................................8

EB80-MT-78.001

1. INTRODUÇÃO
Requisitos legais, regulamentos e padrões que devam ser utilizados na aplicação.
Atributos de qualidade do sistema a ser construído, incluindo usabilidade, performance
e requisitos de suporte.
Outros requisitos como sistema operacional, ambientes de operação, requisitos de
compatibilidade e restrições de projeto.
Regras de negócio do sistema comuns a mais de um caso de uso ou para o sistema
como um todo.
1.1 Objetivo
Especifique o objetivo desta Especificação Suplementar.
1.2 Escopo
Uma breve descrição do escopo desta Especificação Suplementar; a qual(is) Projeto(s) ele está
associado e tudo mais que seja afetado ou influenciado por este documento.
Esta subseção fornece as definições de todos os termos, acrônimos e abreviações requeridos
para interpretar adequadamente a Especificação Suplementar. Essas informações podem ser
fornecidas em relação ao Glossário do projeto.
1.4 Referências
Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte
na Especificação Suplementar. Identifique cada documento por título, número do relatório se
aplicável, data e organização da publicação. Especifique as origens a partir das quais as
referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro
documento.]
1.5 Visão Geral
Esta subseção descreve o que o restante da Especificação Suplementar contém e explica como
o documento é organizado.

EB80-MT-78.001

2. UTILIDADE
Esta seção deve incluir todos os requisitos que afetam a utilidade. Como exemplos, podemos
citar os seguintes:
• especifique o tempo de treinamento requerido para que usuários normais e usuários
potentes se tornem produtivos em operações particulares
• especifique tempos de tarefa mensuráveis para tarefas típicas ou
• especifique requisitos para conformidade com padrões de utilidade comuns, por
exemplo, padrões CUA da IBM ou Padrões GUI da Microsoft]
2.1 <Requisito de Utilidade Um>
A descrição do requisito.
3. CONFIABILIDADE
Os requisitos de confiabilidade do sistema devem ser especificados aqui. A seguir, são
apresentadas algumas sugestões:
• Disponibilidade – especifique a porcentagem de tempo disponível ( xx.xx%), as horas de
utilização, o acesso de manutenção, as operações de modo degradado e similares.
• MTBF (Mean Time Between Failures) – este é, geralmente, especificado em horas, mas
pode também ser especificado em dias, meses ou anos.
• MTTR (Mean Time To Repair)–por quanto tempo o sistema tem permissão para ficar
fora de operação após ter falhado?
• Exatidão –especifique a precisão (resolução) e a exatidão (por algum padrão
conhecido) requeridas na saída dos sistemas.
• Taxa máxima de erros ou defeitos –geralmente expressa em termos de erros/KLOC (mil
linhas de código) ou erros/ponto de função.
• Taxa de erros ou defeitos, categorizada em termos de erros menores, significativos e
críticos: o(s) requisito(s) deve(m) definir o que quer dizer um erro “crítico”; por
exemplo, perda completa de dados ou uma inabilidade completa para utilizar
determinadas partes da funcionalidade do sistema.

EB80-MT-78.001

3.1 <Requisito de Confiabilidade Um>

4. DESEMPENHO
As características do desempenho do sistema devem ser esboçadas nesta seção. Inclua tempos
de resposta específicos. Onde aplicável, faça referência a Casos de Uso relacionados por nome.
Tempo de resposta para uma transação (médio, máximo)
Rendimento do processamento (por exemplo, transações por segundo)
Capacidade (por exemplo, o número de clientes ou transações que o sistema pode acomodar)
Modos de degradação (que é o modo aceitável de operação quando o sistema foi degradado de
alguma maneira)
4.1 <Requisito de Desempenho Um>
5. SUPORTABILIDADE
Esta seção indica os requisitos que aprimorarão a suportabilidade ou a capacidade de
manutenção do sistema que está sendo construído, incluindo padrões de codificação,
convenções de nomenclatura, bibliotecas de classe, acesso de manutenção, utilitários de
manutenção.
5.1 <Requisito de Suportabilidade Um>
6. RESTRIÇÕES DE DESIGN
Esta seção deve indicar as restrições de design no sistema que está sendo construído. As
restrições de design representam decisões de design que foram obrigatórias e às quais deve-se
aderir. Os exemplos incluem linguagens de software, requisitos de processo de software,
utilização prescrita de ferramentas de desenvolvimento, restrições de arquitetura e design,
componentes comprados, bibliotecas de classes e assim por diante.

EB80-MT-78.001

6.1 <Restrição de Design Um>

7. DOCUMENTAÇÃO DO USUÁRIO ON-LINE E REQUISITOS DO
SISTEMA DE AJUDA
Descreve os requisitos, se houver, para a documentação do usuário on-line, sistemas de ajuda,
ajuda sobre observações e assim por diante.
8. COMPONENTES COMPRADOS
Esta seção descreve os componentes comprados a serem utilizados com o sistema, as restrições
aplicáveis de licença ou uso e os padrões associados de compatibilidade/interoperabilidade ou
interface.
9. INTERFACES
Esta seção define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter
especificidade adequada, protocolos, portas, endereços lógicos e assim por diante, para que o
software possa ser desenvolvido e verificado em comparação com os requisitos da interface.
9.1 Interfaces com o usuário
Descreva as interfaces com o usuário que devem ser implementadas pelo software.
9.2 Interfaces de Hardware
Esta seção define as interfaces de hardware que devem ser suportadas pelo software, incluindo
estrutura lógica, endereços físicos, comportamento esperado e assim por diante.
9.3 Interfaces de Software
Esta seção descreve as interfaces de software para outros componentes do sistema de software.
Estas podem ser componentes comprados, componentes reutilizados de outro aplicativo ou
componentes que estão sendo desenvolvidos para subsistemas fora do escopo desta
Especificação, mas com os quais este aplicativo de software deve interagir.

EB80-MT-78.001
SIGLA DO PROJETO> - <Nome do Projeto> Versão: <Número_Versão>

9.4 Interfaces de Comunicações

Descreva as interfaces de comunicações para outros sistemas ou dispositivos como redes locais,
dispositivos seriais remotos e assim por diante.
10. REQUISITOS DE LICENÇA
Define os requisitos de reforço de licença ou outros requisitos de restrição de uso que devem ser
requeridos pelo software.
11. OBSERVAÇÕES LEGAIS, SOBRE DIREITOS AUTORAIS E
OUTRAS OBSERVAÇÕES
Esta seção descreve as isenções legais necessárias, garantias, observações sobre direitos
autorais, observações sobre patente, wordmark, marca registrada ou problemas de
conformidade de logotipo para o software.
12. PADRÕES APLICÁVEIS
Esta seção descreve, por referência, os padrões aplicáveis e as seções específicas desses
padrões que se aplicam ao sistema que está sendo descrito. Por exemplo, isso pode incluir
padrões jurídicos, de qualidade e reguladores, padrões de mercado para utilidade,
interoperabilidade, internacionalização, conformidade com o sistema operacional e assim por
diante.

EB80-MT-78.001
ANEXO G
MODELO DE REGRAS DE NEGÓCIO
<SIGLA DO PROJETO>
<Nome do Projeto>
Regras de Negócio
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - G-1

EB80-MT-78.001

Regras de Negócio Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 LISTA DE REGRAS DE NEGÓCIO .................................................................4
2.1 Descrição das Regras de Negócio..............................................................................4
2.1.1 <Regra de Negócio 1>:....................................................................................................4

EB80-MT-78.001

1. PROPÓSITO
Regras de negócios são tipos de requisitos de como os negócios, incluindo suas
ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao
negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos. São descritas
pelo analista de negócio ou sistemas, com as informações negociais sendo repassadas pelo
cliente do Projeto. Podem fazer referência ao caso de uso envolvido.
2. LISTA DE REGRAS DE NEGÓCIO
Nr Descrição da Regra de Negócio
2.1 Descrição das Regras de Negócio
2.1.1 <Regra de Negócio 1>:

EB80-MT-78.001
ANEXO H
MODELO DE LISTA DE REQUISITOS FUNCIONAIS
<SIGLA DO PROJETO>
<Nome do Projeto>
Lista de Requisitos Funcionais
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - H-1

EB80-MT-78.001

Lista de Requisitos Funcionais Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO DO DOCUMENTO......................................................................4
2 LISTA DE REQUISITOS FUNCIONAIS .........................................................4

EB80-MT-78.001

1. PROPÓSITO DO DOCUMENTO
[Essa seção descreve os requisitos funcionais e relaciona com o caso de uso que será
especificado posteriormente. Serve para melhorar a rastreabilidade das funcionalidades do
Projeto.]
2. LISTA DE REQUISITOS FUNCIONAIS
Nr Requisito Funcional Caso de Uso Responsável

EB80-MT-78.001
ANEXO I
MODELO CASO DE USO DETALHADO
<SIGLA DO PROJETO>
<Nome do Projeto>
Caso de Uso Detalhado
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-1

EB80-MT-78.001

Caso de Uso Detalhado Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 ESPECIFICAÇÃO DE CASO DE USO <NOME DO CASO DE USO>........4

1.1 Nome do Caso de Uso.................................................................................................4
1.2 Breve Descrição..........................................................................................................4
2 FLUXO DE EVENTOS........................................................................................4
2.1 Fluxo Básico................................................................................................................ 4
2.2 Fluxos Alternativos.....................................................................................................5
2.2.1 <Primeiro Fluxo Alternativo>.........................................................................................5
2.2.1.1 <Primeiro subfluxo alternativo>............................................................................5
2.2.1.2 <Segundo subfluxo alternativo>............................................................................5
3 REQUISITOS ESPECIAIS.................................................................................5
3.1 Primeiro Requisito Especial .....................................................................................5
4 CONDIÇÕES PRÉVIAS.....................................................................................6
4.1 < Condição Prévia Um >............................................................................................6
5 CONDIÇÕES POSTERIORES..........................................................................6
5.1 <Condição Posterior Um>.........................................................................................6
6 PONTOS DE EXTENSÃO..................................................................................6
6.1 <Nome do Ponto de Extensão>..................................................................................6

EB80-MT-78.001

1. ESPECIFICAÇÃO DE CASO DE USO <NOME DO CASO DE USO>

NOME DO CASO DE USO
[O template a seguir é fornecido para uma Especificação de Caso de Uso, que contém as
propriedades de texto do caso de uso. Este documento é usado para especificar e
marcar os requisitos contidos nas propriedades do caso de uso.
Os diagramas do caso de uso podem ser desenvolvidos em uma ferramenta de

modelagem visual. ]
1.1 Breve Descrição

[A descrição relata brevemente a finalidade do caso de uso. Para tanto, será suficiente
um único parágrafo.]
2. FLUXO DE EVENTOS
2.1 Fluxo Básico
[Este caso de uso é iniciado quando o ator faz algo. Um ator sempre inicia os casos de
uso. O caso de uso descreve o que o ator faz e o que o sistema faz em resposta. Ele deve
ser elaborado como um diálogo entre o ator e o sistema.
O caso de uso descreve o que acontece dentro do sistema, mas não o porquê nem como.
Se forem trocadas informações, seja específico no que diz respeito ao conteúdo que é
passado e retornado. Por exemplo, não é muito esclarecedor dizer que o ator fornece
informações do cliente. É melhor dizer que ele fornece o nome e o endereço do cliente.
Frequentemente é útil fazer uso de um Glossário de Termos para manter a complexidade
do caso de uso sob controle — poderá ser conveniente definir termos como, por exemplo,
informações do cliente no glossário, a fim de evitar que o caso de uso fique repleto de
detalhes.
As alternativas simples poderão ser apresentadas no texto do caso de uso. Se forem

necessárias apenas algumas frases para descrever o que acontece quando há uma
alternativa, faça essa descrição diretamente na seção Fluxo de Eventos. Se o fluxo
alternativo for mais complexo, use uma seção separada para descrevê-lo. Por exemplo,

EB80-MT-78.001

uma subseção Fluxo Alternativo explica como descrever alternativas mais complexas.
Às vezes, uma figura vale por mil palavras, embora não haja nada que possa substituir
uma redação clara e organizada. Se for mais esclarecedor, sinta-se à vontade para colar
representações gráficas de interfaces do usuário, fluxos de processo ou outras imagens
no caso de uso. Se um fluxograma for útil para apresentar um processo complexo de
decisões, utilize-o sem nenhuma dúvida! Semelhantemente no que diz respeito a
comportamentos dependentes de estado, um diagrama de transição de estado geralmente
esclarece o comportamento de um sistema muito mais do que páginas e páginas de texto.
Use o meio de apresentação certo para o problema, mas procure evitar o uso de
terminologia, notações ou imagens que o público possa deixar de compreender.
Lembre-se de que sua finalidade é esclarecer e não obscurecer.]
2.2 Fluxos Alternativos

2.2.1 <Primeiro Fluxo Alternativo>
[As alternativas mais complexas são descritas em uma seção separada, a que é feita
referência na subseção Fluxo Básico da seção Fluxo de Eventos. Pense nas subseções
Fluxo Alternativo como comportamentos alternativos — cada fluxo alternativo
representa um comportamento alternativo geralmente devido a exceções que ocorrem no
fluxo principal. O tamanho desses fluxos poderá ser tão extenso quanto o necessário
para descrever os eventos associados ao comportamento alternativo. Quando um fluxo
alternativo termina, os eventos do fluxo principal de eventos são retomados a menos que
seja especificado de outra maneira.] <Primeiro sub fluxo alternativo>
[Os sub fluxos alternativos, por sua vez, poderão ser divididos em subseções para
aprimorar a clareza.]
Classificação> Centro de Desenvolvimento de Sistemas Página 5/7

EB80-MT-78.001

2.2.1.1 <Segundo subfluxo alternativo>
[Poderá haver, e muito provavelmente haverá, uma série de fluxos alternativos em um

caso de uso. Mantenha cada fluxo alternativo separado para aprimorar a clareza. O uso
de fluxos alternativos melhora a legibilidade do caso de uso e também evita que os casos
de uso sejam decompostos em hierarquias de casos de uso. Lembre-se de que os casos de
uso são apenas descrições textuais e que sua finalidade principal é documentar o
comportamento de um sistema de maneira clara, concisa e compreensível.]
3. REQUISITOS ESPECIAIS
[Normalmente um requisito especial é um requisito não funcional que é específico de um
caso de uso, mas que não é especificado, de maneira fácil ou natural, no texto do fluxo
de eventos do caso de uso. Entre os exemplos de requisitos especiais estão incluídos
requisitos legais e reguladores, padrões de aplicativo e atributos de qualidade do
sistema a ser criado incluindo requisitos de usabilidade, confiabilidade, desempenho ou
suportabilidade. Além disso, outros requisitos — como sistemas operacionais e
ambientes, requisitos de compatibilidade e restrições de design — deverão ser
capturados nesta seção.]
3.1 Primeiro Requisito Especial

4. CONDIÇÕES PRÉVIAS
[Uma condição prévia de um caso de uso é o estado do sistema que deve estar presente
antes de um caso de uso ser realizado.]
4.1 < Condição Prévia Um >

5. CONDIÇÕES POSTERIORES
[Uma condição posterior de um caso de uso é uma lista dos possíveis estados em que o
sistema poderá se encontrar imediatamente depois do término de um caso de uso.]
5.1 <Condição Posterior Um>

EB80-MT-78.001

6. PONTOS DE EXTENSÃO
[Pontos de extensão do caso de uso.]
6.1 <Nome do Ponto de Extensão>

[Definição da localização do ponto de extensão no fluxo de eventos.]

EB80-MT-78.001
ANEXO J
MODELO DE DOCUMENTO DE ARQUITETURA
<SIGLA DO PROJETO>
<Nome do Projeto>
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-1

EB80-MT-78.001

Documento de Arquitetura Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 INTRODUÇÃO....................................................................................................4
2 REPRESENTAÇÃO ARQUITETURAL...........................................................4
3 RESTRIÇÕES E METAS ARQUITETURAIS.................................................4
4 VISÃO DE CASOS DE USO...............................................................................4
4.1 Realizações de Casos de Uso......................................................................................4
5 VISÃO LÓGICA ..................................................................................................4
5.1 Visão Geral.................................................................................................................. 5
5.2 Pacotes de Design Significativos do Ponto de Vista da Arquitetura.......................5
6 VISÃO DE PROCESSOS....................................................................................5
7 VISUALIZAÇÃO DA IMPLEMENTAÇÃO.....................................................5
8 VISÃO DA IMPLEMENTAÇÃO.......................................................................5
8.1 Visão Geral.................................................................................................................. 5
8.2 Camadas...................................................................................................................... 5
9 VISÃO DE DADOS (OPCIONAL).....................................................................6
10 TAMANHO E DESEMPENHO........................................................................6
11 QUALIDADE......................................................................................................6

EB80-MT-78.001

1. INTRODUÇÃO
[A introdução do Documento de Arquitetura de Software fornece uma visão geral de
todo o Documento de Arquitetura de Software . Ela inclui a finalidade, o escopo, as definições,
os acrônimos, as abreviações, as referências e a visão geral do Documento de Arquitetura de
Software .]
2. REPRESENTAÇÃO ARQUITETURAL
[Esta seção descreve qual é a arquitetura de software do sistema atual e como ela é
representada. Dos Casos de Uso, Implementação, Processo , Lógica e Visualizações de
Implementação, ela enumera as visualizações necessárias e, para cada uma, explica que tipos
de elementos de modelos a mesma contém.]
3. RESTRIÇÕES E METAS ARQUITETURAIS
[Esta seção descreve os requisitos e objetivos do software que têm algum impacto sobre
a arquitetura; por exemplo, segurança, garantia, privacidade, uso de um produto desenvolvido
internamente e pronto para ser usado, portabilidade, distribuição e reutilização. Ela também
captura as restrições especiais que podem ser aplicáveis, como design e estratégia de
implementação, ferramentas de desenvolvimento, estrutura de equipe, planejamento, códigos de
legado e assim por diante.]
4. VISÃO DE CASOS DE USO
[Esta seção lista os casos de uso ou cenários do modelo de casos de uso se eles
representam alguma funcionalidade central significativa do sistema final ou se têm uma ampla
cobertura arquitetural—se eles experimentam muitos elementos arquiteturais ou se enfatizam ou
ilustram um ponto frágil específico da arquitetura.]
4.1 Realizações de Casos de Uso
[Esta seção ilustra o funcionamento do software, apresentando algumas realizações (ou
cenários) de casos de uso selecionadas e explica como os diversos elementos do modelo de
design contribuem para a respectiva funcionalidade.]

EB80-MT-78.001

5. VISÃO LÓGICA
[Esta seção descreve as partes significativas do ponto de vista da arquitetura do
modelo de design, como sua divisão em subsistemas e pacotes. Além disso, para cada pacote
significativo, ela mostra sua divisão em classes e utilitários de classe. Você deve apresentar as
classes significativas do ponto de vista da arquitetura e descrever suas responsabilidades, bem
como alguns relacionamentos, operações e atributos de grande importância.]
5.1 Visão Geral
[Esta subseção descreve toda a decomposição do modelo de design em termos de
camadas e de hierarquia de pacotes.]
5.2 Pacotes de Design Significativos do Ponto de Vista da
Arquitetura
[Para cada pacote significativo, inclua uma subseção com o respectivo nome, uma
breve descrição e um diagrama com todos os pacotes e classes significativos nele contidos.
Para cada classe significativa no pacote, inclua o respectivo nome, uma breve
descrição e, opcionalmente, uma descrição de algumas das suas principais responsabilidades,
operações e atributos.]
6. VISÃO DE PROCESSOS
[Esta seção descreve a decomposição do sistema em processos leves (encadeamentos
simples de controle) e processos pesados (agrupamentos de processos leves). Organize a seção
em grupos de processos que se comunicam ou interagem. Descreva os modos principais de
comunicação entre processos, como transmissão de mensagens e interrupções.]
7. VISUALIZAÇÃO DA IMPLEMENTAÇÃO
[Esta seção descreve uma ou mais configurações da rede física (hardware) na qual o
software é implantado e executado. Ela é uma visão do Modelo de Implantação. No mínimo,
para cada configuração, ela deve indicar os nós físicos (computadores, CPUs) que executam o
software e suas interconexões (barramento, LAN, ponto a ponto, etc.) Inclui também um
mapeamento dos processos da Visualização do Processo sobre os nós físicos.]

EB80-MT-78.001

8. VISÃO DA IMPLEMENTAÇÃO
[Esta seção descreve a estrutura geral do modelo de implementação, a divisão do
software em camadas e subsistemas no modelo de implementação e todos os componentes
significativos do ponto de vista da arquitetura.]
8.1 Visão Geral
[Esta subseção nomeia e define as diversas camadas e o seu conteúdo, as regras que
determinam a inclusão em uma camada específica e as fronteiras entre as camadas. Inclua um
diagrama de componentes que mostre os relacionamentos entre as camadas. ]
8.2 Camadas
[Para cada camada, inclua uma subseção com o respectivo nome, uma lista dos
subsistemas localizados na camada e um diagrama de componentes.]
9. VISÃO DE DADOS (OPCIONAL)

[Uma descrição da perspectiva de armazenamento de dados persistentes do sistema.
Esta seção será opcional se os dados persistentes forem poucos ou inexistentes ou se a
conversão entre o Modelo de Design e o Modelo de Dados for trivial.]
10. TAMANHO E DESEMPENHO
[Uma descrição das principais características de dimensionamento do software que
têm um impacto na arquitetura, bem como as restrições do desempenho desejado.]
11. QUALIDADE
[Uma descrição de como a arquitetura do software contribui para todos os recursos
(exceto a funcionalidade) do sistema: capacidade de extensão, credibilidade, portabilidade e
assim por diante. Se essas características possuírem significado especial, como implicações de
segurança, garantia ou privacidade, elas deverão ser delineadas claramente.]

EB80-MT-78.001
ANEXO K
MODELO DE TERMO DE HOMOLOGAÇÃO
<SIGLA DO PROJETO>
<Nome do Projeto>
Termo de Homologação
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - K-1

EB80-MT-78.001

Termo de Homologação Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 IDENTIFICAÇÃO DO PROJETO....................................................................4
2 RESPONSÁVEIS.................................................................................................4
3 LISTA DE PRODUTOS.......................................................................................4

EB80-MT-78.001

1. IDENTIFICAÇÃO DO PROJETO
Citar nome do Projeto e data de início.
2. RESPONSÁVEIS
Os responsáveis abaixo aprovam e homologam os produtos listados neste Termo.
Emissor Papel OM Assinatura

Maj Gerente do projeto CDS
Receptor Papel OM Assinatura

Cel Coordenador do Projeto DSM
3. LISTA DE PRODUTOS
Conforme disposto na metodologia adotada no projeto, atestamos que os produtos abaixo
descritos estão em conformidade com os objetivos do projeto e são considerados homologados
na data de Homologação abaixo:
Item Produto Versão Data da Homologação

1 Documento de Visão 1
2 Glossário 1
3 Requisitos do sistema 1
4 Regras de negócio 1

EB80-MT-78.001
ANEXO L
MODELO DE DESIGN
<SIGLA DO PROJETO>
<Nome do Projeto>
Modelo de Design
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - L-1

EB80-MT-78.001

Modelo de Design Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 INTRODUÇÃO....................................................................................................4
2 PACOTES DE DESIGN.......................................................................................4
3 CLASSES..............................................................................................................4
4 REALIZAÇÕES DE CASOS DE USO..............................................................4
4.1 Caso de Uso <Nome_do_Caso_de_Uso>...................................................................4
4.1.1 Diagramas de Classes......................................................................................................5
4.1.2 Diagramas de Sequência..................................................................................................5
4.2 Caso de Uso <Nome_do_Caso_de_Uso>...................................................................5

EB80-MT-78.001

1. INTRODUÇÃO
[Uma descrição textual que funciona como uma rápida introdução do modelo.]
2. PACOTES DE DESIGN
[Os pacotes e subsistemas do modelo, representando uma hierarquia.]
3. CLASSES
[As classes são responsáveis por impulsionar o esforço de design , ou seja, são elas que
de fato executam o trabalho real do sistema. Outros elementos de design, como subsistemas,
pacotes e colaborações, descrevem como as classes são agrupadas ou como interoperam.
Conforme os casos de uso são realizados, é necessário unificar as classes e subsistemas
de design identificados para assegurar a homogeneidade e consistência do Modelo de Design.
Pontos a serem considerados:
• Os nomes dos elementos do modelo devem descrever sua função.
• Evite nomes semelhantes e sinônimos porque eles dificultam a distinção dos
elementos do modelo.
• Mescle elementos do modelo que definam um comportamento semelhante ou
que representem o mesmo fenômeno.
• Mescle classes de entidades que representam o mesmo conceito ou que
possuem os mesmos atributos, mesmo que seu comportamento definido seja
diferente.
• Use a herança para abstrair elementos do modelo, o que tende a tornar o
modelo mais robusto.
• Ao atualizar um elemento do modelo, atualize também a descrição do fluxo
de eventos correspondente das realizações de casos de uso. ]
4. REALIZAÇÕES DE CASOS DE USO
[As realizações de caso de uso expressam o comportamento de um conjunto de
elementos de modelo executando algumas coisas ou tudo de um Caso de Uso . Como resultado,
deve haver uma realização para cada caso de uso que precisa ser expressa no modelo de design.

EB80-MT-78.001

Da mesma forma, se os casos de uso não forem usados, suas realizações também serão
omitidas. ]
4.1 Caso de Uso <Nome_do_Caso_de_Uso_1>
[Informe as considerações a respeito da realização deste caso de uso]
4.1.1 Diagramas de Classes
[Utilize padrões e mecanismos de design conforme adequado as classes ou ao recursos
que está sendo projetado e de acordo com as diretrizes de design do projeto.
Agregação de classes para implementação do caso de uso. Serve como elemento para
informar as dependências do caso de uso ]
4.1.2 Diagramas de Sequência
[Para cada realização de casos de uso, ilustre as interações entre seus objetos de
design participantes, criando um ou mais diagramas de sequência.
Descreva cada variante de fluxo em um diagrama de sequência separado. Diagramas
de sequência geralmente são preferíveis ao diagrama de comunicação, visto que sua leitura
tende a ser mais fácil quando o diagrama precisa conter o nível de detalhe que normalmente se
deseja obter ao projetar o sistema.
Comece descrevendo o fluxo básico, que é o mais comum ou o fluxo de eventos mais
importante. Em seguida, descreva as variantes, como os fluxos excepcionais. Você não precisará
descrever todos os fluxos de eventos, desde que empregue e exemplifique todas as operações dos
objetos participantes. Desse modo, fluxos muito triviais poderão ser omitidos, como aqueles que
só se concentram em um objeto.]
4.2 Caso de Uso <Nome_do_Caso_de_Uso_n>

EB80-MT-78.001
ANEXO M
MODELO CASOS DE TESTE
<SIGLA DO PROJETO>
<Nome do Projeto>
Casos de Teste
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - M-1

EB80-MT-78.001

Casos de Teste Data: 23/04/2013

EB80-MT-78.001

SUMÁRIO
1 <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:.........................4

2 <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:.........................4

EB80-MT-78.001

1. <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:

Descrição: [Descreva as lógicas para a execução do teste e os resultados esperados.]
Pré-condições: [Liste as condições que devem ser antes do caso de teste iniciar.]
Pós-condições: [Liste as condições que devem ser verdadeiras quando o caso de teste
terminar]
Dados necessários: [Identifique os tipos e dados requeridos o caso de teste.]
2. <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:

Descrição: [Descreva as lógicas para a execução do teste e os resultados esperados.]
Pré-condições: [Liste as condições que devem ser antes do caso de teste iniciar.]
Pós-condições: [Liste as condições que devem ser verdadeiras quando o caso de teste
terminar]
Dados necessários: [Identifique os tipos e dados requeridos o caso de teste.]

EB80-MT-78.001
ANEXO N
MODELO PLANO DE IMPLANTAÇÃO
<SIGLA DO PROJETO>
<Nome do Projeto>
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-1

EB80-MT-78.001

Plano de Implantação Data: 23/04/2013

<dd/mm/aaaa> <x.x> <detalhes> <nome>

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 INTRODUÇÃO....................................................................................................4
2.1 Objetivo....................................................................................................................... 4
2.2 Escopo......................................................................................................................... 4
2.4 Visão Geral.................................................................................................................. 4
3 REFERÊNCIAS...................................................................................................4
4 PLANO DE IMPLANTAÇÃO............................................................................4
4.1 Responsabilidades......................................................................................................4
4.2 Planejamento..............................................................................................................4
5 RECURSOS..........................................................................................................5
5.1 Recursos...................................................................................................................... 5
5.2 Hardware....................................................................................................................5
5.3 A Unidade de Implantação.........................................................................................5
5.3.1 Software de Suporte..........................................................................................................5
5.3.2 Documentação de Suporte................................................................................................5
5.3.3 Equipe de Suporte.............................................................................................................5
6 TREINAMENTO..................................................................................................5

EB80-MT-78.001

1. PROPÓSITO
<Este documento descreve …>
2. INTRODUÇÃO
<Forneça uma visão geral de todo o documento.>
2.1 Objetivo
<Descreva o objetivo do software ao qual este documento se aplica.>
2.2 Escopo
<Identifique os destinatários dos itens identificados no Plano de Implantação.>
<Esta subseção fornece as definições de todos os termos, acrônimos e abreviações
requeridos para interpretar adequadamente o Plano de Implantação. Essas informações podem
ser fornecidas em relação ao Glossário do projeto.>
2.4 Visão Geral
<Explique como este documento é organizado.>
3. REFERÊNCIAS
<Esta subseção fornece uma lista completa de todos os documentos mencionados em
outra parte no Plano de Implantação. Identifique cada documento pelo seguinte: título, número
do relatório (se for o caso), data e organização responsável pela publicação. Especifique as
origens a partir das quais as referências podem ser obtidas. Essas informações podem ser
fornecidas por um anexo ou outro documento.>
4. PLANO DE IMPLANTAÇÃO
<Descreva todas as atividades executadas na implantação do produto para o cliente.
As atividades incluem planejamento, teste beta, preparação de itens a serem entregues,
empacotamento, “envio”, instalação do produto, treinamento e suporte.>

EB80-MT-78.001

4.1 Responsabilidades
<Identifique as responsabilidades do cliente e da equipe de desenvolvimento na
preparação para implantação. De particular relevância nesta seção é a descrição do
envolvimento do cliente em testes de aceitação e no processo de manipulação de quaisquer
discrepâncias.>
4.2 Planejamento
<Descreva o planejamento e os marcos para conduzir as atividades de implantação. Os
marcos de implantação devem estar em conformidade com os marcos do projeto.
Leve em consideração as seguintes atividades de Implantação:
• Planejando a Implantação
• Desenvolvendo Material de Suporte
• Gerenciando Testes de Aceitação
o Teste de Aceitação no Site de Desenvolvimento
o Teste de Aceitação no site de Implantação
• Produzindo a Unidade de Implantação
• Gerenciando o Programa Beta
• Gerenciando a Produção de Massa e o Empacotamento do Produto
• Tornando o Produto Acessível através da Internet>
5. RECURSOS
<Liste os recursos e suas origens requeridas para executar as atividades de
implantação planejadas.>
5.1 Recursos
<Conforme aplicável, descreva os recursos requeridos para testar e implantar o
software. Os recursos podem incluir construções ou espaços especiais com
pavimento em relevo, requisitos de domínio e recursos especiais para suportar
requisitos de privacidade e segurança.>

EB80-MT-78.001

5.2 Hardware
<Identifique o hardware requerido para executar e suportar o software, conforme
solicitado. Especifique o modelo, as versões e as configurações. Forneça informações sobre
suporte ao fabricante e licença.>
5.3 A Unidade de Implantação
<Liste o software e a documentação fornecida como parte do produto distribuível.>
5.3.1 Software de Suporte
<Conforme aplicável, descreva todo software necessário para suportar o produto
distribuível, como ferramentas, compiladores, ferramentas de teste, dados de teste, utilitários,
ferramentas CM, bancos de dados, arquivos de dados e assim por diante.>
5.3.2 Documentação de Suporte
<Conforme aplicável, descreva a documentação requerida para suportar o produto
distribuível, como descrições de design, casos e procedimentos de teste, manuais do usuário e
assim por diante.>
5.3.3 Equipe de Suporte
<Conforme aplicável, descreva a equipe e seus níveis de habilidade, requeridos para
suportar o produto distribuível.>
6. TREINAMENTO
<Descreva o plano e as entradas para o treinamento de usuários finais para que eles
possam utilizar e adaptar o produto conforme requerido.>

EB80-MT-78.001
ANEXO O
MODELO DE TERMO DE ENCERRAMENTO DE PROJETO
<Sigla de Projeto>
<Nome do Projeto>
Termo de Encerramento de Projeto
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-1

EB80-MT-78.001

Termo de Encerramento de Projeto Data: 23/04/2013

<dd/mm/aaaa> <x.x> <detalhes> <nome>

EB80-MT-78.001

SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 IDENTIFICAÇÃO DO PROJETO....................................................................4
2.1 Nome do Projeto.........................................................................................................4
2.2 Tipo do Projeto...........................................................................................................4
2.3 Gestor do Projeto........................................................................................................4
2.4 Cliente.........................................................................................................................4
2.5 Demandas Associadas................................................................................................4
2.6 Data de Início do Projeto...........................................................................................4
2.7 Data de Entrega do Projeto.......................................................................................4
3 OBJETIVO DO PROJETO.................................................................................4
4 QUADRO RESUMO DE PRAZO......................................................................5
4.1 Primeira Estimativa aprovada..................................................................................5
4.2 Última Estimativa aprovada......................................................................................5
4.3 Prazo Realizado .........................................................................................................5
4.4 Desvio Planejado X Realizado...................................................................................5
4.5 Quadro Resumo de Custo..........................................................................................5
5 ANÁLISE CRITICA DE DESEMPENHO DO PROJETO (PRAZO E
CUSTO)....................................................................................................................5
6 DOCUMENTAÇÃO DO PROJETO..................................................................5
7 ACORDO DE MANUTENÇÃO.........................................................................6
8 ACEITE FORMAL..............................................................................................6
9 CONTROLE DE MUDANÇAS..........................................................................6
10 AVALIAÇÃO DOS RISCOS DO PROJETO...................................................6
11 LIÇÕES APRENDIDAS....................................................................................6
12 APROVAÇÃO PELO RESPONSÁVEL..........................................................6

EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto> ersão: <Número_Versão>

Termo de Encerramento de Projeto

1. PROPÓSITO
<Este documento descreve …>
2. IDENTIFICAÇÃO DO PROJETO
2.1 Nome do Projeto
< Nome do projeto de maneira clara para entendimento geral>
2.2 Tipo do Projeto
< 1 – PE - Projeto Soluções de TIC para Clientes

2 – PI – Projeto de Melhoramento em Produtos e Serviços
3 – PI – Projetos de Gestão
4 – PI – Projetos Estratégicos
5 – PI – Projetos Administrativos>
2.3 Gestor do Projeto
< Nome da pessoa que estará no papel de Gestor do Projeto>
2.4 Cliente
< Nome do cliente que solicitou o projeto>

2.5 Demandas Associadas
< Número(s) da(s) demanda(s) que deram origem ao projeto>
2.6 Data de Início do Projeto
< Data, no formato dd/mm/aaaa, de quando o projeto foi iniciado>

2.7 Data de Entrega do Projeto
< Data, no formato dd/mm/aaaa, de quando o projeto foi entregue ao cliente>

EB80-MT-78.001

3. OBJETIVO DO PROJETO
< Descrição sucinta de onde se deseja chegar com o projeto, relacionando-o com os
processos do negócio do cliente. Os objetivos do projeto devem ser quantificáveis em relação a
tempo, custo e escopo. Objetivos não quantificados (por exemplo, satisfação do cliente)
pressupõem um risco maior para uma conclusão com sucesso.>
4. QUADRO RESUMO DE PRAZO
4.1 Primeira Estimativa aprovada

Início Previsto Término Previsto Duração Prevista
<dd/mm/aaaa> <dd/mm/aaaa> <dd/mm/aaaa>
4.2 Última Estimativa aprovada

Início Previsto Término Previsto Duração Prevista
<dd/mm/aaaa> <dd/mm/aaaa> <dd/mm/aaaa>
4.3 Prazo Realizado
Início Realizado Término Realizado Duração Realizada

<dd/mm/aaaa> <dd/mm/aaaa> <Nro. de dias>
4.4 Desvio Planejado X Realizado
Desvio % da Primeira Estimativa Desvio % da Última Estimativa

< ((duração realizada / duração 1ª < ((duração realizada / duração
Estimativa) - 1 ) *100 > última Estimativa) - 1 ) *100 >

EB80-MT-78.001

4.5 Quadro Resumo de Custo
Valor Global PrevistoValor Global Previsto Última

Desvio % da Primeira Desvio % da Última
1ª Estimativa Estimativa Valor Realizado
Estimativa Estimativa
Aprovada Aprovada
< (( Valor < (( Valor
realizado / Valor realizado / Valor
Previsto na 1ª Previsto na última
Estimativa ) - 1 ) *100 estimativa ) - 1 )
> *100 >
5. ANÁLISE CRITICA DE DESEMPENHO DO PROJETO (PRAZO E

CUSTO)
<Descrever a situação do desempenho do projeto quanto a Prazo e Custo>
6. DOCUMENTAÇÃO DO PROJETO
<Informar o local físico onde se encontra toda documentação do Projeto relativo:

1. As avaliações do processo de gerenciamento do projeto: reuniões, trabalhos interativos,
seqüência de ações;
2. A Avaliação dos documentos utilizados no acompanhamento do projeto, para melhoria
do processo
3. Os Riscos: como foram geridos, investimentos realizados e benefícios colhidos;
4. Os Custos incorridos, maiores desvios (positivo e negativo)
5. A Equipe: formação, mudanças, relacionamentos, envolvimentos e comprometimentos;
6. As informações Técnicas: ações e documentos que contribuíram com o projeto,
processos utilizados, desenvolvidos ou aperfeiçoados;
7. As informações Tecnológicas: Aquisição ou desenvolvimento do conhecimento,
benchmarking realizado;
8. Quais Documentos legais foram necessários. >

EB80-MT-78.001

7. ACORDO DE MANUTENÇÃO
<detalhar o que ficou acordado entre as partes quanto à manutenção posterior do

sistema>
8. ACEITE FORMAL
<ressaltar a importância do desdobramento do aceite em resultados parciais>
9. CONTROLE DE MUDANÇAS
<Informar a quantidade total de mudanças ocorridas durante a execução do Projeto>
Quantidade de mudanças total
10. AVALIAÇÃO DOS RISCOS DO PROJETO
< especificar fatores de risco do projeto que tenham se materializado e análise das
ações tomadas>
11. LIÇÕES APRENDIDAS
<apresentar os acertos e as dificuldades encontradas para a execução do que foi

planejado ou do que foi esquecido de planejar para o projeto e as ações tomadas para solução
das dificuldades >
Acertos e Dificuldades Ações para solução das Dificuldades
Outras lições Aprendidas

EB80-MT-78.001

Tede Encerramento de Projeto Data: 23/04/2013
12. APROVAÇÃO PELO RESPONSÁVEL
< O Gestor do Projeto deve encaminhar o Relatório de Encerramento do Projeto ao

Responsável pela Aprovação. O Responsável pela Aprovação é, necessariamente o Chefe do
Centro de Desenvolvimento de Sistemas, Supervisor do projeto e a OM cliente.>
Nome: Data:
Aprovação:
Justificativa:
Nome: Data:
Aprovação:
Justificativa:

EB80-MT-78.001
GLOSSÁRIO
PARTE I - ABREVIATURAS E SIGLAS
D
Abreviaturas/Siglas Significado
DBA Administrador de Banco de Dados
I
IDE Ambiente de Desenvolvimento Integrado
M
MDS Metodologia de Desenvolvimento de Software
N
NEGAPEB Normas para Elaboração, Gerenciamento e
Acompanhamento de Projetos no Exército
Brasileiro
R
RDBMS Sistema Gerenciador de Banco de Dados
Relacional
RUP Processo Unificado da Rational
U
UML Linguagem de Modelagem Unificada
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1

EB80-MT-78.001
PARTE II – TERMOS E DEFINIÇÕES
Build (construção) - É uma versão compilada de um software ou parte dele que

contém um conjunto de recursos que poderão integrar o produto final.
Código Multi-Thread - Código escrito de forma a favorecer a divisão de

processos em tarefas que sejam executadas de forma concorrente pelo sistema
operacional do computador.
IDE Eclipse - IDE, do inglês Integrated Development Environment, é um

programa de computador que reúne características e ferramentas de apoio ao
desenvolvimento de software com o objetivo de agilizar este processo. O IDE Eclipse é
uma ferramenta de apoio ao desenvolvimento de software que gera código na linguagem
JAVA.
Integração Contínua - A integração contínua é uma prática de implementação

onde membros de equipe integram seu trabalho com conjunto de mudanças realizadas
por outros desenvolvedores e testam a aplicação antes de tornar seu trabalho disponível
para os demais. Isto permite a detecção de erros de integração mais prematuramente
possível, tais como erros de compilação, notificações do sistema de gerenciamento de
configuração e erros relatados pela ferramenta de teste.
Linha de Base - Também conhecida pelo seu nome em inglês Base Line.
Estabelece, em projetos, pontos de referências para futuras comparações. Podem
estabelecer datas de início e término de trabalho, custos e outras variáveis de projetos.
Modelo de Design - O modelo de design é um modelo de objeto que descreve a

realização dos casos de uso e serve como uma abstração do modelo de implementação e
seu código-fonte. O modelo de design é usado como base para atividades de
implementação e teste.

EB80-MT-78.001
Padrão Entidade-Controle-Fronteira - O padrão Entidade-Controle-Fronteira é

um padrão de arquitetura usado para desenhar as funcionalidades como um todo, sendo
especialmente útil na tradução de casos de usos.
Refatoração - Técnica de melhorar o desenho interno de um código ou produto

de trabalho sem afetar as suas interfaces externas.
Stored Procedure - É um conjunto de comandos em SQL, Structured Query

Language, agrupados em um pacote que recebe um nome. Esse conjunto pode ser
executado várias vezes. Pode, também, conter estruturas do tipo “repetição” e “decisão”.
Encontra grande utilização na execução de operações repetitivas em Bancos de Dados.
Testes Alfa - Os teste chamados “alfa” são executados no período entre o

término do desenvolvimento do software e sua entrega. Normalmente, é conduzido pelo
cliente no ambiente do desenvolvedor.
Testes Beta - São testes realizados no ambiente do usuário, por grupos restritos
de usuários, em versões de teste do software.

EB80-MT-78.001
REFERÊNCIAS
KRUCHTEN, Philippe. INTRODUÇÃO AO RUP - RATIONAL UNIFIED

PROCESS. Rio de Janeiro: Editora Ciência Moderna Ltda., 2003.
LIMA, Adilson da Silva. UML 2.0: do requisito à solução. São Paulo: Érica, 2009.
MPS.BR – Melhoria de Processo do Software Brasileiro: Guia Geral. SOFTEx,

2011.
PAULA FILHO, Wilson de Pádua. ENGENHARIA DE SOFTWARE: Fundamentos,

Métodos e Padrões. Rio de Janeiro: LTC, 2001.
PRESSMAN, Roger S. ENGENHARIA DE SOFTWARE. São Paulo: McGraw-Hill,

2006.
Wikipédia: a enciclopédia livre. Disponível em: <http://pt.wikipedia.org/wiki/Scrum>.

Acessado em 14 de Março de 2012.

EB80-MT-78.001
COMANDO DO EXÉRCITO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
Brasília, 18 de Dezembro de 2012
www.dct.eb.mil.br

Metodologia de Desenvolvimento de Software

Enviado por

Dados do documento

Descrição original:

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

Metodologia de Desenvolvimento de Software

Enviado por

Direitos autorais:

Formatos disponíveis

EB80-MT-78.

NÚMERO DE ORDEM ATO DE APROVAÇÃO PÁGINAS AFETADAS DATA

1. FASES DO PROJETO........................................................................................................... 2-1

O ciclo de vida de um software, de acordo com as Instruções Gerais (IG) do

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-1

A metodologia ora apresentada toma por base os processos e boas práticas do

Esta Metodologia de Desenvolvimento de Sistemas (MDS) visa descrever e

a. Definir os papéis e responsabilidades dentro do processo de desenvolvimento de

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-2

Um papel define o comportamento e responsabilidades de um profissional ou

Representa as pessoas que conhecem ou utilizam o processo para o qual o

4.2 Gerente de Projeto

Conduz o planejamento do projeto, coordena as interações com os Clientes e

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-3

• Planeja, coordena e controla o andamento das atividades do projeto

4.3 Analista de Sistemas

Responsável por capturar as regras de negócio e os requisitos do sistema a ser

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-4

• Valida junto ao cliente e gerente de projetos todos os documentos de

Define a arquitetura dos elementos do software. Coordena o desenho técnico

Desenvolve o design de forma que ele atenda a arquitetura e a prototipagem

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-5

Implementa e integra os componentes que são parte da solução e, também,

4.7 Administrador de Banco de Dados

Define tabelas, índices, visões, restrições, triggers, procedimentos

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-6

Identifica, define, implementa e conduz os testes necessários, bem como

4.9 Projetista de Infraestrutura

Analisa os impactos dos requisitos não funcionais com a infraestrutura

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-7

5. MODELO DE DESENVOLVIMENTO DE SOFTWARE

Este modelo de processo de desenvolvimento de software descreve o fluxo de

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-8

Do ponto de vista do gerenciamento, o ciclo de vida do projeto de

Iniciação Elaboração Construção Transição

Tabela 1: Marcos do ciclo de vida do desenvolvimento de software

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-1

1.1 FASE DE INICIAÇÃO

Os projetos no Exército, de acordo com a NEGAPEB, devem ser precedidos

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-2

f) Levantar e planejar o controle dos riscos em potencial (as fontes de

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-3

1.1.1 FLUXO DE ATIVIDADES DA FASE DE INICIAÇÃO

Figura 1: Fluxo de trabalho de uma iteração na fase de iniciação

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-4

1.1.2 ATIVIDADES, TAREFAS E ENVOLVIDOS

Atividade : Planejar o Projeto

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-5

O Gerente do Projeto deve avaliar a necessidade de definir os planos para o

Atividade: Planejar a Iteração

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-6

Atividade: Definir a Visão

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-7

Saídas • Documento de Visão

Atividade: Gerenciar a Iteração

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-8

Atividade: Planejar Próxima Iteração

Atividade: Encerrar a Iteração

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-9

Revisar os Avalie em conjunto com a equipe do projeto, ao final da iteração, se os objetivos e

Atividade: Identificar e Refinar os Requisitos / Encontrar e descrever os requisitos

Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-10