MDS – Metodologia de Desenvolvimento de Sistemas

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

VERSÃO 2.0

Documento Data Versão Página

MDS 12/3/2013 2.0 1/79
 MDS – Metodologia de Desenvolvimento de Sistemas

SUMÁRIO

1. INTRODUÇÃO........................................................................................................................ 4
2. OBJETIVO............................................................................................................................... 4
3. TIPOS DE DEMANDA DE SISTEMA DA DET .................................................................... 5
3.1 Novo Sistema...................................................................................................................... 5
3.2 Sustentação de Sistema ...................................................................................................... 5
3.2.1 Corretiva..................................................................................................................... 5
3.2.2 Evolutiva ..................................................................................................................... 5
3.2.3 Adaptativa .................................................................................................................. 5
3.3 Serviços de Sistemas........................................................................................................... 6
4. TRATAMENTO DAS DEMANDAS DE SISTEMA DA DET ............................................... 6
4.1 Projetos.............................................................................................................................. 6
4.2 Sustentação de Sistemas .................................................................................................... 7
4.3 Serviços de Sistemas........................................................................................................... 7
5. CRITÉRIOS DE TRATAMENTO DAS DEMANDAS .......................................................... 8
6. PAPÉIS E RESPONSABILIDADES....................................................................................... 9
7. PROJETOS DE DESENVOLVIMENTO E PROJETOS DE MELHORIA.........................17
7.1 Pré-Projeto ........................................................................................................................17
7.1.1 Fluxo de Comunicação do Pré-Projeto........................................................................18
7.1.2 Detalhamento das Atividades do Pré-Projeto .............................................................18
7.2 Projeto ..............................................................................................................................20
7.2.1 Iniciação.....................................................................................................................21
7.2.2 Elaboração .................................................................................................................27
7.2.3 Construção.................................................................................................................32
7.2.4 Transição ...................................................................................................................37
8. SUSTENTAÇÃO DE SISTEMAS ..........................................................................................41
9. PROJETOS DE BUSINESS INTELLIGENCE (BI) – DESENVOLVIMENTO E
SUSTENTAÇÃO ............................................................................................................................41
9.1 Iniciação ............................................................................................................................41
9.2 Elaboração.........................................................................................................................43
9.3 Construção ........................................................................................................................45
9.4 Transição ...........................................................................................................................46
10. PADRÕES DA DET/INCRA A SEREM UTILIZADOS .......................................................48
11. ARTEFATOS GERADOS POR DISCIPLINA – PROJETOS DE SISTEMAS ...................50
12. ARTEFATOS GERADOS POR DISCIPLINA – PROJETOS DE BUSINESS
INTELLIGENCE (BI) ....................................................................................................................54
13. ARTEFATOS GERADOS POR ETAPA ...............................................................................57

Documento Data Versão Página

MDS 12/3/2013 2.0 2/79
 MDS – Metodologia de Desenvolvimento de Sistemas

14. FERRAMENTAS DE APOIO AO PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE ...................................................................................................................................73
15. GLOSSÁRIO...........................................................................................................................73
16. REFERÊNCIA ........................................................................................................................78
17. APÊNDICES ...........................................................................................................................78

Documento Data Versão Página

MDS 12/3/2013 2.0 3/79
 MDS – Metodologia de Desenvolvimento de Sistemas

1. INTRODUÇÃO
A Metodologia de Desenvolvimento de Sistemas do Incra (MDS-Incra) foi definida para atender às
demandas de sistemas da Coordenação-Geral de Gestão de Tecnologia da Informação– DET. O
processo de contratação de serviços de Tecnologia da Informação disposto na Instrução Normativa nº
04, de 12 de novembro de 2010, a ser seguido pela Administração Pública Federal direta, autárquica e
fundacional, norteou a definição e principalmente a flexibilidade da Metodologia de Desenvolvimento
de Sistemas do Incra, tornando-a o mais customizável possível. Essa flexibilidade permite que
qualquer tipo de demanda, disciplina ou fase possa ser desenvolvido tanto por uma Fábrica de
Software quanto pelo Incra.
Entende-se por Fábrica de Software, uma empresa terceirizada contratada para desenvolver a demanda
externamente ao Incra. No contexto de desenvolvimento por uma Fábrica de Software alguns papéis
da MDS-Incra passam a executar atividades específicas dessa contratação externa e novos papéis são
definidos para esse fim. Por exemplo, para uma demanda corretiva desenvolvida pelo próprio Incra,
tem-se um Gerente de Projetos responsável por promover e acompanhar todo o desenvolvimento dessa
demanda. Caso essa mesma demanda seja desenvolvida por uma Fábrica de Software, a
responsabilidade de desenvolver essa demanda seria da Fábrica de Software, entretanto haveria o
acompanhamento pelo Gerente de Projetos do Incra.
Com a adoção da MDS-Incra, pretende-se viabilizar a melhoria contínua do processo de
desenvolvimento de sistemas e assegurar um conjunto mínimo de regras, padrões e tarefas
imprescindíveis à execução de projetos com qualidade, produtividade e segurança. A partir de um
roteiro dinâmico e interativo, definido na MDS-Incra, pretende-se evitar, tanto quanto possível, a
subjetividade na execução do trabalho.
Presume-se que o processo de desenvolvimento de software seja constantemente revisado e
aprimorado. Essa maturidade deve ser refletida na Metodologia de Desenvolvimento de Sistemas do
Incra, por meio de sua atualização.

2. OBJETIVO
Este documento tem como objetivo descrever a Metodologia de Desenvolvimento de Sistemas do
Incra a ser usada no desenvolvimento e na sustentação de sistemas pela Coordenação-Geral de Gestão
de Tecnologia da Informação – DET do Incra.
A MDS-Incra contempla a descrição dos processos para atender aos seguintes tipos de demandas:
Novo sistema, Sustentação de sistema (corretiva, evolutiva e adaptativa) e Serviços de sistemas.

Documento Data Versão Página

MDS 12/3/2013 2.0 4/79
 MDS – Metodologia de Desenvolvimento de Sistemas

As demandas de sistemas recebidas pela DET podem ser tratadas como projetos ou sustentação de
sistemas. Cada um desses tipos de tratamento possui um fluxo de processo diferenciado. A decisão de
qual abordagem deve ser utilizada está descrita no item “Critérios de tratamento das demandas”.
No caso de projetos, o processo de desenvolvimento divide-se em pré-projeto e projeto, que se
subdivide nas fases de iniciação, elaboração, construção e transição. Os processos de sustentação de
sistemas não são subdivididos.

3. TIPOS DE DEMANDA DE SISTEMA DA DET

3.1 Novo Sistema

Consiste no desenvolvimento de novos sistemas que darão apoio aos programas e projetos de reforma
agrária do Incra. Para o desenvolvimento, utiliza-se o processo de engenharia de software para garantir
que o produto seja de qualidade e que atenda às necessidades dos usuários.

3.2 Sustentação de Sistema

A sustentação de sistema ocorre após a entrada do sistema em produção. Pode ser um processo que
envolve mudanças para corrigir erros ou uma melhoria e/ou otimização de um sistema. Esta
sustentação inclui um grupo de atividades que são executadas durante o ciclo de vida da aplicação.

3.2.1 Corretiva

Mudanças no sistema (versão de produção) para corrigir defeitos e/ou deficiências que foram
encontrados durante a utilização pelo usuário final. Não envolve mudanças nas funcionalidades de
negócio, mas assegura que cada funcionalidade existente seja executada conforme requerido.

3.2.2 Evolutiva

A evolução (melhoria) de sistemas visa implementar novas funcionalidades, adequar funcionalidades

existentes ou excluir funcionalidades, visando melhorar sua aplicabilidade e usabilidade dentro da
organização.

3.2.3 Adaptativa

Adequação do sistema às mudanças de ambiente operacional e infraestrutura, compreendendo

hardware e software básico, mudanças de versão, linguagem, SGBD e ajustes de performance, que não
impliquem em inserção, alteração ou exclusão de funcionalidades.

Documento Data Versão Página

MDS 12/3/2013 2.0 5/79
 MDS – Metodologia de Desenvolvimento de Sistemas

3.3 Serviços de Sistemas

“Serviços” são demandas pontuais solicitadas pelo usuário, que não envolvem tarefas de
desenvolvimento ou manutenção nas funcionalidades do sistema, mas que dependem de conhecimento
técnico sobre o sistema. Por não envolverem o processo de desenvolvimento de Software essas
demandas têm um fluxo específico que está fora do escopo da MDS-Incra.
Um exemplo de serviço são as solicitações “ad hoc”, previstas no manual de práticas de contagem do
IFPUG, ou seja, funcionalidades que são fornecidas ao usuário final na forma de relatórios de
execução única ou eventual e extração de dados. Exemplo de solicitação:

Análise e Diagnóstico
 Modificações de sistemas para desenvolver novas funcionalidades ou adequações com o
objetivo de atender a regulamentações definidas por órgãos reguladores, leis ou
solicitações de auditoria.

Demanda Regulatória
 Avaliação de demanda para identificar causas de problemas operacionais ou funcionais de
sistemas e apresentar relatório da avaliação/diagnóstico e/ou propor alternativas de
solução e documentação das correções implementadas.

4. TRATAMENTO DAS DEMANDAS DE SISTEMA DA DET

As demandas de sistemas recebidas pela DET podem ser tratadas de duas formas diferentes: como
projetos ou como sustentação. Cada um destes tipos de tratamento segue um fluxo de processo
diferenciado. A decisão de qual abordagem deve ser utilizada está descrita no item “Critérios de
tratamento das demandas”. No caso de projetos, o processo de desenvolvimento divide-se em pré-
projeto e projeto, que se subdivide nas fases de iniciação, elaboração, construção e transição. Os
processos de sustentação de sistemas não são subdivididos.

4.1 Projetos

Um Projeto é definido em termos de suas características distintas – um projeto é um empreendimento

temporário com o objetivo de criar um produto ou serviço único. Temporário significa que tem
começo e fim bem definidos. Único significa que o produto ou serviço produzido é de alguma forma
diferente de todos os outros produtos ou serviços semelhantes.
No âmbito do Incra, consideram-se os seguintes tipos de projetos:
Documento Data Versão Página
MDS 12/3/2013 2.0 6/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Projeto de Desenvolvimento

Consiste no esforço necessário para o atendimento de uma demanda do tipo “novo sistema”, ou seja, a
criação de uma nova aplicação para atender necessidades de negócio dos usuários.

 Projetos de Melhoria

Consiste no esforço necessário para o atendimento de uma demanda de manutenção para evolução de
um sistema já existente. Normalmente os projetos de melhoria estão associados a demandas evolutivas
ou adaptativas, com tamanho funcional significativo e/ou alta criticidade para o negócio e/ou
complexidade de desenvolvimento.
O ciclo de desenvolvimento de projetos deve estar baseado nesta MDS-Incra.

4.2 Sustentação de Sistemas

Manter os sistemas de TI estáveis, em operação, prolongando sua vida útil e otimizando os

investimentos, é tão importante quanto se preocupar com projetos. A Sustentação de Sistemas tem o
objetivo de manter os sistemas em produção pelo maior tempo possível sem falhas, e ao tê-las, adotar
ações de contorno que minimizem o impacto em seu negócio, aumentando a confiança nos sistemas e
reduzindo a necessidade de novos investimentos.
No âmbito do Incra, a Divisão de Desenvolvimento e Manutenção de Sistemas – DET.1 será
responsável pelo atendimento de demandas pontuais, com ciclo de desenvolvimento mais ágil e menos
robusto. A DET.1 será responsável por atender as demandas corretivas, emergenciais, demandas
evolutivas/adaptativas com tamanho funcional pequeno e baixa criticidade para o negócio, e demandas
de serviços.

4.3 Serviços de Sistemas

Serviços de Sistemas são demandas pontuais solicitadas pelo usuário, que não envolvem tarefas de
desenvolvimento ou sustentação de sistema, mas que dependem de conhecimento técnico sobre o
sistema.
Por não envolverem o processo de desenvolvimento de Software essas demandas têm um fluxo
específico que está fora do escopo desta MDS-Incra.

Documento Data Versão Página

MDS 12/3/2013 2.0 7/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Outras solicitações, não previstas no manual de práticas de contagem do IFPUG e de acordo com o
Guia de Contagem do Incra, serão mensuradas diretamente pela estimativa de esforço/tempo
realizada pelo Incra e acordada com a Fábrica de Software.

5. CRITÉRIOS DE TRATAMENTO DAS DEMANDAS

A decisão de tratar as demandas como projetos ou sustentação de sistemas não se dará apenas pelo
tipo da demanda recebida (desenvolvimento de sistema ou manutenção), e sim pela necessidade de
acompanhamento gerencial. Para tomar esta decisão podem ser utilizados critérios como o tamanho
funcional da demanda, criticidade para o negócio, riscos envolvidos, prioridade de atendimento da
demanda, existência de outros projetos em andamento, entre outros.
A diferença primordial entre o tratamento da demanda como projeto ou sustentação de sistemas é o
processo a ser seguido. O processo para projeto é mais robusto e envolve a necessidade de
acompanhamento gerencial, sendo adequado para demandas maiores. Já o processo de sustentação de
sistemas é mais ágil e menos burocrático, sendo adequado para demandas menores e com maior
prioridade de atendimento.
Por padrão, a distribuição das demandas do Incra entre Projetos e Sustentação de Sistemas será
realizada de acordo com os seguintes critérios:

Tipo de Demanda Critérios utilizados Encaminhamento

Novo sistema N/A Projeto de Desenvolvimento
Manutenção adaptativa / Acima de 100 PFs (cem Projeto de Melhoria
evolutiva pontos de função)
Manutenção adaptativa / Até 100 PFs (cem pontos de Sustentação de Sistemas
evolutiva função)
Manutenção corretiva Dentro da garantia Sustentação de Sistemas
Manutenção corretiva Fora da garantia Sustentação de Sistemas
Serviços N/A Serviço de Sistema
Tabela 1: Encaminhamento das Demandas

Demandas classificadas como “Manutenção Adaptativa/Evolutiva” devem ter seu tamanho funcional
estimado para que seja definido o processo de desenvolvimento a que será submetida.
 Solicitações de evoluções de grande impacto seguirão o processo de desenvolvimento de
“Projeto”.
 Solicitações de evoluções de pequeno impacto seguirão o processo de desenvolvimento da
“Sustentação de Sistema”.

Documento Data Versão Página

MDS 12/3/2013 2.0 8/79
 MDS – Metodologia de Desenvolvimento de Sistemas

A decisão sobre o tratamento das demandas como Projetos ou Sustentação de Sistema é de

responsabilidade da Divisão de Desenvolvimento e Manutenção de Sistemas do Incra. A realização de
estimativas em pontos de função pela DET.1 auxiliará na identificação do tamanho funcional da
demanda.
 Quando for verificado que a demanda deve ser tratada como um projeto, a DET.1 designará o
responsável pela elaboração do “Pré-Projeto”. Somente após a análise de viabilidade do Pré-
Projeto, sendo o projeto considerado viável, o mesmo será iniciado.
 Quando for verificado que a demanda deve ser tratada como manutenção, a DET.1
encaminhará a demanda diretamente à equipe de Sustentação de Sistemas.

6. PAPÉIS E RESPONSABILIDADES
Um papel define o comportamento e a responsabilidade de um profissional (ou grupo de profissionais)
que participe do desenvolvimento do sistema. O comportamento é representado através das atividades
que cada papel deve desempenhar. As responsabilidades normalmente estão associadas aos artefatos
que cada papel deve produzir e manter ao longo das atividades que realiza. Na prática, um mesmo
papel pode ser desempenhado por mais de uma pessoa, assim como uma mesma pessoa pode assumir
vários papéis ao longo do processo de desenvolvimento do sistema.

Administrador de Banco de Dados

Responsável pela manutenção do repositório e funcionamento do banco de dados.

Principais atividades:

 Criação, avaliação, gerenciamento e manutenção das estruturas de armazenamento nos bancos

de dados (arquivos, tabelas, índices, procedures, views);
 Garantir o bom funcionamento em todos os ambientes (desenvolvimento, teste, homologação,
produção);
 Determinar e executar, em conjunto com a produção, os procedimentos (backup/recovery,
runstats/rebind) para os arquivos e tabelas dos sistemas;
 Executar as normas de acesso às informações definidas (habilitação de acesso a dados,
arquivos, bancos de dados, tabelas);
 Manter a integridade dos bancos de dados utilizados no Incra.

Documento Data Versão Página

MDS 12/3/2013 2.0 9/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Habilidades esperadas:

 Experiência em administração de banco de dados;

 Conhecimentos em: Sistemas operacionais Linux/Windows;
 Conhecimento do modelo de projeto e de bancos de dados;
 Conhecimento em otimização de performance.

Administrador de dados

Responsável pelo gerenciamento de modelos de dados corporativos do Incra, promovendo sua

conceituação, segurança, integridade e compartilhamento.

Principais atividades:

 Identificação das necessidades de informações da organização;

 Organização e estruturação dos dados, trabalhando na análise e descrição geral de dados, na
definição do modelo conceitual, no projeto lógico do banco de dados e, ainda, na análise
funcional dos dados;
 Garantia da validade, da exatidão, da consistência e da disponibilização dos dados;
 Promoção do compartilhamento dos dados da organização;
 Validação dos padrões de nomenclatura;
 Manutenção e validação dos modelos de dados dos ambientes;
 Definir níveis de integridade e segurança dos dados nos diversos níveis em que as informações
solicitadas progredirem;
 Elabora e promover padrões de dados com dicionário, nomes, tipos etc.

Habilidades esperadas:

 Conhecimento em UML (Unified Modeling Language);

 Conhecimento do modelo de projeto e de bancos de dados;
 Conhecimento em otimização de performance.

Analista de Métricas

Documento Data Versão Página

MDS 12/3/2013 2.0 10/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Responsável pela estimativa e medição dos projetos de desenvolvimento e melhoria e Sustentação de

Sistemas em Pontos de Função, geração e divulgação de indicadores de desempenho.

Principais atividades:

 Estimar tamanho funcional dos projetos/manutenção em pontos de função;

 Medir tamanho funcional dos projetos/manutenção em pontos de função;
 Manter atualizado o tamanho funcional das aplicações desenvolvidas;
 Gerar e divulgar indicadores de desempenho com base em dados coletados pela área de
desenvolvimento.

Habilidades esperadas:

 Conhecimento no negócio;
 Conhecimento em UML (Unified Modeling Language);
 Conhecimento do modelo de projeto e de bancos de dados;
 Domínio do Manual de Contagem do IFPUG.

Analista de Requisitos

Responsável por identificar os requisitos e realizar a modelagem de casos de uso, delimitando o

sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais são os atores e casos de uso
existentes e como eles interagem.

Principais atividades:

 Participar de Reuniões de Levantamento e Homologação de Requisito;

 Levantar Requisitos Funcionais e não Funcionais;
 Identificar Casos de Uso;
 Elaborar/Manter Documento de Visão;
 Elaborar/Manter Diagrama de Casos de Uso e de Atividades;
 Elaborar/Manter Protótipo de Interface;
 Elaborar/Manter Especificação de Casos de Uso;
 Elaborar/Manter Especificação de Melhoria;
 Elaborar/Manter Glossário;
Documento Data Versão Página
MDS 12/3/2013 2.0 11/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Elaborar Manual de Usuário;

Habilidades esperadas:

 Facilidade de comunicação e negociação;

 Conhecimento no negócio;
 Conhecimento em técnicas de modelagem;
 Conhecimento em UML (Unified Modeling Language);
 Conhecimento em otimização de performance.

Analista de Sistemas

Responsável pela realização dos casos de usos (modelagem) e auxílio na criação dos ambientes e
banco de dados.

Principais atividades:

 Auxiliar no desenvolvimento do projeto/manutenção;

 Realizar Caso de Uso, mantendo diagramas como classe e seqüência;
 Elaborar/Manter Modelo de Dados Lógico;
 Integrar os casos de uso construídos pelos desenvolvedores;
 Fornecer informações para a criação do ambiente de homologação e produção;
 Fornecer informações para a criação de banco de dados em produção;
 Elaborar/Manter o Relatório de Ocorrência para demandas corretivas.

Habilidades esperadas:

 Facilidade de comunicação e negociação;

 Conhecimento no negócio;
 Conhecimento em técnicas de modelagem;
 Conhecimento em UML (Unified Modeling Language);
 Conhecimento em otimização de performance.

Documento Data Versão Página

MDS 12/3/2013 2.0 12/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Analista de Testes

É o técnico responsável pela verificação dos artefatos de requisitos e pela definição das condições e
cenários de teste a ser executados, considerando a abordagem, técnicas, tipos de teste definidas no
Plano de Teste. Em casos de inconsistências identificadas, na maioria das vezes defeitos, durantes os
testes de verificação, esse profissional deve também registrá-la sem ferramentas de apoio através das
quais os Analistas de Requisito tomarão conhecimento e providências de correção ou esclarecimentos
das mesmas.

Principais atividades:

 Verificar se os artefatos de requisito estão descritos de forma clara, coesa, padronizada e

testável;
 Avaliar o resultado dos testes, notificando todos os envolvidos sobre esse resultado da
verificação dos artefatos de requisito;
 Registrar todas as inconsistências e/ou melhorias identificadas nos artefatos de requisito;
 Elaborar casos e procedimentos de testes que cubram os requisitos e tipos de testes
especificados no Plano de Teste;
 Atualizar o Relatório de Progresso dos Testes, relatando eventuais atividades não realizadas,
pendências, impedimentos na execução das atividades de teste.

Habilidades esperadas:

 Conhecimento das técnicas e estratégias de testes;

 Habilidades em diagnóstico e resolução de problemas;
 Entendimento de falhas de software comuns;
 Conhecimento do domínio;
 Conhecimento do sistema ou aplicativo em teste;
 Experiência em vários esforços de teste;
 Boa habilidade analítica;
 Mente desafiadora e curiosa;
 Atenção aos detalhes e tenacidade.

Arquiteto

Documento Data Versão Página

MDS 12/3/2013 2.0 13/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Liderar e coordenar as atividades e os artefatos técnicos no decorrer do projeto/manutenção.

Estabelecer a estrutura geral de cada visão de arquitetura. Portanto, comparado aos outros papéis, a
visão do arquiteto de software é ampla, e não detalhada. Deve ter grande conhecimento (geral), possuir
maturidade, visão e profunda experiência que permita identificar problemas rapidamente e dar
opiniões sensatas e criteriosas na falta de informações completas (RUP, 2007).

Principais atividades:

 Prospectar e desenvolver um padrão para desenvolvimento/manutenção dos sistemas;

 Selecionar e indicar o melhor software que será utilizado pelos desenvolvedores;
 Avaliar os códigos desenvolvidos e quando necessário sugerir refatoração dos mesmos;
 Criar e manter a documento da arquitetura;
 Construir componentes coorporativos;
 Ter contato e conhecimento com outras aplicações na organização;
 Interação com o corpo técnico da informática.

Habilidades esperadas:

 Experiência em desenvolvimento de sistemas;

 Conhecimento dos requisitos do sistema;
 Amplo conhecimento da tecnologia a ser utilizada para a elaboração dos modelos que
descreverão a funcionalidade do software;
 Comunicação e negociação;
 Conhecimento do negócio do cliente.

Desenvolvedor

Responsável pela construção e pelos testes unitários dos programas e componentes, de acordo com as
especificações recebidas.

Principais atividades:

 Construir unidades de implementação de acordo com as especificações e prazos estabelecidos;

 Criar e testar código de acordo com o padrão de programação estabelecido;
 Efetuar teste unitário do componente com a massa de testes elaborada;
Documento Data Versão Página
MDS 12/3/2013 2.0 14/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Documentar os resultados dos testes unitários;

 Corrigir inconsistências identificadas pela equipe da Qualidade durante a execução dos testes.

Habilidades esperadas:

 Conhecimento na linguagem de programação adotada para o projeto/manutenção;

 Conhecimento em UML (Unified Modeling Language);
 Conhecimento do modelo de projeto e de bancos de dados.

Designer de Interface

Responsável pelo desenvolvimento e manutenção dos documentos de Padronização de Telas e de

Interface de Sistemas, incluindo os requisitos e definições de usabilidade, acessibilidade e web
Standards.

Principais atividades:

 Definir o layout dos sistemas;

 Colaborar na definição de requisitos, definindo fluxos de navegação com maior usabilidade;
 Determinar a estrutura de código (X)HTML e CSS de acordo com as validações
internacionais;
 Verificação da correta aplicação dos documentos de Padronização de Telas e de Interface de
Sistemas;
 Monitoramento da implantação dos requisitos de acessibilidade e usabilidade.

Habilidades esperadas:

 Experiência em design gráfico;

 Conhecimento de ferramentas de manipulação de imagens;
 Conhecimento em padrões de navegação em sistemas computacionais;
 Conhecimento em padrões de acessibilidade, usabilidade;
 Conhecimento da arquitetura do sistema.

Gerente de Projetos
Documento Data Versão Página
MDS 12/3/2013 2.0 15/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Responsável por atuar na criação de projetos para o atendimento às demandas que necessitem da
criação de novos sistemas ou que impliquem em demandas evolutivas de grande porte.

Principais atividades:

 Ser responsável pela elaboração dos artefatos exigidos pela MDS-Incra e demais metodologias
aplicáveis;
 Garantir a precisão do escopo e controlar suas mudanças;
 Identificar, qualificar, elaborar plano de resposta e monitorar os riscos do projeto;
 Prestar informações ao Chefe da DET.1 sobre o andamento do projeto regularmente;
 Elaborar o cronograma, orçamento e plano de trabalho para o projeto;
 Acompanhar diariamente a execução do projeto com o gerente operacional, sendo responsável
solidário pela identificação, registro, análise e solução das pendências do projeto.

Habilidades esperadas:

 Experiência em definição de Projetos;

 Experiência em Planejamento do trabalho;
 Administrar o Plano de Trabalho
 Administrar conflitos;
 Administrar escopo;
 Administrar riscos;
 Administrar comunicação;
 Administrar a qualidade e a documentação;

Gestor da Informação

Responsável pelo projeto/manutenção e pelo acompanhamento do sistema na área usuária, além disso,
deve possuir um perfil gerencial na Instituição.

 Prover suporte quanto ás regras de negócio do sistema desenvolvido;

 Solicitar serviços de sistemas quanto ao desenvolvimento e/ou sustentação à DET;
 Firmar acordo de serviço com a área de desenvolvimento de sistemas;
 Fornecer informações e subsídios para o desenvolvimento de sistemas;
 Participar das reuniões acordadas;
Documento Data Versão Página
MDS 12/3/2013 2.0 16/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Validar produtos elaborados no processo de desenvolvimento;

 Homologar os produtos finais.

7. PROJETOS DE DESENVOLVIMENTO E PROJETOS DE MELHORIA

7.1 Pré-Projeto

O Pré-Projeto é uma fase que antecede a produção do software propriamente dita. Nesta fase é
identificado o escopo do projeto com base no levantamento dos requisitos do negócio. Nessa fase
também serão elaborados os seguintes artefatos: Análise de Risco e Análise de Viabilidade do
atendimento à solicitação do Gestor da Informação e em caso de viabilidade, será feito um maior
detalhamento do escopo do projeto identificando, em nível macro, suas funcionalidades, as fronteiras
da aplicação, a interface com outros sistemas e uma estimativa do tempo necessário para a produção
do software. A documentação gerada na fase da MDS-Incra denominada de Pré-Projeto será
encaminhada ao Comitê de Tecnologia da Informação (CTI) para aprovação e posteriormente utilizada
na fase de Projeto.

Figura: Visão Geral

Fonte: Adaptado do RUP

Documento Data Versão Página

MDS 12/3/2013 2.0 17/79
 MDS – Metodologia de Desenvolvimento de Sistemas

7.1.1 Fluxo de Comunicação do Pré-Projeto

Figura: Fluxo do Pré-Projeto

7.1.2 Detalhamento das Atividades do Pré-Projeto

7.1.2.1 Atividades Específicas do Pré-Projeto

Etapas Descrição Atores Envolvidos

Iniciar Nesta etapa o requisitante encaminhará à DET  Área Requisitante
Solicitação de formulário de solicitação de demanda.  Coordenador DET
Demanda A DET recebe e encaminha a solicitação à DET-1  Chefia DET.1
para análise e estudo preliminar de viabilidade do  Analista de Requisitos
desenvolvimento da nova demanda.

Reuniões com os gestores serão realizadas para o

estudo da viabilidade.
Atividades:
 Analisar recebimento da solicitação de
demanda pelo gestor do sistema;
 Realizar reuniões de levantamento inicial
junto aos gestores;
 Realizar o registro inicial da demanda nas
ferramentas de controle e gestão da DET.

Documento Data Versão Página

MDS 12/3/2013 2.0 18/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Gerar Nesta etapa, com base nos levantamentos  Chefia DET-1

Documentação preliminares realizados com os gestores do  Analista de Métrica
de Viabilidade sistema serão elaborados os documentos a serem
encaminhados ao Comitê de Tecnologia da
Informação (CTI).
Atividades:
 Elaborar o documento Análise de Risco (AR);
 Elaborar o documento de Análise de
Viabilidade do Projeto (AVP;
 Contagem estimada do custo do projeto;

Aprovação pelo O Comitê de posse das documentações de  CTI

Comitê de viabilidade recebidas e se estiverem em acordo irá
Tecnologia da analisar e aprovar, se for o caso.
Informação Atividades:
(CTI)  Analisar documentação recebida;
 Emitir o Termo de Aprovação, se aprovado;
 Encaminhar documentação aprovada à DET.

Efetivação do Nesta etapa, após a aprovação pelo CTI, a DET  Coordenador DET
Início do Projeto encaminhará à Contratada solicitação de uma  Chefia DET.1
Proposta de Projeto. Estando a proposta aprovada
deverá ser emitida uma Ordem de Serviço à
Contratada para que seja dado início ao
desenvolvimento do sistema.
Atividades:
 Emitir solicitação de Proposta de Projeto à
Contratada;
 Receber e aprovar a Proposta de Projeto;
 Emitir Ordem de Serviço.

7.1.2.2 Artefatos de Entrada/Saída

Artefatos Template (TP) Descrição

Solicitação de Demanda INCRA – Sigla Projeto – SD. Constará um resumo com os dados
principais para a solicitação de
desenvolvimento pelo requisitante.

Análise de Risco – AR INCRA – Sigla Projeto – AR Descrever os subsídios para a

tomada de decisão pelo CTI, quanto
aos riscos que poderá afetar
viabilidade do projeto.

Documento Data Versão Página

MDS 12/3/2013 2.0 19/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Análise de Viabilidade do INCRA – Sigla Projeto – AVP Descrever os subsídios para a

Projeto – AVP tomada de decisão pelo CTI, quanto
à: avaliação da necessidade,
explicitação da motivação,
especificação de requisitos, prazo,
segurança, entre outros.

Proposta de Projeto INCRA – Sigla do Projeto – Descrever os subsídios para manter

Proposta de Projeto um acordo de serviço entre Gestor
da Informação e DET.

Ordem de Serviço INCRA – Sigla do Projeto – Descreve os dados necessários para

Ordem de Serviço a solicitação de início do
desenvolvimento da demanda junto
à contratada e aprovação por ambos
(Gestor da Informação e DET).

Ata de Reunião INCRA – Sigla Projeto – Ata Descrever os assuntos tratados na

de Reunião reunião inicial, com assinatura dos
participantes.

7.2 Projeto

Todos os projetos, sejam de desenvolvimento ou de sustentação, serão obrigatoriamente

acompanhados pela DET.1 do Incra. Na etapa de Projeto, a atividades do gerenciamento do projeto
devem se orientar pelas boas práticas do Gerenciamento de Projetos do PMI. As demais atividades do
processo de desenvolvimento de software baseiam-se no Processo Unificado da Rational – RUP,
seguindo os conceitos de desenvolvimento iterativo e incremental e sua subdivisão em fases. Assim,
para a condução de Projetos, a Metodologia de Desenvolvimento de Sistemas do Incra foi dividida nas
seguintes fases: Iniciação, Elaboração, Construção e Transição.
Para cada fase, foram descritas as principais atividades, os responsáveis e os envolvidos em cada uma
delas, os artefatos a serem produzidos, o material de apoio disponibilizado e as ferramentas usadas.
A conclusão de cada fase é identificada por um marco principal, ou seja, cada fase acontece
basicamente no intervalo de tempo entre dois marcos principais.

Documento Data Versão Página

MDS 12/3/2013 2.0 20/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Figura: Visão Geral

Fonte: Adaptado do RUP

Uma avaliação satisfatória permite que se passe para a próxima fase. Uma passagem pelas quatro fases
corresponde a um ciclo de desenvolvimento. Cada passagem pelas quatro fases produz uma geração
do software, ou seja, um pacote executável do sistema.

7.2.1 Iniciação

Como o próprio nome identifica essa é a fase em que se dá o start do Projeto. Podem-se ter várias
iterações na iniciação, mas o normal é que ocorra apenas uma iteração nesta fase.
O foco da fase é identificar em conjunto com os Stakeholders qual o propósito do projeto propondo
uma solução para as necessidades apresentadas e obter a concordância dos envolvidos.
O esforço maior dessa fase é realizar uma análise de negócio em alto nível contemplando os requisitos
do projeto.
Os principais objetivos da fase de iniciação incluem:
 Definir o escopo da solução - A equipe de desenvolvimento deve definir o escopo da solução
em termos de processos, organizações e sistemas. O modelo de caso de uso auxilia a
identificar as fronteiras da solução proposta.
 Definir as características da solução proposta- Sempre que possível, os Stakeholders devem
ser questionados sobre as funcionalidades que eles esperam que sejam disponibilizas no
sistema, atribuindo-lhes prioridades no projeto.

Documento Data Versão Página

MDS 12/3/2013 2.0 21/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Definir riscos e prioridades - O Processo Unificado prevê que os casos de uso que ofereçam
os maiores riscos para o sucesso no desenvolvimento da solução devem ser atacados já no
início do projeto. É importante que a equipe de desenvolvimento, juntamente com os
Stakeholders, defina as prioridades de desenvolvimento desses casos de uso.
 Capturar um vocabulário comum - Todo projeto tem suas terminologias especializadas, ou
seja, as terminologias envolvidas com o negócio analisado. O Glossário é importante para
garantir que todos os envolvidos e todos os membros da equipe de desenvolvimento
interpretem os termos da mesma forma. O Glossário pode conter: Termos Técnicos, Termos
de Negócios, Abreviações, Acrônimos, Descrição de Funções, dentre outros. O Glossário deve
ser refinado constantemente.
 Definir a arquitetura do Projeto - Exibir, e talvez demonstrar, pelo menos uma opção de
arquitetura para alguns cenários básicos.

Em qualquer momento do desenvolvimento do projeto pode surgir a necessidade de mudança oriunda

de uma solicitação interna (membros da equipe de desenvolvimento) ou externa (Área Gestora,
Legislação, entre outros) sendo necessário o gerenciamento das atividades para atendimento dessa
solicitação de mudança. Ao final de cada fase de desenvolvimento, é descrita a atividade “Gerenciar
Mudanças” através da qual é realizada a avaliação do impacto, a atualização dos documentos
impactados, a execução da solicitação de mudança e a sua conclusão através da sua homologação pelo
Solicitante.
Após a homologação pelo Gestor da Informação dos artefatos de requisito e do sistema, haverá
contagem estimativa e/ou funcional a depender da fase a fim de auxiliar o planejamento e o controle
do escopo do projeto. No Pré-Projeto e na Iniciação é realizada estimativa, enquanto na Elaboração e
na Construção é realizada a medição do tamanho funcional do projeto.

Documento Data Versão Página

MDS 12/3/2013 2.0 22/79
 MDS – Metodologia de Desenvolvimento de Sistemas

7.2.1.1 Fluxo de Comunicação da Iniciação

7.2.1.2 Detalhamento das Atividades da Iniciação

Etapas Descrição Atores envolvidos

Preparar Ambiente Nesta etapa deverá ser criado o repositório de  Analista de Sistemas
do Projeto armazenamento junto ao SVN e atualizar as  Gerente de Projetos
ferramentas de gestão e controle do projeto.

Atividades:


Criar repositório de armazenamento junto
ao SVN
 Atualizar ferramentas de gestão e
controle do projeto
Definir Escopo do Com base nas documentações aprovadas na  Gerente de Projetos

Documento Data Versão Página

MDS 12/3/2013 2.0 23/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Projeto fase de pré-Projeto e reuniões  Analista de Requisitos

complementares com o gestor deverão ser  Analista de Sistemas
 Gestor do Sistema
identificados os requisitos do sistema.

Atividades:

 Identificar Requisitos
 Elaborar o Documento de Visão
 Elaborar o Plano de Desenvolvimento de
Software
 Elaborar Plano de Iteração

Identificar Com base nas informaçõeslevantadas  Analista de Requisitos

Requisitos referentes aos requisitos funcionais, não-  Analista de Sistemas
funcionais, regras de negócio, riscos e demais
dados necessários serão identificados os
casos de uso do sistema.

Atividades:

 Elaborar a Especificação de Requisitos

 Preparar protótipo não-funcional
(detalhar as telas do sistema e suas regras
de apresentação)

Definir Arquitetura Nesta etapa é definida uma arquitetura inicial  Analista de Requisitos
Inicial do sistema. Será definido o grupo inicial de  Arquiteto
elementos significantes para serem utilizados
como base de análise a fim de identificar as
realizações de casos de uso.

Atividades:

 Elaborar o Documento de Arquitetura do

projeto.
Recontagem dos Ao término de cada fase do ciclo de vida do  Analista de Métrica
Pontos de Função projeto deverá haver uma recontagem dos
pontos de função, visando adequar a
estimativa de complexidade do software
fabricado ao aumento de conhecimento do

Documento Data Versão Página

MDS 12/3/2013 2.0 24/79
 MDS – Metodologia de Desenvolvimento de Sistemas

processo de negócio envolvido.

Gerenciar Iteração Essa atividade é realizada durante todo o  Gerente de Projetos
ciclo de vida do projeto. A meta desta
atividade consiste em identificar riscos e
gerenciar as mudanças de forma que possam
ser atenuadas, estabelecendo metas da
iteração e apoiando a equipe de
desenvolvimento para alcançar essas metas.

Atividades:

 Gerenciar as mudanças ocorridas

 Gerenciar os riscos detectados
 Atualizar o Plano de Iteração

7.2.1.3 Artefatos de Entrada/Saída

Artefatos Template (TP) Descrição

Especificação de INCRA – Sigla Projeto – Visa detalhar a descrição dos
Requisitos Especificação de Requisitos requisitos funcionais, aplicáveis ao
projeto como um todo e requisitos
não funcionais, que descrevem
atributos que o sistema deve possuir
ou restrições sob as quais ele deve
operar, bem como, as iterações que
irão ocorrer, como os marcos,
produtos que serão entregues e seus
cronograma.

Na fase seguinte este documento

poderá sofrer alteração e nova
entrega.
Documento de INCRA – Sigla Projeto – Documento Visa fornecer uma visão geral de
Visão de Visão todo o projeto, como: finalidade,
escopo, resumo do negócio,
usuários, entre outros.
Plano de Projeto INCRA – Sigla Projeto – Plano de Define todas as ações do projeto,
Documento Data Versão Página
MDS 12/3/2013 2.0 25/79
 MDS – Metodologia de Desenvolvimento de Sistemas

de Software Projeto de Software para que o mesmo possa atender as

necessidades do requisitante com
qualidade, tempo e custos previstos.

Nas fases seguintes este documento

poderá sofrer alteração e nova
entrega.
Documento de INCRA – Sigla do Projeto – Este documento descreve uma
Arquitetura Documento de Arquitetura visão inicial da arquitetura do
Inicial sistema, empregando diferentes
visões arquiteturais para abordar
diferentes aspectos do sistema.

Nas fases seguintes este documento

poderá sofrer alteração e nova
entrega.
Relatório de INCRA – Sigla do Projeto – Relatório Descreve detalhadamente a
Controle de de Controle de Mudança solicitação da mudança,
Mudanças enfatizando os motivos, condições,
restrições e premissas para a
implementação das mudanças e
aprovações.

Este artefato poderá ou não ser

entregue nesta fase. Irá depender
das mudanças que poderão ocorrer.
Plano de Iteração INCRA - Sigla Projeto - Plano de Este artefato descreve um conjunto
Iteração de atividades e tarefas divididas por
seqüências de tempo, com recursos
atribuídos e dependências de
tarefas. Contém uma estrutura
detalhada da divisão de trabalho
para a atividade e as atribuições
de responsabilidade,
proporcionando critérios de

Documento Data Versão Página

MDS 12/3/2013 2.0 26/79
 MDS – Metodologia de Desenvolvimento de Sistemas

avaliação para a iteração.

Este artefato poderá ou não ser
entregue nesta fase. Irá depender do
acordado entre as partes
interessadas.
Homologação de INCRA - Sigla Projeto - Termo de Este documento é utilizado para a
Produtos Homologação homologação dos produtos
entregues ao Incra. Esta
homologação pode ocorrer para os
produtos entregues, por fase ou
iteração ou no encerramento total
de entrega de todas as fases do
sistema.
Será utilizado em todas as fazes em
que houver produtos a serem
entregues e homologados.
Ata de Reunião INCRA – Sigla Projeto – Ata de Descrever os assuntos tratados na
Reunião reunião, com assinatura dos
participantes.
Este artefato será utilizado em todas
as fases do projeto.

7.2.2 Elaboração

O foco maior dessa fase é definir e refinar os artefatos de requisitos, "estabilizar" a arquitetura do
projeto com base nos requisitos levantados na fase de Iniciação, isso não significa desenvolver toda a
arquitetura, mas sim identificar se a mesma possui base sólida o suficiente para suportar o
desenvolvimento que irá iniciar na fase de Construção. É comum que existam várias iterações nessa
fase.
A Fase não é exclusiva de desenvolvimento de arquitetura, assim deve haver desenvolvimento e
refinamentos de casos de uso e regras de negócio como também o detalhamento dos requisitos
levantados na fase de Iniciação.
Os principais objetivos da fase de elaboração incluem:
 Garantir os requisitos - Assegurar que os requisitos estejam documentados e estáveis.
 Garantir a arquitetura – Assegurar que a arquitetura esteja definida e estável
Documento Data Versão Página
MDS 12/3/2013 2.0 27/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Assegurar que os riscos estejam sendo mitigados – Os riscos identificados devem estar
suficientemente diminuídos a fim de determinar com segurança o custo e a programação para
a conclusão do desenvolvimento.

Em qualquer momento do desenvolvimento do projeto pode surgir a necessidade de mudança oriunda

de uma solicitação interna (membros da equipe de desenvolvimento) ou externa (Área Gestora,
Legislação, entre outros) sendo necessário o gerenciamento das atividades para atendimento dessa
solicitação de mudança. Ao final de cada fase de desenvolvimento, é descrita a atividade “Gerenciar
Mudanças” através da qual é realizada a avaliação do impacto, a atualização dos documentos
impactados, a execução da solicitação de mudança e a sua conclusão através da sua homologação pelo
Solicitante.
Após a homologação pelo Gestor da Informação dos artefatos de requisito e do sistema, haverá
contagem estimativa e/ou funcional a depender da fase a fim de auxiliar o planejamento e o controle
do escopo do projeto. No Pré-Projeto e na Iniciação é realizada estimativa, enquanto na Elaboração e
na Construção é realizada a medição do tamanho funcional do projeto.

7.2.2.1 Fluxo de Comunicação da Elaboração

Documento Data Versão Página

MDS 12/3/2013 2.0 28/79
 MDS – Metodologia de Desenvolvimento de Sistemas

7.2.2.2 Detalhamento das Atividades da Elaboração

Etapas Descrição Atores envolvidos

Elaborar Casos de Com base nos dados levantados serão  Analista de Requisitos
Uso especificados os Casos de Uso, definidas as  Arquiteto
telas, regras de negócio, Diagrama de Caso
de Uso e Diagrama de Atividades.

Atividades:

 Especificar os Casos de Uso;

 Especificar as mensagens do sistema;
 Definir as telas do sistema e suas regras
de apresentação e negócio;
 Definir as regras de negócio;
 Especificar o diagrama de caso de uso;
 Especificar o diagrama de atividades.
Refinar Requisitos Nesta etapa deve ser verificado se algum  Analista de Requisitos
requisito sofreu alteração, procedendo no
refinamento das especificações de caso de
uso e do diagrama de caso de uso.

Atividades:

 Refinar o diagrama de caso de uso

 Refinar a Especificação de requisitos
Projetar Arquitetura Nesta etapa o arquiteto analisa as restrições  Arquiteto
arquitetônicas, identifica os recursos  Analista de Requisitos
disponíveis para construir o sistema, define
como o sistema será estruturado e identifica
as primeiras abstrações e mecanismos que
devem ser fornecidas pela arquitetura.

Atividades:

Documento Data Versão Página

MDS 12/3/2013 2.0 29/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Refinar o documento de Arquitetura

Modelagem de Banco Esta atividade tem como objetivo a  DBA
de Dados elaboração do projeto de banco de dados,  Arquiteto
com sua estrutura de armazenamento,
restrições de integridade e caminhos de
acesso aos dados visando a otimização
(índices, visões e outros).

Atividades:

 Gerar o modelo conceitual lógico

 Gerar o modelo conceitual físico
Recontagem dos Ao término de cada fase do ciclo de vida do  Analista de Métrica
Pontos de Função projeto deverá haver uma recontagem dos
pontos de função, visando adequar a
estimativa de complexidade do software
fabricado ao aumento de conhecimento do
processo de negócio envolvido.
Planejar e Gerenciar Essa atividade é realizada durante todo o  Gerente de Projetos
Iterações ciclo de vida do projeto. A meta desta
atividade consiste em identificar riscos e
gerenciar as mudanças de forma que
possam ser atenuadas, estabelecendo metas
da iteração e apoiando a equipe de
desenvolvimento para alcançar essas metas.

Atividades:

 Gerenciar as mudanças ocorridas

 Gerenciar os riscos detectados
 Atualizar a Especificação de Requisitos

7.2.2.3 Artefatos de Entrada/Saída

Artefatos Template (TP) Descrição

Especificação de INCRA – Sigla Projeto – ECU - Visa detalhar as atividades a serem
Documento Data Versão Página
MDS 12/3/2013 2.0 30/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Caso de Uso Nome do Caso de Uso executadas por intermédio da

descrição dos tópicos do fluxo
principal, fluxo alternativo, regras
de negócio, glossário, diagrama de
casos de uso, diagrama de
atividades, interface de telas, e
mensagens do sistema.

Nas fases seguintes este documento

poderá sofrer alteração e nova
entrega.
Modelo de Dados INCRA – Sigla do Projeto – Detalha a nomenclatura dos objetos
Modelo de Dados Físico do Modelo de Dados (Tabelas,
Views, Stored Procedures, Trigger,
Indexes, Keys, Constraints, etc).

OBS: Fornecer todos os scripts de

criação da estrutura de Banco de
Dados.

Na fase seguinte este documento

poderá sofrer alteração e nova
entrega.
Relatório de INCRA – Sigla do Projeto – Descreve detalhadamente a
Controle de Relatório de Controle de Mudança solicitação da mudança, enfatizando
Mudanças os motivos, condições, restrições e
premissas para a implementação das
mudanças e aprovações.

Este artefato poderá ou não ser

entregue nesta fase. Irá depender
das mudanças que poderão ocorrer.

Documento Data Versão Página

MDS 12/3/2013 2.0 31/79
 MDS – Metodologia de Desenvolvimento de Sistemas

7.2.3 Construção

Na fase de construção ocorre o processo de desenvolvimento de sistemas em que um produto é

desenvolvido de maneira iterativa até que esteja pronto para ser avaliado pelo Gestor da Informação.
Ocorrerá o desenvolvimento do código fonte, componentes, consultas e chamadas. Os testes de
componentes e integração serão executados conforme especificados na documentação do sistema e
seguindo os padrões da Metodologia de Desenvolvimento de Sistemas do Incra. Essa fase exige a
integração entre Desenvolvedor, Analista de Sistema, Analista de Requisito, Analista de Teste,
Arquiteto e Administrador de Dados para a análise, construção e testes do sistema.
Os principais objetivos da fase de construção incluem:
 Integrar o produto de Software – A equipe pode realizar pequenas entregas do produto de
Software disponibilizando por módulos ou funcionalidades desse sistema, porém neste
momento deve-se realizar a entrega do Pacote Executável do Sistema com o produto de
software completo e funcional de cada iteração e/ou sistema.
 Produzir documentação do sistema – Atualizar Glossário, Manual do Usuário, Ajuda do
Sistema e os documentos necessários para a homologação de cada iteração e/ou sistema.
 Finalizar o produto de Software - A equipe de desenvolvimento deve concluir a análise, o
design, o desenvolvimento e o teste de todas as funcionalidades necessárias.
 Validar o sistema - Validar o novo Software construído em confronto com as expectativas do
usuário.

Em qualquer momento do desenvolvimento do projeto pode surgir a necessidade de mudança oriunda

de uma solicitação interna (membros da equipe de desenvolvimento) ou externa (Área Gestora,
Legislação, entre outros) sendo necessário o gerenciamento das atividades para atendimento dessa
solicitação de mudança. Ao final de cada fase de desenvolvimento, é descrita a atividade “Gerenciar
Mudanças” através da qual é realizada a avaliação do impacto, a atualização dos documentos
impactados, a execução da solicitação de mudança e a sua conclusão através da sua homologação pelo
Solicitante.
Após a homologação pelo Gestor dos artefatos de requisito e do sistema, haverá contagem estimativa
e/ou funcional a depender da fase a fim de auxiliar o planejamento e o controle do escopo do projeto.
No Pré-Projeto e na Iniciação é realizada estimativa, enquanto na Elaboração e na Construção é
realizada a medição do tamanho funcional do projeto.

Documento Data Versão Página

MDS 12/3/2013 2.0 32/79
 MDS – Metodologia de Desenvolvimento de Sistemas

7.2.3.1 Fluxo de Comunicação da Construção

7.2.3.2 Detalhamento das Atividades da Construção

Etapas Descrição Atores envolvidos

Identificar / Nesta etapa deve ser verificado se algum  Analista de Requisitos
Refinar Requisitos requisito sofreu alteração, procedendo no  Arquiteto
refinamento das especificações de caso de uso
e do diagrama de caso de uso.

Atividades:

 Refinar as especificações de caso de uso;

 Refinar o diagrama de caso de uso
 Refinar a especificação de requisitos

Construção de Nesta etapa serão criadas as tabelas, colunas e  Administrador de Dados

Bases de Dados atributos para cada entidade identificada na

Documento Data Versão Página

MDS 12/3/2013 2.0 33/79
 MDS – Metodologia de Desenvolvimento de Sistemas

modelagem de banco de dados.

Atividades:

 Implementação de modelagem de banco

 Implementação de procedures
 Gerar o script completo da criação do
Banco de Dados, incluindo a definição das
áreas lógicas de armazenamento e objetos
de otimização de acesso.
Implementação de De posse do protótipo navegável de interface,  Desenvolvedor
Interfaces dos diagramas de interação de usuário e da
definição dos serviços (interface dos
componentes), o desenvolvedor deverá realizar
a codificação das interfaces (telas), integrando
as mesmas aos componentes que foram
codificados.

Atividades:

 Codificação de telas
 Implementação de protótipos
 Verificação das funcionalidades/
Integridades dos protótipos
 Disponibilizar o Build para teste
Implementação Esta atividade tem como objetivo a geração de  Desenvolvedor
dos Casos de Uso códigos-fontes para os diversos elementos
componentes do sistema, visando uma versão
operacional do sistema.

Atividades:

 Implementação dos requisitos funcionais

 Implementação dos requisitos não-
funcionais
 Implementação da arquitetura

Documento Data Versão Página

MDS 12/3/2013 2.0 34/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Gerar arquivo contendo todos os códigos

fontes da aplicação e documentação do
código gerado:
 JAVADOC – projetos JAVA
 NDOC – projetos DOT.NET
 PHPDOC – projetos PHP
 Elaborar o Plano de Implementação/
Integração
Implementação Após a codificação, o produto gerado (sistema  Analista de Teste
dos Casos de Teste ou parte do mesmo) deverá ser testado com a
finalidade de encontrar possíveis erros de
codificação ou mesmo de interpretação da
documentação de análise e de projeto. De
posse da documentação de Análise e de
Projeto, os analistas de sistemas responsáveis
pelos testes da aplicação deverão verificar se o
produto gerado atende aos requisitos de forma
adequada.

Atividades:

 Elaborar Roteiros de Testes

 Realizar testes
 Elaborar artefato Evidência de Testes
Recontagem dos Ao término de cada fase do ciclo de vida do  Analista de Métrica
Pontos de Função projeto deverá haver uma recontagem dos
pontos de função, visando adequar a estimativa
de complexidade do software fabricado ao
aumento de conhecimento do processo de
negócio envolvido.
Planejar e Essa atividade é realizada durante todo o ciclo  Gerente de Projetos
Gerenciar de vida do projeto. A meta desta atividade
Iterações consiste em identificar riscos e gerenciar as
mudanças de forma que possam ser atenuadas,
estabelecendo metas da iteração e apoiando a

Documento Data Versão Página

MDS 12/3/2013 2.0 35/79
 MDS – Metodologia de Desenvolvimento de Sistemas

equipe de desenvolvimento para alcançar essas

metas.

Atividades:

 Gerenciar as mudanças ocorridas

 Gerenciar os riscos detectados
 Atualizar a Especificação de Requisitos

7.2.3.3 Artefatos de Entrada/Saída

Artefatos Template (TP) Descrição

Roteiro de Teste INCRA – Sigla Projeto – Roteiro Documento que reúne um grupo
de Teste – Nome do Caso de Uso de casos de testes que devem ser
executados em uma sequência
lógica para cada Caso de Uso.
Evidência de Testes INCRA – Sigla Projeto –Evidência Evidencia o resultado dos testes
de testes – Nome do Caso de Uso realizados. Serve de base para que
o desenvolvedor verifique o que
deve ser corrigido.
Plano de INCRA – Sigla Projeto – Plano de Contém a organização e estilo do
implementação / Implementação código e ambiente de integração
Integração
Projeto/Solução Arquivo contendo todos os códigos Encaminhar documentação do
(Código Fonte) fontes da aplicação e scripts de código gerado:
Banco de Dados.
JAVA.doc – projetos JAVA

NDOC – projetos DOT.NET

Relatório de Controle INCRA – Sigla do Projeto – Descreve detalhadamente a
de Mudanças Relatório de Controle de Mudança solicitação da mudança,
enfatizando os motivos, condições,
restrições e premissas para a
implementação das mudanças e
aprovações.

Documento Data Versão Página

MDS 12/3/2013 2.0 36/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Este artefato poderá ou não ser

entregue nesta fase. Irá depender
das mudanças que poderão
ocorrer.

7.2.4 Transição

O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais.
É possível que nessa fase existam diversas iterações, pois pode ser necessário realizar treinamentos,
migrações de dados de sistemas legados e ajustes finais. Nesse momento, o foco fica em Gerência de
Configuração e Mudança, pois existe a preocupação com detalhes e ajustes necessários a geração da
entrega (release) final.
Nesse momento é colhido o feedback do usuário quanto ao produto de software desenvolvido. Os
artefatos produzidos são o próprio produto através de uma build de materiais de suporte para o
usuário. Caso o usuário não esteja satisfeito é possível que essa fase dispare um ciclo novo de
desenvolvimento. É possível existir tarefas de requisitos, design, construção e testes nessa fase, mas
espera-se que em escala muito pequena. Nesse ponto começa a gestão de ambientes, servidores de
aplicação e banco de dados.
Os objetivos principais da Fase de Transição são:
 Liberar Sistema – Liberar a release completa do novo sistema;
 Tratar dados – Prepara conversão de bancos de dados operacionais, migrações de dados de
sistemas legados;
 Capacitar Usuários - Capacitação de usuários e equipe de manutenção;
 Estabilizar Sistema – Atividades de ajuste, como correção de erros, melhorando desempenho e na
usabilidade;
 Avaliar entregas - Avaliação das entregas (releases) tendo como base a visão completa e os
critérios de aceitação para o produto;
 Obter aceite final – Obtenção do aceite dos envolvidos com relação ao sistema disponibilizado.

Em qualquer momento do desenvolvimento do projeto pode surgir a necessidade de mudança oriunda

de uma solicitação interna (membros da equipe de desenvolvimento) ou externa (Área Gestora,
Legislação, entre outros) sendo necessário o gerenciamento das atividades para atendimento dessa
solicitação de mudança. Ao final de cada fase de desenvolvimento, é descrita a atividade “Gerenciar
Mudanças” através da qual é realizada a avaliação do impacto, a atualização dos documentos

Documento Data Versão Página

MDS 12/3/2013 2.0 37/79
 MDS – Metodologia de Desenvolvimento de Sistemas

impactados, a execução da solicitação de mudança e a sua conclusão através da sua homologação pelo
Solicitante.
Após a homologação pelo Gestor de Informação quanto aos artefatos de requisito e do sistema, haverá
contagem estimativa e/ou funcional a depender da fase a fim de auxiliar o planejamento e o controle
do escopo do projeto. No Pré-Projeto e na Iniciação é realizada estimativa, enquanto na Elaboração e
na Construção é realizada a medição do tamanho funcional do projeto.

7.2.4.1 Fluxo de Comunicação da Transição

7.2.4.2 Detalhamento das Atividades da Transição

Etapas Descrição Atores envolvidos

Homologação do Nesta etapa o projeto é aprovado internamente e,  Gerente de Projetos
Sistema após, é encaminhado para a homologação pelo  Chefe DET.1
Gestor da Informação. Esta homologação pode  Analista de Sistemas
ocorrer por fase ou iteração ou no encerramento  Gestor da Informação
total de entrega de todas as fases do sistema.

Atividades:

 Emissão e envio ao Gestor da Informação do

Documento Data Versão Página

MDS 12/3/2013 2.0 38/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Termo de Homologação / Aceite

 Elaborar os manuais de Ajuda e do Sistema
Implantação do Nesta etapa será planejada de que forma o sistema  DBA
Sistema deverá ser implantado, como e quando serão  Analista de Produção
realizados os treinamentos aos usuários.  Analista de Sistemas
 Gerente de Projetos
Atividades:

 Elaborar o Plano de Implantação

 Implantar o sistema no ambiente de produção
 Treinar os usuários do sistema
Planejar e Essa atividade é realizada durante todo o ciclo de  Gerente de Projetos
Gerenciar vida do projeto. A meta desta atividade consiste em
Iterações identificar riscos e gerenciar as mudanças de forma
que possam ser atenuadas, estabelecendo metas da
iteração e apoiando a equipe de desenvolvimento
para alcançar essas metas.

Atividades:

 Gerenciar as mudanças ocorridas

 Gerenciar os riscos detectados
Encerramento A etapa de encerramento pode ocorrer por fase ou  Gerente de Projetos
iteração do projeto ou quando todos os produtos  Chefe DET.1
pertencentes ao escopo do projeto forem  Coordenador DET
homologados.  Gestor da Informação
 Equipe
 O Gerente de Projetos elabora o Termo de
Encerramento do Projeto e o envia para
aprovação pelo Gestor da Informação,
identificando todos os produtos e fases
homologadas, de acordo com os Termos de
Homologação de Produtos.

Atividades:

 Obter aprovação do Termo de Encerramento do

Documento Data Versão Página
MDS 12/3/2013 2.0 39/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Projeto;
 Realizar uma nova contagem detalhada e obter a
aprovação do Gestor da Informação;
 Realizar reuniões de encerramento com o
Gestor da Informação;
 Realizar reuniões de encerramento com o
Coordenador e chefe da DET/DET.1;
 Realizar reunião de encerramento com a equipe;
 Avaliar e registrar as Lições Aprendidas do
projeto;
 Registrar o encerramento nas ferramentas de
gerenciamento de projetos;
 Arquivar toda a documentação do projeto;

7.2.4.3 Artefatos de Entrada/Saída

Artefatos Template (TP) Descrição

Termo de Homologação INCRA – Sigla Projeto – Termo de Descreve os produtos a serem
ou Aceite Homologação homologados pelo requisitante.

Plano de Implantação INCRA – Sigla Projeto – Plano de Descreve o planejamento feito

Implantação com o requisitante para a
implantação do sistema.

Manual do Sistema INCRA – Sigla Projeto – Manual Guia de procedimentos para a

do Sistema utilização do sistema pelo
Gestor da Informação

Ajuda Help on-line Ajuda on-line para os usuários

do sistema.

Termo de Encerramento INCRA – Sigla Projeto – Termo de Descrever os produtos

Encerramento entregues, resultado do projeto e
o aceite do requisitante para
apresentação às chefias da DET.

Documento Data Versão Página

MDS 12/3/2013 2.0 40/79
 MDS – Metodologia de Desenvolvimento de Sistemas

8. SUSTENTAÇÃO DE SISTEMAS
Manter os sistemas de Tecnologia da Informação – TI estáveis e em operação, prolongando sua vida
útil e otimizando os investimentos, é tão importante quanto os projetos de desenvolvimento. A
Sustentação de Sistemas tem o objetivo de manter os sistemas em produção pelo maior tempo possível
sem falhas, e ao tê-las, adotar ações de contorno que minimizem o impacto em seu negócio,
aumentando a confiança nos sistemas e reduzindo a necessidade de novos investimentos. No âmbito
do Incra, a Sustentação de Sistemas será responsável pelo atendimento de demandas pontuais, com
ciclo de desenvolvimento mais ágil e menos robusto. A Divisão de Desenvolvimento e Manutenção de
Sistemas será responsável por atender as demandas corretivas, demandas evolutivas/adaptativas com
tamanho funcional pequeno e baixa criticidade para o negócio e demandas emergenciais.

9. PROJETOS DE BUSINESS INTELLIGENCE (BI) – DESENVOLVIMENTO E

SUSTENTAÇÃO

Business Intelligence ou Inteligência Empresarial é o conjunto de processos, metodologias, métricas,

tecnologias e ferramentas que permitem uma empresa gerenciar de forma global o seu negócio,
apoiando os gestores no processo de tomada de decisão (W. H. Inmon).
Data Warehouse (DW) é um conjunto de bancos de dados históricos, integrados e não voláteis criados
para apoiar o processo de tomada de decisão (BI) (W. H. Inmon).
Data Mart é um sub-conjunto do DW. Um Data Mart corresponde às necessidades de informação de
uma determinada comunidade de usuários (W. H. Inmon). São dados referentes a um assunto
específico (p.e. recuperação de crédito, depósito à vista, entre outros que focam em uma ou mais áreas
específicas).
Extract Transform Load são atividades destinadas à extração de dados de diversos sistemas,
transformação desses dados conforme regras de negócios e por fim a carga dos dados em um Data
Mart ou um Data Warehouse.

9.1 Iniciação

Esta fase é composta pelas etapas de Planejamento do Projeto e Definição dos Requisitos.

1 – Planejamento do Projeto

O planejamento do projeto deverá estar alinhado ao PMBOK. Esta atividade consiste na elaboração
da Proposta de Projeto (PP). Deverá ser elaborado e apresentado a DET o planejamento detalhado da

Documento Data Versão Página

MDS 12/3/2013 2.0 41/79
 MDS – Metodologia de Desenvolvimento de Sistemas

execução das tarefas (prazos, recursos, formas de comunicação e de acompanhamento da execução do

projeto), o qual deverá ser aprovado pela DET.

A Proposta de Projeto deverá organizar o restante do projeto em no mínimo duas iterações, e

especificar os temas a serem implementados em cada uma.

Produtos:

 Documento contendo o registro de reuniões;

 Termo de Abertura do Projeto (TAP);
 Proposta de Projeto detalhado (incluindo o cronograma e contagem de ponto estimada);
 Aprovação pela DET.

2 – Definição dos Requisitos

A atividade definição dos requisitos será dividida em duas tarefas: Levantamento das Necessidades
do Negócio e Levantamento das Fontes de Dados.

a) Levantamento das Necessidades do Negócio

Consiste no levantamento das necessidades que o sistema deverá atender. Nesta etapa identifica-
se o público alvo e os requisitos funcionais e não funcionais para o Data Mart.

Identificam-se os temas (assuntos) que irão compor o Data Mart e organiza-se os requisitos de
acordo com os temas identificados. Desta forma o levantamento inicial estabelece o escopo
detalhado do projeto e as funções macro que o Data Mart deverá atender.

Produtos:

 Documento contendo o registro de reuniões;

 Documento de requisitos e temas;
 Aprovação pela Área Requisitante e pela DET

a-1) Requisitos funcionais e não funcionais identificados:

O projeto deve prever a geração de relatórios de qualidade dos dados das bases transacionais de
pessoal. Além de o sistema permitir a geração de relatórios analíticos capazes de responder às
questões gerenciais, deve também proporcionar e execução de consultas comuns.

Tempo médio de resposta a consultas previstas ao repositório deverá ser de, no máximo, 02(dois)
minutos.

Sistema deve possibilitar a atualização sistemática (periódica) de dados/informações,

propiciando uma análise atualizada das questões gerenciais.

Os nomes de objetos de banco de dados criados para o projeto deverão seguir o prescrito no
Documento de Modelagem de Dados (INCRA - Sigla Projeto - Modelagem de dados).

Documento Data Versão Página

MDS 12/3/2013 2.0 42/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Todos os objetos de banco de dados do sistema deverão estar definidos no dicionário de dados e
no modelo de dados.

Todos os objetos de banco de dados das bases transacionais utilizadas no projeto deverão ser
documentados de acordo com o Documento de Modelagem de Dados (INCRA - Sigla Projeto -
Modelagem de dados).

A solução deve ser flexível para permitir a agregação futura de novas tabelas de fatos, tabelas de
dimensões, consultas, usuários e novas fontes de dados transacionais.

A solução deverá carregar as inconsistências encontradas nos dados das bases transacionais na
base dimensional com indicações apropriadas.

b) Levantamento das Fontes de Dados

Consiste no levantamento e análise inicial das fontes de dados, incluindo o levantamento e

análise da documentação existente sobre as fontes identificadas, tais como modelos de dados e
correspondentes metadados, bem como documentação sobre detalhes a respeito de regras de
negócio, tabelas, arquivos e demais artefatos. Tal atividade irá promover o entendimento sobre o
negócio e seus dados, bem como irá auxiliar no planejamento do projeto e na identificação de
riscos correspondentes às fontes de dados.

Produtos:

 Documento contendo o registro de reuniões;

 Documentação das fontes de dados de acordo com o Documento de Modelagem de Dados
(INCRA - Sigla Projeto - Modelagem de dados);
 Aprovação pela equipe da DET

9.2 Elaboração

Esta fase é composta pelas atividades Projetar Arquitetura Técnica, Modelagem Dimensional, Projetar
Aplicação de BI e Contagem de Pontos de Função Estimada.

1 – Projetar Arquitetura Técnica

A atividade projetar a arquitetura técnica consiste do levantamento dos volumes envolvidos, tanto no
que tange às bases de dados, quanto aos volumes de processamento e quantidade de usuários
simultâneos. Também serão organizados os softwares que comporão as camadas da arquitetura
OLAP.

Produtos:

 Documento contendo o registro de reuniões;

 Documentação da Estimativa de volumes das bases de dados;
 Documentação da Estimativa de quantidade de usuários;
 Documentação com Recomendações para aspectos de desempenho;
Documento Data Versão Página
MDS 12/3/2013 2.0 43/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Documentação da arquitetura OLAP;

 Aprovação pela equipe da DET.

2 – Modelagem Dimensional

Consiste da elaboração do modelo dimensional de dados do Data Mart de acordo com o escopo da
iteração do projeto. Nesta atividade são identificados as dimensões e fatos relativos aos temas da
iteração. Para cada fato são definidos: as dimensões envolvidas, o seu conteúdo e o grão dos dados.

O Data Mart deverá armazenar os dados em dimensões e fatos (em modelo dimensional) em grãos de
detalhe equivalentes aos dados de origem correspondentes, de modo a preservar o histórico detalhado
dos dados no nível de eventos de negócio (transação). A partir deste nível de dados dimensionais,
deverão ser criados outros níveis de fatos agregados em grãos adequados para atender aos requisitos
de análise dos usuários.

Produtos:

 Documento contendo o registro de reuniões;

 Modelo dimensional de dados do Data Mart;
 Mapeamento origem destino;
 Documento de aprovação do modelo dimensional;
 Aprovação pela equipe da DET

3 – Projetar Aplicação de BI

Esta atividade consiste da definição das consultas previstas para a iteração e a documentação dos
indicadores identificados. Esta atividade inclui o levantamento das consultas e análises demandadas
pela Área Requisitante e que será a base para a homologação correspondente ao ciclo de
desenvolvimento. Os indicadores identificados deverão ser detalhados em documentação contendo,
no mínimo: dados de entrada, períodos de coleta, fórmulas de cálculo e aplicabilidade. A definição
destes indicadores será feita em conjunto com a Área Requisitante do escopo definido na Proposta de
Projeto.

Produtos:

 Documento contendo o registro de reuniões;

 Documento de requisitos atualizado nos temas do ciclo;
 Documento técnico de especificação das consultas e indicadores;
 Aprovação pela Área Requisitante e pela DET

4 – Contagem de Pontos de Função Estimada

Esta atividade consiste da elaboração de relatório de contagem de pontos de função estimada do

projeto visando adequar a estimativa de complexidade da aplicação de BI fabricado ao aumento do
conhecimento do processo de negócio envolvido.

Produtos:

Documento Data Versão Página

MDS 12/3/2013 2.0 44/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Relatório de Contagem de Pontos de Função Estimada;

9.3 Construção

Esta fase é composta pelas atividades de Projeto Físico, Selecionar e Instalar Produtos, Implementar
Rotinas ETL, Implementar Aplicação de BI e Contagem de Pontos de Função Estimada.

1 – Projeto Físico

Consiste na construção do modelo físico relacional e multidimensional. O modelo físico deriva do

modelo lógico e de tratamentos de performance e controle; o modelo multidimensional depende das
visões e consultas a serem liberadas para os usuários (consultas solicitadas, perfil de usuário, etc).
Serão detalhados os dados um a um, analisando questões de performance para as consultas,
necessidade de tabelas agregadas, etc.

Produtos:

 Documento contendo o registro de reuniões;

 Modelos físicos de dados gerados;
 Documentação sobre as características das bases de dados relacionais/ multidimensionais;
 Aprovação pela equipe da DET.

2 – Selecionar e Instalar Produtos

Consiste em preparar o ambiente de homologação disponibilizando o software e o hardware

configurados. A DET é responsável por disponibilizar o software e hardware e a contratada, por
configurar ambos.

3 – Implementar Rotinas ETL

Consiste na especificação e documentação dos processos de extração, transformação e carga (ETL)

dos dados. Estes processos deverão considerar a possibilidade da carga ser inicial, incremental ou
substitutiva.

Inclui a obtenção dos dados que alimentarão o Data Mart a partir da extração dos dados das bases
transacionais. As rotinas deverão realizar extrações para a carga inicial dos dados, incrementais e
substitutivas, de forma parametrizada, ou seja, deve ser flexível para que seja possível selecionar uma
ou mais modalidades de extração. Inclui também a especificação dos processos de carga dos dados
nas bases relacionais / multidimensionais (Data Mart) e geração de cubos. Consiste ainda da
adequação dos dados obtidos pelas rotinas de extração para o ambiente do Data Mart. As funções de
transformação deverão apontar situações de erros e exceções conforme especificação realizada
durante o levantamento.

Produtos:

 Documento contendo o registro de reuniões;

Documento Data Versão Página
MDS 12/3/2013 2.0 45/79
 MDS – Metodologia de Desenvolvimento de Sistemas

 Processos de ETL implementados e documentados na ferramenta de ETL;

 Documentação das situações de erros e exceções encontrados no processo de ETL;
 Aprovação pela equipe da DET.

4 – Implementar Aplicação de BI

Consiste da implementação das consultas e das fórmulas que gerarão os indicadores que foram
especificados na fase de elaboração. As consultas deverão permitir ao usuário final acessar os dados
agregados e atômicos de todo ambiente Data Mart, incluindo visão integrada de todas as estruturas
multidimensionais, conforme o perfil definido para os usuários. Deverão ser disponibilizadas
consultas “ad hoc” aos cubos com “drill-through” na base para usuários privilegiados e consultas pré-
definidas parametrizadas. Também deverão estar disponíveis consultas em “Dashboards” com
parâmetros previamente determinados. Deverá ainda, ser possível a realização de consultas a partir de
construção livre de cada usuário que se encarregará da definição dos parâmetros e filtros de seu
interesse.

Produtos:

 Documento contendo o registro de reuniões;

 Consultas e indicadores implementados;
 Aprovação pela equipe da DET.

5 – Contagem de Pontos de Função Estimada

Esta atividade consiste da elaboração de relatório de contagem de pontos de função estimada do

projeto visando adequar a estimativa de complexidade da aplicação de BI fabricado ao aumento do
conhecimento do processo de negócio envolvido.

Produtos:

 Relatório de Contagem de Pontos de Função Estimada;

9.4 Transição

Esta fase é composta pelas atividades Implantação, Nova Iteração e Contagem de Pontos de Função
Detalhada.

1 – Implantação

Esta atividade será dividida em cinco tarefas: Teste Integrados do Sistema, Testes de Homologação,
Instalação, Otimização das Bases de Dados e Testes de Aceitação Final.

a) Testes Integrados do Sistema

Documento Data Versão Página

MDS 12/3/2013 2.0 46/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Consiste do planejamento e execução de teste do sistema, envolvendo todas as suas etapas.

Produtos:

 Documento contendo o registro de reuniões.

 Plano de teste integrado.
 Documentação dos resultados e performance dos testes.
 Aprovação pela equipe da DET.

b) Testes de Homologação

Consiste do teste realizado pelo usuário final, validando o atendimento aos requisitos e quanto a
performance. Este teste pode ser realizado no ambiente de desenvolvimento.

Produtos:

 Documento contendo o registro de reuniões.

 Plano de teste do usuário.
 Relatório de teste do usuário.
 Relatório de homologação do sistema.
 Aprovação pela equipe da DET.

c) Instalação

Consiste da disponibilização dos temas desenvolvidos na iteração para o Data Mart no ambiente
de produção e avaliação de performance. Serão realizadas as cargas iniciais do sistema, pelo
menos uma atualização incremental e uma atualização substitutiva. Serão realizados os testes
definitivos do sistema e ajustes que ainda se fizerem necessários. Esta fase inclui também a
passagem da aplicação do ambiente de desenvolvimento para o ambiente de produção, a
documentação do processo e o treinamento dos técnicos que darão sustentação ao aplicativo.
Cabe ressaltar que a aquisição de treinamento em ferramenta de BI ou qualquer outro software
proprietário não são objetos do presente termo. O treinamento citado anteriormente refere-se ao
treinamento na aplicação desenvolvida.

Produtos:

 Registro de reuniões.
 Plano de estabilização.
 Relatório de avaliação geral da estabilização.
 Documentação da passagem para produção.
 Documentação das rotinas de produção.
 Temas do Data Mart especificados para a iteração operando em produção.
 Aprovação pela equipe da DET e área requisitante do projeto

d) Otimização das Bases de Dados

Consiste da revisão e otimização da base de dados relacional/multidimensional.

Documento Data Versão Página

MDS 12/3/2013 2.0 47/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Produtos:

 Documento contendo o registro de reuniões.

 Documentação das otimizações das bases de dados.
 Base de dados relacional/multidimensional otimizada.
 Aprovação pela equipe da DET.

e) Testes de Aceitação Final.

Esta atividade consiste na realização de testes de integração com todas as funcionalidades e
temas do Data Mart do Projeto solicitado, bem como de ajustes e otimizações necessários para o
bom funcionamento do Data Mart.

Os planos de testes devem ser revisados para os testes finais.

Além disto, será feita a avaliação geral do Data Mart pelo usuário para fins de aceitação final.

Produtos:

 Registro de reuniões.
 Plano de teste revisado.
 Relatório dos testes integrados.
 Relatório de aceitação final.

2 – Nova Iteração

Consiste em planejar a próxima iteração levando em conta aspectos ressaltados pelos

desenvolvedores ou usuários dos produtos já disponibilizados pelas iterações finalizadas.

3 – Contagem de Pontos de Função Detalhada

Esta atividade consiste da elaboração de relatório de contagem de pontos de função detalhado do

projeto visando liberação do faturamento a estimativa de complexidade da aplicação de BI fabricado
ao aumento do conhecimento do processo de negócio envolvido.

Produtos:

 Relatório de Contagem de Pontos de Função Detalhada;

10. PADRÕES DA DET/INCRA A SEREM UTILIZADOS

Neste item constam os padrões técnicos elaborados pela DET que deverão ser seguidos como apoio ao
processo de execução, desenvolvimento e sustentação dos sistemas.

Documento Data Versão Página

MDS 12/3/2013 2.0 48/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Artefatos Template (TP) Descrição

Padronização de Telas INCRA - GO - Guia de Identifica, classifica e descreve os
Padronização de Telas. padrões de construção de tela
utilizados nos sistemas a serem
desenvolvidos para o Incra.

Visa facilitar a manutenção e

criação das interfaces do usuário.
Padrão de Interface de INCRA - GO - Padrão de interface Este artefato visa padronizar os
Sistemas de Sistemas futuros sistemas do Incra.

Entende-se a necessidade de um
conjunto comum voltada para a
usabilidade com foco no processo
do serviço e da funcionalidade
Padrão de Banco de INCRA - GO - Padrão Banco de Prover informações para
Dados Dados formalizar a nomenclatura de
objetos de banco de dados, bem
como apresentar regras para sua
utilização. Evitando assim, o
hábito de existir diferentes
nomenclaturas dentro de uma
mesma aplicação.
Projeto de referência Ferramenta específica (Framework) Projeto de referência para o
desenvolvimento DOT.NET
Tabela – Padrões de documentação da DET a serem utilizados

Documento Data Versão Página

MDS 12/3/2013 2.0 49/79
 MDS – Metodologia de Desenvolvimento de Sistemas

11. ARTEFATOS GERADOS POR DISCIPLINA – PROJETOS DE SISTEMAS

Artefatos da Manutenção
Disciplina Artefatos dos Projetos Emergencial Nome do Template
Evolutiva/ Adaptativa Corretiva
Corretiva
Plano de Projeto de INCRA – Sigla Projeto –
Gerência de Projetos Software Plano de Projeto de
Software
Relatório de Controle de Relatório de Controle de INCRA – Sigla do Projeto –
Mudança – RCM Mudança – RCM Relatório de Controle de
Mudança
Proposta de Projeto INCRA – Sigla do Projeto –
Proposta de Projeto
Ata de Reunião Ata de Reunião Ata de Reunião INCRA – Sigla Projeto –
Ata de Reunião
Ordem de Serviço Ordem de Serviço Ordem de Serviço Ordem de Serviço INCRA – Sigla do Projeto –
Ordem de Serviço
Cronograma do Projeto INCRA – Sigla Projeto –
Plano de Projeto de
Software
Cronograma da Cronograma da Cronograma da Disponível no repositório:

Documento Data Versão Página

MDS 12/3/2013 2.0 50/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Demanda Demanda Demanda http://

Solicitação de Demanda Solicitação de Demanda INCRA – Sigla Projeto – SD
Plano de Iteração INCRA - Sigla Projeto -
Plano de Iteração
Termo de Encerramento INCRA – Sigla Projeto –
do Projeto Termo de Encerramento
Termo de Encerramento Termo de Encerramento Termo de INCRA – Sigla Projeto –
da Demanda da Demanda Encerramento da Termo de Encerramento
Demanda
Relatórios Gerenciais Relatórios Gerenciais
Plano de Implantação INCRA – Sigla Projeto –
Plano de Implantação
Plano de Implantação da Plano de Implantação da Plano de Implantação INCRA – Sigla Projeto –
Manutenção Manutenção da Manutenção Plano de Implantação
Plano de Capacitação
Lições Aprendidas
Análise de Viabilidade INCRA – Sigla Projeto –
AVC
Termo de Homologação Termo de Homologação INCRA – Sigla Projeto –
Termo de Homologação
Requisitos Documento de Visão INCRA – Sigla Projeto –

Documento Data Versão Página

MDS 12/3/2013 2.0 51/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Visão
Especificação de Caso de Especificação de Caso de INCRA – Sigla Projeto –
Uso Uso ECU - Nome do Caso de
Uso
Especificação de Especificação de INCRA – Sigla Projeto –
Requisitos Requisitos Especificação de Requisitos
Ata de Reunião Ata de Reunião Ata de Reunião INCRA – Sigla Projeto –
Ata de Reunião
Diagrama de Casos de Diagrama de Casos de INCRA – Sigla Projeto –
Uso Uso ECU - Nome do Caso de
Glossário Glossário Uso
Ajuda do Sistema Ajuda do Sistema Help on-line
Manual do Sistema Manual do Sistema INCRA – Sigla Projeto –
Manual do Sistema
Regras de Negócio Regras de Negócio INCRA – Sigla Projeto –
ECU - Nome do Caso de
Uso
Documento de Documento de INCRA – Sigla do Projeto –
Análise e Design
Arquitetura de Software Arquitetura de Software Documento de Arquitetura
Especificação de Telas Especificação de Telas INCRA – Sigla Projeto –
ECU - Nome do Caso de

Documento Data Versão Página

MDS 12/3/2013 2.0 52/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Uso
Modelo de Dados Físico Modelo de Dados Físico Modelo de Dados Físico Modelo de Dados INCRA – Sigla do Projeto –
e Lógico e Lógico e Lógico Físico e Lógico Modelo de Dados Físico
Script de Banco de Script de Banco de
Dados Dados
Plano de implementação Plano de implementação INCRA – Sigla Projeto –
/ Integração / Integração Plano de Implementação
Implementação Código Fonte Código Fonte Código Fonte Código Fonte
Pacote Executável do Pacote Executável do
Sistema interno (Build) Sistema interno (Build)
Roteiro de Teste Roteiro de Teste INCRA – Sigla Projeto –
Roteiro de Teste – Nome do
Caso de Uso
Testes
Evidências de Teste Evidências de Teste Evidências de Teste Evidências de Teste INCRA – Sigla Projeto –
Evidência de testes – Nome
do Caso de Uso
Planilha de Contagem de Planilha de Contagem de Planilha de Contagem de Planilha de Contagem
Métricas
Pontos de Função Pontos de Função Pontos de Função de Pontos de Função

Documento Data Versão Página

MDS 12/3/2013 2.0 53/79
 MDS – Metodologia de Desenvolvimento de Sistemas

12. ARTEFATOS GERADOS POR DISCIPLINA – PROJETOS DE BUSINESS INTELLIGENCE (BI)

Artefatos da Manutenção
Disciplina Artefatos dos Projetos Nome do Template
Evolutiva/ Adaptativa Corretiva Emergencial Corretiva
INCRA – Sigla Projeto –
Plano de Projeto de
Gerência de Projetos Plano de Projeto de
Software
Software
INCRA – Sigla do
Relatório de Controle de Mudança – RCM Projeto – Relatório de
Controle de Mudança
INCRA – Sigla do
Proposta de Projeto Projeto – Proposta de
Projeto
INCRA – Sigla Projeto –
Ata de Reunião Ata de Reunião Ata de Reunião
Ata de Reunião
INCRA – Sigla do
Ordem de Serviço Projeto – Ordem de
Serviço
INCRA – Sigla Projeto –
Cronograma do Projeto Plano de Projeto de
Software

Cronograma da

Documento Data Versão Página

MDS 12/3/2013 2.0 54/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Demanda
INCRA – Sigla Projeto –
Solicitação de Demanda
SD
INCRA - Sigla Projeto -
Plano de Iteração
Plano de Iteração
Termo de Encerramento INCRA – Sigla Projeto –
do Projeto Termo de Encerramento
INCRA – Sigla Projeto –
Termo de Encerramento da Demanda
Termo de Encerramento
Relatórios Gerenciais Relatórios Gerenciais
INCRA – Sigla Projeto –
Plano de Implantação
Plano de Implantação
Plano de Implantação da INCRA – Sigla Projeto –
Manutenção Plano de Implantação
Plano de Capacitação
Lições Aprendidas
Requisitos Documento de requisitos e temas
Documentação das fontes de dados
Estimativa de volumes das bases de dados
INCRA – Sigla Projeto –
Ata de Reunião
Ata de Reunião

Documento Data Versão Página

MDS 12/3/2013 2.0 55/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Estimativa de quantidade de usuários

Recomendações para aspectos de desempenho
Arquitetura OLAP
Modelo dimensional de dados do Data Mart
Análise e Design
Mapeamento origem destino
Documentação sobre as características das bases de
dados relacionais/ multidimensionais
INCRA – Sigla do
Modelos físicos de dados gerados Projeto – Modelo de
Dados Físico
Implementação Processos de ETL implementados e documentados
na ferramenta de ETL
Plano de teste integrado
Plano de teste do usuário
INCRA – Sigla Projeto –
Roteiro de Teste
Roteiro de Teste
Testes
Evidências de Teste (Documentação das situações de erros e exceções encontrados no processo de ETL e INCRA – Sigla Projeto –
Documentação dos resultados e performance dos testes) Evidência de testes
Métricas Planilha de Contagem de Pontos de Função

Documento Data Versão Página

MDS 12/3/2013 2.0 56/79
 MDS – Metodologia de Desenvolvimento de Sistemas

13. ARTEFATOS GERADOS POR ETAPA

Etapa Artefatos Gerados Disciplina Nome do Template

Análise de Viabilidade do Projeto Gerência de Projetos INCRA – Sigla Projeto – AVP

Planilha de Contagem de Pontos de

Métricas
Função

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião
Pré-Projeto
INCRA – Sigla do Projeto – Proposta
Proposta de Projeto Gerência de Projetos
de Projeto

Solicitação de Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla do Projeto – Ordem de

Ordem de Serviço Gerência de Projetos
Serviço

INCRA – Sigla do Projeto –

Projeto: Fase da Iniciação Documento de Arquitetura de Software Análise e Design
Documento de Arquitetura

INCRA – Sigla Projeto –

Especificação de Requisitos Requisitos
Especificação de Requisitos

Documento de Visão Requisitos INCRA – Sigla Projeto – Visão

Documento Data Versão Página

MDS 12/3/2013 2.0 57/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA – Sigla Projeto – Plano de

Plano de Projeto de Software Gerência de Projetos
Projeto de Software

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião

Planilha de Contagem de Pontos de

Métricas
Função

INCRA – Sigla Projeto – ECU - Nome

Projeto: Fase da Elaboração Especificação de Caso de Uso Requisitos
do Caso de Uso

INCRA – Sigla do Projeto – Modelo

Modelo de Dados Físico e Lógico Análise e Design
de Dados Físico

INCRA – Sigla do Projeto – Modelo

Script de Banco de Dados Análise e Design
de Dados Físico

INCRA – Sigla do Projeto –

Documento de Arquitetura de Software Análise e Design
Documento de Arquitetura

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião

Documento Data Versão Página

MDS 12/3/2013 2.0 58/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Planilha de Contagem de Pontos de

Métricas
Função

Pacote Executável do Sistema interno

Implementação
(Build)

Código-fonte Implementação

INCRA – Sigla Projeto – Plano de

Plano de implementação / Integração Implementação
Implementação

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
Projeto: Fase da Construção de Controle de Mudança

INCRA – Sigla Projeto – Roteiro de

Roteiro de Teste Testes
Teste – Nome do Caso de Uso

INCRA – Sigla Projeto – Evidência de

Evidências de Teste Testes
testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de

Métricas
Função
INCRA – Sigla Projeto – Plano de
Projeto: Fase da Transição Plano de Implantação Gerência de Projetos
Implantação

INCRA – Sigla Projeto – Manual do

Manual do Sistema Requisitos
Sistema

Ajuda Requisitos Help on-line

Documento Data Versão Página

MDS 12/3/2013 2.0 59/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA – Sigla Projeto – Termo de

Termo de Encerramento Gerência de Projetos
Encerramento

INCRA – Sigla Projeto – Termo de

Termo de Homologação Gerência de Projetos
Homologação

Plano de Capacitação Gerência de Projetos

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

Planilha de Contagem de Pontos de

Métricas
Função

Manutenção: Demanda Evolutiva/ INCRA – Sigla do Projeto – Modelo

Script de Banco de Dados Análise e Design
Adaptativa de Dados Físico

INCRA – Sigla do Projeto – Modelo

Modelo de Dados Físico e Lógico Análise e Design
de Dados Físico

INCRA – Sigla do Projeto –

Documento de Arquitetura de Software Análise e Design
Documento de Arquitetura

Pacote Executável do Sistema interno

Implementação
(Build)

Código-fonte Implementação

INCRA – Sigla do Projeto – Ordem de

Ordem de Serviço Gerência de Projetos
Serviço

Documento Data Versão Página

MDS 12/3/2013 2.0 60/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA – Sigla Projeto – Plano de

Cronograma da Demanda Gerência de Projetos
Projeto de Software

Solicitação da Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla Projeto – Termo de

Termo de Encerramento Gerência de Projetos
Encerramento

Relatórios Gerenciais Gerência de Projetos

INCRA – Sigla Projeto – Plano de

Plano de Implantação da Manutenção Gerência de Projetos
Implantação

INCRA – Sigla Projeto – Termo de

Termo de Homologação Gerência de Projetos
Homologação

Relatório de Controle de Mudança – INCRA – Sigla do Projeto – Relatório

Gerência de Projetos
RCM de Controle de Mudança

INCRA – Sigla Projeto – ECU - Nome

Especificação de Caso de Uso Requisitos
do Caso de Uso

INCRA – Sigla Projeto –

Especificação de Requisitos Requisitos
Especificação de Requisitos

INCRA – Sigla Projeto – Ata de

Ata de Reunião Requisitos
Reunião

INCRA – Sigla Projeto – Manual do

Manual do Sistema Requisitos
Sistema

Documento Data Versão Página

MDS 12/3/2013 2.0 61/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Ajuda do Sistema Requisitos Help-Online

INCRA – Sigla Projeto – Plano de

Plano de Implementação / Integração Implementação
Implementação

INCRA – Sigla Projeto – Roteiro de

Roteiro de Teste Testes
Teste – Nome do Caso de Uso

INCRA – Sigla Projeto – Evidência de

Evidências de Teste Testes
testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de

Métricas
Função

INCRA – Sigla do Projeto – Ordem de

Manutenção: Demanda Corretiva Ordem de Serviço Gerência de Projetos
Serviço

INCRA – Sigla Projeto – Plano de

Cronograma da Demanda Gerência de Projetos
Projeto de Software

Solicitação de Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla Projeto – Termo de

Termo de Enceramento Gerência de Projetos
Encerramento

INCRA – Sigla Projeto – Plano de

Plano de Implantação da Manutenção Gerência de Projetos
Implantação

Ata de Reunião Requisitos INCRA – Sigla Projeto – Ata de

Reunião

Documento Data Versão Página

MDS 12/3/2013 2.0 62/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Modelo de Dados Físico e Lógico Análise e Design INCRA – Sigla do Projeto – Modelo
de Dados Físico

Código fonte Implementação

Evidências de Testes Testes INCRA – Sigla Projeto – Evidência de

testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de Métricas

Função

Manutenção: Demanda Emergencial Ordem de Serviço Gerência de Projetos INCRA – Sigla do Projeto – Ordem de
Corretiva Serviço

Cronograma da Demanda Gerência de Projetos INCRA – Sigla Projeto – Plano de

Projeto de Software

Termo de Encerramento da Demanda Gerência de Projetos INCRA – Sigla Projeto – Termo de

Encerramento

Plano de Implantação da Manutenção Gerência de Projetos INCRA – Sigla Projeto – Plano de

Implantação

Modelo de Dados Físico e Lógico Análise e Design INCRA – Sigla do Projeto – Modelo
de Dados Físico

Código Fonte Implementação

Evidências de Teste Testes INCRA – Sigla Projeto – Evidência de

testes – Nome do Caso de Uso

Documento Data Versão Página

MDS 12/3/2013 2.0 63/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Planilha de Contagem de Pontos de Métricas

Função

14. ARTEFATOS GERADOS POR ETAPA PARA PROJETOS DE BI

Etapa Artefatos Gerados Disciplina Nome do Template

Análise de Viabilidade do Projeto Gerência de Projetos INCRA – Sigla Projeto – AVP

Planilha de Contagem de Pontos de

Métricas
Função

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião
Pré-Projeto
INCRA – Sigla do Projeto – Proposta
Proposta de Projeto Gerência de Projetos
de Projeto

Solicitação de Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla do Projeto – Ordem de

Ordem de Serviço Gerência de Projetos
Serviço

Projeto: Fase da Iniciação Documento de requisitos e temas Requisitos

Documento Data Versão Página

MDS 12/3/2013 2.0 64/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Documentação das fontes de dados Requisitos

INCRA – Sigla Projeto – Plano de

Plano de Projeto de Software Gerência de Projetos
Projeto de Software

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião

Planilha de Contagem de Pontos de

Métricas
Função

Estimativa de volumes das bases de

Projeto: Fase da Elaboração Requisitos
dados

Estimativa de quantidade de usuários Requisitos

Recomendações para aspectos de

Análise e Design
desempenho

Arquitetura OLAP Análise e Design

Modelo dimensional de dados do Data

Análise e Design
Mart

Mapeamento origem destino Análise e Design

Documento técnico de especificação Análise e Design

Documento Data Versão Página

MDS 12/3/2013 2.0 65/79
 MDS – Metodologia de Desenvolvimento de Sistemas

das consultas e indicadores

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

INCRA – Sigla Projeto – Ata de

Ata de Reunião Gerência de Projetos
Reunião

Planilha de Contagem de Pontos de

Métricas
Função

Documentação sobre as características

Projeto: Fase da Construção das bases de dados relacionais/ Análise e Design
multidimensionais

Consultas e indicadores
Análise e Design
implementados

Modelos físicos de dados gerados Implementação

Processos de ETL implementados e

Implementação
documentados na ferramenta de ETL

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

Evidências de Teste (Documentação INCRA – Sigla Projeto – Evidência de

das situações de erros e exceções Testes testes
encontrados no processo de ETL)

Documento Data Versão Página

MDS 12/3/2013 2.0 66/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Planilha de Contagem de Pontos de

Métricas
Função
INCRA – Sigla Projeto – Plano de
Plano de Implantação Gerência de Projetos
Implantação

Plano de teste integrado Implementação

Plano de teste do usuário Implementação

Evidências de Teste (Documentação INCRA – Sigla Projeto – Evidência de

dos resultados e performance dos Testes testes
testes)

INCRA – Sigla Projeto – Termo de

Termo de Encerramento Gerência de Projetos
Encerramento
Projeto: Fase da Transição
INCRA – Sigla Projeto – Termo de
Termo de Homologação Gerência de Projetos
Homologação

Plano de Capacitação Gerência de Projetos

INCRA – Sigla do Projeto – Relatório

Relatório de Controle de Mudanças Gerência de Projetos
de Controle de Mudança

Planilha de Contagem de Pontos de

Métricas
Função

Manutenção: Demanda Evolutiva/ INCRA – Sigla do Projeto –

Documento de requisitos e temas Requisito
Adaptativa Documento de Arquitetura

Documento Data Versão Página

MDS 12/3/2013 2.0 67/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Documentação das fontes de dados Requisito

Estimativa de volumes das bases de

Requisito
dados

Estimativa de quantidade de usuários Requisito

Recomendações para aspectos de

Análise e Design
desempenho

Arquitetura OLAP Análise e Design

Modelo dimensional de dados do Data

Análise e Design
Mart

Mapeamento origem destino Análise e Design

Documento técnico de especificação

Análise e Design
das consultas e indicadores

Documento Data Versão Página

MDS 12/3/2013 2.0 68/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA – Sigla do Projeto – Ordem de

Ordem de Serviço Gerência de Projetos
Serviço

INCRA – Sigla Projeto – Plano de

Cronograma da Demanda Gerência de Projetos
Projeto de Software

Solicitação da Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla Projeto – Termo de

Termo de Encerramento Gerência de Projetos
Encerramento

Relatórios Gerenciais Gerência de Projetos

INCRA – Sigla Projeto – Plano de

Plano de Implantação da Manutenção Gerência de Projetos
Implantação

INCRA – Sigla Projeto – Termo de

Termo de Homologação Gerência de Projetos
Homologação

Relatório de Controle de Mudança – INCRA – Sigla do Projeto – Relatório

Gerência de Projetos
RCM de Controle de Mudança

INCRA – Sigla Projeto – ECU - Nome

Especificação de Caso de Uso Requisitos
do Caso de Uso

INCRA – Sigla Projeto –

Especificação de Requisitos Requisitos
Especificação de Requisitos

INCRA – Sigla Projeto – Ata de

Ata de Reunião Requisitos
Reunião

Documento Data Versão Página

MDS 12/3/2013 2.0 69/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA – Sigla Projeto – Manual do

Manual do Sistema Requisitos
Sistema

Ajuda do Sistema Requisitos Help-Online

INCRA – Sigla Projeto – Plano de

Plano de Implementação / Integração Implementação
Implementação

INCRA – Sigla Projeto – Roteiro de

Roteiro de Teste Testes
Teste – Nome do Caso de Uso

INCRA – Sigla Projeto – Evidência de

Evidências de Teste Testes
testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de

Métricas
Função

INCRA – Sigla do Projeto – Ordem de

Ordem de Serviço Gerência de Projetos
Serviço

INCRA – Sigla Projeto – Plano de

Cronograma da Demanda Gerência de Projetos
Projeto de Software

Manutenção: Demanda Corretiva Solicitação de Demanda Gerência de Projetos INCRA – Sigla Projeto – SD

INCRA – Sigla Projeto – Termo de

Termo de Enceramento Gerência de Projetos
Encerramento

INCRA – Sigla Projeto – Plano de

Plano de Implantação da Manutenção Gerência de Projetos
Implantação

Documento Data Versão Página

MDS 12/3/2013 2.0 70/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Ata de Reunião Requisitos INCRA – Sigla Projeto – Ata de

Reunião

Modelo de Dados Físico e Lógico Análise e Design INCRA – Sigla do Projeto – Modelo
de Dados Físico

Código fonte Implementação

Evidências de Testes Testes INCRA – Sigla Projeto – Evidência de

testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de Métricas

Função

Ordem de Serviço Gerência de Projetos INCRA – Sigla do Projeto – Ordem de

Serviço

Cronograma da Demanda Gerência de Projetos INCRA – Sigla Projeto – Plano de

Projeto de Software

Manutenção: Demanda Emergencial Termo de Encerramento da Demanda Gerência de Projetos INCRA – Sigla Projeto – Termo de
Corretiva Encerramento

Plano de Implantação da Manutenção Gerência de Projetos INCRA – Sigla Projeto – Plano de

Implantação

Modelo de Dados Físico e Lógico Análise e Design INCRA – Sigla do Projeto – Modelo
de Dados Físico

Código Fonte Implementação

Documento Data Versão Página

MDS 12/3/2013 2.0 71/79
 MDS – Metodologia de Desenvolvimento de Sistemas

Evidências de Teste Testes INCRA – Sigla Projeto – Evidência de

testes – Nome do Caso de Uso

Planilha de Contagem de Pontos de Métricas

Função

Documento Data Versão Página

MDS 12/3/2013 2.0 72/79
 MDS – Metodologia de Desenvolvimento de Sistemas

15. FERRAMENTAS DE APOIO AO PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE
As ferramentas da Microsoft (Team Foundation Server) e da PowerLogic (Jaguar) disponível,
atualmente, no Incra, deverão ser customizada para apoiar o fluxo de trabalho de desenvolvimento de
Sistemas de Informação e as ferramentas Pentaho e/ou MicroStrategy para apoiar o fluxo de trabalho
de desenvolvimento de Sistemas de Business Intelligence (BI) em conformidade com esta MDS-Incra.
No Incra, são utilizadas as seguintes ferramentas, além da citada acima, para o atendimento às
demandas de sistemas: Sistema de Controle de Demandas - SICODE, DotProject, GPWeb, Joomla!,
Visual Studio, Eclipse, NetBeans, iReport, Crystal Report, SVN, Katle (ETL).

16. GLOSSÁRIO

Termo Definição
Análise de Viabilidade Documento que registra a análise de viabilidade
gerando o registro de questões relativas ao projeto,
como: definições legais, limitações de aspectos de
hardware, segurança, arquitetura de
desenvolvimento, dentre outras dependendo da
natureza do projeto. Todos estes detalhamentos
devem compor e direcionar o parecer final de
viabilidade sendo documentado também no
Documento de Pré-projeto.
Ata de Reunião Documento que descreve os assuntos e as definições
de cada reunião realizada, bem como os envolvidos
e os pontos de atenção identificados.
Diagrama de Atividades Modelo que apresenta o fluxo de atividades em um
único processo. O diagrama mostra a dependência
entre as atividades, ou seja, como uma atividade
depende uma da outra.
Diagrama de Caso de Uso Modelo que apresenta o que um novo sistema deve
fazer; mostra para que serve o sistema ignorando a
forma que o sistema está organizado internamente,
mas permite capturar de forma precisa o
comportamento sem ter de especificar como é ou

Documento Data Versão Página

MDS 12/3/2013 2.0 73/79
 MDS – Metodologia de Desenvolvimento de Sistemas

será implementado.
Diagrama de Classes Modelo que define a estrutura das classes utilizadas
pelo sistema, determinando os atributos e métodos
possuídos por cada classe, além de estabelecer como
as classes se relacionam E trocam informações entre
si.
Diagrama de Sequência Modelo que identifica o evento gerador do processo
modelado, bem como o ator responsável por este
evento, e determina como o processo deve se
desenrolar e ser concluído por meio do envio de
mensagens, que em geral disparam métodos entre os
objetos. Esse diagrama é construído a partir do
Diagrama de Casos de Usos.
Documento de Arquitetura Documento que fornece uma visão geral da
arquitetura que permeará a construção dos sistemas
de software, ou seja, fornece aos desenvolvedores as
informações necessárias para a construção do
sistema. Também serve como um meio de
comunicação entre o arquiteto de software e outros
membros da equipe do projeto.
Documento de Arquitetura de Informação Documento que se destina à organização dos itens
– Menu de menu do sistema utilizando para isso a divisão
em grupos e adequação das nomenclaturas
utilizadas, visando assim, a facilidade do uso pelo
usuário final do sistema.
Documento de Criação de Ambiente Documento que identifica as características para
criar o ambiente de homologação e/ou produção do
sistema em questão (.NET e Java). Nesse
documento estão descritas informações necessárias
para cada área responsável (Suporte à Infraestrutura,
Banco de Dados, Configuração, Segurança) por
criar e apoiar a criação do ambiente, onde se
identifica informações do projeto e um conjunto de
dados para a criação da infra estrutura.
Documento de Pré-Projeto Documento que contém informações sobre o escopo

Documento Data Versão Página

MDS 12/3/2013 2.0 74/79
 MDS – Metodologia de Desenvolvimento de Sistemas

preliminar do projeto, uma visão inicial sobre as

funcionalidades previstas e a estimativa de sua
complexidade. Além disso, deve conter o parecer
sobre a viabilidade do projeto, uma estimativa
funcional elaborada pelo Núcleo de Métricas, um
cronograma inicial além da assinatura de aceite do
Gestor. Esse documento é a base do
desenvolvimento do Projeto e é utilizado pelo
Núcleo de Métricas a fim de possibilitar a realização
da contagem (estimativa/medição) do Projeto.
Documento de Visão Documento que define a visão que os envolvidos
têm do produto a ser desenvolvido, em termos das
necessidades e características mais importantes. Por
conter uma descrição dos requisitos centrais
pretendidos, esse documento proporciona a base
contratual para requisitos técnicos mais detalhados.
Especificação de Caso de Uso Documento que descreve o comportamento das
partes que compõem o sistema, orientando todo o
desenvolvimento e permitindo validar a
compreensão dos requisitos antes do início do
desenvolvimento do sistema. Caso de Uso: é uma
sequência de ações que um sistema executa e que
gera um resultado observável de valor para um ator.
Ator: é alguém ou alguma coisa externa ao sistema e
que interage com o sistema.
FSW Fábrica de Software contratada em processo
licitatório para o Incra
Gestor da Informação Responsável por desenvolver planos estratégicos e
operacionais que julgar mais eficazes para atingir os
objetivos organizacionais, por conceber as
estruturas e estabelecer as regras, políticas e
procedimentos mais adequados aos planos
desenvolvidos e, por fim, implementar e coordenar a
execução dos planos através de um determinado tipo
de comando ou liderança e de controle ou

Documento Data Versão Página

MDS 12/3/2013 2.0 75/79
 MDS – Metodologia de Desenvolvimento de Sistemas

verificação. No desenvolvimento de software do

Incra, é também o responsável por fornecer as
regras do negócio e os requisitos do sistema a ser
desenvolvido e por homologar o sistema.
Glossário O glossário define termos técnicos importantes para
o negócio do usuário e utilizados no projeto.
Manual do Usuário Documento que descreve os procedimentos
necessários para a operacionalização do sistema
disseminando o conhecimento para auxiliar o
usuário na navegação e utilização do sistema
Modelo de Dados Físico Modelo que apresenta como os elementos de dados
serão armazenados no banco de dados. As entidades
e atributos do modelo lógico são neste momento
mapeados para tabelas e colunas do modelo físico. É
comum muitas vezes a introdução de novos objetos
que não contribuem diretamente com os requisitos
de negócio. Tais objetos podem ser criados por
motivos de performance, redução de necessidade de
armazenamento ou até mesmo para simplificar o
desenvolvimento da aplicação.
Modelo de Dados Lógico Modelo que apresenta os dados que as aplicações
devem armazenar satisfazendo os requisitos de
negócios, além de mostrar como esses dados estão
relacionados.
Planilha de Contagem de Pontos de Função Documento em formato de planilha que destina às
contagens do tipo desenvolvimento, manutenção e
aplicação, permitindo que informações importantes,
além da própria contagem, sejam registradas de
forma que as concentre em um único documento,
considerando inclusive os registros quanto aos
Requisitos Não-Funcionais e Itens Não Mensuráveis
associados a requisitos funcionais específicos da
aplicação. A planilha também contém um sumário
responsável por apresentar de forma concisa e
objetiva as diversas informações referentes à

Documento Data Versão Página

MDS 12/3/2013 2.0 76/79
 MDS – Metodologia de Desenvolvimento de Sistemas

contagem, servindo como uma excelente opção no

auxilio a auditoria se levantamentos sobre a
contagem de Pontos de Função.
Plano de Capacitação Documento que reúne as informações necessárias
para promover a disseminação do conhecimento aos
usuários do sistema. Define os objetivos, o prazo e
os recursos necessários para a realização do evento
de capacitação.
Plano de Implantação Documento que agrupa todas as atividades,
informações necessárias para a perfeita execução e
controle do processo de implantação do sistema,
informando as atividades executadas e os
responsáveis por sua execução para garantir a
entrega, com qualidade, do sistema em produção.
Plano de Iteração Descreve um conjunto de atividades e tarefas
divididas por seqüências de tempo, com recursos
atribuídos e dependências de tarefas. Contém uma
estrutura detalhada da divisão de trabalho para a
atividade e as atribuições de responsabilidade.
Relatório de Evidência de Teste Documento produzido ao final do processo de teste
e que resume todas as atividades de teste e seus
resultados. Evidencia o resultado dos testes
realizados.
Stakeholders Compreende todos os envolvidos em um processo,
Podem ser desde os usuários comuns do sistema até
administradores, programadores ou analista de
sistemas.
Termo de Aceite Documento que formaliza a aceitação do produto
desenvolvido e permite o processo de implantação
no ambiente de produção
Termo de Encerramento do Projeto Documento que formaliza o encerramento do
projeto
Usuário Em sistema de informação são agentes externos ao
sistema que usufruem da tecnologia para realizar

Documento Data Versão Página

MDS 12/3/2013 2.0 77/79
 MDS – Metodologia de Desenvolvimento de Sistemas

determinado trabalho. Podem ser desde os usuários

comuns do sistema até administradores,
programadores ou analista de sistemas. São
chamados de stakeholders.
Guia Operacional – GO Documento que determina padrões técnicos que
deverão ser seguidos como apoio ao processo de
fabricação de software.

17. REFERÊNCIA

OpenUP – Processo iterativo para projeto e desenvolvimento de Software;

PMBok – Compêndio do PMI, consagrado para viabilizar a gerência de projetos;
CMM e CMMI – Modelo de maturidade para processos de desenvolvimento de software;
RUP – Rational Unified Process: disciplinas e fases do RUP disponível em
http://www.wthreex.com/rup/portugues/index.htm;
Scrum – Modelo de desenvolvimento ágil de software;
MDS/FNDE – Metodologia de Desenvolvimento de Sistemas da FNDE.

18. APÊNDICES

INCRA - GO - Padrão Banco de Dados - v4-1

INCRA - GO - Padrão de interface de Sistemas
INCRA - GO - Padronização de Telas
INCRA - Sigla Projeto - Ata de Reunião
INCRA - Sigla Projeto - Controle de Mudança
INCRA - Sigla Projeto - Documento de Arquitetura
INCRA - Sigla Projeto - ECU - Nome do Caso de Uso
INCRA - Sigla Projeto - Especificação de Requisitos
INCRA - Sigla Projeto - Especificação de Telas
INCRA - Sigla Projeto - Evidências de Teste Caso de Uso
INCRA - Sigla Projeto - Implementação_Integração
INCRA - Sigla Projeto - Mensagens do Sistema
Documento Data Versão Página
MDS 12/3/2013 2.0 78/79
 MDS – Metodologia de Desenvolvimento de Sistemas

INCRA - Sigla Projeto - Modelagem de dados

INCRA - Sigla Projeto - Ordem de Serviço
INCRA - Sigla Projeto - Plano de Implantação
INCRA - Sigla Projeto - Plano de Iteração
INCRA - Sigla Projeto - Plano de Projeto de Software
INCRA - Sigla Projeto - Proposta de Projeto
INCRA - Sigla Projeto - Roteiro de Testes
INCRA - Sigla Projeto - Termo de Encerramento
INCRA - Sigla Projeto - Termo de Homologação de Artefatos ou Produtos Entregues
INCRA - Sigla Projeto – Visão
Guia de Contagem de Pontos de Função do Incra

Documento Data Versão Página

MDS 12/3/2013 2.0 79/79