Ministério da Saúde

DATASUS

Apoio

Orientação para o gestor

Esta área destina-se aos gestores e usuários de sistemas de informação desenvolvidos pelo DATASUS. Seu objetivo é mostrar aos clientes do DATASUS:

  • Como o DATASUS trabalha no Desenvolvimento de Sistemas;
  • Qual é o papel das partes interessadas no desenvolvimento de sistemas;
  • Como solicitar um projeto ou manutenções;
  • Cuidados para definir um bom projeto.
  • COGP – Coordenação de governança e projetos;
  • CDESS – Coordenação de desenvolvimento de sistemas;
  • COBD – Coordenação de gestão de banco de dados;
  • COGRD – Coordenação de gestão de redes e Datacenter.

1. O usuário gestor preencherá o DCI (Documento de Cadastro de Iniciativa) por meio do portal e encaminhará ao Escritório de Projetos para análise prévia; 

2. O Escritório de Projetos realizará uma reunião com a área gestora para entendimento da demanda e início da versão preliminar do TAP;

3. O Escritório de Projetos solicitará à área responsável pela execução do projeto a indicação do Gerente de Projetos que ficará à frente da Proposta de Projetos;

4. Se a análise realizada pelo Escritório de Projetos concluir que a solicitação se enquadra como projeto, esta será cadastrada no sistema Portfólio do DATASUS e no Sistema de demandas para que o Gerente de Projetos elabore o Documento de Visão de Negócio e providencie a Estimativa de Custo para execução do projeto;

5. Em paralelo, o Escritório de Projetos realizará reuniões com as áreas técnicas do DATASUS para emissão do parecer técnico que avaliará a viabilidade técnica para execução do projeto;

6. Com o Documento de Visão de Negócio, Estimativa de Custo e parecer técnico, o Escritório de Projetos finalizará o TAP para assinatura das partes envolvidas. 

1. Os requisitos do projeto são definidos pelo gestor;

2. A equipe de desenvolvimento do DATASUS apresenta os artefatos de análise para homologação. No momento do recebimento dos artefatos, o gestor assina o Termo de Recebimento Provisório, que conté6-m a lista de artefatos entregues; esse Termo funciona como um recibo e contém o prazo contratual para validação. O Termo de Recebimento Definitivo só será assinado após validação dos artefatos;

3. O gestor deve homologar, assinando os artefatos de requisitos. Após validação, o gestor deve assinar o Termo de Recebimento Definitivo e devolver toda documentação ao DATASUS;

4. A equipe de desenvolvimento do DATASUS apresenta o sistema, módulo ou funcionalidade ao gestor para homologação. No momento do recebimento do sistema, módulo ou funcionalidade, o gestor assina o Termo de Recebimento Provisório, que contém a lista das funcionalidades entregues; esse Termo funciona como um recibo e contém o prazo contratual para homologação. O Termo de Recebimento Definitivo só será assinado após validação do sistema, módulo ou funcionalidade;

5. O gestor deve homologar o sistema, módulo ou funcionalidade, assinando o Termo de Recebimento Definitivo e o devolvendo ao DATASUS.

O DATASUS, em seus contratos de fábrica de software, atendendo a recomendações do TCU e do SISP, adotou a métrica Ponto de Função – PF para medir o tamanho funcional de um sistema. Trata-se de uma técnica utilizada em todo o mundo.

A partir do tamanho de uma funcionalidade, é possível calcular tanto seu prazo quanto seu custo. Existe uma tabela nos contratos que define prazos a partir do PF medido. Nos contratos de fábrica, está definido o valor do PF, portanto não é passível de questionamento o valor do desenvolvimento de uma funcionalidade. Para facilitar a apuração de trabalhos parciais, como executar somente a análise, ou somente o desenvolvimento, ou somente a fase de testes, por exemplo, é atribuído um percentual para cada fase, de modo a permitir a valoração de um serviço.

Iniciação

  • Documento de Visão de Sistema;
  • Plano de Projeto.

Elaboração

  • Especificação de Caso de Uso;
  • Documento de Regras;
  • Lista de Mensagem.

Construção

  • Produto (sistema, módulo ou funcionalidade).

Transição

  • Manual do usuário.

O gerente de projetos é responsável por tarefas importantes como:

  • Definição de atividades;
  • Sequenciamento das atividades;
  • Estimativa dos recursos necessários;
  • Estimativa de duração das atividades;
  • Desenvolvimento do cronograma e
  • Controle do cronograma.

Estas tarefas irão direcionar o desenvolvimento de todo o projeto, como um fluxo de execução.

Quando uma necessidade de mudança (inclusão, alteração ou exclusão de funcionalidades) é identificada pelo usuário gestor, é importante compreender que o trabalho realizado inicialmente pelo gerente de projetos poderá ser refeito e as atividades de desenvolvimento, que geralmente são realizadas por equipes de empresas prestadoras de serviços e que possuem contratos específicos, poderão ser faturadas novamente.

Assim sendo, analise a real necessidade e urgência de uma mudança, pois ela envolverá, dependendo do estágio em que se encontra a funcionalidade, toda a equipe de desenvolvimento (Coordenador de desenvolvimento, gerente de projeto, analista de requisito, analista de teste, arquiteto de software, analista de métrica, gerente de configuração, desenvolvedor, dentre outros).

Veja o custo de uma alteração:

  • Funcionalidades INCLUÍDAS – serão remuneradas em 100% da quantidade de PF da(s) fase(s) contratada(s) vezes o valor do ponto de função;
  •  
  • Funcionalidades ALTERADAS – serão remuneradas em 60% da quantidade de PF da(s) fase(s) contratada(s) vezes o valor do ponto de função;
  •  
  • Funcionalidades EXCLUÍDAS – serão remuneradas em 40% da quantidade de PF da(s) fase(s) contratada(s) vezes o valor do ponto de função.

Uma vez proposto o prazo pelo Gerente de Projeto, você pode solicitar redução do prazo de entrega. Mas essa redução tem custo adicional, pois se presume que a contratada autorizará seus colaboradores a trabalhar hora extraordinária ou contratará mais profissionais para comprimir o prazo. Para redução do prazo, é utilizado o seguinte critério, originado no Manual de Métricas do SISP:

  • Redução de prazo de 10% –  Aumento de esforço de 20% (projetos urgentes);
  • Redução de prazo de 20% – Aumento de esforço de 50% (projetos críticos);
  • Redução de prazo de 25% – Aumento de esforço de 70% (projetos de alta criticidade).
  • Ambiente de Desenvolvimento: utilizado pela equipe responsável pelo desenvolvimento e testes dos sistemas.
  • Ambiente de Homologação: utilizado pelos usuários gestores com o intuito de aprovar ou não os produtos entregues.
  • Ambiente de Treinamento: utilizado para capacitação no uso das funcionalidades dos sistemas.
  • Ambiente de Produção: utilizado pelos usuários finais no dia a dia de suas atividades.

Cada ambiente usa dados específicos. O ambiente de homologação não pode ser usado para treinamentos e o ambiente de produção não pode ser usado nem para treinamentos nem para homologação de sistemas.

Dados de um ambiente poderão ser migrados para outro. No caso de ser necessária a replicação dos dados do ambiente de produção para outros ambientes, o usuário gestor deverá solicitar formalmente para o gerente de projetos. Somente com a sua autorização, será possível executar esse serviço.

  • Aderir e respeitar o processo de engenharia de software implantado.
  • Oficializar a demanda por meio da elaboração do DCI (Documento de Cadastro de Iniciativa);
  • Abrir demanda no Sirius;
  • Homologar a documentação técnica do sistema de acordo com o prazo estipulado em contrato por meio de assinatura no documento e tramitação no Sirius;
  • Estabelecer as prioridades das demandas relativas ao sistema;
  • Informar as necessidades da área, definir as regras de negócio do sistema, priorizar requisitos quando solicitado pela equipe de desenvolvimento;
  • Testar, em ambiente apropriado, o sistema de informação, evidenciar eventuais erros ou dificuldades e apresentar orientações ou sugestões para correção;
  • Aprovar cada versão do sistema quando disponível em produção;
  • Divulgar informes e dar orientações referentes a procedimentos de atualização e consulta do sistema, sem prejuízo do serviço de atendimento ao usuário;
  • Promover treinamentos sobre a utilização do sistema.
  • Solicitar mudanças no projeto junto ao Escritório de Projetos;
  • Solicitar manutenções nos sistemas em produção por meio da ferramenta Sirius.
  • Reuniões de ponto de controle;
  • Relatório de acompanhamento.

Encerrar um projeto ou uma fase é o processo de finalização de todas as atividades, de todos os grupos de processos de gerenciamento e desenvolvimento do projeto.

É, também, o momento de celebrarmos as vitórias e compartilharmos as dificuldades do projeto documentando as lições aprendidas.

O projeto pode ser encerrado nas seguintes condições:

  • Concluído;
  • Cancelado ou;
  • Absorvido por outro projeto.

Ao término do projeto, o Termo de Encerramento de Projeto deve ser assinado pelo DATASUS e pelo gestor.

Glossário

  • A
  • B
  • C
  • D
  • E
  • F
  • G
  • I
  • M
  • N
  • P
  • Q
  • R
  • S
  • T
  • U
  • V

Análise

(UML) Parte do processo de desenvolvimento de software em que o principal objetivo é construir um modelo do domínio do problema. A análise foca no o que fazer. O projeto foca no como fazer.

Análise de impacto

Uma análise de impacto avalia os efeitos que uma mudança proposta terá sobre um sistema ou parte interessada.

Arquitetura

Descreve os subsistemas e componentes que compõem o sistema e relacionamento entre eles, incluindo a definição dos mecanismos fundamentais (linguagens, plataformas, protocolos, padrões etc.) que serão utilizados para seu desenvolvimento.

Artefato

Representa um produto concreto produzido, modificado ou utilizado pelas atividades de um processo. Um artefato pode ser um modelo, um componente de um modelo ou um documento. Um artefato pode conter outros artefatos.

Atividade

Representa um conjunto de passos e tarefas que um profissional, que desempenha o papel responsável por aquela atividade, deve executar para gerar algum resultado.

Ator

(RUP) Alguém ou algo externo ao sistema ou negócio que interage com o sistema ou negócio.

(UML) Um conjunto coerente de papéis que usuários de casos de uso exercem quando interagem com ele. Um ator tem um papel para cada caso de uso com o qual interage.

Build

Versão operacional de um sistema ou parte dele que demonstra um conjunto das funcionalidades a serem oferecidas pelo produto final.

Business case

É uma forma de justificar o investimento para aprovar um projeto estratégico que agrega valor ao negócio da empresa (Business Case, 2011).

Caso de uso

(RUP) Uma sequência de ações que um sistema deve realizar para apresentar um resultado de valor mensurável para o usuário.

(UML) Especificação de uma sequência de ações, incluindo suas variações, que um sistema (ou outra entidade) pode realizar, interagindo com seus atores.

CDESS

Coordenação de desenvolvimento de sistemas.

Cenário

Instância de um caso de uso. Um dos fluxos possíveis de passos em um caso de uso.

CGGOV

Coordenação-geral de governança e gestão de projetos em tecnologia da informação e comunicação

CGIE

Coordenação-geral de infraestrutura

Classe

(UML) Descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.

Código-fonte

Artefato da MDS que representa qualquer trecho de código implementado ao longo do desenvolvimento do sistema. Não possui modelo.

Compilação do sistema

Representa o sistema executável compilado. Não possui modelo.

Componente

(UML) Parte não trivial de um sistema, quase independente e substituível que realiza uma função clara no contexto de uma arquitetura bem definida.

Configuração

Requisitos, projeto e implementação que definem uma versão específica de um sistema ou componente.

COGRD

Coordenação de gestão de redes e datacenter

Controle de mudanças

Atividade de controlar e rastrear as modificações.

DIAAD

Divisão de análise e administração de dados

Diagrama

Representação gráfica de todo, ou parte de um modelo.

Diagrama de caso de uso

Um tipo de diagrama definido pela UML que captura todos os atores e casos e uso envolvidos com um sistema ou produto.

Dicionário de dados

Um modelo de análise descrevendo as estruturas e dados e atributos necessários para o sistema.

Documento de arquitetura de software

Artefato da MDS que descreve as principais decisões de projeto tomadas pela equipe de desenvolvimento e os critérios considerados durante a tomada destas decisões.

Documento de cadastro de iniciativa (DCI)

Documento que formaliza a solicitação da área gestora para a execução de algum serviço, no que tange à Tecnologia da Informação.

Documento de visão de negócio

Artefato da MDS que estabelece as características do produto com base nas necessidades da área de negócio e fornece informações para o Termo de Abertura do Projeto.

Entrega

Qualquer produto ou serviço de trabalho único e verificável que uma parte concordou em entregar.

Escopo do produto

(PMBOK 96) Aspectos e funções que devam ser incluídos no produto ou serviço.

Escopo do projeto

(PMBOK 96) Trabalho que deve ser feito com a finalidade de entregar um produto de acordo com os aspectos e as funções especificadas.

Estrutura analítica do projeto (EAP)

Uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe do projeto para atingir os objetivos do projeto e criar as entregas requeridas. Ela organiza e define o escopo total do projeto.

Fase

Espaço de tempo entre dois marcos significativos do projeto, durante o qual objetivos são atingidos, artefatos elaborados e decisões sobre passar ou não para a próxima fase são tomadas.

Fluxo de atividades

Apresenta a sequência e a dependência entre as atividades do projeto ao longo do tempo.

Framework

É uma estrutura genérica em um domínio específico que pode formar a base de uma família de aplicações. Os frameworks são geralmente implementados como um conjunto de classes concretas e abstratas, especializadas e instanciadas para criar uma aplicação.

Funcionalidade

(RUP) Serviço oferecido por um sistema, observável externamente, que satisfaz uma necessidade do stakeholder.

Gerência de configuração

Processo de apoio cujo objetivo é identificar, definir e estabelecer baselines de itens de configuração.

Gerência de requisitos

Abordagem sistemática para levantar, organizar e documentar os requisitos de um sistema, e estabelecer e manter um acordo entre o cliente e a equipe do projeto sobre as alterações nestes requisitos.

Glossário

Artefato da MDS que registra termos e definições específicos ao domínio do sistema e do projeto.

Implantação

Atividade da MDS representada pela área de Implantação do DATASUS e está fora do escopo da equipe de desenvolvimento do sistema.

Incremental

Característica de uma estratégia de desenvolvimento iterativa em que o sistema é desenvolvido com a adição de novas funcionalidades a cada iteração.

Interface

(UML) Conceito abstrato para uma coleção de operações utilizada para especificar o serviço de uma classe ou componente.

Item de configuração

Artefatos do sistema, arquivos ou conjunto de arquivos, produzidos ou utilizados como insumos em suas atividades.

Iteração

Sequência distinta de atividades, com planejamento e critérios de avaliação estabelecidos, que resulta em uma versão (interna ou externa) do produto.

Iterativo

Processo que se repete diversas vezes para se chegar a um resultado e a cada vez gera um resultado parcial que será usado na vez seguinte.

MAD

Metodologia de Administração de Dados – DATASUS.

Marco

São pontos significativos de um projeto. Pontos em que uma iteração é formalmente encerrada.

Matriz de rastreabilidade

Artefato da MDS que registra todos os requisitos do sistema levantados junto aos usuários gestores e finais.

MDS

Metodologia de Desenvolvimento de Software – DATASUS.

Método

Maneira de dizer, de fazer, de ensinar uma coisa, segundo certos princípios e em determinada ordem.

Métrica

É um nível quantificável de um indicador que uma organização deseja alcançar em um ponto específico do tempo.

MGP

Metodologia de Gerenciamento de Projetos – DATASUS.

MGProc

Metodologia de Gerenciamento de Processos – DATASUS.

MGServ

Metodologia de Gerenciamento de Serviço – DATASUS.

MGSI

Metodologia de Gerenciamento de Serviço de Infraestrutura – DATASUS.

Modelo

Descrição completa de um sistema sob determinada perspectiva (por completa entenda-se que não é necessária nenhuma outra informação para a compreensão daquela perspectiva do sistema).

Modelo de banco de dados

Artefato que descreve todo o projeto de banco de dados do sistema. Não possui template.

Modelo de casos de uso

Artefato da MDS que descreve toda a visão funcional do sistema através de seus atores e casos de uso.

Necessidade do negócio

Um tipo de requisito de negócio de alto nível que é uma declaração de um objetivo do negócio ou um impacto que a solução deverá trazer ao ambiente do negócio.

Pacote

Mecanismo de propósito genérico para organizar elementos em grupos. Pacotes podem ser aninhados em outros pacotes.

Pacote de distribuição

Empacotamento físico de uma versão do sistema, incluindo o sistema executável, kits de instalação, manuais do sistema, documentação do projeto, bases de dados para carga etc.

Papéis

Definem o comportamento e responsabilidades de profissionais que participam do desenvolvimento do projeto.

PDOC

Projeto de Documentação. Área responsável por realizar e atualizar a documentação sobre os manuais do usuário.

PGDS

Processo de Gerenciamento e Desenvolvimento de Software – DATASUS.

Pós-condição

Descrição textual de uma restrição no sistema quando um caso de uso ou um caso de teste termina.

Pré-condição

Descrição textual de uma restrição no sistema para que um caso de uso ou um caso de teste possa ser iniciado.

Processo

Conjunto de passos relativamente ordenados executados com a intenção de se atingir um objetivo.

Processo de desenvolvimento

Conjunto de passos relativamente ordenados executados com um determinado propósito durante o desenvolvimento de um sistema.

Processo de engenharia de software

Um processo de Engenharia de Software é formado por um conjunto de passos de processo parcialmente ordenados, relacionados com artefatos, pessoas, recursos, estruturas organizacionais e restrições, tendo como objetivo produzir e manter os produtos de software finais requeridos.

Processo unificado

O processo unificado (Unified Process - UP) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software.

Produto

Software resultante do desenvolvimento e alguns dos artefatos relacionados (documentação, material de treinamento, etc).

Projeto

(PMBOK) Um esforço temporário com a finalidade de criar um produto/serviço único.

Proposta de projeto

Fase da MGP que abrange o entendimento do problema e suas necessidades. A partir dessas informações é definido o escopo e o tamanho funcional do projeto, cujo objetivo é conseguir concordância de todos os stakholders sobre a continuidade do projeto.

Qualidade

Grau com que um conjunto de características inerentes (produto, sistema ou processo) satisfaz a requisitos.

Regra de negócio

(RUP) Declaração de uma política ou condição que deve ser satisfeita no contexto do negócio.

Relacionamento

(UML) Conexão semântica entre elementos de um modelo.

Repositório

(UML) Local de armazenamento de documentos, modelos, interfaces e implementações.

Requisito

(IEEE 83) Condição ou capacitação que um sistema precisa atender ou ter para satisfazer um contrato, padrão, especificação, ou outro documento formalmente estabelecido.
(RUP) Condição ou capacidade a qual o sistema deve estar em conformidade, derivada diretamente das necessidades dos stakeholders ou definida em um contrato, padrão, especificação ou outro tipo de documento formal.

(UML) Funcionalidade, propriedade ou comportamento desejado para um sistema.

(Abbot86) Função, restrição, ou outra propriedade que precisa ser fornecida, encontrada, ou atendida para satisfazer as necessidades do usuário do futuro sistema.

Requisito de sistema

(IEEE 90) Condição ou capacitação que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer uma condição ou capacitação requerida por um cliente ou usuário final.

(RUP) Especificação de um comportamento do sistema ou do seu ambiente, observável externamente, por exemplo: entradas, saídas, funções, atributos etc.

Requisito de software

(IEEE 90) Condição ou capacitação que precisa ser contemplada pelo software, necessitada pelo usuário ou cliente para resolver um problema ou alcançar um objetivo.

Revisão

Grupo de atividades executadas com o propósito de localizar defeitos potenciais e verificar a qualidade de um conjunto de artefatos.

Risco

(PMBOK 96) Possibilidade de sofrer perdas.

(RUP) Preocupação progressiva ou iminente que tem grande probabilidade de afetar adversamente o sucesso do projeto.

RUP

Rational Unified Process (Processo Unificado Rational)

Sirius

Sistema de Gestão de Demandas do DATASUS.

Sistema

Uma coleção de elementos inter-relacionados que interagem para atingir um objetivo. Elementos do sistema podem incluir hardware, software e pessoas. Um sistema pode ser um sub elemento (ou subsistema) de outro sistema.

Software

(Pressman) Instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados.

Template

Estrutura pré-definida para um artefato.

UML

Unified Modeling Language - Linguagem de Modelagem Unificada. Linguagem para visualizar, especificar, construir e documentar artefatos de um sistema de software.

UST

(TCU) Unidade de Serviços Técnicos ou denominações correlatas. Essa técnica consiste em listar uma série de serviços na forma, por exemplo, de um catálogo e valorá-los a fim de pagar mediante a conclusão.

Usuário final

Representa o usuário do sistema propriamente dito. Este será o usuário que utilizará o sistema em seu dia-a-dia e sentirá na prática os benefícios (ou prejuízos) operacionais consequentes da implantação do sistema.

Validação

(CMMI) Demonstrar que o produto ou componente do produto satisfazem seu uso pretendido quando colocado no ambiente pretendido.

Verificação

(CMMI) Assegurar que os produtos de trabalho selecionados satisfazem seus requisitos especificados.

Versão do sistema

Produto da MDS que representa o sistema executável ao final de uma fase do projeto, representando um dos grandes marcos do ciclo de vida do projeto. Não possui modelo.

Visão

Ponto de vista do cliente ou usuário do produto a ser desenvolvido, especificada no nível de necessidades do usuário e funcionalidades do sistema.

Histórico de revisão

16/08/2019 >> v1.4

  • Atualização dos artefatos;
  • Plano de trabalho para versão 5.0;
  • Documento de Regras para versão 2.0;
  • Especificação de Caso de Uso para versão 2.0;
  • Evidência de Teste;
  • Plano de Implantação para versão 2.0;
  • Lista de Mensagem para versão 2.0;
  • Matriz de Rastreabilidade;
  • Manual do Usuário para versão 2.0;
  • Nota de Release para versão 2.0.

26/12/2018 >> v1.3

  • Atualização do plano de trabalho para versão 2.0;
  • Remoção dos artefatos “Plano de Trabalho Manutenção Corretiva Definitiva”, “Plano de trabalho Manutenção Corretiva de Contorno, “Plano de trabalho Novo ou Melhoria”, para inclusão de um único plano de trabalho.

07/11/2018 >> v1.2

  • Atualização dos índices dos artefatos “Plano de Trabalho” projeto novo ou melhoria, manutenção corretiva definitiva.

06/11/2018 >> v1.1

  • Atualização dos artefatos “Plano de Trabalho” para melhoria, corretiva com solução de contorno, corretiva sem solução de contorno, sustentação para inclusão do nome do projeto, número da demanda e retirada do produto caso de desenvolvimento.

02/06/2016 >> v1.0

  • Criação da MDS (Fases, atividades e artefatos).

01/04/2010 >> v3.0

  • Criação do PGDS da união do PDS e EGP;
  • Revisão de processos da metodologia com o Guia PMBOK 4.

29/05/2009 >> v2.3

  • Inclusão de Recomendações para Web Service;
  • Migração dos artefatos para o modelo de documentação do SGQ;
  • Retirada dos campos de gerenciamento de projetos do Documento de Consenso;
  • Disponibilização de dois formatos de Matriz de Requisitos: texto (chamado Documento de Requisitos) e planilha.

12/08/2008>> v2.2

  • Implementação de correções e melhorias de baixo impacto.

27/08/2007>> v2.1

  • Inserção das recomendações de segurança, oriundas do projeto DSS (Desenvolvimento de Software Seguro).

09/01/2007>> v2.0

Simplificação do PDS v1.6 através de:

  • Redução do número de artefatos;
  • Substituição do processo baseado em disciplina para o processo baseado em papéis;
  • Representação do fluxo de atividades de forma integrada.

19/10/2006>> v1.6

  • Remoção dos artefatos do PTS;
  • Adequação do site aos padrões de site acessíveis do DATASUS.

16/08/2005 >> v1.5.1

  • Disponibilização do formulário Fale Conosco.

30/06/2005 >> v1.5

  • Foi acrescentado o Mapa do Site e Como Navegar no site do PDS;
  • Modificação na marca do DATASUS;
  • Conversão da árvore de navegação para html.

30/12/2004 >> v1.4

  • Foi acrescentado uma descrição aos papéis dos atores envolvidos nas disciplinas do PDS, vinculando os papéis aos fluxos de atividades e artefatos.

17/12/2004 >> v1.3.3

  • Modificação do endereço de e-mail do PDS;
  • Atualização da Apresentação do PDS, disponível em Downloads.

15/07/2004 >> v1.3.2

  • Conversão da árvore de navegação para JS;
  • Remoção do modelo de artefato Modelo de Casos de Uso, Análise de Projeto.

06/07/2004 >> v1.3.1

  • Atualizações internas.

29/06/2004 >> v1.3

  • O site do PDS possui agora uma nova identidade visual;
  • Os modelos de artefatos e checklists estão disponíveis em dois tipos de formatos. OpenOffice.org  e Acrobat;
  • Foram atualizados e adicionados novos documentos do MGP no site do PDS.

03/05/2004 >> v1.2.1

  • O modelo de artefato Matriz de Riscos foi excluído do processo como um documento específico. Seu conteúdo, a matriz de riscos propriamente dita, foi acrescentado ao modelo do artefato Análise de Riscos;
  • A apresentação do PDS v1.0 foi acrescentada no site, em Downloads.

22/03/2004

  • A testeira do site foi atualizada conforme a nova identidade visual do governo eletrônico;
  • O site do PDS-DATASUS foi publicado em nova estrutura baseada nas especificações HTML 4.01 e CSS Nível 2 do W3C.

Contato

E-mail: mds.suporte@saude.gov.br

Telefone: (61) 3315-2357

Responsáveis:

  • Claudia Manerich
  • Gabriela Carvalho

Endereço: Ministério da Saúde – Esplanada dos ministérios, sala 139, anexo A – Brasília – DF.