PDS-GuiaCompleto v2.3

PDS-DATASUS
Processo de Desenvolvimento de
Software
Guia Completo
Versão do produto: 2.3
Edição do documento: Maio de 2009
MS - SE - DATASUS
PDS-DATASUS
Processo de Desenvolvimento de
Software
Guia Completo
Versão do produto: 2.3
Edição do documento: Maio de 2009
Número de páginas: 114
©
DATASUS – Todos os direitos reservados
Impresso no Brasil
As informações contidas neste documento são de propriedade do DATASUS, sendo proibida

a sua divulgação, reprodução ou armazenamento em base de dados ou sistema de
recuperação sem permissão prévia e por escrito do DATASUS. Estão sujeitas a alterações
sem notificação prévia.
Os nomes de produtos, serviços ou tecnologias eventualmente mencionados neste

documento são marcas registradas dos respectivos detentores.
Fazer cópias de qualquer parte deste documento para qualquer finalidade, além do uso
pessoal, constitui violação das leis internacionais de direitos autorais.
MINISTÉRIO DA SAÚDE
Secretaria Executiva
Departamento de Informática do SUS
Processo de Documentação de Sistemas — PDOC
ii Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

Histórico de edições
M AI O DE 2009
Edição 1.3, referente ao PDS-DATASUS, versão 2.3
A GOSTO DE 2008
A GOSTO DE 2007
J A NEI RO DE 2007
Edição 1.0, referente ao PDS-DATASUS, versão 2.0.
Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 iii

Índice
1. I NTRODUÇÃO 3
1.1 Apresentação 3
2. H ISTÓRICO 7
3. M ELHORES PRÁTICAS 11
3.1 Desenvolvimento Iterativo e Incremental 11
3.2 Gerência de Requisitos 12
3.3 Gerência de Configuração 12
3.4 Gerência de Mudanças 12
3.5 Participação Ativa dos Usuários 12
3.6 Melhoria Contínua do Processo de Desenvolvimento 13
4. R ECOMENDAÇÕES DE SEGURANÇA 17
4.1 Gerência de Configuração 17
4.2 Gerência de Requisitos 19
4.3 Gerência de Documentação 20
4.4 Ciclo de Vida de Software 21
4.5 Teste de Software e Análise de Vulnerabilidade 23
5. E LEMENTOS DO PDS 27
5.1 Papéis 27
5.2 Artefatos 27
5.3 Atividades 27
5.4 Fluxo de Atividades 28
6. F ASES 31
6.1 Concepção 31
6.2 Elaboração 32
6.3 Construção 34
6.4 Transição 35
7. A TIVIDADES 39
7.1 Viabilização do projeto 39
7.2 Definir escopo do sistema 39
7.3 Classificar sistema 41
7.4 Identificar requisitos do sistema 43
Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 v

Índice MS - SE - DATASUS
7.5 Projetar arquitetura do sistema 45

7.6 Especificar casos de uso do sistema 47
7.7 Projetar sistema para validação da arquitetura 49
7.8 Modelar banco de dados para validação da arquitetura 50
7.9 Implementar sistema para validação da arquitetura 52
7.10 Testar e validar arquitetura 54
7.11 Projetar sistema 55
7.12 Modelar banco de dados 57
7.13 Codificar programas 58
7.14 Realizar testes unitários 60
7.15 Integrar e compilar o sistema 61
7.16 Estabelecer versão do sistema 62
7.17 Realizar testes no sistema 64
7.18 Elaborar documentação de usuário 66
7.19 Homologar sistema 68
7.20 Implantar sistema 69
7.21 Sistema Implantado 70
8. P APÉIS E PROCESSOS RELACIONADOS 75

8.1 Gerente de Sistemas 75
8.2 Analista de Sistemas 76
8.3 Projetista de BD 76
8.4 Programador 77
8.5 Gerente de Configuração 77
8.6 Implantação 78
8.7 Usuário 78
8.8 Usuário Gestor 78
8.9 Usuário Final 79
8.10 PTS – Processo de Teste de Software 79
8.11 PDOC – Processo de Documentação de Sistemas 79
8.12 PHS – Processo de Homologação de Software 80
9. A RTEFATOS 83
9.1 Documento de Consenso do Produto 83
9.2 Glossário 83
9.3 Matriz de Requisitos 83
9.4 Documento de Arquitetura 84
9.5 Modelo de Casos de Uso 84
9.6 Diagrama de Classes 84
9.7 Modelo de Banco de Dados 84
9.8 Código-fonte 84
9.9 Compilação do Sistema (build) 85
9.10 Versão do Sistema (release) 85
vi Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

MS - SE - DATASUS Índice
9.11 Pacote de Distribuição 85

9.12 Documentação de Usuário 86
10. D OCUMENTOS DE A POIO 89

10.1 Plano de Gerência de Configuração 89
10.2 Perfis de Segurança 89
10.3 Recomendações de Segurança para Web Service 90
11. CLASSIFICAÇÃO DE SISTEMAS 93
12. G LOSSÁRIO 97
12.1 Dicionário de Símbolos 106
L ISTA DE FIGURAS
Figura 1. Fluxo da Fase de Concepção 31

Figura 2. Fluxo da fase de Elaboração 32
Figura 3. Fluxo da Fase de Construção 34
Figura 4. Fluxo da Fase de Transição 35
Figura 5. Ciclo de versões 85
Figura 6. Dicionário de Símbolos 106
L ISTA DE TABELAS
Tabela 1. Classificação de Sistemas 94
Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 vii

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 1
1. I NTRODUÇÃO
Este documento tem como objetivo apresentar tecnicamente o Processo de
Desenvolvimento de Software padronizado para o DATASUS, o PDS-
DATASUS versão 2.3 ou PDS.
O Processo de Desenvolvimento de Software do DATASUS está em constante
processo de elaboração sendo este documento um retrato de como está a sua
definição até o momento.
1.1 Apresentação
O PDS (Processo de Desenvolvimento de Software) estabelece uma
metodologia para o desenvolvimento de software no DATASUS, através da
definição de responsáveis, artefatos, atividades e um fluxo que padroniza o
ciclo de vida de um projeto de desenvolvimento.
Apesar do PDS já estar implementado e formalizado no DATASUS desde
2002, é fato que ele não está consolidado e nem faz parte da cultura desta
instituição. Muitas vezes é a atividade mais sacrificada durante o
desenvolvimento de produtos de TI, considerando principalmente prazos e
recursos disponíveis.
Com base nesta constatação e através de acompanhamento e relatos de
equipes de desenvolvimento, verificamos a necessidade de revisão e
redesenho do PDS, tornando-o uma metodologia de desenvolvimento mais
amigável.
Na versão 2.0 do PDS todas as alterações realizadas foram feitas com o intuito
de facilitar a sua utilização por parte dos desenvolvedores, sem, contudo,
prejudicar a sua finalidade principal, ou seja: padrão de documentação de
desenvolvimento. Nesta nova visão, o PDS esta estruturado em papéis,
demonstrando claramente qual a responsabilidade dos atores envolvidos e os
produtos gerados em cada atividade.
A partir da versão 2.0 do PDS-DATASUS, consideramos que o DATASUS,
enfim, terá condições de consolidar sua metodologia de desenvolvimento de
produtos de TI.
NOTA A referência completa do PDS pode ser obtida

através do sítio: http://pds.datasus.gov.br/

2. H ISTÓRICO
A primeira versão do PDS foi desenvolvida em 2002, em um momento em que
grandes A primeira versão do PDS foi desenvolvida em 2002, em um
momento em que grandes sistemas do Datasus estavam sendo desenvolvidos
por empresas externas. Sua estrutura inicial, baseada inteiramente no RUP,
tinha como principal finalidade “padronizar” estes sistemas, facilitando a
transferência de conhecimento entre as empresas contratadas e as equipes de
desenvolvimento da instituição.
Dessa forma, quando analisamos a estrutura das primeiras versões do PDS,
observamos que grande parte de seus artefatos são extremamente descritivos,
e que vários deles não se justificariam em projetos de menor porte, com
equipes de desenvolvimento integradas e compostas por poucos profissionais.
Ainda assim, a metodologia previa a possibilidade de adequação de sua
estrutura conforme as reais necessidades de cada projeto, porém este esforço
de “personalização” do PDS demonstrou-se inviável com o passar do tempo.
Passados 2 anos da publicação da primeira versão do PDS, começaram a
surgir demandas por um processo de desenvolvimento mínimo, ou por um
conjunto mínimo de artefatos, que deveriam ser utilizados pelos projetos.
Apesar de cientes dos problemas existentes com o PDS, nossa visão sempre foi
a de que a definição de um “conjunto mínimo” descaracterizaria a
metodologia como um todo, e que o processo em si ficaria restrito a uma
burocracia de preenchimento de documentos.
Por outro lado ficava cada vez mais explícito que o tamanho do processo de
desenvolvimento era um dos principais entraves para sua efetiva
disseminação e utilização por parte das equipes de desenvolvimento da
instituição.
Motivados por todas essas questões, no início de 2006 demos início a um
processo de simplificação do Processo de Desenvolvimento de Software, tendo
como principal objetivo torná-lo prático e ágil, mais adequado aos perfis e
necessidades das nossas equipes de desenvolvimento.
Este processo de simplificação contou com a participação de desenvolvedores
de diversas áreas do Datasus, além de representantes de outros processos já
estabelecidos, como o PTS e o PTH, e envolveu uma revisão completa do ciclo
de vida de um projeto, suas atividades, e necessidades de artefatos formais.
Apesar de todo o esforço de simplificação, mantivemos as bases conceituais e

Histórico MS - SE - DATASUS
melhores práticas que fundamentaram as primeiras versões do PDS, como o

desenvolvimento iterativo e incremental, a preocupação com a gerência de
configurações e mudanças, a necessidade de envolvimento constante do
usuário durante o desenvolvimento do projeto, entre outras.
Esperamos com isso que o PDS se torne uma metodologia mais “natural” para
o Datasus, gerando reações menores por parte dos desenvolvedores e
gerentes, demandando menos esforço para satisfação de suas exigências, e
permitindo, com a sua adoção, a melhoria da qualidade dos produtos de
software desenvolvidos pela instituição.
8 Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

3. M ELHORES PRÁTICAS
Apesar de não aparecerem de forma explícita nas representações gráficas, o

PDS baseia-se na realização de práticas fundamentais para o desenvolvimento
de software.
Estas práticas devem ser implementadas como processos de apoio, formais ou
informais, e devem ser consideradas pelo gerente durante o planejamento e
acompanhamento de um projeto.
3.1 Desenvolvimento Iterativo e Incremental

Há muito se fala em desenvolvimento iterativo e incremental, e a prática já é
difundida em projetos de diversos gêneros e realizada por praticamente todos
os membros de uma equipe, mesmo que de forma empírica.
Por exemplo, quando um programador recebe uma especificação completa de
um módulo e, ao invés de implementá-la por completo, ele implementa e testa
uma única função, antes de passar para a função seguinte, ele está realizando
um desenvolvimento iterativo e incremental.
O planejamento de um projeto deve considerar a sua divisão em iterações
menores, com objetivos bem definidos, de modo a facilitar a correção de
desvios observados no decorrer do projeto em relação ao seu planejamento
original.
Considerando o ciclo PDCA de melhoria (Planejar, Executar, Verificar,
Agir/Corrigir), vemos também que mais importante que o planejamento das
iterações é a avaliação de resultados obtidos após a conclusão de cada uma, e
o aproveitamento destes resultados no planejamento e execução das próximas.
Costuma-se dizer que, em projetos de desenvolvimento, toda iteração deverá
gerar uma versão intermediária do produto que se está construindo. Embora
possa parecer estranho em uma primeira análise, esta garante o
amadurecimento da própria equipe de projeto e dos processos de trabalho,
forçando que atividades como integração/compilação do produto,
estabelecimento e empacotamento de versões e testes não sejam atividades
atômicas realizadas uma única vez ao final do projeto. E quando se fala em
versão intermediária entendemos que o produto em si não está completo –
afinal, ainda estamos no meio do projeto – mas sim que a versão contem tudo
aquilo que estava planejado para ser construído até este momento.
Conduzindo um projeto desta forma conseguimos identificar e atacar riscos

Melhores práticas MS - SE - DATASUS
antes que se tornem problemas, e resolver problemas antes que comprometam

o projeto como um todo.
3.2 Gerência de Requisitos

A gerência de requisitos tem como principal objetivo garantir que a equipe
desenvolva tudo e somente o que foi acordado com o usuário. Para isso é
necessário que os requisitos do projeto e do sistema, sejam eles de alto nível
(políticas e regulamentações) ou detalhados (especificações funcionais e não-
funcionais) sejam descritos e acordados com o usuário do sistema. Tão
importante quanto o registro destes requisitos é saber quem foi o responsável
por cada um deles, e quem pode autorizar que eles sejam alterados.
3.3 Gerência de Configuração

A gerência de configuração lida com a estrutura do produto que está sendo
desenvolvido. Os diversos itens de configuração que compõem o produto
evoluem ao longo do projeto, gerando uma série de versões que devem ser
identificadas e devem poder ser recuperadas e analisadas em um momento
futuro. Além disso, os itens de configuração de um projeto possuem
dependências entre si. Um executável depende de determinada versão de um
arquivo-fonte. Um site depende de determinada versão de uma página
HTML. Um arquivo-fonte também depende da versão da especificação
utilizada para seu desenvolvimento.
3.4 Gerência de Mudanças

A gerência de mudanças garante que todas as mudanças realizadas no projeto
ao longo do seu desenvolvimento sigam um processo formal de análise,
avaliação de impacto e autorização/aprovação pelas partes envolvidas no
projeto, tanto do lado da equipe de desenvolvimento quanto dos usuários. A
equipe do projeto deve estabelecer um processo para acompanhamento das
requisições de mudança desde a sua criação até a sua conclusão, após
implementada nos diversos níveis de artefatos do projeto.
3.5 Participação Ativa dos Usuários

O usuário representa o “cliente” do projeto de desenvolvimento. É para ele
que o sistema está sendo desenvolvido. Deste ponto de vista, este passa a ser o
papel de maior importância em todo o processo de desenvolvimento. O
usuário deve participar de todas as atividades do projeto, desde a definição do
escopo do produto e do levantamento de requisitos, até a validação e aceite do
produto final. Quanto mais rápido obtivermos retorno dos usuários quanto à
sua satisfação e concordância com os caminhos que um projeto toma, mais
rápido podemos realizar os ajustes necessários no projeto para garantir que

MS - SE - DATASUS Melhores práticas
seus objetivos sejam atendidos.
3.6 Melhoria Contínua do Processo de

Desenvolvimento
Um processo de desenvolvimento deve ser visto como uma entidade viva
dentro de uma instituição. As pessoas mudam, a tecnologia muda, o
conhecimento muda. Todo processo deve estar sendo regularmente analisado
e avaliado de forma a garantir que problemas observados sejam corrigidos,
novas necessidades sejam atendidas e novas experiências sejam assimiladas.

4. R ECOMENDAÇÕES DE SEGURANÇA
As recomendações descritas aqui são oriundas do Perfil de Segurança para

Desenvolvimento de Sistemas Parte IV – Requisitos Não Funcionais de
Segurança. Os requisitos não funcionais de segurança são aqueles não ligados
diretamente à codificação dos sistemas de informação, mas que agregam
segurança ao processo de desenvolvimento de software. Requisitos não
funcionais de segurança contemplam medidas administrativas diretamente
relacionadas ao ambiente de desenvolvimento de software e aos
procedimentos de geração dos sistemas. Requisitos não funcionais têm como
objetivo minimizar o roubo de código, introdução de código malicioso,
garantir o sigilo do código fonte, garantir a origem e autenticidade dos
executáveis gerados, permitir o rastreamento de alterações nos códigos fontes
e controlar o fluxo de informação. As recomendações de segurança estão
divididas nas seguintes seções:
■ Gerência de Configuração
■ Gerência de Requisitos
■ Gerência de Documentação
■ Ciclo de Vida de Software
■ Teste de Software
■ Análise de Vulnerabilidade
4.1 Gerência de Configuração

O objetivo de segurança da Gerência de Configuração é garantir a integridade
dos códigos fonte e prevenir alterações, subtrações, extravios e edição não
autorizada do sistema.
A gerência de configuração deve:
■ Detectar modificações não autorizadas ou acidentais no sistema ou em

partes do sistema quando ocorrerem.
o Prover, de maneira automatizada, a garantia que somente

modificações autorizadas sejam implementadas no sistema e em todos
os itens de configuração.

Recomendações de segurança MS - SE - DATASUS
o Prover meios automatizados para averiguar as mudanças entre o

sistema e sua versão predecessora. Se nenhuma versão prévia do
sistema existir, o desenvolvedor precisa prover meio automatizado
para averiguar as mudanças entre o sistema e uma versão futura.
■ Garantir a integridade do sistema desde os estágios de elaboração até os

esforços de manutenção subseqüentes.
o Descrever todos os passos necessários para geração, instalação e

inicialização segura do sistema.
o Descrever todos os procedimentos necessários para manter a

segurança ao distribuir versões do sistema para o ambiente usuário.
■ Identificar unicamente o sistema para garantir que não haja dúvidas

quanto à versão que está sendo utilizada e para que todos os usuários
envolvidos possam ter certeza de quais versões do sistema estão
utilizando.
o A referência deve ser única para cada versão do sistema.
o O sistema deve ser rotulado com sua referência. Ex: Ver 1.2.0.0;
Relase1, Beta1, Debug2.1.0
■ Identificar unicamente os itens de configuração para melhorar a

compreensão da composição do sistema, contribuindo para o avaliador
determinar os itens de configuração passíveis de avaliação.
o Incluir uma lista de configuração e descrever o método de

identificação dos itens de configuração.
o Identificar todos os itens de configuração inclusos no sistema.
o Identificar unicamente todos os itens de configuração inclusos no

sistema a cada versão.
o Descrever os itens de configuração inclusos no sistema.
■ Prover controles a fim de garantir que modificações não autorizadas não

sejam feitas no sistema, ajudando a manter sua integridade.
■ Implementar procedimentos de aceite para confirmar que qualquer criação

ou modificação de itens de configuração tenha sido previamente
autorizada.
■ Implementar as ferramentas automatizadas que precisam apoiar as

numerosas mudanças que acontecem durante o desenvolvimento e
assegurar que essas mudanças serão autorizadas.
o Descrever as ferramentas automatizadas utilizadas no sistema de

gerência de configuração.

MS - SE - DATASUS Recomendações de segurança
o Descrever como são utilizadas as ferramentas automatizadas do

sistema de gerência de configuração.
o Assegurar que todos os itens de configuração são controlados por

meios automatizados.
■ Garantir que exista controle na distribuição do sistema e nos

procedimentos de entrega do sistema, a fim de garantir que os clientes
recebam a aplicação conforme ela foi criada, sem quaisquer modificações.
Para se considerar uma entrega válida, os procedimentos usados para a
distribuição do sistema devem endereçar as ameaças identificadas no
Perfil de Segurança ou descrição funcional relacionadas à segurança do
sistema durante a entrega. Esses procedimentos visam garantir que:
o O sistema recebido pelo usuário corresponda, precisamente, à cópia

mestra do sistema.
o Evitar ou detectar qualquer falsificação da versão atual do sistema.
o Prevenir que versões adulteradas/fraudulentas do sistema sejam

distribuídas.
o Evitar divulgação não autorizada da distribuição do sistema.
o Evitar ou detectar que o sistema seja interceptado durante entrega.
o Evitar atrasos ou extravios de distribuição do sistema.
4.2 Gerência de Requisitos

A Gerência de Requisito deve:
■ Descrever os Requisitos Funcionais de Segurança e suas interfaces

externas, ainda que de modo informal.
■ Descrever o propósito e método de utilização das interfaces externas de

todos os Requisitos Funcionais de Segurança, fornecendo detalhes dos
objetos, exceções e mensagens de erro.
■ Atender completamente aos Requisitos Funcionais de Segurança.
■ Descrever a estrutura das funções de segurança em subsistemas.
■ Descrever as funcionalidades de segurança implementadas por cada

função de segurança em subsistemas.
■ Identificar qualquer hardware, firmware, e/ou softwares (DLL´S, etc.) de

camadas próximas solicitados pelas funções de segurança do sistema, com
a condição de representar as funções de segurança implementadas por
aquele determinado hardware, firmware, ou software.
■ Identificar todas as interfaces das funções de segurança por subsistemas.

■ Identificar todas as interfaces e subsistemas das funções de segurança

visíveis externamente.
■ Ser única, e não ambígua, com detalhamento de como a função de

segurança pode ser gerada sem necessitar de decisões adicionais.
4.3 Gerência de Documentação

O objetivo das recomendações da Gerência de Documentação é garantir que
os requisitos de segurança estejam na documentação de orientação (manuais)
de usuários e administradores.
A Gerência de Documentação deve:
■ Garantir que todo sistema tenha documentação com foco no

Administrador descrevendo:
o As funções administrativas e interfaces acessíveis aos administradores

do sistema.
o Como administrar o sistema de maneira segura.
o Alertas e avisos sobre funções e privilégios que devem ser controlados

em um ambiente operacional seguro.
o Todas as suposições relativas ao comportamento de usuário que

possam comprometer a segurança do sistema.
o Todos os parâmetros de segurança sob o controle do administrador e

seus valores apropriados.
o Os eventos significativos de segurança e as ações necessárias a serem

desempenhadas para garantir a operação segura do sistema, incluindo
quaisquer mudanças de características na camada de apoio ou sistemas
sob o controle da função de segurança.
o Ser clara, consistente e coerente com toda documentação fornecida

para avaliação.
o Todos os requisitos de segurança para o ambiente de TI que sejam

relevantes para o administrador.
■ Garantir que todo sistema tenha documentação com foco no Usuário

descrevendo:
o As funções e interfaces acessíveis a usuários que não são

administradores do sistema.
o O uso das funções de segurança acessíveis ao usuário fornecidas pelo

sistema.

para uma operação segura.
o Claramente ao usuário, suas responsabilidades referente a operação

segura do sistema, incluindo aquelas relacionadas as premissas de
comportamento do usuário, descritas na declaração de segurança do
sistema.
o De uma forma consistente e coerente baseada na documentação

provida para avaliação.
o Todos os requisitos de segurança para o ambiente de TI, que

apresentem relevâncias ao usuário.
4.4 Ciclo de Vida de Software

O Ciclo de Vida de Software deve:
■ Especificar um modelo de ciclo de vida a ser adotado.
o O documento de definição do ciclo de vida deve descrever o modelo

usado no desenvolvimento e manutenção do sistema.
o O modelo de ciclo de vida adotado deve dispor de controles

apropriados para o desenvolvimento e manutenção do sistema.
■ Estabelecer disciplina e controle no processo de desenvolvimento e

manutenção do sistema.
■ Fazer recomendações de segurança no desenvolvimento, que englobe

medidas de segurança física para o ambiente e procedimentos
operacionais.
o Fornecer procedimentos para tratamento de falhas aos

desenvolvedores do sistema.
o Estabelecer procedimentos para receber e agir sobre qualquer

notificação de falhas de segurança e requisições para correções dessas
falhas.
o Fornecer orientação de tratamento de falhas dirigida aos usuários do

sistema.
■ O tratamento de falhas exige procedimentos claros para receber ou

reportar falhas de segurança no sistema, endereçá-las corretamente e tratá-
las conforme sua criticidade, risco e tempo necessários para sua correção,
distribuição e implantação.
o Descrever os procedimentos para mapeamento e rastreamento das

falhas de segurança reportadas ou descobertas em cada release ou
versão do sistema.

o Solicitar uma descrição da natureza e efeito que cada falha de

segurança pode acarretar, assim como a correção apresentada para a
falha.
o Solicitar que ações corretivas sejam devidamente identificadas para

cada falha de segurança.
o Descrever os procedimentos adotados em caso de falhas, desde sua

percepção, correções e um guia de ações corretivas aos usuários.
o Descrever os métodos usados para relatar falhas, correções e guiar

ações corretivas aos usuários do sistema.
o Descrever as maneiras e meios que o desenvolvedor receberá, dos

usuários do sistema, as respostas e solicitações sobre suspeitas de falha
de segurança no sistema.
o Garantir que qualquer falha reportada será corrigida e a correção

comunicada e dirigida aos usuários do sistema.
o Garantir que correções não impliquem em novas falhas de segurança
o Descrever uma maneira de como os usuários do sistema podem

reportar uma suspeita de quebra de segurança.
■ Especificar as ferramentas e técnicas que são usadas para a elaboração do

sistema.
o Todas as ferramentas de desenvolvimento usadas para implementação

devem ser bem definidas.
o A documentação das ferramentas de desenvolvimento deve definir, de

maneira clara e não ambígua, todas as opções e valores usados na
implementação das ferramentas.
o A documentação das ferramentas de desenvolvimento deve definir, de

maneira clara, o propósito para cada opção definida na ferramenta de
desenvolvimento.
■ Ser documentado contendo:
o As medidas adotadas para procedimentos, pessoas, acesso físico e

outras medidas que são necessárias para garantir a integridade e
confidencialidade do sistema e sua implementação no ambiente de
desenvolvimento.
o As evidências que as medidas foram adotadas durante o

desenvolvimento e manutenção do sistema.
o As evidências devem garantir que as medidas são suficientes para

garantir o nível de proteção, confidencialidade e integridade do
sistema.

4.5 Teste de Software e Análise de Vulnerabilidade

Esta etapa ajuda a estabelecer que a segurança esteja de acordo com os
requisitos funcionais de segurança, embora não constate que o sistema não faz
mais do que foi especificado e descrito. Os testes também podem ser dirigidos
à estrutura interna da função de segurança, para provar que subsistemas ou
módulos atendem às especificações. Avalia também a existência de
vulnerabilidades no sistema, uso indevido e configuração incorreta do sistema
verificando a possibilidade de quebra de mecanismos probabilísticos (ex.:
criptografia) ou permutacionais (ex.: senhas) e a possibilidade de exploração
de vulnerabilidades introduzidas propositadamente no desenvolvimento ou
operação do sistema.
O Teste de Software deve:
■ Confirmar que a(s) função(ões) de segurança opera(m) de acordo com sua

especificação. (Testes Funcionais dos Casos de Uso das Funções de
Segurança).
■ Gerar evidências sobre a cobertura de testes contendo:
o A correspondência entre os testes identificados na documentação de

teste e a função de segurança como descrito na especificação funcional.
■ Contemplar teste de profundidade:
o Demonstrando, na documentação de teste, que as funções de

segurança operam de acordo com a descrição de alto nível.
■ Ser documentado contendo:
o Planos de teste, descrições de procedimento de teste, resultados

esperados do teste e resultados de teste atuais.
o Os planos de teste identificam a função de segurança a ser testada e

descreve os objetivos dos testes a serem executados.
o A descrição dos procedimentos de testes identifica os testes a serem

executados e descrevem os cenários para testar cada função de
segurança. Esses cenários incluem quaisquer dependências nos
resultados de outros testes.
o O planejamento do teste deve mostrar, antecipadamente, o resultado

esperado da execução do teste.
o O resultado do teste do desenvolvedor deve demonstrar que cada

função de segurança testada se comportou como especificada. A
Análise de Vulnerabilidade deve:
■ Detectar facilmente estados inseguros do sistema.
■ Fornecer uma documentação de ajuda que apresente identificação de

todos os possíveis modos de operação da aplicação, inclusive de operações

que possam conduzir a falhas, suas conseqüências e implicações para
manutenção de uma operação segura.
o Esta documentação identifica todos os possíveis modos de operação do

sistema (Incluindo operação após falhas de sistema ou erro
operacional), suas conseqüências e implicações para manter a operação
segura.
o A documentação de orientação deve ser Clara, Completa, Consistente

e Racional.
o A documentação de orientação deve listar todas as considerações a

respeito do ambiente operacional pretendido.
o A documentação de orientação deve listar todos os requisitos para

medidas externas de segurança, incluindo procedimentos, segurança
física e em pessoas.
■ Deve conter uma especificação de resistência ou força na função de

segurança do sistema, a análise de resistência. Esta análise deve
demonstrar:
o Que atende ou excede a especificação mínima de força definido no

Perfil de Segurança ou descrição funcional.
o Que a função de segurança atende ou excede a especificação de força,

resistência ou métrica definida no Perfil de Segurança ou descrição
funcional.
■ Ser documentada descrevendo:
o O tratamento dado as maneiras óbvias que um usuário teria de tentar

violar as funções de segurança.
o As vulnerabilidades óbvias de segurança e confirmar que não podem

ser exploradas no ambiente da qual a aplicação será instalada.

5. E LEMENTOS DO PDS
O PDS é representado e estruturado com base em 4 elementos básicos, que
representam “quem” faz “o quê”, “como” e “quando”:
■ Papéis (quem)
■ Artefatos (o quê)
■ Atividades (como)
■ Fluxo de Atividades (quando)
5.1 Papéis
Um papel define o comportamento e responsabilidades de um profissional ou
grupo de profissionais que participam do desenvolvimento do projeto.
O comportamento é representado através das atividades que cada papel deve
desempenhar ao longo do projeto.
As responsabilidades normalmente estão associadas aos 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 projeto.
5.2 Artefatos
Em sentido amplo, o termo artefato representa um produto concreto
produzido, modificado ou utilizado pelas atividades de um processo.
Os artefatos representados no PDS não incluem todos os artefatos de um
projeto de desenvolvimento, mas todos estes devem ser elaborados ao longo
do projeto.
O PDS disponibiliza modelos (templates) para a maioria de seus artefatos, com
o objetivo de orientar e facilitar a sua elaboração.
5.3 Atividades
Uma atividade no PDS representa um conjunto de passos e tarefas que um

Elementos do PDS MS - SE - DATASUS
profissional, que desempenha o papel responsável por aquela atividade, deve

executar para gerar algum resultado.
As atividades envolvem a produção e modificação de artefatos do projeto.
5.4 Fluxo de Atividades

O fluxo de atividades do PDS apresenta a seqüência e a dependência entre as
atividades do projeto ao longo do tempo. As atividades no fluxo são divididas
em fases do ciclo de vida do projeto e nos papéis responsáveis pela execução
de cada uma.
É possível fazer o download do fluxo de atividades através do link
http://pds.datasus.gov.br/PDS/downloads/PDS-FluxoAtividadesA4_v2.3.pdf

6. F ASES
O ciclo de vida do projeto no PDS é representado em um diagrama de
atividades, tendo em um dos eixo as 4 fases previstas para um projeto de
desenvolvimento e, no outro, os papéis responsáveis por cada uma das
atividades. Cada fase possui um objetivo específico e o final de cada fase
representa um grande marco do projeto. Ao final de cada fase, o gerente do
sistema deverá solicitar à área responsável pelo PDS para gerar o checklists
para validação de segurança no sistema.
6.1 Concepção
Figura 1. Fluxo da Fase de Concepção
Esta fase marca o início do projeto de desenvolvimento.

O objetivo da fase de Concepção é o estabelecimento de um acordo formal,
entre a equipe de desenvolvimento e usuários do projeto, do escopo do
produto a ser desenvolvido.
A viabilização do projeto pelo Datasus marca o início do projeto de
desenvolvimento. O processo de viabilização propriamente dito é considerado
externo ao PDS e não faz parte do escopo da metodologia.
A partir da viabilização, a equipe do projeto dá início ao detalhamento do
escopo do produto.
O escopo detalhado deve ser registrado no Documento de Consenso do
Produto e aprovado formalmente pelos usuários.
O fim da fase de Concepção representa o primeiro grande marco do projeto.

Fases MS - SE - DATASUS
Marco
■ Escopo Aprovado
Artefatos Produzidos
■ Documento de Consenso do Produto (aprovado)
■ Glossário (versão inicial)
6.2 Elaboração
Figura 2. Fluxo da fase de Elaboração
Esta fase envolve uma análise detalhada sobre as necessidade e problemas

gerais do projeto e a definição de como o sistema será desenvolvido em
termos tecnológicos, considerando os requisitos, limitações e restrições
identificados durante a fase de Concepção.
O objetivo da fase de Elaboração é o estabelecimento e validação de uma
arquitetura de hardware e software que suporte de forma adequada os
requisitos funcionais e não-funcionais do sistema.
Durante esta fase os analistas de sistema da equipe do projeto devem
identificar os requisitos detalhados do produto a partir de reuniões e
entrevistas de levantamento junto aos usuários.
Estes requisitos deverão ser descritos detalhadamente na Matriz de Requisitos
do projeto e através de um Diagrama de Casos de Uso, representando a visão
funcional e as fronteiras do sistema.
Os casos de uso identificados deverão ser descritos detalhadamente no
Modelo de Casos de Uso que, além do diagrama de casos de uso elaborado
durante o levantamento de requisitos, inclui também as Especificações de
Casos de Uso.
Em paralelo, a equipe de analistas de sistema define a arquitetura de
hardware e software do sistema, que deverá ser documentada no Documento

MS - SE - DATASUS Fases
de Arquitetura.
Do total de casos de uso especificados para o sistema, deve-se selecionar os
cenários que, uma vez implementados, permitam a avaliação de viabilidade e
validação da arquitetura especificada para o sistema.
As demais atividades desta fase garantem que os cenários de casos de uso
selecionados sejam projetados, implementados e testados, de forma a garantir
que a arquitetura especificada seja suficientemente adequada para suportar os
requisitos funcionais e não-funcionais do sistema.
O fim da fase de Elaboração representa o segundo grande marco do projeto.
Marco
■ Arquitetura Validada
■ Matriz de Requisitos
■ Modelo de Casos de Uso
■ Documento de Arquitetura
■ Diagrama de Classes (contemplando a arquitetura do sistema)
■ Modelo de Banco de Dados (contemplando a arquitetura do sistema)
■ Versão do Sistema (arquitetura testada e validada)
■ Glossário

6.3 Construção
Figura 3. Fluxo da Fase de Construção
Esta fase compreende o desenvolvimento propriamente dito do sistema, em

termos de códigos-fonte e componentes de software.
O objetivo desta fase é o desenvolvimento de uma versão operacional do
sistema, estável o suficiente para ser disponibilizada para homologação por
seus usuários finais, no menor tempo possível, considerando os critérios de
qualidade estabelecidos pelo projeto.
Os analistas de sistema da equipe estarão envolvidos no projeto detalhado do
sistema – Diagramas de Classes e outros diagramas considerados relevantes
para a representação do projeto do sistema, enquanto os projetistas de banco
de dados estarão envolvidos na modelagem da versão completa do banco de
dados. Com bases nestas informações, no Modelo de Casos de Uso, na Matriz
de Requisitos e no Documento de Arquitetura, os programadores estarão
focados na implementação do sistema e de seus componentes, através de
atividades de codificação, realização de testes unitários e na integração e
compilação de versões intermediárias.
A fase de Construção deverá ser divida em iterações de acordo com a
necessidade identificada pelo gerente do sistema.
A cada iteração será gerada e testada uma nova compilação do sistema,
contendo os cenários de casos de uso implementados até o momento.
Todos os produtos do projeto deverão estar sob uma gerência de
configuração, de responsabilidade do gerente de configuração da equipe.
A cada iteração, o gerente de configuração é responsável por estabelecer um
nova versão do sistema e gerar um novo pacote de distribuição contendo,
além do sistema em si, toda a documentação associada ao mesmo, incluindo

MS - SE - DATASUS Fases
todos os sub-produtos que o compõem.

Este pacote de distribuição é, então, disponibilizado para testes pelo Processo
de Testes de Software do Datasus. Os testes de software, apesar de descritos
superficialmente no PDS, estão fora do escopo da metodologia e encontram-se
melhor descritos em documentação própria, disponível no site do PTS (http://
pts.datasus.gov.br).
Ao fim da última iteração desta fase a equipe do projeto terá a primeira versão
operacional do sistema.
O fim da fase de Construção representa o terceiro grande marco do projeto.
Marco
■ Versão Operacional do Sistema
■ Diagrama de Classes (completo)
■ Modelo de Banco de Dados (completo)
■ Versão do Sistema (testada)
■ Pacote de Distribuição (operacional)
6.4 Transição
Figura 4. Fluxo da Fase de Transição
Esta fase envolve as atividades necessárias para que o sistema desenvolvido

seja adequadamente disponibilizado a seus usuários.
O objetivo desta fase é o aceite da versão final do sistema por seus usuários,
através de atividades referentes à homologação e implantação do produto,
com a preocupação em que os usuários sejam auto-suficientes na utilização,
operação e administração do produto.

Em paralelo à homologação do sistema, a documentação de usuário pode ser

desenvolvida pela equipe do Processo de Documentação de Sistemas, PDOC.
A atividade de documentação, apesar de descrita junto à metodologia, é
considerada externa ao PDS e pode ser melhor detalhada diretamente no site
do PDOC (http://pdoc.datasus.gov.br).
A homologação do sistema deve ser realizada através do Processo de
Homologação de Software do Datasus. Apesar de descrita superficialmente
nesta metodologia, esta atividade é considerada fora do escopo do PDS e
encontra-se melhor descrita em documentação específica do PHS. Estando o
sistema homologado pelo Datasus junto a seus usuários, ele estará disponível
para implantação em ambiente de produção.
As atividades de implantação também são consideradas externas ao escopo do
PDS e podem ser melhor descritas pela área de Implantação do Datasus.
Apesar desta fase estar baseada principalmente em atividades externas ao
PDS, consideramos importante relacioná-las no ciclo de vida do projeto, uma
vez que são consideradas etapas do processo de desenvolvimento como um
todo.
Entendemos que a passagem do produto para o ambiente de produção deve
ser preocupação constante da equipe de desenvolvimento, e todas as
atividades relacionadas devem ser planejadas desde o início do projeto.
Todo o PDS tem como objetivo final a disponibilização para os usuários de um
produto desenvolvido em conformidade com suas especificações, dentro dos
critérios de qualidade previstos para o projeto, e que possa ser prontamente
utilizado por seus usuários.
O fim da fase de Transição marca o fim do projeto de desenvolvimento,
representado pelo quarto grande marco do projeto.
Marco
■ Versão Final do Sistema
■ Versão do Sistema (homologada)
■ Documentação de usuário
■ Pacote de Distribuição (final)

7. A TIVIDADES
Uma atividade no PDS 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.
As atividades envolvem a produção e modificação de artefatos do projeto.
Abaixo estão relacionadas as atividades previstas no PDS:
7.1 Viabilização do projeto
Definição
A viabilização do projeto envolve todo esforço de negociação, aprovação e
alocação de responsabilidades, considerando a participação de representantes
do Datasus e dos usuários. Por se tratarem de tarefas estritamente gerenciais,
consideramos que devem ser melhor descritas em metodologia de gerência de
projetos própria e, por este motivo, não fazem parte do escopo do PDS. Do
ponto de vista do PDS, o projeto de desenvolvimento tem início a partir do
momento em que o projeto é viabilizado pelo Datasus e um gerente de sistema
responsável é alocado.
Nesta atividade deve ser escolhido o Gerente de Sistemas e também um
substituto, ambos devem ser nomeados pela área que solicitou o sistema.
7.2 Definir escopo do sistema
Responsável
Gerente de Sistemas
Definição
A definição de escopo do sistema envolve a participação do gerente do
sistema e de representantes dos usuários, com apoio de analistas de sistemas
da equipe de desenvolvimento.
Esta atividade tem como objetivo o estabelecimento das principais
funcionalidades e fronteiras do sistema.
Parte destas informações já terão sido identificadas e estabelecidas durante o

Atividades MS - SE - DATASUS
processo de viabilização do projeto.

Uma outra parte deverá ser obtida junto a representantes dos usuários através
de reuniões e entrevistas de levantamento.
No decorrer desta atividade o gerente do sistema deve elaborar o Documento
de Consenso do Produto, contendo as seguintes informações:
■ objetivos do produto
■ contexto do problema / oportunidade
■ escopo e não escopo
■ principais necessidades dos usuários
■ visão macro do sistema / diagrama de contexto
Ao fim da atividade, o Documento de Consenso do Produto é considerado

90% concluído, restando apenas a classificação do sistema quanto ao nível de
segurança que será adotado durante seu desenvolvimento.
Em paralelo, a equipe do projeto inicia a elaboração de um Glossário contendo
as definições de termos específicos ao projeto considerados relevantes.
Passos
■ Identificar objetivos do sistema a ser desenvolvido
■ Descrever o contexto do projeto, com todos os detalhes da situação atual
■ Levantar as principais necessidades dos usuários do sistema, da forma

como são definidas pelos mesmos
■ Levantar escopo do produto, com principais funcionalidades e recursos a

serem oferecidos
■ Observar e registrar as funcionalidades e recursos que não farão parte do

sistema (não-escopo)
■ Elaborar diagrama de contexto do sistema, representando sua interação

com seus usuários, outros sistemas já existentes e processos de negócio
associados
■ Elaborar o Documento de Consenso do Produto
■ Registrar as definições de termos específicos ao sistema, identificados até o

momento, no Glossário do projeto
■ Revisar o Glossário junto à área de Homologação em conformidade com o

PHS
Entradas
■ Informações provenientes da viabilização do projeto

MS - SE - DATASUS Atividades
■ Plano de gerência de configuração
Saídas
■ Documento de consenso do produto (90% completo)
■ Glossário (versão inicial)
7.3 Classificar sistema
Responsável
Gerente de Sistemas
Definição
A classificação do sistema envolve a participação do gerente do sistema, com o
apoio de analistas e da equipe de desenvolvimento.
Esta atividade inclui uma análise das informações administradas pelo sistema
e a definição da classe ao qual ele pertence.
Os sistemas do DATASUS podem ser classificados em um dos 3 (três) grupos
abaixo:
■ Internos / de Apoio
■ Financeiros / Gerenciais
■ Médicos / Ambulatoriais
Os detalhes de cada classe de sistema podem ser obtidos no capítulo

Classificação de Sistemas. Caso o sistema apresente características de mais de
uma classe, a classe de mais alto nível deverá ser adotada.
Para classificação dos sistemas deverão ser adotados os seguintes critérios:
■ Caso o sistema lide com informações que permitam a identificação pessoal

de usuários do SUS, ele deverá ser classificado como Médico /
Ambulatorial;
■ Caso o sistema lide com informações financeiras e cadastrais de

profissionais, gestores e órgãos do SUS, ele deverá ser classificado como
Financeiro / Gerencial;
■ Caso o sistema não se enquadre em uma das classificações acima deverá

ser classificado como Interno / de Apoio.
Cada classe de sistema é subdividida em 3 (três) níveis de segurança: básico,

médio, alto. A definição do nível adotado para o sistema deverá estar baseada
nos fatores probabilidade, severidade e relevância dos riscos de segurança

relacionados ao sistema.
Ao fim da atividade o Documento de Consenso do Produto deve ser
atualizado com o resultado da classificação de segurança e deve ser
formalmente aprovado entre o gerente do sistema e o usuário gestor do
sistema, servindo como um “contrato” daquilo que será desenvolvido.
A partir da aprovação do Documento de Consenso, toda alteração no projeto
que tenha impacto em seu conteúdo deve ser analisada e renegociada entre a
equipe do projeto e representantes dos usuários, e uma nova versão do
documento deve ser estabelecida e aprovada por ambas as partes.
Passos
■ Avaliar o escopo do produto e os ativos de informação envolvidos no
sistema
■ Definir a classe de segurança do sistema com base nas informações

manipuladas e escopo do sistema
■ Caso o sistema apresente características de mais de uma classe, a classe de

maior nível de segurança deverá ser selecionada
■ Avaliar a probabilidade, severidade e relevância de riscos de segurança ao

sistema
■ Estabelecer o nível de segurança adotado
■ Registrar no Documento Consenso de Produto a classificação do sistema

quanto à segurança
■ Revisar o Documento de Consenso de Produto junto à área de

Homologação em conformidade com o PHS
■ Realizar reunião para apresentação e aprovação do Documento de

Consenso do Produto entre o Usuário Gestor do sistema, o Gerente do
Sistema e o Coordenador Geral responsável pelo sistema
Entradas
■ Documento de consenso do produto (90% completo)
Saídas
■ Documento de consenso do produto (aprovado)

7.4 Identificar requisitos do sistema
Responsável
Analista de Sistemas
Definição
A identificação de regras de negócio e requisitos conta com a participação da
equipe de analistas de sistemas em conjunto com representantes do usuário
gestor e dos usuários finais do sistema e quaisquer outras fontes de
informação consideradas relevantes pela equipe do projeto.
Esta atividade tem como objetivo a definição de uma visão do sistema e a
representação desta visão através de um Diagrama de Casos de Uso e de uma
Matriz de Requisitos.
Parte dos requisitos do sistema poderão ser obtidos através do Documento de
Consenso do Produto.
Uma outra parte deve ser obtida através de entrevistas e reuniões de
levantamento com representantes do usuário gestor e usuários finais,
consultas a regulamentações, políticas e padrões aplicáveis, entre outras
fontes.
As regras de negócio estabelecem requisitos gerais para o sistema,
provenientes do próprio negócio como normas, políticas, legislações etc
Um requisito é definido no PDS como “uma condição ou capacidade que o
sistema precisa atender ou ter”.
Os requisitos levantados durante esta atividades devem ser descritos,
priorizados e classificados na Matriz de Requisitos do Projeto.
A priorização de cada regra de negócio e/ou requisito deve ser realizada em
conjunto com os responsáveis por sua definição e devem ser definidos como:
■ Essenciais – a não implementação do requisito inviabiliza o sistema como

um todo;
■ Importante – a não implementação do requisito limita o alcance do

sistema, mas não impede sua utilização;
■ Desejável – a não implementação do requisito não prejudica os objetivos

do projeto.
As regras de negócio e os requisitos devem ser classificados entre funcionais,

não-funcionais, informativos e regras do negócio:
■ Funcionais – a implementação do requisito estará refletida em

funcionalidades do sistema;
■ Não-funcionais – estabelecem restrições gerais do sistema em termos de

usabilidade, performance, confiabilidade, documentação, entre vários

outros;
■ Informativos – acrescentam informações adicionais relevantes para o

projeto;
Os requisitos funcionais e as regras de negócios serão mapeados por casos de

uso os quais deverão ser representados no Diagrama de Casos de Uso,
juntamente com os diversos atores do sistema identificados.
Durante esta atividade o Glossário do projeto será atualizado com novos
termos identificados.
As interações entre os diversos atores com o sistema serão levantadas
detalhadamente na atividade Especificar Casos de Uso do Sistema.
Passos
■ Identificar as regras de negócio e os requisitos já definidos no Documento
de Consenso do Produto e em outras documentações referenciadas neste
■ Levantar os requisitos e as regras de negócios do sistema através de

entrevistas com representantes do usuário gestor e usuários finais, e
registrá-los na Matriz de Requisitos do Sistema
■ Com base na classificação do sistema, levantar no Perfil de Segurança

adequado os requisitos que serão implementados no sistema e registrá-los
na Matriz de Requisitos
■ Atualizar o Glossário do projeto com novos termos identificados durante o

levantamento de requisitos
■ Priorizar os requisitos levantados, em conjunto com o responsável por sua

definição, como: essencial, importante ou desejado
■ Classificar os requisitos levantados como: funcionais, não-funcionais,

informativos ou regras de negócio
■ Identificar, com base nos requisitos funcionais levantados, os atores e

casos de uso do sistema
■ Identificar os relacionamentos entre atores e casos de uso, representando-

os através de um Diagrama de Casos de Uso
■ Revisar a Matriz de Requisitos, o Diagrama de Casos de Uso e o Glossário

junto à área de Homologação em conformidade com o PHS
■ Revisar, junto aos representantes do usuário gestor e de usuários finais, a

Matriz de Requisitos e o Diagrama de Casos de Uso.

Entradas
■ Glossário (inicial)
■ Perfis de segurança
■ Regulamentações relacionadas
Saídas
■ Matriz de requisitos
■ Modelo de casos de uso (diagrama de casos de uso)
■ Glossário (atualizado)
7.5 Projetar arquitetura do sistema
Responsável
Definição
O projeto da arquitetura do sistema conta com a participação da equipe de
analistas do projeto, com o apoio de programadores e projetistas de banco de
dados. É comum, também, a existência de um membro específico da equipe
que assume o papel de arquiteto.
O objetivo desta atividade é a definição dos mecanismos fundamentais que
serão utilizados para o desenvolvimento do sistema.
A arquitetura definida deverá suportar de forma adequada os requisitos
funcionais e não-funcionais levantados para o sistema.
A definição dos mecanismos da arquitetura inclui decisões de projeto a
respeito de como o sistema será implementado em termos de:
■ Linguagens de programação
■ Tecnologias/plataformas utilizadas
■ Métodos, componentes e ferramentas para acesso e recuperação de dados
■ Distribuição e comunicação entre componentes e aplicativos
■ Infra-estrutura de hardware e software
■ Log e tratamento de erros
■ Segurança

■ Padrões e convenções
A arquitetura deverá ser descrita a partir do Documento de Arquitetura que

deve conter, além das descrições dos mecanismos, os critérios que motivaram
as decisões tomadas para o projeto do sistema.
Além das descrições dos mecanismos fundamentais, a arquitetura pode ser
representada através de diagramas demonstrando as estruturas estáticas e
dinâmicas do sistema e, principalmente, sua distribuição física e lógica.
Estas representações podem ser elaboradas utilizando diagramas da UML
(pacotes, classes, seqüência, distribuição, componentes etc.).
Passos
■ Analisar os requisitos funcionais e não-funcionais levantados para o
sistema com base na Matriz de Requisitos, no Diagrama de Casos de Uso e
no Documento de Consenso do Produto
■ Projetar os mecanismos fundamentais necessários para que a arquitetura

projetada suporte de forma adequada os requisitos do sistema
■ Avaliar a viabilidade de implementação dos mecanismos definidos
■ Elaborar representações gráficas da arquitetura e de seus mecanismos
■ Registrar as decisões de projeto, os mecanismos definidos e a as

representações gráficas elaboradas no Documento de Arquitetura
■ Revisar o Documento de Arquitetura junto à área de Homologação em

conformidade com o PHS
■ Revisar, em conjunto com representantes do usuário gestor e usuários

finais, a arquitetura proposta para o sistema
Entradas
■ Recomendações de segurança para Web Service (se necessário)
Saídas
■ Documento de arquitetura

7.6 Especificar casos de uso do sistema
Responsável
Definição
A especificação de casos de uso conta com a participação da equipe de
analistas de sistemas em conjunto com representantes do usuário gestor e dos
usuários finais do sistema.
Esta atividade tem como objetivo o detalhamento das interações entre os
diversos atores do sistema e os casos de uso identificados.
Para cada caso de uso, o analista deverá identificar qual a resposta e
comportamento esperado para o sistema para cada ação de um ator (usuário).
A especificação de cada caso de uso deverá incluir as seguintes informações:
■ Descrição (resumida) do objetivo do caso de uso
■ Atores envolvidos
■ Pré-condição – situação ou estado tido como pré-requisito para que o caso

de uso possa ser realizado
■ Fluxo Principal – relação “natural” de passos descrevendo as ações do ator

envolvido e a conseqüente resposta esperada para o sistema, considerando
uma situação em que tudo ocorra como previsto
■ Fluxo Alternativo – relação de passos alternativos ao roteiro “natural” do

caso de uso, apresentando as reações do sistema em situações alternativas
■ Exceções – relação de passos alternativos ao roteiro “natural” do caso de

uso, apresentando as reações do sistema em condições de erros
■ Pós-condição – situação ou estado definido como conseqüência da

conclusão do caso de uso
■ Requisitos – identificadores dos requisitos associados com o caso de uso
A especificação de cada caso de uso deve ser revisada e aprovada por um

representante do usuário gestor ou usuários finais.
Passos
■ Analisar os requisitos funcionais e não-funcionais levantados para o
sistema com base na Matriz de Requisitos, no Diagrama de Casos de Uso e
no Documento de Consenso do Produto
■ Para cada caso de uso, em conjunto com representantes do usuário gestor

ou dos usuários finais, através de reuniões de especificação de caso de uso:
o Descrever os objetivos do caso de uso
o Identificar os atores envolvidos
o Levantar as pré-condições para realização do caso de uso
o Descrever o fluxo principal do caso de uso
o Descrever os fluxos alternativos identificados para o caso de uso
o Descrever as situações de exceção identificadas para o caso de uso
o Identificar pós-condições esperadas
o Relacionar os requisitos do sistema (registrados na Matriz de

Requisitos) que estão implementados e/ou cobertos no caso de uso
■ Revisar o Diagrama de Casos de Uso com possíveis modificações

identificadas durante o processo de especificação
■ Revisar a Matriz de Requisitos em função de informações obtidas durante

a especificação de casos de uso, principalmente em relação aos
relacionamentos entre requisitos e casos de uso
■ Verificar se todos os requisitos funcionais estão cobertos pelos casos de

uso especificados
■ Revisar o Modelo de Caso de Uso, a Matriz de Requisitos (em função de

informações obtidas durante a especificação de casos de uso) e o Glossário
junto à área de Homologação em conformidade com o PHS
■ Revisar as especificações de casos de uso em conjunto com representantes

do usuário gestor e usuários finais e obter aprovação para cada uma delas
Entradas
■ Glossário
Saídas
■ Modelo de casos de uso (especificação de casos de uso)
■ Glossário (atualizado)

7.7 Projetar sistema para validação da arquitetura
Responsável
Definição
O projeto do sistema para validação da arquitetura é realizado pela equipe de
analistas de sistemas.
Esta atividade tem como objetivo o projeto de parte do sistema, mais
especificamente dos cenários de casos de uso necessários para validação da
arquitetura definida para o sistema.
Nesta fase do projeto, os analistas deverão identificar os cenários de casos de
uso que, uma vez implementados, permitam uma validação confiável da
arquitetura definida para o sistema, garantindo que a mesma suporte de
forma adequada os requisitos funcionais e não-funcionais do sistema.
Normalmente estes cenários representam até 20% das funcionalidades
esperadas para o sistema completo.
Demais casos de uso e cenários serão projetados e implementados durante a
fase de Construção.
A atividade de projeto tem como objetivo a elaboração de um diagrama de
classes representando classes necessárias para realização dos casos de uso do
sistema.
O Diagrama de Classes deverá ser desenvolvido com base no Modelo de
Casos de Uso, nos mecanismos descritos no Documento de Arquitetura, e nos
requisitos do sistema descritos na Matriz de Requisitos.
Conforme o caso pode ser necessário a elaboração de diagramas adicionais
como, por exemplo, o de seqüência e o de estado.
Ao final desta atividade, o Diagrama de Classes deverá conter além das
classes identificadas, seus relacionamentos, atributos e métodos.
Passos
■ Analisar os mecanismos de projeto definidos (Documento de Arquitetura),
os requisitos do sistema (Matriz de Requisitos) e as especificações de casos
de uso (Modelo de Casos de Uso)
■ Identificar os cenários de caso de uso que, uma vez implementados,

permitam uma validação segura da arquitetura do sistema
■ Identificar, a partir dos cenários de casos de uso selecionados, as classes

necessárias para sua realização

■ Identificar os relacionamentos entre as classes levantadas
■ Identificar os atributos para cada classe
■ Identificar os métodos necessários a cada classe para realização dos

cenários de casos de uso selecionados
■ Elaborar o Diagrama de Classe
■ Revisar o Diagrama de Classe junto à área de Homologação em

■ Analisar conformidade entre o diagrama de classes elaborado, os

requisitos do sistema e os mecanismos de projeto definidos no Documento
de Arquitetura
Entradas
■ Modelo de casos de uso
■ Documento arquitetura
■ Glossário
Saídas
■ Diagrama de classes (contemplando a arquitetura do sistema)
7.8 Modelar banco de dados para validação da

arquitetura
Responsável
Projetista de Banco de Dados
Definição
A modelagem de banco de dados para validação da arquitetura é realizada
pelo projetista de banco de dados da equipe.
Esta atividade tem como objetivo a elaboração do projeto de banco de dados,
mais especificamente dos elementos necessários para suportar a
implementação dos cenários de casos de uso selecionados para validação da
arquitetura do sistema.
O Modelo de Banco de Dados deverá ser desenvolvido com base no Diagrama
de Classes, elaborado pela equipe de analistas de sistemas, e nos mecanismos

fundamentais descritos no Documento de Arquitetura.

O projeto do banco de dados deve levar em consideração, também, os
requisitos não-funcionais, principalmente os de performance e segurança,
estabelecidos na Matriz de Requisitos do projeto.
O Modelo de Banco de Dados deve incluir:
■ Tabelas do sistema e seus campos
■ Relacionamentos
■ Chaves primárias e estrangeiras
■ Índices
■ Especificação de stored procedures
■ Triggers
■ Papéis e usuários, com informações sobre as devidas permissões
■ Dicionário de dados, com descrição textual dos valores armazenados e

convenções utilizadas para cada elemento.
O projeto do banco de dados deve prever, também, o tamanho estimado da

base de dados no momento de implantação do sistema, e sua previsão de
crescimento (em termos relativos ou absolutos) com o passar do tempo.
O PDS, até o momento, não disponibiliza templates para o Modelo de Banco de
Dados, devendo ser utilizada a ferramenta de modelagem definida para o
projeto.
Passos
o Diagrama de Classes, os requisitos não-funcionais do sistema (Matriz de
Requisitos) e as especificações de casos de uso (Modelo de Casos de Uso)
■ Identificar, a partir do Diagrama de Classes elaborado, as tabelas

necessárias para armazenamento dos dados persistentes do sistema
■ Identificar os relacionamentos e as chaves primárias e estrangeiras das

tabelas
■ Com base nos cenários de casos de uso e nos métodos definidos para as
classes do sistema, identificar as stored procedures e triggers necessárias
■ Com base nos requisitos não-funcionais de performance e nos acessos

previstos às tabelas dos sistemas, identificar os índices necessários para
cada tabela
■ Com base nos requisitos de segurança e perfis de acesso do sistema,

identificar os papéis e usuários do banco de dados, com a definição de

suas permissões
■ Elaborar o dicionário de dados do sistema
■ Elaborar o Modelo de Banco de Dados contendo os elementos

identificados
■ Revisar o Dicionário de Dados e o Modelo de Banco de Dados junto à área

de Homologação em conformidade com o PHS
■ Analisar a conformidade entre o modelo de banco de dados, o diagrama

de classes, os requisitos do sistema e os mecanismos de projeto definidos
no Documento de Arquitetura
Entradas
■ Diagrama de classes
■ Glossário
Saídas
■ Modelo de banco de dados
7.9 Implementar sistema para validação da

arquitetura
Responsável
Programador
Definição
A implementação do sistema para validação da arquitetura é realizada pela
equipe de programadores do projeto.
Esta atividade tem como objetivo a geração de uma versão executável do
sistema (intermediária), que permita a realização de testes e a validação da
arquitetura de software definida.
Nesta fase do projeto, a implementação do sistema contempla apenas os
cenários de casos de uso selecionados para validação da arquitetura e que,
neste momento, já estarão especificados e projetados.
A implementação deve ser realizada com base nas Especificações de Casos de
Uso, Diagrama de Classes, Modelo de Banco de Dados e Documento de
Arquitetura, e envolve as seguintes tarefas:

■ Codificação dos cenários selecionados para validação da arquitetura
■ Implementação de scripts, stored procedures e triggers para o banco de dados
■ Realização de testes unitários sobre o código desenvolvido
■ Integração e compilação do sistema
■ Realização de testes de integração sobre o sistema compilado
■ Estabelecimento de versão do sistema (versão intermediária para

validação da arquitetura)
Passos
■ Analisar as especificações de casos de uso (Modelo de Casos de Uso), os
mecanismos de projeto definidos (Documento de Arquitetura), o
Diagrama de Classes e o Modelo de Banco de Dados
■ Codificar os elementos do sistema
■ Implementar os scripts, stored procedures e triggers do banco de dados
■ Realizar testes unitários sobre cada elemento implementado
■ Integrar e compilar o sistema
■ Realizar testes de integração sobre a versão compilada do sistema
■ Estabelecer formalmente uma versão para o sistema, garantindo que os

itens de configuração que compõem esta versão sejam devidamente
identificados no repositório de controle de versão do projeto
Entradas
■ Diagrama de classes (contemplando a arquitetura do sistema)
■ Modelo de banco de dados (contemplando a arquitetura do sistema)
Saídas
■ Versão do sistema (Para validação da arquitetura)

7.10 Testar e validar arquitetura
Responsável
Programador
Definição
O teste e a validação da arquitetura envolvem a participação da equipe de
programadores do projeto, com o apoio da equipe de analistas, projetistas de
banco de dados, equipe de teste e representantes do usuário gestor e usuários
finais.
Esta atividade tem como objetivo a validação formal da arquitetura definida
para o sistema.
Para validação da arquitetura é necessária a realização de testes, a fim de
garantir que a versão implementada do sistema, contemplando no momento
apenas a arquitetura, atenda de forma adequada aos requisitos estabelecidos.
Apesar de já ser possível a realização de testes funcionais, o foco principal
desta atividade está em testes não funcionais, uma vez que, a maior parte dos
requisitos considerados para o projeto da arquitetura são os requisitos não-
funcionais.
A equipe do projeto pode demandar a realização destes testes ao PTS. O PTS
(Processo de Teste de Software) é um processo de testes certificado que conta
com infra-estrutura do LACQUA (Laboratório de Controle de Qualidade de
Soluções Informatizadas do SUS), apropriada para a realização de testes
especializados.
Ao fim desta atividade, a equipe do projeto está em condições de garantir que
a arquitetura definida para o sistema suporta de forma adequada seus
requisitos funcionais fundamentais e não-funcionais.
Caso os requisitos do sistema não sejam atendidos pela arquitetura projetada,
esta deve ser revista, reimplementada e testada novamente, antes que o
projeto passe para a próxima fase.
A validação da arquitetura constitui o segundo grande marco do projeto e, por
este motivo, deve ser aprovada pelos representantes do usuário gestor e
usuários finais.
Esta atividade marca o fim da fase de Elaboração.
Passos
■ Analisar o projeto da arquitetura (Documento de Arquitetura), os
requisitos não-funcionais do sistema (Matriz de Requisitos) e as
especificações de casos de uso (Modelo de Casos de Uso)
■ Realizar o planejamento dos testes necessários para validação dos

requisitos e cenários de casos de uso implementados

■ Conforme a necessidade, solicitar a realização de testes ao PTS (consultar o

site do Processo de Teste de Software http://pts.datasus.gov.br para
maiores informações)
■ Desenvolver casos de teste para validação dos requisitos e cenários de

casos de uso selecionados
■ Implementar e executar os testes sobre a versão do sistema (release)
■ Avaliar, com base nos resultados obtidos durante os testes, a

conformidade da release do sistema com os requisitos estabelecidos na
Matriz de Requisitos e com as especificações de casos de uso
■ Obter aprovação junto aos representantes do usuário quanto à validação

realizada e à adequação da arquitetura aos requisitos estabelecidos para o
sistema
Entradas
■ Versão do sistema (Para validação da arquitetura)
Saídas
■ Versão do sistema (arquitetura testada e validada)
7.11 Projetar sistema
Responsável
Definição
O projeto do sistema é realizado pela equipe de analistas de sistemas do
projeto.
Esta atividade tem como objetivo a conclusão do projeto do sistema,
considerando que parte do projeto, contemplando os cenários de casos de uso
necessários para validação da arquitetura, já foi desenvolvida durante a fase
de Elaboração.
Nesta fase os analistas devem concluir a elaboração do diagrama de classes do
projeto para todos os cenários de casos de uso do sistema, a partir da versão

parcial do diagrama de classes já desenvolvida.

O Diagrama de Classes deve ser desenvolvido com base no Modelo de Casos
de Uso, nos mecanismos descritos no Documento de Arquitetura, e nos
requisitos do sistema descritos na Matriz de Requisitos.
Conforme o caso, pode ser necessária a elaboração de diagramas adicionais
como, por exemplo, o de seqüência e o de estado.
Ao final desta atividade, o Diagrama de Classes deve conter todas as classes
do sistema, com seus relacionamento, atributos e métodos.
Passos
os requisitos do sistema (Matriz de Requisitos) e as especificações de casos
de uso (Modelo de Casos de Uso)
■ Identificar, a partir dos cenários de casos de uso do sistema, as classes

necessárias para sua realização
■ Identificar os relacionamentos entre as classes levantadas
■ Identificar os atributos para cada classe
■ Identificar os métodos necessários a cada classe para realização dos

cenários de casos de uso
■ Elaborar o Diagrama de Classe
■ Revisar o Diagrama de Classe junto à área de Homologação em

■ Analisar a conformidade entre o diagrama de classes elaborado, os

requisitos do sistema e os mecanismos de projeto definidos no Documento
de Arquitetura
Entradas
■ Glossário
Saídas

7.12 Modelar banco de dados
Responsável
Projetista de Banco de Dados
Definição
A modelagem de banco de dados é realizada pelo projetista de banco de
dados da equipe.
Esta atividade tem como objetivo a conclusão do projeto de banco de dados,
considerando que parte do projeto, contemplando apenas a arquitetura do
sistema, já foi desenvolvida durante a fase de Elaboração.
O Modelo de Banco de Dados deve ser desenvolvido com base no Diagrama
de Classes, elaborado pela equipe de analistas de sistemas, e nos mecanismos
fundamentais descritos no Documento de Arquitetura.
O projeto do banco de dados deve levar em consideração, também, os
requisitos não-funcionais, principalmente os de performance e segurança,
estabelecidos na Matriz de Requisitos do projeto.
O Modelo de Banco de Dados deve incluir:
■ Tabelas do sistema e seus campos
■ Relacionamentos
■ Chaves primárias e estrangeiras
■ Índices
■ Especificação de stored procedures e triggers
■ Papéis e usuários, com informações sobre as devidas permissões
■ Dicionário de dados, com descrição textual dos valores armazenados e

convenções utilizadas para cada elemento
Nesta fase do projeto, as estimativas de tamanho inicial e de taxa de

crescimento da base de dados, elaboradas durante a fase anterior, devem ser
revistas e adequadas conforme a necessidade.
O PDS, até o momento, não disponibiliza templates para o Modelo de Banco de
Dados, devendo ser utilizada a ferramenta de modelagem definida para o
projeto.
Passos
■ Analisar os mecanismos de projeto definidos (Documento de arquitetura),
o Diagrama de Classes, os requisitos não-funcionais do sistema (Matriz de
Requisitos) e as especificações de casos de uso (Modelo de Casos de Uso)

■ Identificar as tabelas necessárias para armazenamento dos dados

persistentes do sistema, a partir do Diagrama de Classes elaborado
■ Identificar os relacionamentos e as chaves primárias e estrangeiras das

tabelas
■ Com base nos cenários de casos de uso e nos métodos definidos para as
classes do sistema, especificar as stored procedures e triggers necessárias
■ Com base nos requisitos não-funcionais de performance e nos acessos

previstos às tabelas dos sistema, identificar os índices necessários para
cada tabela
■ Com base nos requisitos de segurança e perfis de acesso do sistema,

identificar os papéis e usuários do banco de dados, com a definição de
suas permissões
■ Elaborar o Modelo de Banco de Dados contendo os elementos

identificados
■ Revisar o Modelo de Banco de Dados junto à área de Homologação em

■ Analisar a conformidade entre o modelo de banco de dados, o diagrama

de classes, os requisitos do sistema e os mecanismos de projeto definidos
no Documento de Arquitetura
Entradas
■ Glossário
Saídas
■ Modelo de Banco de Dados (contemplando a arquitetura do sistema)
7.13 Codificar programas
Responsável
Programador
Definição
A codificação de programas é realizada pela equipe de programadores do
projeto.

Esta atividade tem como objetivo a geração de códigos-fontes para os diversos

elementos componentes do sistema, visando uma versão operacional do
sistema.
A atividade de codificação considera, também, a implementação de scripts,
stored procedures e triggers de banco de dados.
Nesta fase do projeto, o esforço de codificação deve manter o foco na
produtividade dos programadores, uma vez que os riscos inerentes ao escopo
e à arquitetura do sistema já foram praticamente eliminados ao longo das fases
anteriores do projeto.
O trabalho de codificação é desenvolvido com base na versão intermediária do
sistema estabelecida ao final da fase de Elaboração, e contempla apenas todos
os cenários de casos de uso especificados e projetados.
A codificação deve ser realizada com base nas Especificações de Casos de Uso,
Diagrama de Classes, Modelo de Banco de Dados e Documento de
Arquitetura.
Passos
■ Analisar as especificações de casos de uso (Modelo de Casos de Uso), os
mecanismos de projeto definidos (Documento de Arquitetura), o
Diagrama de Classes e o Modelo de Banco de Dados
■ Codificar os elementos do sistema
■ Implementar os scripts, stored procedures e triggers do banco de dados
■ Revisar o código-fonte e demais componentes de código junto à área de

■ Revisar os elementos codificados em conformidade com as especificações e

requisitos do sistema
Entradas
Saídas
■ Código-fonte
■ Procedures de banco de dados

7.14 Realizar testes unitários
Responsável
Programador
Definição
Os testes unitários são realizados pelos programadores da equipe do projeto.
Esta atividade tem como objetivo avaliar se os elementos do sistema
codificado atendem às respectivas especificações de requisitos.
A realização de testes unitários considera a criação de componentes de teste
para cada elemento do sistema implementado.
Como melhor prática, estes componentes de teste deveriam ser
implementados antes da implementação do próprio elemento do sistema
associado a ele.
A criação de componentes de teste facilita os esforços futuros de realização de
testes de regressão sobre todo o sistema.
Testes de regressão são fundamentais para garantir que novas
implementações, sejam por melhoria ou correção, não introduzam erros em
trechos de código já testado.
Além dos testes funcionais, outras verificações também devem ser realizadas
sobre os elementos do sistema:
■ Análise de cobertura dos testes
■ Análise de código não utilizado
■ Análise de performance do código gerado (profiling)
■ Análise de alocação/desalocação de memória
Existem, disponíveis no mercado, várias ferramentas e plataformas visando

testes unitários e análise de código.
A maioria dos IDE´s disponíveis já disponibilizam estas ferramentas de forma
integrada.
Esta atividade deve ser desenvolvida com base nas Especificações de Casos de
Uso, no Diagrama de Classes, no Modelo de Banco de Dados e no Documento
de Arquitetura.
Passos
■ Desenvolver componentes de teste de acordo com as especificações dos
elementos implementados
■ Realizar testes funcionais sobre o código-fonte

■ Realizar análises sobre o código-fonte dos elementos
■ Corrigir problemas identificados durante os testes e análises conforme a

necessidade
■ Disponibilizar o elemento testado para integração e compilação
Entradas
■ Código-fonte
Saídas
■ Código-fonte (testados)
7.15 Integrar e compilar o sistema
Responsável
Programador
Definição
A integração do sistema é realizada por um membro da equipe de
programadores - o Integrador - especificamente designado para esta atividade
e que é apoiado pelos demais programadores do projeto.
Esta atividade tem como objetivo gerar uma versão compilada do sistema
(build).
O integrador é responsável por reunir os diversos elementos do sistema,
testados unitariamente, e compilar uma versão integrada do sistema, de
acordo com a estrutura de implementação especificada no Documento de
Arquitetura.
Esta integração e compilação deve acontecer em uma estação de trabalho
específica, designada para este fim, e o integrador deve ser o único membro da
equipe com permissão para fazê-lo.
Neste momento, deve-se ter atenção principalmente às versões dos diversos
elementos do sistema utilizadas para a geração da versão em questão.
Esta atividade se repete diversas vezes ao longo do projeto.

Uma boa prática de desenvolvimento é a geração de compilações em curtos

intervalos de tempo.
Ao final desta atividade é gerado um executável do sistema.
Ao fim de cada iteração do projeto deve haver a geração de uma nova
compilação.
Ao fim da última iteração desta fase, é compilada a primeira versão
operacional do sistema completo.
Passos
■ Verificar os elementos testados disponibilizados para integração
■ Integrar os elementos disponibilizados na estação de compilação, de

acordo com a estrutura de implementação do projeto definida no
Documento de Arquitetura
■ Verificar a disponibilidade de bibliotecas externas necessárias para a

compilação do sistema, na estação de compilação
■ Gerar nova compilação do sistema (build)
■ Revisar a compilação do sistema junto à área de Homologação em

■ Disponibilizar a compilação para estabelecimento de nova versão do

sistema
Entradas
■ Código-fonte (testados)
Saídas
■ Compilação do sistema (build)
7.16 Estabelecer versão do sistema
Responsável
Gerente de configuração
Definição
O estabelecimento da versão do sistema é realizado pelo gerente de
configuração, com o apoio de todos os membros da equipe.

O objetivo desta atividade é estabelecer formalmente uma nova versão do

sistema, com a identificação de todos os itens de configuração do projeto que a
compõem e gerar um novo pacote de distribuição do produto.
Esta atividade deve ser apoiada por uma ferramenta de controle de versão.
O Datasus disponibiliza para suas equipes de desenvolvimento um servidor
Subversion. Este servidor deve ser utilizado para armazenamento de todos os
itens de configuração gerados ou utilizados ao longo das atividades do
projeto.
Para solicitar a criação de um repositório de controle de versão o gerente de
sistema deve entrar em contato com a Administração de Redes do Datasus
(admrede@datasus.gov.br).
O gerente de configuração deve verificar, no repositório do sistema, a
integridade dos itens de configuração, verificando se todos estão disponíveis
em suas versões corretas.
Os itens de configuração do projeto incluem desde os códigos-fonte até o
sistema compilado, incluindo toda a documentação do projeto, manuais,
planos, entre outros.
Uma vez verificada a integridade e disponibilidade dos itens de configuração,
o gerente de configuração define o número da versão do sistema que será
estabelecida e “marca” todos os itens de configuração com este número,
criando uma associação entre a versão do sistema e os itens de configuração (e
em que versão) que a compõem.
Estabelecida a versão no repositório do projeto, o gerente de configuração
deve criar o Pacote de Distribuição do sistema para esta versão.
Uma nova versão do sistema deve ser gerada ao fim de cada iteração.
No final da última iteração da fase de Construção é gerada a primeira versão
operacional do sistema.
Para que o software seja considerado seguro, o Gerente de Configuração deve
cumprir as seguintes recomendações de segurança:
■ Estruturar o ambiente de desenvolvimento no repositório do sistema e

identificar e controlar os itens de configuração
■ Estabelecer a nova versão do sistema no repositório, marcando todos os

itens de configuração que a compõem
■ Definir os números das versões do sistema, de forma a identificar

unicamente o sistema
■ A referência deve ser única para cada versão do sistema
■ O sistema deve ser rotulado com sua referência
■ Apoiar a equipe do sistema no uso das ferramentas de gerência de

configuração
■ Elaborar registro das alterações implementadas em cada versão

disponibilizada do sistema (changelog)
Passos
■ Verificar a integridade e versões dos itens de configuração no repositório
do projeto. Quaisquer inconsistências observadas devem ser comunicadas
ao responsável pelo item de configuração em questão e corrigidas antes do
estabelecimento da versão
■ Definir o número da próxima versão do sistema a ser estabelecida
■ Estabelecer, no repositório a nova versão do sistema, marcando todos os

itens de configuração que a compõem
■ Gerar o Pacote de Distribuição da nova versão
■ Revisar a Versão do Sistema e o Pacote de Distribuição junto à área de

■ Disponibilizar o Pacote de Distribuição do sistema para testes
Entradas
■ Itens de configuração do sistema (todos)
Saídas
■ Versão do sistema (operacional)
■ Pacote de distribuição
7.17 Realizar testes no sistema
Responsável
PTS – Processo de Teste de Software
Definição
Os testes no sistema devem seguir o PTS - Processo de Teste de Software do
CTI- Datasus.
O PTS é um processo completo de testes, baseado no RUP - Rational Unified
Process que descreve, detalhadamente, todos os papéis, atividades e artefatos
envolvidos na verificação e validação de softwares em conformidade com seus
requisitos.

O processo de teste faz parte do Sistema de Gestão da Qualidade e está

adequado aos requisitos da norma ISO 9001:2000.
As atividades do PTS são implementadas através de Projetos de Teste
realizados no LACQUA - Laboratório de Controle de Qualidade de Soluções
Informatizadas do SUS.
O LACQUA fornece a infra-estrutura de hardware, de software e especialistas,
necessária para realização dos projetos de teste do Processo de Teste de
Software.
Para realização dos testes através do PTS, o profissional da equipe de
desenvolvimento designado como solicitante do teste, cadastra as informações
sobre a release no registro do sistema da aplicação SCP - Módulo PTS e registra
uma Solicitação de Teste.
A aplicação SCP - Módulo PTS é um sistema para automatizar o controle e a
execução do fluxo de trabalho das atividades do Processo de Teste de
Software - PTS onde são armazenadas as solicitações de teste.
Maiores informações sobre o PTS e o LACQUA podem ser obtidas
diretamente no site http://pts.datasus.gov.br/.
Os testes devem ser planejados desde o início do projeto de desenvolvimento
e devem ser realizados ao fim de cada iteração.
Ao fim da última iteração da fase de Construção, a versão do sistema, depois
de testada, é considerada a primeira versão operacional do sistema e
representa o terceiro grande marco do processo de desenvolvimento.
Neste momento, o sistema está pronto para ser disponibilizado a seus
usuários finais durante a fase de Transição.
Para que o software seja considerado seguro, os testes devem assegurar que
sejam cumpridas as seguintes recomendações de segurança :
■ Confirmação que a(s) função (ões) de segurança opera(m) de acordo com

sua especificação. (através de testes funcionais dos Casos de Uso referentes
a Funções de Segurança)
■ Geração de evidências sobre a cobertura de testes contendo:
o A correspondência entre os testes identificados na documentação de

teste e a função de segurança como descrito na especificação funcional
■ Atendimento a teste de profundidade:
o Demonstrando, na documentação de teste, que as funções de

segurança operam de acordo com a descrição de alto nível
■ Elaboração dos seguintes documentos: Planos de teste, descrições de

procedimento de teste, resultados esperados do teste e resultados de testes
atuais.

o Previsão de conteúdo da documentação:
1. O plano de teste identifica as funções de segurança a serem

testadas e descrevem os objetivos dos testes a serem executados
2. O planejamento do teste deve mostrar, antecipadamente, o

resultado esperado da execução do teste
3. A descrição dos procedimentos de testes identifica os testes a

serem executados e descreve os cenários para testar cada
função de segurança. Esses cenários incluem quaisquer
dependências nos resultados de outros testes
4. O resultado do teste deve demonstrar que cada função de

segurança testada se comportou como especificada.
Passos
■ Consultar o Processo de Teste de Software do Datasus (PTS).
Entradas
■ Manuais do sistema
■ Documentos do projeto
Saídas
■ Versão do sistema (testada)
7.18 Elaborar documentação de usuário
Responsável
PDOC
Definição
O DATASUS desenvolveu o Processo de Documentação de Sistemas, como
proposta para elaboração da documentação dos sistemas em ações de
vigilância à saúde do SUS, para implementar o uso, e ampliar o apoio técnico e
operacional aos municípios para o desenvolvimento de suas atividades,
destacando-se a capacitação dos recursos humanos dos municípios e das
instâncias regionais das secretarias de saúde.

O PDOC tem como objetivo a gestão da documentação dos softwares do

DATASUS, embasados nas melhores práticas e recomendações de entidades
reguladoras de normas de software como IEEE e ISO.
O PDOC foi criado para propiciar aos sistemas de software maior facilidade
de utilização; ampliação do conhecimento; maior aceitabilidade e
receptividade dos produtos; além de auxiliar nas implantações, suporte
técnico e treinamentos de seus softwares.
Para solicitar a elaboração da documentação de sistemas voltadas aos
usuários, as equipes de desenvolvimento devem encaminhar o e-mail com a
solicitação para o PDOC –documentacao@listas.datasus.gov.br
Para mais informações sobre o procedimento de solicitação da documentação,
visite o site http://pdoc.datasus.gov.br.
Para que o software seja considerado seguro, o Gerente de Sistemas deve
fornecer ao PDOC, todas as informações necessárias a fim de viabilizar o
cumprimento das seguintes recomendações de segurança:
■ Garantir que todo sistema tenha documentação com foco no

Administrador descrevendo:
o As funções administrativas e interfaces acessíveis aos administradores

do sistema
o Como administrar o sistema de maneira segura

em um ambiente operacional seguro
o Todas as suposições relativas ao comportamento de usuário que

possam comprometer a segurança do sistema
o Todos os parâmetros de segurança sob o controle do administrador e

seus valores apropriado
o Os eventos significativos de segurança e as ações necessárias a serem

desempenhadas para garantir a operação segura do sistema, incluindo
quaisquer mudanças de características na camada de apoio ou sistemas
sob o controle da função de segurança
o Ser clara, consistente e coerente com toda documentação fornecida

para avaliação
o Todos os requisitos de segurança para o ambiente de TI que sejam

relevantes para o administrador
o Recomendação de gerência de usuários, grupos e permissões
■ Garantir que todo sistema tenha documentação com foco no Usuário

descrevendo:

o As funções e interfaces acessíveis a usuários que não são

administradores do sistema
o O uso das funções de segurança acessíveis ao usuário fornecidas pelo

sistema

para uma operação segura
o Claramente ao usuário, suas responsabilidades referentes à operação

segura do sistema, incluindo aquelas relacionadas às premissas de
comportamento do usuário, descritas na declaração de segurança do
sistema
o De uma forma consistente e coerente baseada na documentação

provida para avaliação
o Todos os requisitos de segurança para o ambiente de TI, que

apresentem relevâncias ao usuário
Passos
■ Consultar a o Processo de Documentação de Sistemas (PDOC).
Entradas
■ Documentação do projeto
■ Versão do sistema
Saídas
7.19 Homologar sistema
Responsável
PHS – Processo de Homologação de Software
Definição
A homologação do sistema deve seguir o PHS - Processo de Homologação de
Software do Datasus. O PHS visa garantir a qualidade dos sistemas
desenvolvidos pelo Datasus através da verificação dos artefatos produzidos
ao longo do projeto e da validação do produto de software desenvolvido. O
processo verifica a conformidade do sistema desenvolvido com as normas e
padrões estabelecidos para o projeto e conta com a participação de

representantes tantos dos usuários como da equipe de desenvolvimento.

Maiores informações sobre o PHS podem ser obtidas diretamente no site
http://phs.datasus.gov.br.
Passos
■ Consultar o Processo de Homologação de Software do Datasus (PHS).
Entradas
■ Manuais do sistema
Saídas
■ Versão do sistema (homologada)
7.20 Implantar sistema
Responsável
Implantação
Definição
A implantação do sistema é realizada pela área de Implantação do Datasus,
com o apoio da equipe de desenvolvimento do projeto.
Esta atividade tem como objetivo colocar o sistema em funcionamento em seu
ambiente de produção.
Dependendo das características do sistema, o processo de disponibilização em
produção pode ocorrer de diferentes formas:
■ Interna – implantação centralizada do sistema no ambiente de produção

do Datasus com disponibilização de acesso externo a seus usuários
■ Externa – implantação do sistema em ambientes de produção externos ao

Datasus, nas dependências físicas de seus usuários
■ Interna e externa – implantação de parte do sistema no ambiente de

produção do Datasus e parte no ambiente de produção dos usuários
■ Distribuição – aplicação disponibilizada para download no site do Datasus

com instalação a cargo de seus usuários
Para que o software seja considerado seguro, a Distribuição deve cumprir as

seguintes recomendações de segurança:
■ Descrever todos os passos para geração, instalação e inicialização segura

do sistema
■ Descrever todos os procedimentos para manter a segurança ao distribuir

versões do sistema para o ambiente usuário
■ Garantir que o sistema recebido pelo usuário corresponda precisamente à

copia mestra do sistema
■ Evitar ou detectar qualquer falsificação da versão atual do sistema
■ Prevenir que versões adulteradas / fraudulentas do sistema sejam

distribuídas
■ Evitar divulgação não autorizada da distribuição do sistema
■ Evitar que o sistema seja interceptado durante a entrega
■ Evitar atrasos ou extravios de distribuição do sistema.
Maiores informações sobre a implantação de sistemas podem ser obtidas

diretamente com a área de Implantação do Datasus.
Passos
■ Consultar a área de Implantação do Datasus.
Entradas
■ Versão do sistema (homologada)
Saídas
■ Versão do sistema (produção)
7.21 Sistema Implantado
Definição
Uma vez disponibilizado para seus usuários finais, o gerente do sistema deve

obter dos representantes do usuário gestor e usuários finais um aceite formal

do sistema entregue.
A partir deste momento o processo de desenvolvimento é dado como
concluído.
Implementações futuras sobre o sistema, sejam elas corretivas ou de melhoria,
devem ser avaliadas caso a caso.
No caso de um processo contínuo de manutenção do sistema, estas atividades
não são cobertas atualmente pelo PDS e devem ser tratadas como serviços.
No caso de implementações que gerem mudanças significativas no sistema, é
necessário um consenso entre as partes (Datasus e usuários) das
funcionalidades que serão implementadas e/ou modificadas.
Esta situação caracteriza o início de um novo projeto, e este consenso deve ser
registrado em um novo Documento de Consenso do Produto, dando início a
todo o ciclo do Processo de Desenvolvimento novamente.

8. P APÉIS E PROCESSOS
RELACIONADOS
8.1 Gerente de Sistemas

O gerente de sistemas é responsável por todas as atividades referentes ao
gerenciamento e planejamento do projeto, incluindo:
■ Alocar recursos
■ Estabelecer prioridades
■ Coordenar as negociações e acordos com usuários e demais áreas do

Datasus
■ Definir para cada membro da sua equipe, seus respectivos papéis e as

permissões que são atribuídas a cada papel
■ Instituir o uso de uma ferramenta de controle de versão para garantir, de

maneira automatizada, que somente alterações autorizadas sejam
implementadas no sistema e em todos os itens de configuração.
■ E assim, poder averiguar as mudanças entre o sistema e uma versão futura
■ Assegurar que todos os itens de configuração são controlados por meios

automatizados
■ Autorizar a atualização de uma versão de produção do sistema por uma

nova versão estabelecida pelo Gerente de Configuração. Qualquer
mudança em versões de produção deve ser autorizada pelo Gerente do
Sistema
O gerente de sistemas é o responsável por garantir o planejamento, execução e

controle do Processo de Desenvolvimento de Software durante todo o ciclo de
vida do projeto.
Atividades
■ Definir escopo detalhado do sistema
■ Validar se o sistema está sendo desenvolvido de maneira segura

Papéis e processos relacionados MS - SE - DATASUS
Artefatos
■ Documento de Consenso do Produto
8.2 Analista de Sistemas

O analista de sistemas é responsável pelas atividades de análise e projeto do
sistema, incluindo:
■ Levantar e especificar de requisitos
■ Modelar e especificar casos de uso
■ Projetar a arquitetura do sistema
■ Projetar o sistema detalhadamente, através da modelagem de classes,

módulos, pacotes etc
Atividades
■ Identificar requisitos do sistema Projetar arquitetura do sistema
■ Especificar casos de uso do sistema
■ Projetar sistema para validação da arquitetura
■ Projetar sistema
Artefatos
■ Glossário
■ Matriz de Requisitos
■ Documento de Arquitetura
■ Modelo de Casos de Uso
■ Diagrama de Classes
8.3 Projetista de BD
O projetista de banco de dados é responsável pela definição de tabelas, views,
triggers, stored procedures e outros elementos específicos de banco de dados
necessários para o armazenamento e recuperação de dados persistentes do
sistema.
Atividades
■ Modelar banco de dados para validação da arquitetura

MS - SE - DATASUS Papéis e processos relacionados
■ Modelar banco de dados
Artefatos
■ Modelo de Banco de Dados
8.4 Programador
O programador é responsável pela implementação dos
componentes/elementos do sistema e pela realização de testes unitários sobre
os mesmos.
Um dos programadores da equipe deve assumir a função de Integrador,
sendo responsável por integrar os componentes/elementos desenvolvidos
pelos demais programadores do projeto e gerar as compilações do sistema
(builds).
Durante a fase de Elaboração, a equipe de programadores em conjunto com a
equipe de analistas de sistemas, assumem a responsabilidade pela condução
dos testes para validação da arquitetura.
Atividades
■ Implementar sistema para validação da arquitetura
■ Testar e validar a arquitetura
■ Codificar programas
■ Realizar testes unitários
■ Integrar e compilar o sistema
Artefatos
■ Código-fonte
■ Compilação do Sistema (builds)
8.5 Gerente de Configuração

O gerente de configuração é responsável pela administração do repositório de
controle de versões do projeto e pelo estabelecimento das versões do sistema
ao longo do ciclo de desenvolvimento. É responsável, também, pela
construção do Pacote de Distribuição.
Atividades
■ Estabelecer versão do sistema

Artefatos
■ Versão do Sistema (releases)
■ Pacote de Distribuição
8.6 Implantação
Este papel é representado no PDS pela área de Implantação do Datasus e está
fora do escopo da equipe de desenvolvimento do sistema. Maiores
informações podem ser obtidas diretamente com a área de Implantação do
Datasus.
De acordo com o Plano de Gerência de Configuração do Datasus por nós
sugerido, a Implantação é responsável pela publicação e controle das versões
de produção dos sistemas.
Atividades
■ Substituir as versões de produção dos sistemas por novas versões
disponibilizadas pelos Gerentes de Configuração e autorizadas pelos
Gerentes dos Sistemas
■ Disponibilizar informações sobre versões de produção dos sistemas
■ Atividades
■ Implantar sistema
8.7 Usuário
O usuário não executa diretamente nenhuma atividade ou é responsável por
quaisquer artefatos no PDS.
Entretanto, este papel representa os “clientes” do projeto de desenvolvimento.
É para ele, e por causa dele, que o sistema está sendo desenvolvido.
Deste ponto de vista, este passa a ser o papel de maior importância para todo
o processo.
O usuário participa indiretamente de todas as atividades do processo, desde a
definição do escopo do produto e do levantamento de requisitos, até a
validação e aceite do produto final.
O PDS distingue o usuário em 2 tipos: gestor e final.
8.8 Usuário Gestor

O usuário gestor é responsável pela definição geral do sistema e, em alguns
casos, pode ser o próprio patrocinador do projeto.

MS - SE - DATASUS Papéis e processos relacionados
Sua visão do sistema está mais relacionada ao negócio e seus maiores

interesses normalmente estão associados a informações.
8.9 Usuário Final

O usuário final representa o usuário do sistema propriamente dito.
Este é o usuário que utiliza o sistema em seu dia-a-dia e sente na prática os
benefícios (ou prejuízos) operacionais conseqüentes da implantação do
sistema.
Apesar de, normalmente, ter pouco poder de decisão sobre as funcionalidades
do sistema, suas experiências em relação ao ambiente onde o sistema é
efetivamente utilizado pode ser um fator crítico para o sucesso do projeto.
8.10 PTS – Processo de Teste de Software

Estas tarefas são representadas no PDS pelo Processo de Teste de Software do
CTI - Datasus. O PTS inclui a verificação e validação de softwares para a
equipe de desenvolvimento do sistema.
Maiores informações podem ser obtidas diretamente no site
http://pts.datasus.gov.br
Atividade
■ Realizar testes no sistema
8.11 PDOC – Processo de Documentação de Sistemas

Este papel é representado no PDS pelo Processo de Documentação de
Sistemas do Datasus, PDOC, e está fora do escopo da equipe de
desenvolvimento do sistema.
Maiores informações podem ser obtidas diretamente com o PDOC através do
site http://pdoc.datasus.gov.br.
Atividades
■ Elaborar documentação de usuário
Artefatos
■ Documentação de Usuário

8.12 PHS – Processo de Homologação de Software

Estas tarefas são representadas no PDS pelo Processo de Homologação de
Software do CTI - Datasus e está fora do escopo da equipe de
Maiores informações podem ser obtidas diretamente no site
http://phs.datasus.gov.br.
Atividade
■ Homologar sistema

9. A RTEFATOS
Em sentido amplo, o termo artefato representa um produto concreto
produzido, modificado ou utilizado pelas atividades de um processo. Os
artefatos representados no PDS não incluem todos os artefatos de um projeto
de desenvolvimento, mas todos os artefatos representados no PDS devem ser
elaborados ao longo do projeto. O PDS disponibiliza modelos (templates) para
a maioria de seus artefatos, com o objetivo de orientar e facilitar a sua
elaboração.
9.1 Documento de Consenso do Produto

O Documento de Consenso do Produto estabelece as principais
funcionalidades e fronteiras do sistema. Foca na definição do escopo do
produto. Maiores informações sobre escopo do projeto devem ser obtidas na
Metodologia de Gerenciamento de Projetos.
Este artefato tem a função de estabelecer um contrato entre os diferentes
interessados no sistema (Datasus, usuário gestor, usuário final etc.),
registrando tudo aquilo que será desenvolvido ao longo do projeto. Deve ser
formalmente aprovado pelas partes envolvidas.
9.2 Glossário
O Glossário registra termos e definições específicos ao domínio do sistema e
do projeto. Este artefato funciona como um dicionário para a equipe de
desenvolvimento contendo a definição de termos comuns ao vocabulário dos
usuários gestores e finais, tendo o objetivo de facilitar a comunicação entre as
partes.
9.3 Matriz de Requisitos

A Matriz de Requisitos (ou Documento de Requisitos) registra todos os
requisitos e as regras de negócios do sistema levantados junto aos usuários
gestores e finais. Este artefato deve estar sob rígido controle de mudanças uma
vez que as alterações em suas informações podem ter impacto por todo o
sistema.
Está disponível no PDS em dois formatos: texto ou planilha. A Matriz de
Requisitos em formato texto é tratada como Documento de Requisitos.

Artefatos MS - SE - DATASUS
9.4 Documento de Arquitetura

O Documento de Arquitetura descreve as principais decisões de projeto
tomadas pela equipe de desenvolvimento e os critérios considerados durante a
tomada destas decisões. Suas informações incluem desde a especificação da
infra-estrutura de hardware e software do sistema, até descrições detalhadas
dos diversos mecanismos de arquitetura de software adotados.
9.5 Modelo de Casos de Uso

O Modelo de Casos de Uso descreve toda a visão funcional do sistema através
de seus atores e casos de uso. Este artefato inclui o Diagrama de Casos de Uso
e as Especificações de Casos de Uso, às vezes mencionados como se fossem
artefatos independentes ao longo do processo. As especificações de casos de
uso representam o nível mais detalhado de requisitos no PDS e, justamente
por se tratarem de requisitos do sistema, devem ser formalmente aprovadas
pelos usuários responsáveis.
9.6 Diagrama de Classes

O Diagrama de Classes apresenta uma visão estática do sistema, através das
classes projetadas para realização dos casos de uso e de seus relacionamentos.
O PDS não disponibiliza um modelo (template) para este artefato, devendo ser
utilizada, para sua geração, a ferramenta de modelagem selecionada pela
equipe de desenvolvimento.
9.7 Modelo de Banco de Dados

O Modelo de Banco de Dados descreve todo o projeto de banco de dados do
sistema. Este artefato inclui diagramas entidade-relacionamento, dicionário de
dados, relação de usuários, papéis e permissões no banco de dados,
especificação de índices, triggers, stored procedures e quaisquer outros
elementos específicos ao projeto de banco de dados. O PDS não disponibiliza
um modelo (template) para este artefato, devendo ser utilizada, para sua
geração, a ferramenta de modelagem de banco de dados selecionada pela
equipe de desenvolvimento.
9.8 Código-fonte
O código-fonte representa qualquer trecho de código implementado ao longo
do desenvolvimento do sistema. Apesar de ser um artefato concreto (o código
e o arquivo-fonte existem), sua representação no PDS tem uma finalidade
conceitual. O código-fonte representa a unidade fundamental de um sistema,
desenvolvida pela equipe de programadores do projeto.

MS - SE - DATASUS Artefatos
9.9 Compilação do Sistema (build)

A Compilação do Sistema, ou build, representa o sistema executável
compilado. Ao longo do projeto de desenvolvimento serão gerados inúmeras
compilações do sistema para fins de integração, testes e validações. A última
compilação do sistema será a versão final.
9.10 Versão do Sistema (release)

A Versão do Sistema, ou release, representa o sistema executável ao final de
uma fase do projeto, representando um dos grandes marcos do ciclo de vida
do projeto. Uma compilação do sistema, após ser formalmente estabelecida
pelo gerente de configuração, torna-se uma versão.
Ao longo do ciclo de vida do desenvolvimento são geradas várias versões
intermediárias antes da Versão que ficará em produção.
Na fase de Elaboração, após a implementação do sistema para validação da
arquitetura é gerada a primeira versão. Essa versão nada mais é do que o
executável que possibilite a realização de testes e a validação da arquitetura de
software definida. Essa versão é citada no PDS como “Para validação da
arquitetura”. Após a arquitetura ser testada e validada, a versão passa a ser
chamada de “Com arquitetura testada e validada”.
A primeira versão Operacional do sistema surge na atividade Estabelecer
versão do sistema, quando esta vai ser testada e homologada e após,
finalmente tornar-se Versão em produção.
Figura 5. Ciclo de versões
9.11 Pacote de Distribuição

O Pacote de Distribuição representa 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.
Dependendo das características do sistema poderá se apresentar de diversas
formas e em diferente meios: disquetes ou CD´s de instalação, pacotes para
implantação em servidores de aplicação, arquivos auto-instaláveis disponíveis

Artefatos MS - SE - DATASUS
para download etc.
9.12 Documentação de Usuário

O artefato Documentação de Usuário representa o conjunto de documentações
elaboradas com foco no usuário final do sistema, incluindo manuais, ajuda,
guias rápidos, releases notes, entre outros.
O Processo de Documentação de Sistemas do DATASUS, PDOC, possui uma
equipe capacitada e ferramentas adequadas para a elaboração destes artefatos.
Os produtos gerados pelo PDOC incluem:
■ Visão Geral – Apresenta os objetivos e funcionalidades principais do

software, discorre sobre as características que sustentam estas
funcionalidades, porém sem entrar em detalhes técnicos e/ou utilizar
linguagem eminentemente técnica.
■ Manual de Operação – Apresenta em detalhes funcionalidades disponíveis

ao usuário. As funcionalidades do software são agrupadas logicamente em
Manuais de Operação.
■ Manual de Relatórios – Descreve as informações que são apresentadas em

cada relatório disponível.
■ Manual de Instalação e Administração – Traz informações como instalar,

configurar e manter o produto de software operacional.
■ Release Notes - Descreve sucintamente a versão do produto que está sendo

liberada, relacionando as novidades, oriundas de requisitos funcionais e
não funcionais, e também as correções que foram efetuadas. Para se ter
uma idéia do histórico de evolução do software, este documento é fonte
primária de informação. Tudo o que foi descrito neste documento deve
estar refletido em detalhes na documentação do produto, caracterizando-
se desta forma a atividade de manutenção e evolução da documentação do
produto.
■ Guia Rápido – Manual de referência rápida, no qual estão descritos

conceitos ou comandos principais de um produto de forma sucinta.
Para mais informações visite o site do PDOC – http://pdoc.datasus.gov.br

10. D OCUMENTOS DE A POIO
Os Documentos de Apoio auxiliam no desenvolvimento do projeto. Estes
documentos podem ser oriundos do PDS ou externos ao processo.
Ao contrário dos artefatos, os documentos de apoio não necessitam de
preenchimento, pois eles servem de padrões para qualquer projeto, se
enquadrando as necessidade do Datasus.
10.1 Plano de Gerência de Configuração

O Plano de Gerência de Configuração descreve todas as atividades
relacionadas à gerência de configuração e controle de mudanças do projeto a
serem realizadas ao longo do ciclo de vida do produto. Relaciona as
responsabilidades dos membros da equipe do projeto e recursos necessários
de hardware, software e humanos.
10.2 Perfis de Segurança

Os perfis de segurança descrevem requisitos funcionais de segurança que
devem ser implementados nos sistemas que tenham sido classificados de
acordo com seu nível de segurança.
No Datasus, os sistemas podem ser classificados como:
Médico / Ambulatorial
Lidam com informações sobre usuários do SUS e procedimentos associados
(médicos, hospitalares, ambulatoriais, assistenciais, entre outros. Estes
sistemas permitem a associação dos dados dos pacientes com as suas
informações médicas. O principal objetivo da segurança neste perfil é garantir
o sigilo das informações e a privacidade dos usuários do SUS.
Financeiro / Gerencial
São sistemas que administram valores (financeiros, estoques, patrimoniais,
entre outros) utilizados na gestão do SUS. O principal objetivo da segurança
neste perfil é garantir o sigilo das informações financeiras e cadastrais de
entidades e órgãos do Sistema Único de Saúde.

Documentos de Apoio MS - SE - DATASUS
Internos / de Apoio
São os sistemas de apoio e infra-estrutura do SUS ou internos e
administrativos em geral.
10.3 Recomendações de Segurança para Web

Service
Os Web Services definem uma nova tecnologia criada com o objetivo de
realizar troca de informações em formato padronizado entre aplicações
utilizando a rede, podendo esta ser intranet ou internet.
O objetivo desse documento é mostrar os requisitos de segurança corporativos
na implementação de Web Services (WS). Diante desta necessidade foram
descritos alguns cenários possíveis de uso e evolução desta tecnologia
buscando orientar sua implantação de forma segura no ambiente corporativo.
Além disso, o documento apresenta as principais vulnerabilidades
encontradas na utilização desta tecnologia e as recomendações (opcionais e
mandatórias) para cada uma delas com o intuito de prevenir ataques em cada
um dos cenários apresentados.

11. C LASSIFICAÇÃO DE SISTEMAS
A Classificação dos Segurança considera aspectos técnicos, jurídicos

(legislação pertinente), informação tratada pelo sistema, conectividade entre
sistemas, ambiente de operação, distribuição, tipos de usuário e ativos de
informação.
Os sistemas são classificados de acordo com os seguintes critérios:
■ Médico / Ambulatorial: lidam com informações sobre usuários do SUS e

procedimentos associados (médicos, hospitalares, ambulatoriais,
assistenciais, entre outros). Estes sistemas permitem a associação dos
dados dos pacientes com as suas informações médicas.
O principal objetivo da segurança neste perfil é garantir o sigilo das

informações e a privacidade dos usuários do SUS.
■ Financeiro / Gerencial: são sistemas que administram valores (financeiros,

estoques, patrimoniais, entre outros) utilizados na gestão do SUS.
O principal objetivo da segurança neste perfil é garantir o sigilo das

informações financeiras e cadastrais de entidades e órgãos do Sistema
Único de Saúde.
■ Interno / de Apoio: são os sistemas de apoio e infra-estrutura do SUS ou

internos e administrativos em geral. ão.
CARACTERÍSTICA INTERNOS/ DE FINANCEIROS / MÉDICOS /

APOIO GERENCIAIS AMBULATORIAIS
Baixo Médio Alto

NÍVEL
- Não necessitam de - Legislação - Legislação

ATENDEM A
controles objetivos à específica específica
legislação - Normas - Normas
- Devem considerar - Portarias - Portarias
toda e qualquer - Decretos - Decretos
interação com outros - Objetivos de - Objetivos de
sistemas negócio negócio
Os Fatores Reembolso e Garantir o sigilo

OBJETIVOS
confidencialidade, pagamentos do das informações
ESPECÍFICOS

Classificação de sistemas MS - SE - DATASUS
CARACTERÍSTICA INTERNOS/ DE FINANCEIROS / MÉDICOS /

APOIO GERENCIAIS AMBULATORIAIS
integridade e sistema único de dos usuários do

disponibilidade são saúde Garantir o Sistema Único de
variáveis de acordo sigilo das Saúde – SUS
com a finalidade do informações Garantir a
sistema Requisitos financeiras e privacidade dos
funcionais de cadastrais dos usuários do
segurança devem ser usuários, Sistema Único de
selecionados do entidades e órgãos Saúde – SUS
perfil de segurança do Sistema Único
de acordo com os de Saúde – SUS
objetivos de
segurança do sistema
Média/Alta Alta Alta

CONFIDENCIALIDADE
Média/Alta Alta Alta

INTEGRIDADE
Média/Alta Média/Alta Alta

DISPONIBILIDADE
Tabela 1. Classificação de Sistemas

12. G LOSSÁRIO
Este capítulo apresenta os termos e conceitos do PDS.
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 quê fazer. O projeto foca no como
fazer.
analista Membro da equipe do projeto responsável por

levantar e interpretar as necessidades dos
stakeholders, e comunicar estas necessidades a
toda a equipe.
Analista de Sistemas Papel do PDS responsável pelas atividades de

análise e projeto do sistema.
arquitetura Mecanismos fundamentais (infra-estrutura de

hardware e software) que serão utilizados para o
desenvolvimento do sistemas.
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

Glossário MS - SE - DATASUS
a serem oferecidas pelo produto final.
caso de uso (RUP) Uma seqüê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 seqüência de ações,
incluindo suas variações, que um sistema (ou
outra entidade) pode realizar, interagindo com
seus atores.
cenário Instância de um caso de uso. Um dos fluxos

possíveis de passos em um caso de uso.
classe (UML) Descrição de um conjunto de objetos que

compartilham os mesmos atributos, operações,
relacionamentos e semântica.
Código-fonte Artefato do PDS que representa qualquer trecho

de código implementado ao longo do
desenvolvimento do sistema. Não possui
modelo.
Compilação do Sistema (Build) Artefato do PDS que 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.
Concepção Primeira fase do PDS-DATASUS em que o

objetivo é acordar o escopo do projeto com
usuários. Esta fase marca o início do projeto de
desenvolvimento.
configuração Requisitos, projeto e implementação que

definem uma versão específica de um sistema ou
componente.
Construção Terceira fase do PDS-DATASUS em que o

objetivo é disponibilizar uma versão operacional
do sistema.
controle de mudanças Atividade de controlar e rastrear as

modificações em artefatos.
diagrama (UML) Representação gráfica de todo, ou parte

de, um modelo.

MS - SE - DATASUS Glossário
Diagrama de Classes Artefato do PDS que apresenta uma visão

estática do sistema, através das classes
projetadas para realização dos casos de uso e de
seus relacionamentos. Não possui modelo.
Documentação Papel do PDS representado pela área de

Documentação do Datasus e está fora do escopo
da equipe de desenvolvimento do sistema.
Documentação de Usuário Artefato do PDS que representa toda a

documentação de usuário gerada para o sistema.
Documento de Arquitetura Artefato do PDS 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 Consenso do Artefato do PDS que estabelece as principais

Produto funcionalidades e fronteiras do sistema e
registra informações que delimitam o projeto de
desenvolvimento como um todo.
Elaboração Segunda fase do PDS-DATASUS em que o

objetivo é validar a arquitetura do sistema.
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 especificados.
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 seqüência e a dependência entre as

atividades do projeto ao longo do tempo.
funcionalidade (feature) (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.
Gerente de Configuração Papel do PDS responsável pela administração do

repositório de controle de versões do projeto e
pelo estabelecimento das versões do sistema ao
longo do ciclo de desenvolvimento.
Gerente de Sistemas Papel do PDS responsável por todas as

atividades referentes ao gerenciamento e
planejamento do projeto.
Glossário Artefato do PDS que registra termos e definições

específicos ao domínio do sistema e do projeto.
guia Descrição de como realizar determinada

atividade ou como trabalhar com determinado
artefato, descrevendo, inclusive, seu processo de
criação e revisão.
Implantação Papel do PDS representado 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 Itens de configuração são os artefatos do

sistema, arquivos ou conjunto de arquivos,
produzidos ou utilizados como insumos em suas
atividades.
São tratados como uma única unidade e devem

estar sob gerência de configuração.
iteração Seqüência distinta de atividades, com

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

marco Ponto em que uma iteração é formalmente

encerrada.
Matriz de Requisitos Artefato do PDS que registra todos os requisitos

do sistema levantados junto aos usuários
gestores e finais.
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 do PDS que descreve todo o projeto de

banco de dados do sistema. Não possui modelo.
Modelo de Casos de Uso Artefato do PDS que descreve toda a visão

funcional do sistema através de seus atores e
casos de uso.
pacote Mecanismo de propósito genérico para

organizar elementos em grupos. Pacotes podem
ser aninhados em outros pacotes.
Pacote de Distribuição Artefato do PDS que representa 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.
PHS Processo de Homologação de Software do

Datasus e está fora do escopo da equipe de
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.
produto Software resultante do desenvolvimento e

alguns dos artefatos relacionados
(documentação, material de treinamento, etc.).
Programador Papel do PDS responsável pela implementação

dos componentes/elementos do sistema e pela
realização de testes unitários sobre os mesmos.
Projetista de Banco de Dados Papel do PDS responsável pela definição de

tabelas, views, triggers, stored procedures e outros
elementos específicos de banco de dados
necessários para o armazenamento e
recuperação de dados persistentes do sistema.
projeto (UML) Parte do processo de desenvolvimento de

software em que o principal objetivo é decidir
como o sistema será implementado.
PTS Processo de Teste de Software do CTI – Datasus.

Inclui as tarefas de verificação e validação do
software em conformidade com requisitos
definidos pela equipe de desenvolvimento do
sistema.
qualidade (SGQ / DATASUS) Grau com que um conjunto

de características inerentes (produto, sistema ou
processo) satisfaz a requisitos.
regra de negócio (Sistemas de (RUP) Declaração de uma política ou condição

Informação) que deve ser satisfeita no contexto do negócio.
(BRG) Instrução que define ou restringe algum
aspecto do negócio.
regra de negócio (Organizações) (BRG) Uma diretiva, intencionada a influenciar

ou guiar o comportamento de um negócio, para
suportar políticas formuladas em resposta a
oportunidades, ameaças e pontos fortes e fracos.
relacionamento (UML) Conexão semântica entre elementos de

um modelo.
release Todo, ou parte do, produto final, objeto de

avaliação ao final de uma fase do processo de
desenvolvimento. É composta por uma versão
estável e executável do produto junto com os

artefatos necessários a sua utilização, podendo

ser interna ou externa.
repositório (UML) Local de armazenamento de

documentos, modelos, interfaces e
implementações.
requisito (requirement) (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.
(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.
(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.
requisito de sistema (system (IEEE 90) Condição ou capacitação que deve ser
requirement) 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 (software (IEEE 90) Condição ou capacitação que precisa

requirement) 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)
SCP- Módulo PTS Sistema para automatizar o controle e a

execução do fluxo de trabalho das atividades do
Processo de Teste de Software onde são
armazenadas as solicitações de teste.
template Gabarito. Estrutura pré-definida para um

artefato.
Transição A quarta fase do PDS-DATASUS em que o

objetivo é disponibilizar a versão final do
sistema.
UML Unified Modeling Language
Unified Modeling Language Linguagem de Modelagem Unificada.

Linguagem para visualizar, especificar, construir
e documentar artefatos de um sistema de
software.
usuário Papel do PDS que não executa diretamente

nenhuma atividade e nem é responsável por
qualquer artefato,mas representa os “clientes”
do projeto de desenvolvimento. O PDS2
distingue o usuário em 2 tipos: gestor e final.
usuário final Papel do PDS responsável pela definição geral

do sistema e, em alguns casos, pode ser o
próprio patrocinador do projeto.
usuário gestor Papel do PDS que 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 conseqüentes da implantação do
sistema.
Versão do Sistema (Release) Artefato do PDS 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.

Referências
1. [PMBOK 96] Project Managment Body of Knowledge, Project Management

Institute, 1996.
2. [BRG] Business Rules Group, Organizing Business Plans: The Standard

Model for Business Rules Motivation, 1 ed., Novembro, 2000.
3. [IEEE 83] IEEE Standard Glossary of Software Engineering Terminology,

Nova Iorque; IEEE, ANSI/IEEE Std 729.1983, 1983.
4. [Abbott86] Abbott, R. J.; An Integrated Approach to Software

Development, Nova Iorque; John Wiley, 1986.
5. [RUP] Rational Unified Process, Rational Software, 2000.
6. [UML] OMG Unified Modeling Language Specification, Version 1.3.

Rational Software Corporation, 1999.
7. [IEEE 90] IEEE Standard Glossary of Software Engineering Terminology,

ANSI/IEEE Std 610.12, 1990.
12.1 Dicionário de Símbolos

Figura 6. Dicionário de Símbolos

PDS-GuiaCompleto v2.3

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PDS-GuiaCompleto v2.3

Hochgeladen von

Copyright:

Verfügbare Formate

PDS-DATASUS

Versão do produto: 2.3

Edição do documento: Maio de 2009

Versão do produto: 2.3

Edição do documento: Maio de 2009

Número de páginas: 114

As informações contidas neste documento são de propriedade do DATASUS, sendo proibida

Os nomes de produtos, serviços ou tecnologias eventualmente mencionados neste

ii Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 iii

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 v

7.5 Projetar arquitetura do sistema 45

8. P APÉIS E PROCESSOS RELACIONADOS 75

vi Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

9.11 Pacote de Distribuição 85

10. D OCUMENTOS DE A POIO 89

11. CLASSIFICAÇÃO DE SISTEMAS 93

Figura 1. Fluxo da Fase de Concepção 31

Tabela 1. Classificação de Sistemas 94

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 vii

NOTA A referência completa do PDS pode ser obtida

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 3

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 7

melhores práticas que fundamentaram as primeiras versões do PDS, como o

8 Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

Apesar de não aparecerem de forma explícita nas representações gráficas, o

3.1 Desenvolvimento Iterativo e Incremental

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 11

antes que se tornem problemas, e resolver problemas antes que comprometam

3.2 Gerência de Requisitos

3.3 Gerência de Configuração

3.4 Gerência de Mudanças

3.5 Participação Ativa dos Usuários

12 Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

seus objetivos sejam atendidos.

3.6 Melhoria Contínua do Processo de

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 13

As recomendações descritas aqui são oriundas do Perfil de Segurança para

■ Ciclo de Vida de Software

4.1 Gerência de Configuração

■ Detectar modificações não autorizadas ou acidentais no sistema ou em

o Prover, de maneira automatizada, a garantia que somente

Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3 17

o Prover meios automatizados para averiguar as mudanças entre o

■ Garantir a integridade do sistema desde os estágios de elaboração até os

o Descrever todos os passos necessários para geração, instalação e

o Descrever todos os procedimentos necessários para manter a

■ Identificar unicamente o sistema para garantir que não haja dúvidas

o A referência deve ser única para cada versão do sistema.

■ Identificar unicamente os itens de configuração para melhorar a

o Incluir uma lista de configuração e descrever o método de

o Identificar todos os itens de configuração inclusos no sistema.

o Identificar unicamente todos os itens de configuração inclusos no

o Descrever os itens de configuração inclusos no sistema.

■ Prover controles a fim de garantir que modificações não autorizadas não

■ Implementar procedimentos de aceite para confirmar que qualquer criação

■ Implementar as ferramentas automatizadas que precisam apoiar as

o Descrever as ferramentas automatizadas utilizadas no sistema de

18 Ed. Maio de 2009, PDS-DATASUS-Processo de Desenvolvimento de Software, 2.3

o Descrever como são utilizadas as ferramentas automatizadas do

o Assegurar que todos os itens de configuração são controlados por

■ Garantir que exista controle na distribuição do sistema e nos

o O sistema recebido pelo usuário corresponda, precisamente, à cópia