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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-2
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:
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-3
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-4
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-5
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-6
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-7
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 1-8
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-1
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
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-2
FASE DE INICIAÇÃO
e de riscos que permitam avaliar as reais possibilidades de sucesso do projeto. Em seu
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-3
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-4
EB80-MT-78.001
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
envolvidos
Identificar os usuários, conhecedores do domínio, responsáveis pela validação
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
duração do projeto
Aplicar técnica de mensuração de tamanho de projeto de software para estimar o
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;
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-5
FASE DE INICIAÇÃO
Figura 2: Subprocesso Identificar e Refinar Requisitos
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.
Analisar o escopo do projeto e seus principais requisitos para descrever quais
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
riscos
A equipe deve identificar os riscos, avaliar e atualizar a lista de 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.
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
trabalhos
e
objetivos de cada
iteração para a
fase.
Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para
compor o escopo da iteração com base nos cenários e valores adicionados. Os
itens selecionados definem a meta da iteração.
Determinar quais requisitos dentre os selecionados para a iteração atual
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
planejamento
Iteração
o Documentar os requisitos selecionados para a iteração (meta).
da Documentar o planejamento acordado na reunião.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-6
FASE DE INICIAÇÃO
Descrever o ciclo
de vida do projeto
EB80-MT-78.001
Relacionamentos
Papéis
Responsável: Gerente do Projeto
Participantes:
•
Analista de Sistemas
•
Arquiteto
•
Testador
•
Desenvolvedores
•
Cliente
Entradas
•
Plano do Projeto
Saídas
•
Plano da Iteração
Observações
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
Clientes/Usuários
Identificam-se os envolvidos, clientes e usuários que farão parte do
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
solicitados pelos
Clientes
Serão base para elucidar os requisitos para desenvolver o produto. Deve-se
realizar reuniões para discutir as solicitações do cliente.
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-7
FASE DE INICIAÇÃO
É 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ª
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.
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.
Descrição
Capturar e
comunicar o
andamento das
Iterações
O gerente de projeto necessita:
• monitorar continuamente o projeto para assegurar que esteja progredindo
corretamente.
• 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
e os problemas
Identifique a causa e o impacto dos problemas e exceções assim que eles
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
gerenciar os riscos
Identifique os riscos assim que o projeto inicie. A Lista de Riscos será incluída no
documento Plano de Projeto, de acordo com a NEGAPEB. Deve ser revisada
semanalmente, ou no mínimo uma vez por iteração.
Gerenciar os
objetivos
Altere o escopo do trabalho, caso necessário, para assegurar que a equipe
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
Papéis
Responsável: Gerente de Projeto
Participantes:
•
Analista de Sistemas
•
Arquiteto
•
Desenvolvedor
•
Cliente
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-8
FASE DE INICIAÇÃO
Tarefas
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.
Descrição
Selecionar
os
trabalhos
e
objetivos de cada
iteração para a
fase.
Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para
compor o escopo da iteração com base nos cenários e valores adicionados. Os
itens selecionados definem a meta da iteração.
Determinar quais requisitos dentre os selecionados para a iteração atual
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
planejamento
Iteração
o Documentar os requisitos selecionados para a iteração (meta).
da Documentar o planejamento acordado na reunião.
Relacionamentos
Papéis
Responsável: Gerente de Projeto
Participantes:
• Analista de Sistemas
• Arquiteto
• Analista de Teste
• Desenvolvedor
• Cliente
Entradas
Plano de Projeto
Plano de Iteração
Saídas
Plano de Iteração
Plano de Projeto revisado
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-9
FASE DE INICIAÇÃO
Tarefas
EB80-MT-78.001
Revisar os
resultados da
iteração
Avalie em conjunto com a equipe do projeto, ao final da iteração, se os objetivos e
os critérios de avaliação estabelecidos no Plano de Iteração foram alcançados, e
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.
Proceda com o pagamento de acordo com o valor calculado do tamanho
desenvolvido, em pontos de função, em caso de desenvolvimento feito por
empresa contratada:
Divulgue a todos os envolvidos via e-mail, atualização do andamento do projeto e
a conclusão da iteração.
Realizar
procedimentos
contratuais
Se aplicável, encerrar os contratos vigentes para o término do projeto.
Relacionamentos
Papéis
Responsável: Gerente do Projeto
Participantes:
• Analista de Sistemas
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
Plano de Projeto 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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-10
FASE DE INICIAÇÃO
Realizar
procedimentos
administrativos
EB80-MT-78.001
Papéis
Responsável:
• Analista de Sistemas
Participantes:
• Gerente do Projeto
• Analistas de Sistemas
• Arquiteto
• Cliente/Usuário
•
•
•
•
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
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
Detalhar requisitos
Descrição
•
•
•
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
Papéis
Responsável: Analista de Sistemas
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-11
FASE DE INICIAÇÃO
Entradas
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
Responsável: Analista de Sistemas
Participantes:
• Gerente de Projeto
• Cliente/Usuário
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
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
ferramentas
Verificar as ferramentas necessárias para o desenvolvimento, nas devidas
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
Dados
Instalar sistema gerenciador de banco de dados e base de dados do projeto, se
for o caso.
Configurar
ambiente
Deixar os computadores dos desenvolvedores prontos para a implementação
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
• Analista de Sistemas
• Desenvolvedor
• DBA
Entradas
•
Plano do Projeto e Plano de Iteração
Saídas
•
•
Repositório Configurado
Ambiente de Desenvolvimento Configurado
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-12
FASE DE INICIAÇÃO
Papéis
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.
Identifique quais dos requisitos atuais são arquiteturalmente significantes. Explore
e refine aqueles que devem ser implementados para alcançar as metas
arquiteturais da iteração atual.
Identificar as
restrições na
arquitetura
Liste quaisquer restrições na arquitetura e eventuais conflitos entre os requisitos e
os recursos concorrentes. Decida como a arquitetura irá resolver essas questões.
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
selecionar os
recursos
disponíveis
Identifique os recursos de outras áreas que podem ser reutilizados na arquitetura
atual. Podem ser: frameworks arquiteturais, mecanismos arquiteturais, decisões
arquiteturais, restrições, aplicações e componentes.
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
mecanismos
arquiteturais
Faça uma lista dos serviços técnicos que o sistema precisa fornecer e capture
algumas informações básicas sobre cada item na lista. Normalmente, é uma boa
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-13
FASE DE INICIAÇÃO
Identificar os
requisitos
arquiteturalmente
significantes
EB80-MT-78.001
Verificar a
coerência
arquitetural
Trabalhe com o Desenvolvedor e o Gerente de Projeto, para verificar se a
arquitetura está consistente com os requisitos e se as descrições da arquitetura
estão claras, significativas e completas.
Capturar as
decisões
arquiteturais
Capture decisões importantes sobre a arquitetura para referência futura.
Considere o uso dos templates fornecidos para o Documento de Arquitetura. Os
Desenvolvedores em particular, devem compreender claramente o estado atual da
arquitetura em cada iteração antes do desenvolvimento da arquitetura.
Relacionamentos
Responsável: Arquiteto
Participantes:
• Analista de Sistemas
• Desenvolvedor
• Gerente de Projeto
• Cliente
Entradas
Visão
Modelo de Casos de Uso
Glossário
Saídas
Documento de Arquitetura
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-14
FASE DE INICIAÇÃO
Papéis
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
características
técnicas do
ambiente de
produção, suas
possibilidades e
limitações.
Identificar as características do ambiente de produção relevantes para o sistema
em desenvolvimento, tais como: servidores, capacidades de processamento,
memória, armazenamento de dados, de banda de rede e backup, sistemas
operacionais e softwares existentes e suas licenças de uso, bem como
capacitação do pessoal. Verificar, também, a projeção de utilização dessas
capacidades pelos sistemas atuais e futuros (previstos).
Verificar se a
infraestrutura atual
atende o sistema
Verificar se a infraestrutura atual e/ou futura atende os requisitos não-funcionais
do sistema.
Propor ajustes no
ambiente de
produção e/ou
reservas de
capacidades.
Propor ajustes na infraestrutura de produção, para atender aos requisitos
não-funcionais do sistema. Propor, também, reserva de recursos de infraestrutura,
visando atender o sistema em desenvolvimento. Consolidar todo o estudo em um
relatório.
Relacionamentos
Papéis
Responsável: Projetista de Infraestrutura
Participantes:
• Analista de Sistemas
• Arquiteto
• Gerente de Projeto
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
FASE DE ELABORAÇÃO
Verificar as
Verificar as necessidades do sistema, em virtude dos requisitos não-funcionais,
necessidades do
levantados nas especificações suplementares.
sistema decorrentes
dos requisitos
não-funcionais
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.
Os principais objetivos da fase sã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
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-16
FASE DE ELABORAÇÃO
desenvolvimento;
EB80-MT-78.001
1.2.1
FLUXO DE ATIVIDADES DA FASE DE ELABORAÇÃO
FASE DE ELABORAÇÃO
Figura 3: Fluxo de trabalho de uma iteração na fase de elaboração / construção
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-17
EB80-MT-78.001
Figura 5: Subprocesso Testar a Solução
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-18
FASE DE ELABORAÇÃO
Figura 4: Subprocesso Desenvolver Incremento da 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
Tarefas
Verificar
requisitos
iteração
Descrição
os Verificar se os objetivos da iteração da fase anterior foram atingidos.
da Avaliar o trabalho a ser realizado dentro da fase atual e confrontar com 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
Papéis
Responsável: Gerente de Projeto
Participantes:
• Analista de Sistemas
• Arquiteto
• Desenvolvedor
• Testador
Entradas
Plano de Projeto
Visão do Projeto
Plano da Iteração
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-19
FASE DE ELABORAÇÃ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.
EB80-MT-78.001
Relatório de Avaliação de Iteração anterior
Saídas
Plano da Iteração revisado
Observações
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
elementos de design
arquiteturalmente
significantes
Refine as principais abstrações em elementos concretos de design (tais como
classes e subsistemas) e forneça pelo menos um nome e uma descrição
resumida para cada um.
Refinar os
mecanismos
arquiteturais
Refine cada mecanismo arquitetural priorizado em um estado de design.
Revise os requisitos da iteração atual para identificar quais mecanismos
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
qualidade de código
Defina as métricas e os parâmetros que serão utilizados para avaliar a
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-20
FASE DE ELABORAÇÃO
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.
EB80-MT-78.001
durante o desenvolvimento.
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
decisões
Assegure-se de que aqueles que necessitam agir sobre o trabalho arquitetural
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
Papéis
Responsável: Arquiteto
Participantes:
• Gerente de Projeto
• Desenvolvedor
Entradas
Visão
Modelo de Casos de Uso
Glossário
Documento de Arquitetura
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
detalhes dos
requisitos
Examine os Caso de Uso relevantes e a Especificação de Requisitos
Suplementares para compreender o escopo da tarefa de design e as
expectativas sobre o Design
Compreender a
arquitetura
Revise o Documento de Arquitetura para identificar mudanças e adições à
arquitetura
Este passo pode ser ignorado, se não houve alterações na arquitetura proposta
na iteração anterior.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-21
FASE DE ELABORAÇÃO
Validar a arquitetura
EB80-MT-78.001
Identifique os elementos que colaboram entre si para fornecer o
comportamento desejado. Isto pode começar com as principais abstrações
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
os elementos
colaboram para
realizar o cenário
Percorra o cenário distribuindo as responsabilidades aos elementos
participantes e assegurando que eles têm os relacionamentos necessários para
colaborar.
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
Design
Comunique o design do sistema para aqueles que necessitam compreendê-lo.
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
• Analista de Sistemas
• Testador
Entradas
Documento de Arquitetura
Caso de Uso Detalhado
Especificação de Requisitos Suplementares
Saídas
Modelo de Design
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-22
FASE DE ELABORAÇÃO
Identificar
elementos de
design
EB80-MT-78.001
Observaçõ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
Validar o modelo
Verifique a aderência do modelo de dados às normas para definição de dados e
metadados (IR 14-06).
Identificar reuso
Identifique oportunidades para reutilização de dados
Implementar o
modelo 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.
Definir regras de cumprimento de integridade referencial e dados (Chaves
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-23
FASE DE ELABORAÇÃO
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.
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
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
realizações
Casos de Uso
as Verifique se todos os cenários da iteração atual foram completamente abordados
de pelas realizações de casos de uso. Todos os comportamentos dos sub fluxos
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
Papéis
Responsável: Arquiteto
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,
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-24
FASE DE ELABORAÇÃ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.
EB80-MT-78.001
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
oportunidades para
reuso
Identifique algum código existente ou elementos de implementação que possa
ser reutilizado em parte da Implementação que você esteja criando ou
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
em implementação
Se você estiver usando ferramentas de modelagem sofisticadas, poderá gerar
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
implementação
Verifique se a implementação está ajustada à sua finalidade. Examine 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:
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-25
FASE DE ELABORAÇÃO
estratégia
EB80-MT-78.001
Melhore a implementação baseada nos resultados destas avaliações.
Comunicar decisões
significantes
Comunique o impacto de mudanças inesperadas no design e nos requisitos.
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-26
FASE DE ELABORAÇÃO
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.
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
Tarefas
Descrição
Refinar o escopo e
identificar os testes
Selecione o incremento de trabalho a ser testado e identifique os testes de
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
instanciação do
teste
Para executar um teste com sucesso o sistema deve estar em um estado
conhecido de modo que o comportamento correto possa ser definido. Implemente
a lógica de instanciação que deva ser executada como parte do teste de
desenvolvedor.
Definir os
resultados
esperados
Defina os resultados esperados de cada teste de modo que eles possam ser
verificados.
Escrever a lógica
do teste
Escreva as etapas de execução dos testes.
Definir a resposta
do teste
Defina as informações que os testes devem produzir para indicar se houve
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
para limpeza
Identifique e implemente os passos necessários para restaurar o ambiente de
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-27
FASE DE ELABORAÇÃO
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.
EB80-MT-78.001
Papéis
Responsável: Desenvolvedor
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.
Descrição
Executar os Testes
de Desenvolvedor
Configure o ambiente de teste para assegurar que todos os elementos
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
corrigir a execução
dos testes.
Determine a ação corretiva apropriada para recuperar-se de uma execução de
teste de desenvolvedor que tenha falhado.
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
Resultados do
Teste
Examine os resultados do teste para assegurar que eles sejam confiáveis e que
as falhas, avisos ou resultados inesperados não tenham sido causados por
influências externas (ao objetivo do teste), como configuração ou dados
inadequados.
Relacionamentos
Papéis
Responsável: Desenvolvedor
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-28
FASE DE ELABORAÇÃO
Tarefas
EB80-MT-78.001
Atividade: Desenvolver Incremento da Solução / Integrar e Criar a Construção.
FASE DE ELABORAÇÃO
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-29
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
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
Papéis
Responsável: Desenvolvedor
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
implementação
Analise os artefatos de código produzidos pelos desenvolvedores, verificando:
• 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
base
Crie uma linha de base que identifique inequivocamente a versão que esteja
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-30
FASE DE ELABORAÇÃO
Execute os Testes de Desenvolvedor nos elementos integrados para verificar se
eles se comportam da mesma forma que quando estavam isolados.
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
Papéis
Responsável: Arquiteto
Participantes:
• Projetista
• Desenvolvedor
Entradas
Modelo de Design
Construção
Saídas
Versão operacional
Notas de Release
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
requisitos a serem
testados
Trabalhe com o Analista e o Desenvolvedor para identificar quais cenários
necessitam de casos de teste novos ou adicionais.
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:
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-31
FASE DE ELABORAÇÃO
Observações
EB80-MT-78.001
•
•
•
Analista de Sistemas
Desenvolvedor
Cliente
Entradas
Lista de Requisitos Funcionais
Modelo de Caso de Uso
Caso de Uso detalhado
Saídas
Casos de Teste
Observações
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
Selecionar os
Casos de Teste a
implementar
Selecione um conjunto de Casos de Teste para desenvolver Script de Teste
detalhados e executáveis.
Trabalhe com o Gerente de Projeto e o Desenvolvedor para determinar quais
Casos de Teste precisam de Scripts de Teste detalhados durante a iteração atual.
Projetar o Script de
Teste
Determine se o Script de Teste será manual ou automático
Se o Caso de Teste estiver bem compreendido, é melhor implementar um Script
de Teste automatizado sem antes escrever um procedimento manual.
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.
Implementar o
Script de Teste
executável
Desenvolva um Script de Teste procedural e detalhado baseado no seu projeto.
Use um estilo solicitação/resposta que declara uma entrada exata, e espera uma
saída exata.
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.
Verificar a
implementação
Execute o Script de Teste para verificar que ele implementa o Caso de Teste
corretamente.
Para testes manuais, percorra o Script de Teste. Para testes automatizados,
verifique se o Script de Teste executa corretamente e produz o resultado
esperado.
Relacionamentos
Papéis
Responsável: Testador
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-32
FASE DE ELABORAÇÃO
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.
EB80-MT-78.001
Participantes:
• Analista de Sistemas
• 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
Descrição
Selecionar os
Scripts de Teste
Selecione os Scripts de Teste relacionados aos itens de trabalho concluídos na
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.
Fornecer feedback
para a equipe
Resuma e forneça feedback para a equipe sobre quanto a construção satisfaz os
requisitos previstos para a iteração. Focalize na medição do progresso em termos
de testes executados com sucesso.
Relacionamentos
Papéis
Responsável: Testador
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
requisitos não
funcionais
Verificar os requisitos não-funcionais que devem ser atendidos pelo sistema no
ambiente de produção.
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
não-funcionais
Executar testes que permitam avaliar os requisitos não-funcionais exigidos pelo
sistema.
Relacionamentos
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-33
FASE DE ELABORAÇÃO
Tarefas
EB80-MT-78.001
Papéis
Responsável: Testador
Participantes: Projetista de Infraestrutura
Entradas
Especificação de Requisitos Suplementares
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.
Descrição
Identificar não
conformidades
Identificar quais os requisitos não funcionais não foram atendido, bem como aferir
a medida do não atendimento.
Avaliar possíveis
causas
Avaliar as possíveis causas que contribuem para que os requisitos não funcionais,
não sejam atendidos.
Ajustar e/ou propor
medidas de ajuste
na infraestrutura.
Caso seja possível, ajustar os parâmetros do ambiente de produção, para atender
os requisitos não-funcionais. Caso isso não seja possível ou não resolva a
situação, propor medidas de ajustes no ambiente de produção. Consolidar todo
esse estudo em um relatório.
Relacionamentos
Papéis
Responsável: Projetista de Infraestrutura
Participantes: Arquiteto
Entradas
Especificação de Requisitos Suplementares
Registro de Teste
Saídas
Relatório
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-34
FASE DE ELABORAÇÃO
Tarefas
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
funcionalidades
Utilize a versão operacional disponibilizada para validar as funcionalidades
implementadas
Avaliar requisitos
Verifique se os requisitos definidos para a iteração foram implementados
Relacionamentos
Responsável: Cliente
Participantes:
• Gerente
• Analista de Sistemas
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.
Os principais objetivos da fase são:
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;
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-35
FASE DE CONSTRUÇÃO
Papéis
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.
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.
1.3.2
ATIVIDADES, TAREFAS E ENVOLVIDOS
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013.- 2-36
FASE DE CONSTRUÇÃO
1.3.1
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.
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-37
FASE DE TRANSIÇÃO
Os principais objetivos da fase são:
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-38
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.
1.4.2
ATIVIDADES, TAREFAS E ENVOLVIDOS
Atividade: Planejar Implantação
Tarefas
Planejar
implantação
software
produção
Planejar
Empacotar
Software
Descrição
a O resultado da implementação e das atividades de teste são programas
do executáveis testados. Esses programas executáveis devem ser associados a
em outros produtos de trabalho para constituírem uma unidade ou um produto de
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.
como Os vários produtos de trabalho que compõem o produto liberado são
o empacotados na mídia adequada, tais como: CD-ROM, DVD, arquivos de servidor
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-39
FASE DE TRANSIÇÃ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
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.
EB80-MT-78.001
Relacionamentos
Papéis
Responsável: Analista de Sistemas
Participantes:
• Gerente de Projeto
• Arquiteto
Entradas
Plano de Iteração
Plano de Projeto
Saídas
Plano de Implantação
Atividade: Desenvolver Material de Suporte
Tarefas
Descrição
Desenvolver
material de suporte
Materiais de suporte para o usuário destinam-se a descrever a utilização do
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
materiais
treinamento
Produzir materiais necessários para treinar os usuários do sistema.
de Definir os objetivos do 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
requisitos
software
instalação
sistema.
Consiste em especificações de softwares e em instruções documentadas
de necessárias para instalar o sistema.
para
do
Desenvolver
material
manutenção
Organizar e elaborar a documentação para manutenção descrevendo os
para principais erros e soluções que podem ocorrer na utilização do sistema.
Relacionamentos
Papéis
Responsável: Analista de Sistemas
Participantes:
• Gerente de Projeto
• Arquiteto
Entradas
Plano de Iteração
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)
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-40
FASE DE TRANSIÇÃO
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.
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
treinamentos
Elaborar apresentação sobre operação do sistema, baseado nos manuais.
Elaborar apresentação sobre manutenção do sistema, baseado nos manuais.
Planejar e dimensionar turmas de treinamento.
Agendar
treinamentos
Reservar sala, infra-estrutura (projetor, computadores, etc).
Convocar envolvidos para os treinamentos.
os Apresentar procedimentos de operação do sistema para os usuários.
Apresentar procedimentos de manutenção do sistema para equipe responsável.
Registrar
treinamento
Recolher assinaturas na lista de presença dos treinamentos realizados.
Relacionamentos
Papéis
Responsável: Analista de Sistemas
Participantes:
• Gerente de Projeto
• Usuários
• Arquiteto
Entradas
Plano de Iteração
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
Criar unidade
implantação
Descrição
de Gerar versão do sistema para implantação em ambiente de produção.
Criar cópia dos itens distribuíveis na mídia necessária para implantação no
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-41
FASE DE TRANSIÇÃO
Ministrar
treinamentos
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
Responsável: Arquiteto
Participantes:
• Gerente de Projeto
• Analista de Sistemas
• Desenvolvedor
Entradas
Plano de Iteração
Plano de Projeto
Plano de Implantação
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
Reunião
validação
clientes.
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.
de Obter aprovação do Termo de Aceite do módulo (versão beta) ou projeto final.
com
Relacionamentos
Papéis
Responsável: Gerente de Projeto
Participantes:
• Cliente/Usuário
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-42
FASE DE TRANSIÇÃO
Papéis
EB80-MT-78.001
•
Analista de Sistemas
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.
Avaliar o projeto e o Realiza uma avaliação geral e o registro das lições aprendidas.
processo
de
desenvolvimento
Relacionamentos
Papéis
Responsável: Gerente do Projeto
Participantes:
• Cliente
• Analista de Sistemas
Entradas
Plano de Projeto
Plano de Implantação
Todos os termos de homologação anteriores
Saídas
Termo de Aceite do Produto
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2-43
FASE DE TRANSIÇÃO
Encerrar processos Conclui o fechamento do projeto, finaliza a aplicação dos recursos, encerra
administrativos.
contratos e realoca equipe.
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-1
EB80-MT-78.001
Produto de Trabalho
fases
Responsável
I
E
C
T
Plano de Projeto
G
R
R
-
Plano de Iteração
G
R
R
R
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
-
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
-
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
Manual do Sistema
-
-
-
G
Manual de Treinamento
-
-
-
G
Relatórios da Infraestrutura
G
G
G
-
Projetista
Infraestrutura
Termo de Encerramento do Projeto
-
-
-
G
Gerente de Projeto
Gerente de Projeto
Analista de Sistemas
Projetista
Analista de Sistemas
de
Tabela 2: Produtos de Trabalho Gerados (resumo)
Legenda:
I – Iniciação
E – Elaboração
C – Construção
T – Transição
G – Gerado
R – Revisado
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-2
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
Plano de iteração
Relatório de Avaliação da Iteração
Termo de homologação
Caso de Teste
Registro de Teste
Plano de Implantação
Manual de Treinamento
Termo de Encerramento do Projeto
Relatórios da Infraestrutura
Visão
Glossário
Modelo de Casos de Uso
Especificações Suplementares
Lista de regras de negócio
Lista de Requisitos Funcionais
Casos de Uso Detalhados
Documento de Arquitetura
Código Fonte
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-3
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-4
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-5
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)
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-6
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-7
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-8
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
- Classes
- Modelo de Design
- Componentes
- Implantação
- Pacotes
- Documento de Arquitetura
Tabela 4: Diagramas da UML e Produtos de Trabalho
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-9
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)
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-10
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)
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3-11
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>
Data: 23/04/2013
Plano de Iteração
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2 /4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - A-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão:<Número_Versão>
Data: 23/04/2013
Plano de Iteração
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - A-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão:<Número_Versão>
Data: 23/04/2013
Plano de Iteração
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
Entrega do Documento de
Data Início
Data Fim
Analista
Visão
Entrega
do
Modelo
de
Analista 1
Casos de Uso visão geral
Entrega do Glossário
<Classificação>
Analista 2
Centro de Desenvolvimento de Sistemas
Página 4 /4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - A-4
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>
Data: 23/04/2013
Relatório de Avaliação da Iteração
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2 / 6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-2
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
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3 / 6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-3
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
RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO
1. INTRODUÇÃO
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Relatório de Avaliação da Iteração
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
<SIGLA DO PROJETO> - <Nome do Projeto>
Relatório de Avaliação da Iteração
Página 5 / 6
Versão: <Número_Versão>
Data: 23/04/2013
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-5
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6 / 6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - B-6
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2 /6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3 /6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
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]
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-4
EB80-MT-78.001
<Classificação>
Centro de Desenvolvimento de Sistemas
<SIGLA DO PROJETO> - <Nome do Projeto>
Página 5 /6
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
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
[Nomeie o tipo [Descreva
Responsabilidades
[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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-5
EB80-MT-78.001
<Classificação>
Centro de Desenvolvimento de Sistemas
<SIGLA DO PROJETO> - <Nome do Projeto>
Página 6 /6
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Visão do Projeto
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6 /6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - C-6
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Glossário
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - D-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Glossário
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - D-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Glossário
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - D-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Glossário
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 5/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - D-5
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Caso de Uso
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - E-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Caso de Uso
SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 MODELO DE CASO DE USO...........................................................................4
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - E-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Caso de Uso
3. PROPÓSITO
Este documento descreve ...
4. MODELO DE CASO DE USO
(Exemplo de Diagrama de Casos de Uso)
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - E-4
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Especificação Suplementar
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Especificação Suplementar
SUMÁRIO
1 INTRODUÇÃO....................................................................................................4
1.1 Objetivo....................................................................................................................... 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 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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Especificação Suplementar
Versão: <Número_Versão>
Data: 23/04/2013
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.
1.3 Definições, Acrônimos e Abreviações
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Especificação Suplementar
Versão: <Número_Versão>
Data: 23/04/2013
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 5/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-5
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Especificação Suplementar
Versão: <Número_Versão>
Data: 23/04/2013
3.1 <Requisito de Confiabilidade Um>
A descrição do requisito.
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>
A descrição do requisito.
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>
A descrição do requisito.
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-6
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Especificação Suplementar
Data: 23/04/2013
6.1 <Restrição de Design Um>
A descrição do requisito.
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 7/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-7
EB80-MT-78.001
SIGLA DO PROJETO> - <Nome do Projeto>
Especificação Suplementar
Versão: <Número_Versão>
Data: 23/04/2013
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 8/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - F-8
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Regras de Negócio
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - G-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Regras de Negócio
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - G-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Regras de Negócio
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>:
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - G-4
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Lista de Requisitos Funcionais
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - H-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Lista de Requisitos Funcionais
SUMÁRIO
1 PROPÓSITO DO DOCUMENTO......................................................................4
2 LISTA DE REQUISITOS FUNCIONAIS .........................................................4
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - H-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Lista de Requisitos Funcionais
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
<Classificação>
Caso de Uso
Centro de Desenvolvimento de Sistemas
Responsável
Página 4/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - H-4
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/7
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/7
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
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,
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/7
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-5
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
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>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6/7
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-6
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Caso de Uso Detalhado
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 7/7
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - I-7
EB80-MT-78.001
ANEXO J
MODELO DE DOCUMENTO DE ARQUITETURA
<SIGLA DO PROJETO>
<Nome do Projeto>
Documento de Arquitetura
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-1
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Documento de Arquitetura
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Documento de Arquitetura
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Documento de Arquitetura
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Documento de Arquitetura
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 5/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-5
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Documento de Arquitetura
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - J-6
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Termo de Homologação
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - K-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Termo de Homologação
SUMÁRIO
1 IDENTIFICAÇÃO DO PROJETO....................................................................4
2 RESPONSÁVEIS.................................................................................................4
3 LISTA DE PRODUTOS.......................................................................................4
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - K-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Termo de Homologação
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
Maj
Papel
Gerente do projeto
OM
CDS
Assinatura
Receptor
Cel
Papel
Coordenador do Projeto
OM
DSM
Assinatura
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
1
2
3
4
<Classificação>
Produto
Documento de Visão
Glossário
Requisitos do sistema
Regras de negócio
Versão
1
1
1
1
Centro de Desenvolvimento de Sistemas
Data da Homologação
Página 4/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - K-4
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Design
Histórico de Revisões
Data
Versão
Descrição
Autor
,
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 2/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - L-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Design
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - L-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Design
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.
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - L-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Modelo de Design
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>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 5/5
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - L-5
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Casos de Teste
Histórico de Revisões
Data
Versão
<Classificação>
Descrição
Centro de Desenvolvimento de Sistemas
Autor
Página 2/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - M-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Casos de Teste
SUMÁRIO
1 <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:.........................4
2 <ID CASO DE TESTE> - <NOME DO CASO DE TESTE>:.........................4
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - M-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Casos de Teste
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.]
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/4
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - M-4
EB80-MT-78.001
ANEXO N
MODELO PLANO DE IMPLANTAÇÃO
<SIGLA DO PROJETO>
<Nome do Projeto>
Plano de Implantação
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-1
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Plano de Implantação
Histórico de Revisões
Data
<dd/mm/aaaa>
<Classificação>
Versão
Descrição
Autor
<x.x>
<detalhes>
<nome>
Centro de Desenvolvimento de Sistemas
Página 2/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Plano de Implantação
SUMÁRIO
1 PROPÓSITO.........................................................................................................4
2 INTRODUÇÃO....................................................................................................4
2.1 Objetivo....................................................................................................................... 4
2.2 Escopo......................................................................................................................... 4
2.3 Definições, Acrônimos e Abreviações........................................................................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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Plano de Implantação
Plano de Implantação
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.>
2.3 Definições, Acrônimos e Abreviações
<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.>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Plano de Implantação
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.>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 5/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-5
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Data: 23/04/2013
Plano de Implantação
5.2
Versão: <Número_Versão>
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.>
A Unidade de Implantação
5.3
<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.>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6/6
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - N-6
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
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Termo de Encerramento de Projeto
Histórico de Revisões
Data
<dd/mm/aaaa>
<Classificação>
Versão
Descrição
Autor
<x.x>
<detalhes>
<nome>
Centro de Desenvolvimento de Sistemas
Página 2/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-2
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Termo de Encerramento de Projeto
Data: 23/04/2013
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
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 3/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-3
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
ersão: <Número_Versão>
Termo de Encerramento de Projeto
Data: 23/04/2013
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>
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 4/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-4
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
ersão: <Número_Versão>
Data: 23/04/2013
Termo de Encerramento de Projeto
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>
Início Realizado
Término Realizado
Duração Realizada
<dd/mm/aaaa>
<dd/mm/aaaa>
<Nro. de dias>
4.3 Prazo Realizado
4.4 Desvio Planejado X Realizado
Desvio % da Primeira Estimativa
< ((duração realizada / duração 1ª
Estimativa) - 1 ) *100 >
<Classificação>
Desvio % da Última Estimativa
< ((duração realizada / duração
última Estimativa) - 1 ) *100 >
Centro de Desenvolvimento de Sistemas
Página 5/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-5
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Termo de Encerramento de Projeto
4.5 Quadro Resumo de Custo
Valor Global PrevistoValor Global Previsto Última
1ª Estimativa
Estimativa
Aprovada
Aprovada
Valor Realizado
Desvio % da Primeira Desvio % da Última
Estimativa
Estimativa
<
((
Valor
realizado
/
Valor realizado / Valor
na
1ª Previsto na última
Previsto
< (( Valor
Estimativa ) - 1 ) *100 estimativa ) - 1 )
>
5.
*100 >
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. >
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 6/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-6
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
ersão: <Número_Versão>
Data: 23/04/2013
Termo de Encerramento de Projeto
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
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-7
EB80-MT-78.001
<SIGLA DO PROJETO> - <Nome do Projeto>
Versão: <Número_Versão>
Data: 23/04/2013
Tede Encerramento de Projeto
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:
<Classificação>
Centro de Desenvolvimento de Sistemas
Página 8/8
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - O-8
EB80-MT-78.001
GLOSSÁRIO
PARTE I - ABREVIATURAS E SIGLAS
D
Abreviaturas/Siglas
DBA
Significado
Administrador de Banco de Dados
I
Abreviaturas/Siglas
IDE
Significado
Ambiente de Desenvolvimento Integrado
M
Abreviaturas/Siglas
MDS
Significado
Metodologia de Desenvolvimento de Software
N
Abreviaturas/Siglas
Significado
Normas para Elaboração, Gerenciamento e
NEGAPEB
Acompanhamento de Projetos no Exército
Brasileiro
R
Abreviaturas/Siglas
RDBMS
Significado
Sistema Gerenciador de Banco de Dados
Relacional
RUP
Processo Unificado da Rational
U
Abreviaturas/Siglas
UML
Significado
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 2
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 3
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.
Separata do Boletim do Exército nº 17, 26 de abril de 2013. - 4
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