Proyecto crowdfunding para distribuir electricidad sin cables en
Metodologia Desenvolvimento Software IEC5 · ferramentas de apoio, distribuir e acompanhar...
Transcript of 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
METODOLOGIA DE DESENVOLVIMENTO DE
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
METODOLOGIA DE DESENVOLVIMENTO DE
Histórico de Revisão do Documento
Descrição da alteração
Versão inicial
Metodologia de Desenvolviment
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
imento de Software – Versão 1.0
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
Metodologia de Desenvolviment
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
imento de Software – Versão 1.0
................................................................................................
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
Metodologia de Desenvolviment
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]
[Necessidade do Usuário]
[Necessidade do Usuário]
imento de Software – Versão 1.0
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”.
[Necessidade do Usuário] [Situação Atual. Caso seja algo novo colocar “N/A”.
[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]
[Solução proposta para atender à necessidade]
[Solução proposta para atender à necessidade]
Metodologia de Desenvolviment
1.1.3 Características do Produto
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]
[Descrição da Característica]
1.1.3.2 Características N
1.1.3.2.1 [Nome da
[Descrição da Característica]
1.1.3.2.2 [
[Descrição da Característica]
*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]
imento de Software – Versão 1.0
Características do Produto
Características Funcionais
[Nome da Característica]
[Descrição da Característica]
[Nome da Característica]
[Descrição da Característica]
Características Não-Funcionais
[Nome da Característica]
[Descrição da Característica]
[Nome da Característica]
[Descrição da Característica]
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
Metodologia de Desenvolviment
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
imento de Software – Versão 1.0
Objetivo deste Documento
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
Metodologia de Desenvolviment
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
imento de Software – Versão 1.0
Plano de Gerenciamento de Configuração
[Sigla – Nome] [Nome] [Sigla – Nome]
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 sua integridade durante o projeto e controlar
sistematicamente as mudanças.
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
Para que isso aconteça serão detalhados os recursos necessários (equipes,
ferramentas e ambiente), as responsabilidades atribuídas e o cronograma de
Escopo
Este Plano de Gerenciamento de Configuração é destinados para todos os
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
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
ua integridade durante o projeto e controlar
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
Para que isso aconteça serão detalhados os recursos necessários (equipes,
ferramentas e ambiente), as responsabilidades atribuídas e o cronograma de
Este Plano de Gerenciamento de Configuração é destinados para todos os
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.
Metodologia de Desenvolviment
• 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
imento de Software – Versão 1.0
Cronograma do Projeto <criar link para o cronograma do projeto>
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çã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>
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:
Metodologia de Desenvolviment
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.
imento de Software – Versão 1.0
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
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ã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
É o ambiente que servira como integração dos códigos fontes que estão
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 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
o de livre escolha do desenvolvedor, desde que a
mesma seja uma ferramenta de Software Livre, tais como Atom, Eclipse, NetBeans,
É o ambiente que servira como integração dos códigos fontes que estão
Metodologia de Desenvolvimento
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
WebService IP : PortaRedis IP : Porta
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
mento de Software – Versão 1.0
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
área gestora. Este ambiente é controlado e mantido de acordo com as políticas da
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
área gestora. Este ambiente é controlado e mantido de acordo com as políticas da
Metodologia de Desenvolvimento
WebService IP : PortaRedis IP : Porta
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
WebService IP : PortaRedis IP : Porta
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
mento de Software – Versão 1.0
IP : Porta IP : Porta
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
IP : Porta 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
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.
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
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
Documento de Permissões de Pastas e Acessos por Perfil
Metodologia de Desenvolvimento
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.
mento de Software – Versão 1.0
Especificação de Caso de Uso
1.3.3.1.2 Baselines do Projeto
As baselines serão definidas a cada mudança de fase do projeto, e uma de
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á
documento PAP do projeto, que estará disponível na pasta de Gerencia de
Controle de Configuração e Mudança
1.3.3.2.1 Processo de Solicitações de Mudança
[Descreva o processo pelo qual os problemas e as mudanças são
submetidos, revisados e dispostos.]
1.3.3.2.2 Comitê de Controle de Mudança (CCB)
[Descreva os membros do CCB e os procedimentos para processar
solicitações de mudança e aprovações a serem seguidos pelo CCB.]
Estimativa do Status de Configuração
1.3.3.3.1 Processo de Armazenamento e Liberação do
[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
Pág. 13 de 42
As baselines serão definidas a cada mudança de fase do projeto, e uma de
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
documento PAP do projeto, que estará disponível na pasta de Gerencia de
[Descreva o processo pelo qual os problemas e as mudanças são
[Descreva os membros do CCB e os procedimentos para processar
solicitações de mudança e aprovações a serem seguidos pelo CCB.]
e Liberação do Projeto
[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 — on-line, off-line,
Metodologia de Desenvolvimento
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
mento de Software – Versão 1.0
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 Relatórios e Auditorias
[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 “qualidade do produto” em qualquer
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
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
Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos
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 e corrigidos? Qual é a “lacuna de
qualidade” em termos de defeitos pendentes em comparação com defeitos
corrigidos? Qual é a média de tempo de correção de um defeito?]
[Identifique os marcos internos e do fornecedor relacionados ao esforço 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
destina e se há quaisquer problemas conhecidos ou instruções de instalação.]
[Descreva o conteúdo, o formato e a finalidade dos relatórios e auditorias de
lidade do produto” em qualquer
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 desenvolvedores para
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
Vencimento (Relatórios Baseados em Períodos): Há quanto tempo defeitos
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
Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos
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
e corrigidos? Qual é a “lacuna de
qualidade” em termos de defeitos pendentes em comparação com defeitos
corrigidos? Qual é a média de tempo de correção de um defeito?]
[Identifique os marcos internos e do fornecedor relacionados ao esforço 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. ]
Metodologia de Desenvolvimento
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
Gestor do Projeto[Nome[E-mail
[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]
mento de Software – Versão 1.0
Controle de Software de Subcontratados e Fornecedores
[Descreva como o desenvolvimento de software externo ao ambiente do
projeto será incorporado. Geralmente aplicado em processos de internalizações de
Documento de Visão de Sistema
[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 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
[Descreva como o desenvolvimento de software externo ao ambiente do
de internalizações de
Gerente de Projeto Nome]
-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]
Metodologia de Desenvolvimento
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
[Descrição Detalhada do Requisito]
RNF002
[Descrição Detalhada do Requisito]
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.]
mento de Software – Versão 1.0
Visão Geral do Produto
2.1.4.1 Requisitos Funcionais
RF001 - [Nome do Requisito]
[Descrição Detalhada do Requisito]
RF002 - [Nome do Requisito]
[Descrição Detalhada do Requisito]
2.1.4.2 Requisitos não Funcionais
RNF001 - [Nome do Requisito]
[Descrição Detalhada do Requisito]
RNF002 - [Nome do Requisito]
[Descrição Detalhada do Requisito]
Restrições
[Descrever aqui as restrições que sejam impostas ao sistema ou ao
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
[Descrever aqui as restrições que sejam impostas ao sistema ou ao
mentos que serviram de subsídio para a criação do
Metodologia de Desenvolvimento
2.2 Caso de Desenvolvimento
Gestor do Projeto[Nome[E-mail
[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.
mento de Software – Versão 1.0
Caso de Desenvolvimento
[Sigla] – [Nome do Projeto]
Gestor do Projeto Gerente de ProjetoNome] [Nome
mail] [E-Telefone] [Telefone
Objetivo deste Documento
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
Gerente de Projeto Nome]
-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
Detalhes da revisão Ferramentas
Analise e Design
Detalhes da revisão Ferramentas
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
Metodologia de Desenvolvimento de Software – Versão 1.0
Implementação
Detalhes da revisão Ferramentas
Detalhes da revisão Ferramentas
Detalhes da revisão Ferramentas
Configuração e Gerenciamento de Mudança
Detalhes da revisão Ferramentas
Versão 1.0 Pág. 19 de 42
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]
Metodologia de Desenvolvimento de Software – Versão 1.0
Gerenciamento de Projeto
Detalhes da revisão Ferramentas
Artefatos não utilizados
Motivo
Aprovação do Documento
Data
Assinatura
Versão 1.0 Pág. 20 de 42
Templates
Metodologia de Desenvolvimento
2.3 Documento de Definição Arquitetural
Gestor do Projeto[Nome[E-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 analisados posteriormente para seleção da melhor alternativa.
imento de Software – Versão 1.0
Documento de Definição Arquitetural
[Sigla] – [Nome do Projeto]
Gestor do Projeto Gerente de ProjetoNome] [Nome
mail] [E-Telefone] [Telefone
Objetivo deste Documento
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
Gerente de Projeto Nome]
-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
2.3.1 Características do Produto
<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>
Metodologia de Desenvolvimento de Software – Versão 1.0
<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
Versão 1.0 Pág. 22 de 42
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
Metodologia de Desenvolvimento de Software – Versão 1.0
<Texto que descreverá a justificativa de seleção de uma determinada arquitetura
Versão 1.0 Pág. 23 de 42
Metodologia de Desenvolvimento
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
imento de Software – Versão 1.0
Análise de Impacto
Objetivo deste Documento
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]
x • [Descrever os impactos neste fluxo]
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]
[Descrever os impactos neste fluxo]
[Descrever os impactos neste fluxo]
Descrições
Metodologia de Desenvolvimento
[Entidade]
[Entidade]
Responsável Técnico [Nome] Gestor do Projeto [Nome]
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.]
imento de Software – Versão 1.0
x • [Descrever os impactos neste fluxo]
x • [Descrever os impactos neste fluxo]
Aprovação do Documento
Data
Assinatura
Data
Assinatura
Especificação de Caso de Uso
[EUC_xxxx – Nome da Especificação de Caso de Uso]
Objetivo deste Documento
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]
[Descrição das ações da atividade do ator nesse Caso de Uso.]
Pág. 25 de 42
[Descrever os impactos neste fluxo]
[Descrever os impactos neste fluxo]
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
[Descrição das ações da atividade do ator nesse Caso de Uso.]
Metodologia de Desenvolvimento
3.1.4.2
[Descrição das ações da atividade do ator nesse Caso de Uso.]
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
1 [Descrição do passo.]
FA02. <Título>
ID Passo
1 [Descrição do passo.]
imento de Software – Versão 1.0
[Nome Do Ator]
[Descrição das ações da atividade do ator nesse Caso de Uso.]
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
[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 Regras
de Negócio
Mensagem
[Descrição do passo.] [Referência
do(s) Fluxo(s)
[Sigla da Regra
de
[Sigla da Mensagem que deve
Pág. 26 de 42
[Descrição das ações da atividade do ator nesse Caso de Uso.]
condição de um caso de uso é o estado do sistema que deve
Mensagem Tela
[Sigla da Mensagem que deve
acionada no passo descrito]
[Referência da Tela
correspondente ao passo descrito]
Mensagem Tela
[Sigla da Mensagem que deve
acionada no passo descrito]
[Referência da Tela
correspondente ao passo descrito]
Mensagem Tela
[Sigla da Mensagem que deve
[Referência da Tela
correspondente
Metodologia de Desenvolvimento
2
3.1.6.3
FE01 <Título>
ID Passo
1 [Descrição do passo.]
2
FE02 <Título>
ID Passo
1 [Descrição do 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.]
imento de Software – Versão 1.0
que são acionados a partir do
passo descrito.]
Negócio acionada
nesse passo.]
ser acionada no passo descrito]
Fluxo de Exceção
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 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]
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]
[Definição da localização do ponto de extensão no fluxo de eventos.]
Pág. 27 de 42
acionada no passo descrito]
ao passo descrito]
Mensagem Tela
[Sigla da Mensagem que deve
acionada no passo descrito]
[Referência da Tela
correspondente ao passo descrito]
Mensagem Tela
da Mensagem que deve
acionada no passo descrito]
[Referência da Tela
correspondente ao passo descrito]
condição é uma lista dos possíveis estados em que o sistema do término de um caso de uso.]
[Definição da localização do ponto de extensão no fluxo de eventos.]
Metodologia de Desenvolvimento
3.1.8.2
[Definição da localização do ponto de extensão no fluxo de eventos.]
3.1.9 Pontos de
3.1.9.1
[Definição da localização do ponto de extensão no fluxo de eventos.]
3.1.9.2
[Definição da localização do ponto de extensão no fluxo de eventos.]
3.1.10 Observações
[Neste item deve registrar informações qmotivo, não foi possível descrevê
imento de Software – Versão 1.0
[Nome do Ponto de Extensão]
[Definição da localização do ponto de extensão no fluxo de eventos.]
Pontos de Inclusão
[Nome do Ponto de Inclusão]
[Definição da localização do ponto de extensão no fluxo de eventos.]
[Nome do Ponto de Inclusão]
[Definição da localização do ponto de extensão no fluxo de eventos.]
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
[Definição da localização do ponto de extensão no fluxo de eventos.]
[Definição da localização do ponto de extensão no fluxo de eventos.]
[Definição da localização do ponto de extensão no fluxo de eventos.]
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.
Responsável Técnico [Nome] Gestor do Projeto [Nome]
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Aprovação do Documento
Responsável Técnico Data
Assinatura
Data
Assinatura
Versão 1.0 Pág. 29 de 42
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)
Metodologia de Desenvolvimento de Software – Versão 1.0
Modelo de Caso de Uso
Objetivo deste Documento
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
Objetivo deste Documento
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
Metodologia de Desenvolvimento de Software
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]
Responsável Técnico [Nome] Gestor do Projeto [Nome]
Metodologia de Desenvolvimento de Software – Versão 1.0
Regras do Sistema
Regras de Negócio
N001 - [Título] [Descrição da regra de negócio]
N002 - [Título] [Descrição da regra de negócio]
N003 - [Título] [Descrição da regra de negócio]
Regras de Apresentação
A001 - [Título] [Descrição da regra de apresentação]
A002 - [Título] [Descrição da regra de apresentação]
A003 - [Título] [Descrição da regra de apresentação]
Aprovação do Documento
Data
Assinatura
Data
Assinatura
Pág. 31 de 42
Metodologia de Desenvolvimento de Software
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
Metodologia de Desenvolvimento de Software – Versão 1.0
Lista de Mensagem
Descrição [Descrição da mensagem]
Documento de Arquitetura de Software
Objetivo deste Documento
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
aspectos do sistema. O objetivo deste documento é capturar e comunicar as
s 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
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
aspectos do sistema. O objetivo deste documento é capturar e comunicar as
s 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
Metodologia de Desenvolvimento de Software
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]
Metodologia de Desenvolvimento de Software – Versão 1.0
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
de um sistema, como performance, disponibilidade e escalabilidade[QOS].
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
de um sistema, como performance, disponibilidade e escalabilidade[QOS].
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
Metodologia de Desenvolvimento de Software
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.
Metodologia de Desenvolvimento de Software – Versão 1.0
Casos de Uso significantes para a arquitetura
Exemplo de Diagrama com os casos de uso significativos e atores
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
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 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
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
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
na arquitetura, subsistemas, pacotes
Metodologia de Desenvolvimento de Software
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
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Metodologia de Desenvolvimento de Software
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
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Metodologia de Desenvolvimento de Software
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
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Enumerar os itens relativos ao volume de acesso aos recursos da aplicação:
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
Enumerar os itens referentes à resposta esperada do sistema:
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
Enumerar os itens relativos ao volume de acesso aos recursos da aplicação:
Enumerar os itens referentes à resposta esperada do sistema:
cução de determinada transação: [000]
Metodologia de Desenvolvimento de Software
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
[Inserir o texto aqui]
4.1.2 Estágios de Teste
[Inserir o texto aqui]
4.1.3 Tipos de Testes
[Inserir o texto aqui]
4.1.4 Recursos Necessários
4.1.4.1.1 Recursos Humanos
[Inserir o texto aqui]
4.1.4.1.2 Recursos Computacionais
[Inserir o texto aqui]
4.1.5 Riscos e Restrições
[Inserir o texto aqui]
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Objetivo deste Documento
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.
[Inserir o texto aqui]
Escopo
[Inserir o texto aqui]
Estágios de Teste
[Inserir o texto aqui]
de Testes
[Inserir o texto aqui]
Recursos Necessários
Recursos Humanos
[Inserir o texto aqui]
Recursos Computacionais
[Inserir o texto aqui]
Riscos e Restrições
[Inserir o texto aqui]
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
Metodologia de Desenvolvimento de Software
4.1.6 Produtos Gerados
[Inserir o texto aqui]
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
[Inserir o texto aqui]
Ata de Reunião
Local
Área E-mails
Pendências e Encaminhamentos
Item Responsável
Aprovação do Documento
Data
Assinatura
Data
Assinatura
Pág. 39 de 42
Telefone
Responsável Prazo
Metodologia de Desenvolvimento de Software
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
Metodologia de Desenvolvimento de Software – Versão 1.0
Lista de Participantes
Local Assunto / Projeto
Área E-mail (Letra de Forma)
SIAPE Rubrica
Pág. 40 de 42
Assunto / Projeto
Rubrica Fone/Ramal
Metodologia de Desenvolvimento de Software
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]
Metodologia de Desenvolvimento de Software – Versão 1.0
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
Aprovação do Documento
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
Metodologia de Desenvolvimento de Software
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.
Metodologia de Desenvolvimento de Software – Versão 1.0
Termo de Recebimento Provisório
[xx/ano]
[Sigla] – [Nome do Projeto]
Gestor do Projeto Gerente de Projeto[Nome] [Nome]
mail] [E-[Telefone] [Telefone]
Objetivo deste Documento
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]
[Sigla] – [Nome do Projeto]
Gestor do Projeto Gerente de Projeto[Nome] [Nome]
mail] [E-mail][Telefone] [Telefone]
Objetivo deste Documento
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.
Pág. 42 de 42
Gerente de Projeto [Nome]
-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.
de Projeto [Nome]
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.