metodologia desenvolvimento software iec5 · ferramentas de apoio, distribuir e acompanhar...

Metodologia de Desenvolviment

IEC –

METODOLOGIA DE DESENVOLVIMENTO DE

Versão Data

1.0 06/03/2017

imento de Software – Versão 1.0

– Instituto Evandro Chagas


SOFTWARE – IEC

Histórico de Revisão do Documento

Autor Descrição da alteração

SOINF/IEC/SVS/MS

Pág. 1 de 42

Instituto Evandro Chagas


Histórico de Revisão do Documento

Descrição da alteração

Versão inicial


1. PROPOSTA DO PROJETO

1.1 DOCUMENTO DE VISÃO DE

1.1.1 Descrição do Problema

1.1.2 Necessidade do Usuário

1.1.3 Características do Produto

1.2 GLOSSÁRIO ................................

1.3 PLANO DE GERENCIAMENTO DE

1.3.1 Introdução ................................

1.3.2 Gerência de Configuração de Software

1.3.3 O Programa de Gerenciamento de Configuração

1.3.4 Marcos ................................

1.3.5 Treinamento e Recursos

1.3.6 Controle de Software de Subcontratados e Fornecedores

2. INICIAÇÃO ................................

2.1 DOCUMENTO DE VISÃO DE

2.1.1 Escopo do Produto

2.1.2 Não Escopo do Produto

2.1.3 Descrição dos Envolvidos

2.1.4 Visão Geral do Produto

2.1.5 Restrições ................................

2.1.6 Referências ................................

2.2 CASO DE DESENVOLVIMENTO

2.2.1 Detalhamento do Caso de Desenvolvimento

2.3 DOCUMENTO DE DEFINIÇÃO

2.3.1 Características do

2.4 DOCUMENTO DE ANÁLISE DE

2.4.1 Dados ................................

2.4.2 Impacto da Solicitação

3. ELABORAÇÃO ................................

3.1 ESPECIFICAÇÃO DE C3.1.1 Descrição do Caso de Uso

3.1.2 Documentos Relacionados

3.1.3 Diagrama de Caso de Uso

3.1.4 Atores ................................

3.1.5 Pré-Condições ................................

3.1.6 Fluxos De Eventos

3.1.7 Pós-Condições ................................

3.1.8 Pontos de Extensão

3.1.9 Pontos de Inclusão

3.1.10 Observações ................................

3.1.11 Especificação de Tela

3.2 MODELO DE CASO DE

3.2.1 Modelo de Casos de Uso

3.2.2 Documento de Regras

3.2.3 Lista de Mensagem

3.2.4 Documento de Arquitetura de Software

4. CONSTRUÇÃO ................................

4.1 PLANO DE TESTE................................

4.1.1 Introdução ................................

4.1.2 Estágios de Teste


SUMÁRIO

PROPOSTA DO PROJETO ................................................................................................

ISÃO DE NEGÓCIO ................................................................

Descrição do Problema ................................................................................................

Necessidade do Usuário ................................................................................................

Características do Produto................................................................................................

................................................................................................................................

ERENCIAMENTO DE CONFIGURAÇÃO ................................................................

................................................................................................

Gerência de Configuração de Software ................................................................

O Programa de Gerenciamento de Configuração ................................................................

................................................................................................................................

Treinamento e Recursos ................................................................................................

Controle de Software de Subcontratados e Fornecedores ................................

................................................................................................................................

ISÃO DE SISTEMA ................................................................

Escopo do Produto ................................................................................................

Não Escopo do Produto ................................................................................................

Descrição dos Envolvidos ................................................................................................

Visão Geral do Produto ................................................................................................

................................................................................................................................

................................................................................................

ESENVOLVIMENTO ................................................................................................

Detalhamento do Caso de Desenvolvimento ................................................................

EFINIÇÃO ARQUITETURAL ................................................................

Características do Produto................................................................................................

NÁLISE DE IMPACTO ................................................................

................................................................................................................................

Impacto da Solicitação................................................................................................

................................................................................................

CASO DE USO ................................................................

Descrição do Caso de Uso ................................................................................................

Documentos Relacionados ................................................................................................

Diagrama de Caso de Uso ................................................................................................

................................................................................................................................

................................................................................................

Fluxos De Eventos ................................................................................................

................................................................................................

Pontos de Extensão ................................................................................................

Pontos de Inclusão ................................................................................................

................................................................................................

Especificação de Tela ................................................................................................

ASO DE USO ................................................................................................

Modelo de Casos de Uso ................................................................................................

Documento de Regras ................................................................................................

Lista de Mensagem ................................................................................................

Documento de Arquitetura de Software ................................................................

................................................................................................

................................................................................................

................................................................................................

................................................................................................

Pág. 2 de 42

................................................ 4

.................................................................. 4 .................................................... 4 ................................................... 4

............................................... 5 .......................................... 6

............................................... 7 ....................................................................... 7

........................................................... 9 .......................................... 12

........................................... 14 ................................................ 14

............................................................. 15

..........................................15

................................................................. 15 ......................................................... 15

................................................. 15 ............................................... 15

.................................................. 16 ....................................... 16

.................................................................... 16 ............................................ 17

................................................. 18 .................................................... 21

............................................. 22 ............................................................. 24

............................................. 24 ................................................... 24

...................................................................25

.................................................................... 25 .............................................. 25 ............................................. 25

.............................................. 25 ............................................ 25

................................................................ 26 .......................................................... 26

................................................................ 27 ........................................................ 27

......................................................... 28 .............................................................. 28

................................................ 29

................................................ 30

................................................ 30 ................................................... 30

........................................................ 32

........................................................ 32

...................................................................38

................................................................ 38 ..................................................................... 38

........................................................... 38


4.1.3 Tipos de Testes ................................

4.1.4 Recursos Necessários

4.1.5 Riscos e Restrições

4.1.6 Produtos Gerados

5. DIVERSOS ................................

5.1 ATA DE REUNIÃO ................................

5.2 LISTA DE PARTICIPANTES

5.3 NOTA TÉCNICA ................................

5.4 TERMO DE RECEBIMENTO

5.5 TERMO DE RECEBIMENTO


................................................................................................

Recursos Necessários ................................................................................................

Riscos e Restrições ................................................................................................

Produtos Gerados ................................................................................................

................................................................................................................................

................................................................................................

ARTICIPANTES................................................................................................

................................................................................................

ECEBIMENTO PROVISÓRIO ................................................................

ECEBIMENTO DEFINITIVO ................................................................

Pág. 3 de 42

............................................................... 38 ..................................................... 38

......................................................... 38 .......................................................... 39

...........................................39

................................................................ 39 ................................................... 40

................................................................... 41 ............................................................ 42

.............................................................. 42


1. PROPOSTA DO PROJETO

1.1 Documento de Visão d

Gestor do Projeto[Nome[E-mail

[Telefone

Este documento tem como objetivo estabelecer uma visão preliminar e as

principais características do sistema descrevendo informações que embasem o processo de aprovação do projeto

1.1.1 Descrição do Problema

Gatilho do problema

[Descreva o que iniciou a

Problema gerado [Descreva o problema gerado]

Quem é afetado [Descreva quem é afetado indireta e diretamente pelo problema.]

Solução adotada [Descreva qual a soluçtarefa do problema

Solução sistêmica [Descreva a(s) solução(ões) sistêmica(s) que pode resolver o problema.]

1.1.2 Necessidade do Usuário

Necessidade

[Necessidade do Usuário]




PROPOSTA DO PROJETO

Documento de Visão de Negócio

[Sigla] – [Nome do Projeto]

Gestor do Projeto Gerente de ProjetoNome] [Nome

mail] [E-Telefone] [Telefone

Objetivo deste Documento

Este documento tem como objetivo estabelecer uma visão preliminar e as principais características do sistema descrevendo informações que embasem o processo de aprovação do projeto.

Descrição do Problema

[Descreva o que iniciou a necessidade de um novo sistema]

Descreva o problema gerado]

[Descreva quem é afetado indireta e diretamente pelo problema.]

[Descreva qual a solução adota atualmente para executar a tarefa do problema gerado]

[Descreva a(s) solução(ões) sistêmica(s) que pode resolver o problema.]

Necessidade do Usuário

Situação Atual

[Necessidade do Usuário] [Situação Atual. Caso seja algo novo colocar “N/A”.



Pág. 4 de 42

Gerente de Projeto Nome]

-mail] Telefone]

Este documento tem como objetivo estabelecer uma visão preliminar e as principais características do sistema descrevendo informações que embasem o

necessidade de um novo sistema]

[Descreva quem é afetado indireta e diretamente pelo

ão adota atualmente para executar a

[Descreva a(s) solução(ões) sistêmica(s) que pode resolver o

Solução Proposta

[Solução proposta para atender à necessidade]





1.1.3.1 Características Funcionais

1.1.3.1.1 [

[Descrição da Característica]

1.1.3.1.2 [Nome da Característica]


1.1.3.2 Características N

1.1.3.2.1 [Nome da


1.1.3.2.2 [


*Observação: É indispensável a leitura do Guia de Preenchimento para a descrição dos Requisitos Não-Funcionais

Responsável Técnico [Nome] Gestor do Projeto [Nome]


Características do Produto

Características Funcionais

[Nome da Característica]




Características Não-Funcionais





Observação: É indispensável a leitura do Guia de Preenchimento para a descrição Funcionais.

Aprovação do Documento

Data

Assinatura

Data

Assinatura

Pág. 5 de 42

Observação: É indispensável a leitura do Guia de Preenchimento para a descrição


1.2 Glossário

Este documento tem como objetivo registrar termos e definições específicos no domínio do sistema, explicando termos que podem ser descrições dos documentos do projeto.

Termo



Este documento tem como objetivo registrar termos e definições específicos no explicando termos que podem ser desconhecidos do leitor nas

descrições dos documentos do projeto.

Descrição

Pág. 6 de 42

Este documento tem como objetivo registrar termos e definições específicos no desconhecidos do leitor nas


1.3 Plano de Gerenciamento de Configuração

Projeto [SiglaGerente de Projetos [NomeFábrica de Software [Sigla

1.3.1 Introdução

O Plano de Gerenciamento de Configuração descreve todas as atividades do

Gerenciamento de Controle de Configuração e Mudança que serão executadas

durante o ciclo de vida do produto. Suas atividades envolvem identificar a

configuração do software, manter s

sistematicamente as mudanças.

1.3.1.1 Objetivos

O objetivo deste documento é criar um padrão a ser seguido por todos os

membros da equipe com o intuito de garantir o maior controle do produto no decorrer

do projeto.

Para que isso aconteça serão detalhados os recursos necessários (equipes,

ferramentas e ambiente), as responsabilidades atribuídas e o cronograma de

atividades.

1.3.1.2 Escopo

Este Plano de Gerenciamento de Configuração é destinados para todos os

integrantes da Fábrica de Software

controle e gerenciamento da configuração do projeto

1.3.1.3 Definições, Acrônimos e Abreviações

Termo

RUP Rational Unified Processda IBM.

MDS Metodologia de Desenvolvimento de Software.

Baseline

Linha de base. Conjunto de versões de itens de configuração comprovadamente estáveis. Uma no desenvolvimento da próxima fase do artefato e tem suas mudan

1.3.1.4 Referências

• Template do Plano de Gerenciamento de Configuração, RUP 7.0, IBM.

• Plano do Projeto


Plano de Gerenciamento de Configuração

[Sigla – Nome] [Nome] [Sigla – Nome]




configuração do software, manter sua integridade durante o projeto e controlar

sistematicamente as mudanças.

Objetivos





Escopo


brica de Software <sigla - nome da fábrica>

controle e gerenciamento da configuração do projeto <sigla – nome do projeto>.

Definições, Acrônimos e Abreviações

Descrição Rational Unified Process. Processo de engenharia de da IBM. Metodologia de Desenvolvimento de Software.Linha de base. Conjunto de versões de itens de configuração comprovadamente estáveis. Uma baseline é usada como base no desenvolvimento da próxima fase do artefato e tem suas mudanças controladas por um processo formal.

Referências

do Plano de Gerenciamento de Configuração, RUP 7.0, IBM.

Plano do Projeto <criar link para o plano do projeto>

Pág. 7 de 42




ua integridade durante o projeto e controlar






nome da fábrica>, e abrange todo o

nome do projeto>.

. Processo de engenharia de software

Metodologia de Desenvolvimento de Software. Linha de base. Conjunto de versões de itens de configuração

é usada como base no desenvolvimento da próxima fase do artefato e tem suas

ças controladas por um processo formal.

do Plano de Gerenciamento de Configuração, RUP 7.0, IBM.


• Cronograma do Projeto

1.3.1.5 Evolução

O Plano de Gerenciamento de Configuração deve ser mantido atualizado para

refletir o planejamento corrente. Dessa forma, as seguintes situações representam

gatilhos para atualização do plano e nova aprovação deste documento:

• Mudança nos itens de configuraç

• Mudança na identificação dos arquivos;

• Mudança na identificação das

• Mudança no padrão de versionamento;

• Gerência de Configuração de Software


Cronograma do Projeto <criar link para o cronograma do projeto>

Evolução




Mudança nos itens de configuração;

Mudança na identificação dos arquivos;

Mudança na identificação das Tags/Branches;

Mudança no padrão de versionamento;

Gerência de Configuração de Software

Pág. 8 de 42

<criar link para o cronograma do projeto>





1.3.2 Gerência de Configuração de Software

1.3.2.1 Organização, Responsabilidades

Funções

Gerente de Projeto

Responsável por solicitar a criação dos ambientes dos projetos, geração de linha de base, autorizarMudança, acompanhar resolução de defeitos de GCS, apoiar na elaboração/adaptação do Plano de Gerência de Configuração, validar adaptações no repositório e demais ferramentas de apoio, distribuir e acompanhar execução das tarefas que envolvarepositório, realizar análises de impacto com o apoio do CCM e apoiar a execução do processo de GCS pela equipe do projeto.

Gerente de Configuração

Responsável por elaborar e manter as Políticas de Gerenciamento de divulgar os procedimentos e definir o uso das respectivas ferramentas, apoiar a equipe do projeto relativo à conformidade das linhas de base do projeto e produto, com as regras e os procedimentos de gestão de configuraçã

Analista de Configuração

Responsável por criar/adaptar e auditar a correta execução do Processo de GCS pelos Colaboradores da Equipe do Projeto, realizar verificações nos artefatos em relação aos critérios de GCS, gerar comunicar a equipe do projeto e Envolvidos Interessados em relação às entregas efetuadas, criação de de GCS e liberação de artefatos para atualização após aprovação de Requisição de Mudança.

Comitê de Mudanças

Equipe multidisciplinar envolvidos no projeto, Gestores, Coordenadores e Gerentes com o objetivo de avaliar o impacto de mudanças.

Colaborador da Equipe

Profissionais envolvidos na execução do projeto, sob coordenação do Gerente de Projeto, que farão urepositório e demais ferramentas de apoio que deverão obedecer ao processo e os critérios de qualidade previstos no Plano de GCS e corrigir defeitos apontados nas revisões de GCS.

Envolvidos Interessados

Integrantes da equipe de execução do projeto,projeto, patrocinadores, usuários e demais interessados elencados pelo Gerente do Projeto.

Banco de Dados Equipe responsável pela configuração e disponibilização dos diversos bancodesenvolvimento, testes, homologação e produção.

Teste Equipe responsável pela execução dos testes planejados para cada versão do sistema e registro dos defeitos em não conformidades identificadas.


Gerência de Configuração de Software

Organização, Responsabilidades e Interfaces

Responsabilidades Responsável por solicitar a criação dos ambientes dos projetos, geração de linha de base, autorizarMudança, acompanhar resolução de defeitos de GCS, apoiar na elaboração/adaptação do Plano de Gerência de Configuração, validar adaptações no repositório e demais ferramentas de apoio, distribuir e acompanhar execução das tarefas que envolvam criação/atualização de artefatos no repositório, realizar análises de impacto com o apoio do CCM e apoiar a execução do processo de GCS pela equipe do projeto. Responsável por elaborar e manter as Políticas de Gerenciamento de Configuração, desenvolver, manter e divulgar os procedimentos e definir o uso das respectivas ferramentas, apoiar a equipe do projeto relativo à conformidade das linhas de base do projeto e produto, com as regras e os procedimentos de gestão de configuraçãResponsável por criar/adaptar e auditar a correta execução do Processo de GCS pelos Colaboradores da Equipe do Projeto, realizar verificações nos artefatos em relação aos critérios de GCS, gerar baselines, gerenciar comunicar a equipe do projeto e Envolvidos Interessados em relação às entregas efetuadas, criação de de GCS e liberação de artefatos para atualização após aprovação de Requisição de Mudança. Equipe multidisciplinar composta por colaboradores envolvidos no projeto, Gestores, Coordenadores e Gerentes com o objetivo de avaliar o impacto de mudanças.Profissionais envolvidos na execução do projeto, sob coordenação do Gerente de Projeto, que farão urepositório e demais ferramentas de apoio que deverão obedecer ao processo e os critérios de qualidade previstos no Plano de GCS e corrigir defeitos apontados nas revisões de GCS. Integrantes da equipe de execução do projeto,projeto, patrocinadores, usuários e demais interessados elencados pelo Gerente do Projeto. Equipe responsável pela configuração e disponibilização dos diversos banco de dados necessários para o desenvolvimento, testes, homologação e produção. Equipe responsável pela execução dos testes planejados para cada versão do sistema e registro dos defeitos em não conformidades identificadas.

Pág. 9 de 42

Interfaces

Responsável por solicitar a criação dos ambientes dos projetos, geração de linha de base, autorizar Requisições de Mudança, acompanhar resolução de defeitos de GCS, apoiar na elaboração/adaptação do Plano de Gerência de Configuração, validar adaptações no repositório e demais ferramentas de apoio, distribuir e acompanhar execução das

m criação/atualização de artefatos no repositório, realizar análises de impacto com o apoio do CCM e apoiar a execução do processo de GCS pela equipe do

Responsável por elaborar e manter as Políticas de Configuração, desenvolver, manter e

divulgar os procedimentos e definir o uso das respectivas ferramentas, apoiar a equipe do projeto relativo à conformidade das linhas de base do projeto e produto, com as regras e os procedimentos de gestão de configuração. Responsável por criar/adaptar e auditar a correta execução do Processo de GCS pelos Colaboradores da Equipe do Projeto, realizar verificações nos artefatos em relação aos

, gerenciar branches e comunicar a equipe do projeto e Envolvidos Interessados em relação às entregas efetuadas, criação de branches, defeitos de GCS e liberação de artefatos para atualização após

composta por colaboradores envolvidos no projeto, Gestores, Coordenadores e Gerentes com o objetivo de avaliar o impacto de mudanças. Profissionais envolvidos na execução do projeto, sob coordenação do Gerente de Projeto, que farão uso do repositório e demais ferramentas de apoio que deverão obedecer ao processo e os critérios de qualidade previstos no Plano de GCS e corrigir defeitos apontados nas revisões de

Integrantes da equipe de execução do projeto, Gestor do projeto, patrocinadores, usuários e demais interessados

Equipe responsável pela configuração e disponibilização dos de dados necessários para o

desenvolvimento, testes, homologação e produção. Equipe responsável pela execução dos testes planejados para cada versão do sistema e registro dos defeitos em não

Metodologia de Desenvolvimento

Infraestrutura

Equipe respprojeto, rede e comunicação dos diversos ambientes. Trabalha em parceria com a Equipe de GCS com o objetivo de atender às demandas do projeto.

1.3.2.2 Ferramentas, Ambientes

1.3.2.2.1

Termo Versão

Gogs 0.9.128.0131

Git-SCM 2.10.2

OTRS 5

Pencil Project 2.7.2

GanttProject 2.8.2

SonarQube 6.2

Nexus 2.14.2

Jenkins 2.32.2

1.3.2.2.2

O ambiente que será entregue a equipe de desenvolvimento, deverá ser

mantido pela equipe de arquitetura, através de Virtual Machines que seguiram os

padrões dos ambientes mantidos pela equipe de infraestrutura. As ferramentas de

desenvolvimento “IDEs” serã

mesma seja uma ferramenta de Software Livre, tais como Atom, Eclipse, NetBeans

outros.

1.3.2.3 Infraestrutura

1.3.2.3.1

É o ambiente que servira como integração dos códigos fontes que estão

sendo liberados pela equipe de desenvolvimento.

mento de Software – Versão 1.0

Equipe responsável pela infraestrutura computacional do projeto, rede e comunicação dos diversos ambientes. Trabalha em parceria com a Equipe de GCS com o objetivo de atender às demandas do projeto.

Ferramentas, Ambientes e Infraestrutura

1.3.2.2.1 Ferramentas

Versão Descrição

0.9.128.0131 Ferramenta de administração dos repositórios e usuários GIT, serviço disponibilizado

2.10.2 Ferramenta de controle de versãodisponibilizado Internamente

Ferramenta de Controle de Demandas utilizada pela equipe de desenvolvimento, serviço disponibilizado internamente

2.7.2 Ferramenta para diagramar e documentar processos, download disponibilizado no endereço: http://pencil.evolus.vn/

.2

Ferramenta para elaboração do cronograma do projeto, bem como o seu planejamento e acompanhamento, download disponibilizado no endereço: https://sourceforge.net/projects/ganttproject/

6.2 Ferramenta para análise de qualidade do código do projeto, serviço disponibilizado internamente

2.14.2-01 Ferramenta para gestão de bibliotecas Java, serviço disponibilizado internamente

2.32.2 Ferramenta para Integração Contínua, serviço disponibilizado internamente

1.3.2.2.2 Ambientes




desenvolvimento “IDEs” serão de livre escolha do desenvolvedor, desde que a

mesma seja uma ferramenta de Software Livre, tais como Atom, Eclipse, NetBeans

Infraestrutura

1.3.2.3.1 Desenvolvimento


la equipe de desenvolvimento.

Pág. 10 de 42

onsável pela infraestrutura computacional do projeto, rede e comunicação dos diversos ambientes. Trabalha em parceria com a Equipe de GCS com o objetivo

dos repositórios e , serviço disponibilizado Internamente

Ferramenta de controle de versão, serviço

Ferramenta de Controle de Demandas utilizada pela equipe de desenvolvimento, serviço

Ferramenta para diagramar e documentar processos, download disponibilizado no endereço:

Ferramenta para elaboração do cronograma do projeto, bem como o seu planejamento e acompanhamento, download disponibilizado no

https://sourceforge.net/projects/ganttproject/ Ferramenta para análise de qualidade do código do projeto, serviço disponibilizado internamente Ferramenta para gestão de bibliotecas Java, serviço disponibilizado internamente Ferramenta para Integração Contínua, serviço




o de livre escolha do desenvolvedor, desde que a

mesma seja uma ferramenta de Software Livre, tais como Atom, Eclipse, NetBeans,



Tipo

DNS http://projeto.desenvolvimento.iec.gov.brLoad Balance IP do servidorNode 01 IP do servidor / Nome servidorNode 02 IP do servidor / Nome Servidor NFS IP do servidor / Nome servidorCaminho Físico /pasta_servidorSMTP smtp.aplicacao.iecBanco de Dados

ORACLE

WebService IP : PortaRedis IP : Porta

1.3.2.3.2

É o ambiente que servirá como base para

gestora dos códigos fontes e requisitos do sistema.

Tipo

DNS http://projeto.desenvolvimento.iec.gov.brLoad Balance IP do servidorNode 01 IP do Node 02 IP do servidor / Nome servidorServidor NFS IP do servidor / Nome servidorCaminho Físico /pasta_servidor/projetoSMTP smtp.aplicacao.saude.Banco de Dados

ORACLE


1.3.2.3.3

É o ambiente que servirá como treinamento de um

área gestora. Este ambiente é controlado e mantido de acordo com as políticas da

GMUD.

Tipo DNS http://projeto.desenvolvimento.iec.gov.brLoad Balance IP do servidorNode 01 IP do servidor / Nome servidorNode 02 IP do servidor / Nome servidorServidor NFS IP do servidor / Nome servidorCaminho Físico /pasta_servidor/projetoSMTP smtp.aplicacao.iecBanco de Dados

ORACLE


Descrição http://projeto.desenvolvimento.iec.gov.br IP do servidor IP do servidor / Nome servidor IP do servidor / Nome servidor IP do servidor / Nome servidor /pasta_servidor/projeto smtp.aplicacao.iec.gov.br ORACLE - IP : Porta

IP : Porta IP : Porta

1.3.2.3.2 Homologação

É o ambiente que servirá como base para os testes e homologação pela área

gestora dos códigos fontes e requisitos do sistema.

Descrição http://projeto.desenvolvimento.iec.gov.br IP do servidor IP do servidor / Nome servidor IP do servidor / Nome servidor IP do servidor / Nome servidor /pasta_servidor/projeto smtp.aplicacao.saude.iec.gov ORACLE - IP : Porta

IP : Porta Porta

1.3.2.3.3 Treinamento

É o ambiente que servirá como treinamento de um release


Descrição http://projeto.desenvolvimento.iec.gov.br IP do servidor IP do servidor / Nome servidor IP do servidor / Nome servidor IP do servidor / Nome servidor /pasta_servidor/projeto

aplicacao.iec.gov.br ORACLE - IP : Porta

Pág. 11 de 42

os testes e homologação pela área

release de produção, pela




1.3.2.3.4

É o ambiente de produção de um

mantido de acordo com as políticas da GMUD.

Tipo

DNS http://projeto.desenvolvimento.iec.gov.brLoad Balance IP do servidorNode 01 IP do servidor / Nome servidorNode 02 IP do servidor / Nome servidorServidor NFS IP do servidor / Nome servidorCaminho Físico /pasta_servidor/projetoSMTP smtp.aplicacao.iecBanco de Dados

ORACLE


1.3.3 O Programa

1.3.3.1 Identificação d

1.3.3.1.1

O detalhamento para a convenção para rotular os artefatos na estrutura de

pastas do produto, será detalhada no documento PAP do projeto, que estará

disponível no diretório de Gerencia de Configuração. Abaixo segue uma tabela com

os acrônimos e significados.

Acrônimos ARQ Documento de ArquiteturaIMP Documento de ImplantaçãoPGC Plano de Gerenciamento de ConfiguraçãoPAP Documento de Permissões de Pastas e Acessos por PerfilCBL Documento de Controle de NEG Documento de NegocioPPR Plano do ProjetoPPF Planilha de Contagem de Ponto de FunçãoPNE Documento de Processo de NegócioCRT Checklist de Revisão TécnicaRRT Relatório de Revisão TécnicaPLT Plano de TestePRT Plano de Resultado de TesteRTE Roteiros de Teste



1.3.2.3.4 Produção

É o ambiente de produção de um release. Este ambiente é controlado e

mantido de acordo com as políticas da GMUD.

Descrição http://projeto.desenvolvimento.iec.gov.br IP do servidor IP do servidor / Nome servidor IP do servidor / Nome servidor IP do servidor / Nome servidor /pasta_servidor/projeto smtp.aplicacao.iec.gov.br ORACLE - IP : Porta


O Programa de Gerenciamento de Configuração

Identificação da Configuração

1.3.3.1.1 Métodos de Identificação

detalhamento para a convenção para rotular os artefatos na estrutura de



os acrônimos e significados.

Significado Documento de Arquitetura Documento de Implantação Plano de Gerenciamento de Configuração Documento de Permissões de Pastas e Acessos por PerfilDocumento de Controle de BaseLines Documento de Negocio Plano do Projeto Planilha de Contagem de Ponto de Função Documento de Processo de Negócio Checklist de Revisão Técnica Relatório de Revisão Técnica Plano de Teste Plano de Resultado de Teste Roteiros de Teste

Pág. 12 de 42

. Este ambiente é controlado e

detalhamento para a convenção para rotular os artefatos na estrutura de



Documento de Permissões de Pastas e Acessos por Perfil


EUC Especificação de Caso de Uso

1.3.3.1.2

As baselines serão definidas a cada mudança de fase do projeto, e uma de

encerramento.

Fase

Fase 1 Documento de ArquiteturaDocumento de ImplantaçãoPlano de Gerenciamento de

Fase 2 Documento de Permissões de Pastas e Acessos por PerfilDocumento de Controle de Documento de Negocio

Fase 3 Plano do ProjetoPlanilha de Contagem de Ponto de FunçãoDocumento de Processo de Negócio

Fase 4 ChecklistRelatório de Revisão TécnicaPlano de Teste

Encerramento Todos os Itens de configuração gerados nas fases anterioresTermo de encerramento

1.3.3.1.3

O detalhamento da estrutura de diretórios do repositório, será

documento PAP do projeto, que estará disponível na pasta de Gerencia de

Configuração.

1.3.3.2 Controle de Configuração e

1.3.3.2.1

[Descreva o processo pelo qual os problemas e as mudanças são

submetidos, revisados e

1.3.3.2.2

[Descreva os membros do CCB e os procedimentos para processar

solicitações de mudança e aprovações a serem seguidos pelo CCB.]

1.3.3.3 Estimativa do Status de Configuração

1.3.3.3.1

[Descreva as políticas de retenção e os planos de backup, erros irreversíveis

e recuperação. Descreva também como a mídia deve ser mantida

tipo de mídia e formato.


Especificação de Caso de Uso

1.3.3.1.2 Baselines do Projeto


Itens de ConfiguraçãoDocumento de Arquitetura Documento de Implantação Plano de Gerenciamento de Configuração Documento de Permissões de Pastas e Acessos por PerfilDocumento de Controle de BaseLines Documento de Negocio Plano do Projeto Planilha de Contagem de Ponto de Função Documento de Processo de Negócio Checklist de Revisão Técnica Relatório de Revisão Técnica Plano de Teste Todos os Itens de configuração gerados nas fases anterioresTermo de encerramento

1.3.3.1.3 Estrutura do Repositório

O detalhamento da estrutura de diretórios do repositório, será


Controle de Configuração e Mudança

1.3.3.2.1 Processo de Solicitações de Mudança


submetidos, revisados e dispostos.]

1.3.3.2.2 Comitê de Controle de Mudança (CCB)



Estimativa do Status de Configuração

1.3.3.3.1 Processo de Armazenamento e Liberação do


e recuperação. Descreva também como a mídia deve ser mantida

Pág. 13 de 42


Itens de Configuração

Documento de Permissões de Pastas e Acessos por Perfil

Todos os Itens de configuração gerados nas fases anteriores

O detalhamento da estrutura de diretórios do repositório, será detalhada no





e Liberação do Projeto


e recuperação. Descreva também como a mídia deve ser mantida — on-line, off-line,


O processo de liberação descreve o conteúdo do release, a quem

destina e se há quaisquer problemas conhecidos ou instruções de instalação.]

1.3.3.3.2

[Descreva o conteúdo, o formato e a finalidade dos relatórios e auditorias de

configuração solicitados.

Os relatórios são usados para avaliar a “qua

fase do ciclo de vida do projeto ou produto. Os relatórios sobre defeitos com base

em solicitações de mudança podem fornecer alguns indicadores de qualidade

proveitosos e, dessa forma, alertar a administração e os desenvolved

determinadas áreas prioritárias do desenvolvimento. Geralmente os defeitos são

classificados por prioridade (alta, média e baixa) e podem ser reportados com base

nos seguintes aspectos:

• Vencimento (Relatórios Baseados em Períodos): Há quanto temp

de diversos tipos estão pendentes? Qual é o “tempo de retardo’’ entre o

momento em que são encontrados defeitos no ciclo de vida e quando eles

são corrigidos?

• Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos

nas diversas categorias por proprietário, prioridade ou estado de correção?

Tendência (Relatórios Relacionados a Períodos e Contagens): Qual é o

número acumulado de defeitos encontrados e corrigidos no decorrer do tempo? Qual

é a classificação dos defeitos detectados

qualidade” em termos de defeitos pendentes em comparação com defeitos

corrigidos? Qual é a média de tempo de correção de um defeito?]

1.3.4 Marcos

[Identifique os marcos internos e do fornecedor relacionados ao esforço de

GC do projeto ou produto. Esta seção inclui detalhes sobre quando o Plano de

Gestão de Configuração deve ser atualizado.]

1.3.5 Treinamento e

[Descreva as ferramentas de software, pessoal e treinamento requerido para

implementar e especificar as atividades da


O processo de liberação descreve o conteúdo do release, a quem


1.3.3.3.2 Relatórios e Auditorias


configuração solicitados.

Os relatórios são usados para avaliar a “qualidade do produto” em qualquer



proveitosos e, dessa forma, alertar a administração e os desenvolved



Vencimento (Relatórios Baseados em Períodos): Há quanto temp



Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos

categorias por proprietário, prioridade ou estado de correção?



é a classificação dos defeitos detectados e corrigidos? Qual é a “lacuna de




projeto ou produto. Esta seção inclui detalhes sobre quando o Plano de

figuração deve ser atualizado.]

Treinamento e Recursos

Descreva as ferramentas de software, pessoal e treinamento requerido para

implementar e especificar as atividades da gerência de configuração. ]

Pág. 14 de 42

O processo de liberação descreve o conteúdo do release, a quem ele se



lidade do produto” em qualquer



proveitosos e, dessa forma, alertar a administração e os desenvolvedores para



Vencimento (Relatórios Baseados em Períodos): Há quanto tempo defeitos



Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos

categorias por proprietário, prioridade ou estado de correção?



e corrigidos? Qual é a “lacuna de




projeto ou produto. Esta seção inclui detalhes sobre quando o Plano de

Descreva as ferramentas de software, pessoal e treinamento requerido para

gerência de configuração. ]


1.3.6 Controle de Software de Subcontratados e Fornecedores

[Descreva como o desenvolvimento de software externo ao ambiente do

projeto será incorporado. Geralmente aplicado em processos

softwares. ]

2. INICIAÇÃO

2.1 Documento de Visão de Sistema


[Telefone

Este documento tem como objetivo estabelecer uma visão de alto nível para

requisitos técnicos mais detalhados. Nele serão feitas adaptações necessárias ao longo do projeto para que as necessárias para que as necessidades sejam atendidas.

2.1.1 Escopo do Produto

[Descreva aqui o escopo do produto]

2.1.2 Não Escopo do Produto

[Descreva

2.1.3 Descrição dos Envolvidos

2.1.3.1

Nome

[Nome do Gestor]

2.1.3.2

Nome

[Nome dos usuários]


Controle de Software de Subcontratados e Fornecedores


projeto será incorporado. Geralmente aplicado em processos de internalizações de

Documento de Visão de Sistema





Este documento tem como objetivo estabelecer uma visão de alto nível para requisitos técnicos mais detalhados. Nele serão feitas adaptações necessárias ao longo do projeto para que as necessárias para que as necessidades sejam

Escopo do Produto

[Descreva aqui o escopo do produto]

Não Escopo do Produto

[Descreva aqui o não escopo do produto]

Descrição dos Envolvidos

2.1.3.1 Resumo dos Gestores

Responsabilidades

[Descrição das responsabilidades do gestor]

2.1.3.2 Resumo dos Usuários

Descrição Responsabilidades

[Descrição do usuário] [Responsabilidades do usuário]

Pág. 15 de 42

Controle de Software de Subcontratados e Fornecedores


de internalizações de


-mail] Telefone]

Este documento tem como objetivo estabelecer uma visão de alto nível para os requisitos técnicos mais detalhados. Nele serão feitas adaptações necessárias ao longo do projeto para que as necessárias para que as necessidades sejam

Responsabilidades

[Descrição das responsabilidades do gestor]

Responsabilidades

[Responsabilidades do usuário]


2.1.4 Visão Geral do Produto

2.1.4.1

RF001

[Descrição Detalhada do Requisito]

RF002

[Descrição Detalhada do Requisito

2.1.4.2

RNF001


RNF002


2.1.5 Restrições

[Descrever aqui as restrições que sejam impostas ao sistema ou ao

processo de desenvolvimento.]

2.1.6 Referências

[Descrever os docu

documento de visão.]


Visão Geral do Produto

2.1.4.1 Requisitos Funcionais

RF001 - [Nome do Requisito]


RF002 - [Nome do Requisito]


2.1.4.2 Requisitos não Funcionais

RNF001 - [Nome do Requisito]


RNF002 - [Nome do Requisito]


Restrições


processo de desenvolvimento.]

Referências

[Descrever os documentos que serviram de subsídio para a criação do

documento de visão.]

Pág. 16 de 42


mentos que serviram de subsídio para a criação do


2.2 Caso de Desenvolvimento


[Telefone

Este documento tem como objetivo descrever os desvios do processo.

Declarando especificamente qual parte de cada modelo foram escolhidas para serem usadas no projeto.


Caso de Desenvolvimento





Este documento tem como objetivo descrever os desvios do processo. Declarando especificamente qual parte de cada modelo foram escolhidas para

usadas no projeto.

Pág. 17 de 42


-mail] Telefone]

Este documento tem como objetivo descrever os desvios do processo. Declarando especificamente qual parte de cada modelo foram escolhidas para

2.2.1 Detalhamento do Caso de Desenvolvimento

2.2.1.1 Disciplinas X Artefatos

2.2.1.1.1 Modelagem De Negócios

Artefatos Como Usar

I E C T Doc. de Visão de Negócio

Checklist de Negócio Diagrama de Processo

2.2.1.1.2 Requisitos

Artefatos Como Usar

I E C T Glossário Doc. de Visão de Sistema

Modelo de Caso de Uso Documento de Regras Especificação de Caso de Uso

Lista de Mensagem Matriz de Rastreabilidade

Checklist de Requisitos

2.2.1.1.3 Analise e Design

Artefatos Como Usar

I E C T Documento de Definição

Metodologia de Desenvolvimento de Software – Versão 1.0

Detalhamento do Caso de Desenvolvimento

Modelagem De Negócios

Detalhes da revisão Ferramentas


Analise e Design


Versão 1.0 Pág. 18 de 42

Templates

Templates

Templates

Arquitetural Documento de Arquitetura de Software

2.2.1.1.4 Implementação

Artefatos Como Usar

I E C T Protótipo Modelo de Dados Código Fonte

2.2.1.1.5 Teste

Artefatos Como Usar I E C T

Plano de Teste Roteiro de Teste Planilha de Resultado de Teste

2.2.1.1.6 Implantação

Artefatos Como Usar

I E C T Plano de Implantação

2.2.1.1.7 Configuração e Gerenciamento de Mudança

Artefatos Como Usar

I E C T Plano de Gerenciamento de Configuração

Controle de Baseline e


Implementação




Configuração e Gerenciamento de Mudança



Templates

Templates

Templates

Templates

Branches

2.2.1.1.8 Gerenciamento de Projeto

Artefatos Como Usar

I E C T Plano de Projeto Caso de Desenvolvimento

2.2.1.1.9 Artefatos não utilizados

Artefatos

Gerente de Projetos [Nome]


Gerenciamento de Projeto


Artefatos não utilizados

Motivo


Data

Assinatura


Templates


2.3 Documento de Definição Arquitetural


[Telefone

Este documento tem como objetivo mapear um conjunto consistente de

estratégias arquiteturais. Seu escopo engloba a definição das características das visões arquiteturais das soluções de estratégias candidatas e os critérios que analisados posteriormente para seleção da melhor alternativa.


Documento de Definição Arquitetural





Este documento tem como objetivo mapear um conjunto consistente de estratégias arquiteturais. Seu escopo engloba a definição das características das visões arquiteturais das soluções de estratégias candidatas e os critérios que analisados posteriormente para seleção da melhor alternativa.

Pág. 21 de 42


-mail] Telefone]

Este documento tem como objetivo mapear um conjunto consistente de estratégias arquiteturais. Seu escopo engloba a definição das características das visões arquiteturais das soluções de estratégias candidatas e os critérios que serão


<Relacionar as principais características do projeto que possam afetar a arquitetura>

2.3.1.1 Soluções Candidata

Solução Requisitos e Restrições

FASE - INICIAÇÃO

<Descrever a Solução>

N/A

2.3.1.2 Riscos Arquiteturais

Funcionalidade

FASE - INICIAÇÃO

<Nome da Funcionalidade>

2.3.1.3 Avaliação Arquitetural

Solução Detalhamento tecnológico

FASE – INICIAÇÃO

<Descrever a Solução>

<Detalhamento tecnológico>


<Relacionar as principais características do projeto que possam afetar a arquitetura>

Restrições Breve descrição

<Breve descrição da solução candidata>

Afeta Arquitetura

Risco Arquitetural Descrição dos Riscos

<Sim/não> <Baixo/médio/alto> <Breve detalhamento do risco>

Detalhamento tecnológico Seleção da Solução

<Detalhamento tecnológico> <Aprovada/Rejeitada


Breve descrição

<Breve descrição da solução candidata>

Descrição dos Riscos

<Breve detalhamento do risco>

Seleção da Solução

<Aprovada/Rejeitada>

2.3.1.4 Conclusão

<Texto que descreverá a justificativa de seleção


<Texto que descreverá a justificativa de seleção de uma determinada arquitetura



2.4 Documento de Análise de Impacto

O objetivo deste documento é registrar mudanças necessárias ao projeto solicitadas pelo cliente ou identificadas pela equipe e que poderão gerar alterações na linha de base do projeto em andamento ou para registrar solicitações de manutenção do sistema em produção. registradas na Ferramenta de Controle de

☐☐☐☐ Manutenção Evolutiva☐☐☐☐ Manutenção Corretiva

2.4.1 Dados

Solicitante: [Nome do Solicitante]

Solicitação: [Descrição da Solicitação]

Necessidade: [Descrição das Necessidades]

2.4.2 Impacto da

<O quadro abaixo deverá ser replicado para cada uc impactado

UCXXX – [Nome do Caso de Uso]

Necessidade: [Relacionar as necessidades]Documentação

existente: ☐

Outros Doc. Impactados:

-

Nome do Fluxo I

[FB – Pesquisar] x

[FA01 – Visualizar] x

[FA02 – Exportar] x

Nome da Entidade I


Análise de Impacto


O objetivo deste documento é registrar mudanças necessárias ao projeto cliente ou identificadas pela equipe e que poderão gerar alterações

na linha de base do projeto em andamento ou para registrar solicitações de manutenção do sistema em produção. As solicitações de mudanças serão registradas na Ferramenta de Controle de Demanda e conterão os itens a seguir.

Tipo de Solicitação

Evolutiva Corretiva

[Nome do Solicitante]

[Descrição da Solicitação]

[Descrição das Necessidades]

Impacto da Solicitação

O quadro abaixo deverá ser replicado para cada uc impactado

[Nome do Caso de Uso]

[Relacionar as necessidades]

☐ Sim ☐ Não

[Lista dos documentos impactados]

Impacto

I A E Descrições

x • [Descrever os impactos neste fluxo]



I A E Descrições

Pág. 24 de 42

O objetivo deste documento é registrar mudanças necessárias ao projeto cliente ou identificadas pela equipe e que poderão gerar alterações

na linha de base do projeto em andamento ou para registrar solicitações de s solicitações de mudanças serão

e conterão os itens a seguir.

O quadro abaixo deverá ser replicado para cada uc impactado.>

Descrições

[Descrever os impactos neste fluxo]



Descrições


[Entidade]

[Entidade]


3. ELABORAÇÃO

3.1 Especificação de Caso

[EUC_xxxx

Este documento tem como finalidade permitir que o analista de sistemas possa

especificar os limites e as funcionalidades do sistema. Por meio dele é possível que clientes e usuários validem o sistema e que os desenvolvedores do sistema construam o que é esperado.

3.1.1 Descrição do Caso de Uso

[Neste item, deverá ser descrito resumidamente o objetivo geral do caso de uso.]

3.1.2 Documentos Relacionados

[Indique todos os artefatos que sirva de insumo à ele.]

3.1.3 Diagrama de Caso de Uso

[Imagem.]

3.1.4 Atores

3.1.4.1

[Descrição das ações da atividade do ator nesse Caso de Uso.]





Data

Assinatura

Data

Assinatura

Especificação de Caso de Uso

[EUC_xxxx – Nome da Especificação de Caso de Uso]


Este documento tem como finalidade permitir que o analista de sistemas possa especificar os limites e as funcionalidades do sistema. Por meio dele é possível que

e usuários validem o sistema e que os desenvolvedores do sistema construam o que é esperado.

Descrição do Caso de Uso

[Neste item, deverá ser descrito resumidamente o objetivo geral do

Documentos Relacionados

[Indique todos os artefatos que fazem referência a este caso de uso ou que sirva de insumo à ele.]

Diagrama de Caso de Uso

[Nome do Ator]


Pág. 25 de 42



Nome da Especificação de Caso de Uso]

Este documento tem como finalidade permitir que o analista de sistemas possa especificar os limites e as funcionalidades do sistema. Por meio dele é possível que

e usuários validem o sistema e que os desenvolvedores do sistema

[Neste item, deverá ser descrito resumidamente o objetivo geral do

que fazem referência a este caso de uso ou



3.1.4.2


3.1.5 Pré-Condições

[Uma pré-condição de um caso de uso é o estado do sistema que deve estar presente antes de um caso de uso ser realizado.]

3.1.6 Fluxos De Eventos

3.1.6.1

FB01 <Título>

ID Passo

1 [Descrição do passo.]

3.1.6.2

FA01. <Título>

ID Passo


FA02. <Título>

ID Passo



[Nome Do Ator]


Condições

condição de um caso de uso é o estado do sistema que deve estar presente antes de um caso de uso ser realizado.]

Fluxos De Eventos

Fluxo Básico

Fluxos Regras

de Negócio

Mensagem

[Descrição do passo.]

[Referência do(s)

Fluxo(s) que são

acionados a partir do

passo descrito.]

[Sigla da Regra

de Negócio acionada

nesse passo.]

[Sigla da Mensagem que deve

ser acionada no passo descrito]

Fluxos Alternativos

Fluxos Regras

de Negócio

Mensagem


[Referência do(s)

Fluxo(s) que são


passo descrito.]

[Sigla da Regra


nesse passo.]



Fluxos Regras

de Negócio

Mensagem

[Descrição do passo.] [Referência

do(s) Fluxo(s)

[Sigla da Regra

de


Pág. 26 de 42


condição de um caso de uso é o estado do sistema que deve

Mensagem Tela


acionada no passo descrito]

[Referência da Tela

correspondente ao passo descrito]

Mensagem Tela





Mensagem Tela



correspondente


2

3.1.6.3

FE01 <Título>

ID Passo


2

FE02 <Título>

ID Passo


2

3.1.7 Pós-Condições

[Uma pós-condição é uma lista dos possíveis estados em que o sistema poderá se encontrar imediatamente depois

3.1.8 Pontos de Extensão

3.1.8.1

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


que são acionados a partir do

passo descrito.]

Negócio acionada

nesse passo.]


Fluxo de Exceção

Fluxos Regras

de Negócio

Mensagem


[Referência do(s)

Fluxo(s) que são


passo descrito.]

[Sigla da Regra


nesse passo.]



Fluxos Regras

de Negócio

Mensagem


[Referência do(s)

Fluxo(s) que são


passo descrito.]

[Sigla da Regra


nesse passo.]



Condições

condição é uma lista dos possíveis estados em que o sistema poderá se encontrar imediatamente depois do término de um caso de uso.]

Pontos de Extensão

[Nome do Ponto de Extensão]


Pág. 27 de 42


ao passo descrito]

Mensagem Tela





Mensagem Tela

da Mensagem que deve




condição é uma lista dos possíveis estados em que o sistema do término de um caso de uso.]



3.1.8.2


3.1.9 Pontos de

3.1.9.1


3.1.9.2


3.1.10 Observações

[Neste item deve registrar informações qmotivo, não foi possível descrevê


[Nome do Ponto de Extensão]


Pontos de Inclusão

[Nome do Ponto de Inclusão]


[Nome do Ponto de Inclusão]


Observações

[Neste item deve registrar informações que sejam relevantes e que por algum motivo, não foi possível descrevê-la nos itens acima.]

Pág. 28 de 42




ue sejam relevantes e que por algum

3.1.11 Especificação de Tela

TL001. [TÍTULO]

Legenda

O - Preenchimento obrigatório | A - Preenchimento automático pelo sistema |

TIPO: A = Alfanumérico, N = Numérico, D = Data, AC = Autocomplete.

N Nome do Atributo Descrição

1.

2.

3.

4.

5.



Preenchimento automático pelo sistema | E - Valor do atributo pode ser editado

= Data, M = Imagem, BT = Botão, LK = Link, SU = Seleção única,

Descrição O A E Tipo

(Tam.) Máscara

GRID DE RESULTADO


Responsável Técnico Data

Assinatura

Data

Assinatura


atributo pode ser editado

= Seleção única, SM = Seleção múltipla,

Regras e Hint

Metodologia de Desenvolvimento de Software

3.2 Modelo de Caso de Uso

Este documento tem como objetivo

sistema através de um modelo de caso de uso que apresenta também a interação dessas funcionalidades com os usuários.

3.2.1 Modelo de Casos d

3.2.1.1 Atores

Nome do Ator Descrição sobre Ator

[Nome do Ator] [Breve descrição sobre o ator e suas responsabilidades]

3.2.1.2 Diagrama de Casos de Uso

3.2.1.2.1

3.2.1.2.2

3.2.1.3 Descrição de Casos de Uso

ID Nome do caso de uso

UC1. [Nome do Caso de Uso]UC2. UC3.

3.2.2 Documento de Regras

Este documento tem como objetivo apresentar as regras gerais

sistema. (Restrições, validações, condições e exceções)


Modelo de Caso de Uso


Este documento tem como objetivo descrever as principais funcionalidades do sistema através de um modelo de caso de uso que apresenta também a interação dessas funcionalidades com os usuários.

Modelo de Casos de Uso

Atores

Descrição sobre Ator

[Breve descrição sobre o ator e suas responsabilidades]

Diagrama de Casos de Uso

<Nome do Pacote 1>

[Insira aqui o diagrama]

<Nome do Pacote 2>

[Insira aqui o diagrama]

Descrição de Casos de Uso

Nome do caso de uso Descrição do caso de uso

[Nome do Caso de Uso] [Breve descrição sobre o caso de uso]

Documento de Regras


Este documento tem como objetivo apresentar as regras gerais Restrições, validações, condições e exceções).

Pág. 30 de 42

descrever as principais funcionalidades do sistema através de um modelo de caso de uso que apresenta também a interação

Tipo de Ator

[Sistema ou Humano]

Descrição do caso de uso

[Breve descrição sobre o caso de uso]

Este documento tem como objetivo apresentar as regras gerais utilizadas pelo


3.2.2.1 Regras do Sistema

3.2.2.1.1 Regras de Negócio

RN001 [Descrição da regra de negócio]

RN002 [Descrição da regra de negócio]

RN003 [Descrição da regra de

3.2.2.1.2 Regras de Apresentação

RA001 [Descrição da regra de apresentação] RA002 [Descrição da regra de apresentação] RA003 [Descrição da regra de apresentação]



Regras do Sistema

Regras de Negócio

N001 - [Título] [Descrição da regra de negócio]



Regras de Apresentação

A001 - [Título] [Descrição da regra de apresentação]




Data

Assinatura

Data

Assinatura

Pág. 31 de 42


3.2.3 Lista de Mensagem

Código MSG001 [Descrição da mensagem]

3.2.4 Documento de Arquitetura de Software

Este documento tem como objetivo descrever as principais decisões de projeto

tomadas pela equipe de desenvolvimento e os critérios considerados durante a tomada destas decisões. Suas informações incluem a parte de do sistema.

3.2.4.1 Introdução

3.2.4.1.1 Finalidade

Este documento fornece uma visão arquitetural abrangente do sistema

do sistema], usando diversas visões de arquitetura para representar diferentes

aspectos do sistema. O objetivo deste documento é capturar e comunicar as

decisões arquiteturais significativas que foram tomadas em relação ao sistema.

O documento irá adotar uma estrutura baseada na visão “4+1” de modelo de

arquitetura [KRU41].

Visão de Processos


Lista de Mensagem

Descrição [Descrição da mensagem]

Documento de Arquitetura de Software


Este documento tem como objetivo descrever as principais decisões de projeto tomadas pela equipe de desenvolvimento e os critérios considerados durante a tomada destas decisões. Suas informações incluem a parte de hardware

Introdução

Finalidade

Este documento fornece uma visão arquitetural abrangente do sistema

, usando diversas visões de arquitetura para representar diferentes


s arquiteturais significativas que foram tomadas em relação ao sistema.


Visão lógica Visão de Implementação

Visão de Processos Visão de Implantação

Visão de Casos de Uso

Figura 1 – Arquitetura 4+1

Pág. 32 de 42

Este documento tem como objetivo descrever as principais decisões de projeto tomadas pela equipe de desenvolvimento e os critérios considerados durante a

hardware e software

Este documento fornece uma visão arquitetural abrangente do sistema [nome

, usando diversas visões de arquitetura para representar diferentes


s arquiteturais significativas que foram tomadas em relação ao sistema.



3.2.4.1.2 Escopo

Este Documento de

que será desenvolvido pela [área / equipe].

3.2.4.1.3 Definições, Acrônimos e Abreviações

QoS – Quality of Service, ou qualidade de serviço. Termo utilizado para

descrever um conjunto de qualidades que descreve

de um sistema, como performance, disponibilidade e escalabilidade[QOS].

3.2.4.2 Requisitos e Restrições Arquiteturais

Esta seção descrever os requisitos de software e restrições que tem um impacto significante na arquitetura.

Requisito

Linguagem

Plataforma

Segurança

Persistência

Internacionalização

(i18n)

Tabela 2

3.2.4.3 Visão de Casos de Uso

Esta seção lista as especificações centrais e significantes para a arquitetura do sistema.

Lista de casos de uso do sistema:

• Caso de Uso [00X]• Caso de Uso [00X]


Escopo

Este Documento de Arquitetura de Software se aplica ao [nome do sistema],

que será desenvolvido pela [área / equipe].

Definições, Acrônimos e Abreviações

Quality of Service, ou qualidade de serviço. Termo utilizado para

descrever um conjunto de qualidades que descrevem as requisitos não


Requisitos e Restrições Arquiteturais

Esta seção descrever os requisitos de software e restrições que tem um impacto significante na arquitetura.

Solução

[Especificar a(s) linguagem(ns) utilizada(s) no

desenvolvimento.]

[Especificar o servidor de aplicações utilizado.]

[Especificar a necessidade de segurança e as características básicas da segurança.] [Especificar a necessidade de persistência e qual o mecanismo de persistência que será adotado.][Especificar a necessidade de

internacionalização/localização na aplicação.]

Tabela 2 – Exemplo de requisitos e restrições

Visão de Casos de Uso

Esta seção lista as especificações centrais e significantes para a arquitetura

Lista de casos de uso do sistema:

[00X] [00X]

Pág. 33 de 42

Arquitetura de Software se aplica ao [nome do sistema],

Quality of Service, ou qualidade de serviço. Termo utilizado para

m as requisitos não-funcionais


Esta seção descrever os requisitos de software e restrições que tem um impacto

[Especificar a(s) linguagem(ns) utilizada(s) no

[Especificar o servidor de aplicações utilizado.]

[Especificar a necessidade de segurança e as

[Especificar a necessidade de persistência e qual o mecanismo de persistência que será adotado.]

internacionalização/localização na aplicação.]

ições

Esta seção lista as especificações centrais e significantes para a arquitetura


1.1.1.1. Casos de Uso significantes para a arquitetura

[Exemplo:

Figura 2 – Exemplo de Diagrama com os casos de uso significativos e atores

3.2.4.4 Visão Lógica

Descrever uma visão lógica da arquitetura. Descrever as classes mais

importantes, sua organização em pacotes de serviços e subsistemas, e a

organização desses subsistemas em camadas. Também descreve as realizações

dos casos de uso mais importantes, por exemplo, aspectos dinâmicos da

arquitetura. Diagramas de classes e sequência devem ser incluídos para ilustrar os

relacionamentos entre as classes significativas

e camadas.


Casos de Uso significantes para a arquitetura

Exemplo de Diagrama com os casos de uso significativos e atores

Visão Lógica



subsistemas em camadas. Também descreve as realizações



relacionamentos entre as classes significativas na arquitetura, subsistemas, pacotes

Pág. 34 de 42

Casos de Uso significantes para a arquitetura

Exemplo de Diagrama com os casos de uso significativos e atores



subsistemas em camadas. Também descreve as realizações



na arquitetura, subsistemas, pacotes


3.2.4.5 Visão Geral

[Exemplo:

Figura 3

Figura 4

Camada

Cliente

Navegador Web

Camada de

Serviço REST

Web Service

REST

Controladores

Recursos REST


Visão Geral – pacotes e camadas

Figura 3 – Exemplo de Diagrama de Camadas da Aplicação

4 – Exemplo de Diagrama de Pacotes da Aplicação

Camada de

Serviço REST

Web Service

REST

Controladores /

Recursos REST

Camada de

Negócio

Interfaces de

Serviço

Implementação

De Serviços

Camada de

Persistência

Repositórios

Entidades

Camada de

Autenticação

API de

Autenticaçao

DATASUS

Pág. 35 de 42

Exemplo de Diagrama de Camadas da Aplicação

Exemplo de Diagrama de Pacotes da Aplicação

Dados


3.2.4.6 Visão de

3.2.4.6.1 Caso de Uso [00X]

3.2.4.6.1.1

[Exemplo

Figura 5

3.2.4.6.1.2

Figura 6


Visão de Implementação

Caso de Uso [00X]

3.2.4.6.1.1 Diagrama de Classes

[Exemplo:

Figura 5 – Exemplo de Diagrama de Classes

3.2.4.6.1.2 Diagrama de Sequência

Figura 6 – Exemplo de Diagrama de Sequência

Pág. 36 de 42


3.2.4.7 Visão de Implantação

Descrever os nodos físicos, as

implantados.

[Exemplo:

Figura 7

3.2.4.8 Dimensionamento e Performance

3.2.4.8.1 Volume

Enumerar os itens relativos ao volume de acesso aos recursos da aplicação:

• Número de estimado usuários: • Número estimado de acessos diários: • Número estimado de acessos por período: • Tempo de sessão de um usuário:

3.2.4.8.2 Performance

Enumerar os itens referentes à resposta esperada do sistema:

• Tempo máximo para a exe


Visão de Implantação

Descrever os nodos físicos, as configurações e os artefatos que serão

Figura 7 – Exemplo de Diagrama de Implantação Java

Dimensionamento e Performance

Volume


Número de estimado usuários: [000] Número estimado de acessos diários: [000] Número estimado de acessos por período: [000] Tempo de sessão de um usuário: [000]

Performance


Tempo máximo para a execução de determinada transação

Pág. 37 de 42

configurações e os artefatos que serão

Exemplo de Diagrama de Implantação Java



cução de determinada transação: [000]


3.2.4.9 Qualidade

Enumerar os itens de qualidade de software [QOS] significativos para a aplicação:

Item Descrição

Escalabilidade [Breve Descrição]Confiabilidade, Disponibilidade

[Breve Descrição]

Portabilidade [Breve Descrição]Segurança [Breve Descrição]

4. CONSTRUÇÃO

4.1 Plano de Teste

Este documento tem como objetivo

definir os métodos a serem empregados e estabelecer métricas e formas de acompanhamento do processo.

4.1.1 Introdução

[Inserir o texto aqui]

4.1.1.1.1 Escopo


4.1.2 Estágios de Teste


4.1.3 Tipos de Testes


4.1.4 Recursos Necessários

4.1.4.1.1 Recursos Humanos


4.1.4.1.2 Recursos Computacionais


4.1.5 Riscos e Restrições



Qualidade

Enumerar os itens de qualidade de software [QOS] significativos para a

Descrição Solução

[Breve Descrição] [Breve descrição da Solução][Breve Descrição] [Breve descrição da Solução]

[Breve Descrição] [Breve descrição da Solução][Breve Descrição] [Breve descrição da Solução]

Plano de Teste


Este documento tem como objetivo planejar as atividades a serem realizadas, definir os métodos a serem empregados e estabelecer métricas e formas de acompanhamento do processo.


Escopo


Estágios de Teste


de Testes


Recursos Necessários

Recursos Humanos


Recursos Computacionais


Riscos e Restrições


Pág. 38 de 42

Enumerar os itens de qualidade de software [QOS] significativos para a

[Breve descrição da Solução] [Breve descrição da Solução]

[Breve descrição da Solução] [Breve descrição da Solução]

planejar as atividades a serem realizadas, definir os métodos a serem empregados e estabelecer métricas e formas de


4.1.6 Produtos Gerados


5. DIVERSOS

5.1 Ata de Reunião

Informações Básicas

Data Horário

dd/mm/aaaa 00h

Lista de Participantes

Participantes

Assunto(s)

1. 2.

Decisões Tomadas

Assunto 1 •

Assunto 2

•

Pendências e Encaminhamentos

Item

Redator [Nome] Condutor da Reunião [Nome] Metodologia de Desenvolvimento de Software – Versão 1.0

Produtos Gerados


Ata de Reunião

Local

Área E-mails

Pendências e Encaminhamentos

Item Responsável


Data

Assinatura

Data

Assinatura

Pág. 39 de 42

Telefone

Responsável Prazo


5.2 Lista de Participantes

Data Hora

Nº Nome (Letra de Forma)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20


Lista de Participantes

Local Assunto / Projeto

Área E-mail (Letra de Forma)

SIAPE Rubrica

Pág. 40 de 42

Assunto / Projeto

Rubrica Fone/Ramal


5.3 Nota Técnica

Nota Técnica nº: [000/Ano]

Assunto

[Descrever o assunto tratado na nota.]

Objetivo

[Descrever o objetivo da nota técnica]

Fatos

[Descrever os fatos que levaram a elaboração da Nota Técnica.]

Análise

[Descrever detalhadamente os fatos relacionados à nota técnica, com notação técnica referente aos itens listados.]

Conclusão

[Descrever a conclusão do analista baseada na análise feita, indicando a solução do problema abordado.]

Responsável Técnico (Cargo/Área) [Nome] Coordenador de Desenvolvimento (Cargo/Área) [Nome]


Nota Técnica nº: [000/Ano] – IEC

[Descrever o assunto tratado na nota.]

[Descrever o objetivo da nota técnica]

[Descrever os fatos que levaram a elaboração da Nota Técnica.]

[Descrever detalhadamente os fatos relacionados à nota técnica, com notação técnica referente aos itens listados.]

[Descrever a conclusão do analista baseada na análise feita, indicando a solução do


Data

Assinatura

de Desenvolvimento Data

Assinatura

Pág. 41 de 42

[Descrever detalhadamente os fatos relacionados à nota técnica, com notação

[Descrever a conclusão do analista baseada na análise feita, indicando a solução do


5.4 Termo de Recebimento Provisório

Gestor do Projeto[Nome][E-mail]

[Telefone]

Este documento tem o propósito de obter a evidência de entrega de produtos

pela contratada e apresentar a data prevista para homologação por parte do Gestor.

5.5 Termo de Recebimento Definitivo

Gestor do Projeto[Nome][E-mail]

[Telefone]

Este documento tem o propósito de obter a evidência de entrega de produtos

pela contratada e apresentar a data prevista para homologação por parte do Gestor.


Termo de Recebimento Provisório

[xx/ano]


Gestor do Projeto Gerente de Projeto[Nome] [Nome]

mail] [E-[Telefone] [Telefone]


Este documento tem o propósito de obter a evidência de entrega de produtos pela contratada e apresentar a data prevista para homologação por parte do Gestor.

Termo de Recebimento Definitivo

[xx/ano]


Gestor do Projeto Gerente de Projeto[Nome] [Nome]

mail] [E-mail][Telefone] [Telefone]



Pág. 42 de 42

Gerente de Projeto [Nome]

-mail] [Telefone]


de Projeto [Nome]

mail] [Telefone]


metodologia desenvolvimento software iec5 · ferramentas de apoio, distribuir e acompanhar...

Documents