MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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;

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

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

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.

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.

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

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

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.