ASPECTOS GERAIS DE PROJETO

DE SISTEMAS

Prof.: Denise F. Togneri

INTRODUO

INTRODUO

uma atividade de MODELAGEM que define COMO o

software dever ser implementado, levando-se em
considerao
sua plataforma de implementao (linguagem de
programao, local/meio de armazenamento tal como
SGBDOO, SGBD relacional, arquivos, plataforma de
implementao (centralizada, cliente/servidor) e
Os requisitos no funcionais tais como
desempenho, facilidade de uso, facilidade de alterao,
segurana (contra acessos indevidos e perdas
acidentais de dados) e confiabilidade.

Denise F. Togneri

INTRODUO

uma atividade executada pelo projetista do sistema.

O artefato de entrada para essa atividade o
Documento de Requisitos gerado na atividade de
Engenharia de Requisitos.
O artefato gerado nessa atividade um documento
intitulado Especificao do Projeto do Sistema.

Denise F. Togneri

INTRODUO

A Especificao do Projeto do Sistema contm

(1) uma descrio do escopo global do projeto (objetivos do
Sistema, principais requisitos de software, restries de projeto,
limitaes)
(2) o projeto de dados
(3) o projeto de arquitetura
(4) o projeto de interface
(5) o projeto dos componentes
(6) a referncia cruzada de requisitos ( uma matriz com
objetivo de estabelecer que todos os requisitos forem atendidos no
projeto, bem como indicar que mdulos so crticos para a
implementao de requisitos especficos) e
(7) uma proviso de testes
(8) apndices: manual preliminar de instalao/operao.
Denise F. Togneri

INTRODUO

... o processo de se aplicar vrias tcnicas e princpios com o objetivo

de se definir um dispositivo, um processo ou um sistema com detalhes
suficientes para permitir sua realizao fsica (Taylor, 1959).
A fase de projeto uma fase de MODELAGEM.
iniciado assim que os requisitos do software tenham sido analisados e
especificados.
A meta do projetista produzir um modelo que ser construdo
posteriormente.
O processo pelo qual o modelo desenvolvido combina intuio e
julgamento, baseado:
Na experincia de construir entidades similares;
Um conjunto de princpios ou heursticas que guiam a forma na qual
um modelo evolui;
Um conjunto de critrios que permitem avaliao da qualidade;
Um processo de iterao que leva a uma representao final do
projeto.
Denise F. Togneri

INTRODUO

Modelo
funcional

Modelo de
Informao
Proj. de dados

Projeto

Modelo
comportamental

Proj. arquitetural
Proj. procedimental
Proj. interface

Outros requisitos
(no funcionais)

Cdigo

Mdulos de
programa
Teste

Software integrado e validado

Denise F. Togneri

INTRODUO

No projeto, deve-se conhecer os requisitos no funcionais, alm da

definio de quais so mais importantes para implementar.
Os requisitos de software podem ser (Thayer, 1997):
funcionais: refere-se definio do mapeamento aceitvel entre
os valores de input do sistema e seus correspondentes valores de
output (informaes, funes e eventos);
no funcionais: refere-se a todas as outras restries incluindo
desempenho, confiana, manutenibilidade, reusabilidade e
segurana.
A pergunta bsica : Se aumento a segurana, aumento o
desempenho?
A resposta no. Estes requisitos so inversamente proporcionais.
Denise F. Togneri

INTRODUO
Decises de projeto afetam a facilidade de manuteno de um software.

Denise F. Togneri

INTRODUO

10

Por que no possvel passar da fase de anlise direto para a

fase de construo? Por que o Projeto to importante ?
RESPOSTA: QUALIDADE! O projeto promove a qualidade no
desenvolvimento do software.
Manter Rastreabilidade;
Definir a plataforma de implementao, que deve ser feito no incio do
projeto. Deve-se definir:
Linguagem de programao: definir qual e no somente o
paradigma. Ex: Eiffel tem persistncia; C no tem.
Local/meio de armazenamento: BDOO, BD relacional, arquivos, ...
Plataforma de implementao (centralizada, cliente/servidor)
Sistema ser distribudo ?

Sem projeto, corre-se o risco de construir softwares instveis - que

podem falhar com pequenas mudanas, serem difceis de testar, sem
possibilidade de avaliar qualidade e maior custo.
Denise F. Togneri

11

INTRODUO
Anlise e Especificao
de Requisitos (o que)
(Mundo Real)

Implementao
(Mundo Computacional)

domnio do
problema

Domnio da
soluo

Projeto
(como)
O processo de
transio do domnio
do problema para o
domnio de soluo
o projeto.

Denise F. Togneri

INTRODUO - PROJETO DE SOFTWARE E

ENGENHARIA DE SOFTWARE

12

O Projeto de Software se situa no ncleo tcnico do processo de

Engenharia de Software.
aplicado independentemente do modelo de processo de software
(ciclo de vida) que est sendo utilizado.
a primeira das trs atividades tcnicas - projeto, gerao de cdigo e
teste - que so requeridas para construir e verificar um software.
Cada um dos elementos do modelo de anlise (modelo de dados,
modelo funcional e modelo de comportamento) fornece informaes
que so requeridas para criar um modelo de projeto.
Processo do Projeto o processo atravs do qual os requisitos so
transportados/ transformados para uma representao do software.
Denise F. Togneri

INTRODUO
PRODUTOS DA FASE DE PROJETO

Projeto
Projeto
Projeto
Projeto

de
de
de
de

13

Arquitetura
Interface
Dados
Componentes

Denise F. Togneri

INTRODUO
PRODUTOS DA FASE DE PROJETO

14

Projeto de Dados:
transforma o modelo do domnio da informao criado
durante a anlise em estruturas de dados que sero
requeridas para implementao do software.
O DER e o Dicionrio de dados fornecem a base para o
projeto de dados.
Projeto de Arquitetura:
define os componentes estruturais do software e seus
relacionamentos.
Esta representao de projeto - uma framework modular
- pode ser derivada a partir do modelo de anlise e da
interao de subsistemas definidos no modelo de
anlise;
Denise F. Togneri

INTRODUO
PRODUTOS DA FASE DE PROJETO

15

Projeto de Interface:
Descreve a comunicao, ou seja, descreve como o
software dever se comunicar
dentro dele mesmo (interface interna - importante
para software distribudo, arquitetura cliente/servidor,
para analisar como os componentes iro se
comunicar);
com outros sistemas que interagem com ele e
com pessoas que o utilizam (interface externa).
derivado do Diagrama de Fluxo de Informao (Dados
e/ou Controle);
Denise F. Togneri

INTRODUO
PRODUTOS DA FASE DE PROJETO

Projeto de Componentes (ou Procedimental):

detalha a descrio procedimental dos componentes da
arquitetura de software, ou seja, transforma os
componentes estruturais da arquitetura do programa em
descries procedurais dos componentes do software.

16

A base para o projeto de componentes obtida a partir

da especificao do processo, especificao de controle
e do Diagrama de Transio de Estados.

Estes 4 projetos so aplicveis tanto ao paradigma

estruturado quanto ao paradigma orientado o objetos.
Denise F. Togneri

INTRODUO - SEQUNCIA PARA GERAO17

DOS PRODUTOS DA FASE DE PROJETO
1 opo:

Projeto de Arquitetura
Projeto de Dados
neste caso, o projeto de
dados poder sofrer
alteraes posteriores, em
funo de decises tomadas
no projeto de interface.
Projeto de Interface
Projeto de Componentes

2 opo:

Projeto
Projeto
Projeto
Projeto

de
de
de
de

Arquitetura
Interface
Dados
Componentes

3 opo:

Projeto de Interface pode ser

feito em paralelo com a Anlise
bem como o Projeto de
Arquitetura
Projeto de Dados
Projeto de Componentes

Denise F. Togneri

QUALIDADE DE PROJETO

18

19

QUALIDADE

Qualidade a totalidade de caractersticas de um produto

ou servio que lhe confere a capacidade de satisfazer as
necessidades explcitas ou implcitas (ISO 9126).
Necessidades explcitas so expressas na definio de
requisitos propostos pelo produtor. Esses requisitos
definem as condies em que o produto deve ser utilizado,
seus objetivos, funes e o desempenho esperado.
Necessidades implcitas so aquelas que no esto
expressas nos documentos do produtor mas que so
necessrias para o usurio. identificado como sendo o
aspecto subjetivo da Qualidade (Tsukumo, 1996).
Denise F. Togneri

20

QUALIDADE DO SOFTWARE

a conformidade a requisitos funcionais e de desempenho

explicitamente declarados, a padres de desenvolvimento
claramente documentados e a caractersticas implcitas que
so
esperadas
de
todo
software
profissionalmente
desenvolvido (Pressman, 2002).
um conjunto de atributos que devem ser alcanados, em um
determinado grau, de forma que o produto atenda s necessidades de
seus usurios. Um primeiro e importante passo no tratamentos dos
problemas de software considerar a tarefa global de desenvolvimento
como um processo que pode ser controlado, medido e melhorado.
Pesquisas evidenciaram a profunda relao entre a qualidade
do produto de software e a qualidade do processo de
desenvolvimento de software (Falbo, 1996a).

Denise F. Togneri

10

21

QUALIDADE DO PROJETO
As organizaes tm percebido que seus problemas fundamentais
esto na inabilidade de gerenciar o processo de software (Paulk,
1993).

A fase de projeto tecnolgico do ciclo de desenvolvimento de um

sistema responsvel por incorporar a tecnologia aos requisitos
essenciais do usurio, projetando o que ser codificado pela
programao.

Assim sendo, essa fase desempenha um papel fundamental para a

imagem (percepo de qualidade) que o usurio ter do sistema
durante a sua utilizao.

Alm de estabelecer critrios de qualidade a serem seguidos no

projeto, criar uma matriz de avaliao da qualidade do software,
estabelecendo mtricas que demonstrem tambm a opinio do
usurio. preciso medir a qualidade.

Denise F. Togneri

CRITRIOS DE QUALIDADE A SEREM

OBSERVADOS NO PROJETO

Completeza: atendimento aos requisitos do usurio

Desempenho: uso otimizado dos recursos computacionais
disponveis

Segurana contra acessos indevidos

Interatividade (facilidade de uso)

22

Confiabilidade (segurana contra perdas): preservao da

disponibilidade do sistema e da integridade das informaes
armazenadas.

Manutenibilidade: facilidade de alterao

Economia: custo adequado ao escopo do sistema

Denise F. Togneri

11

CRITRIOS DE QUALIDADE:
DESEMPENHO

23

Uso otimizado dos recursos computacionais disponveis

(hardware, software, peopleware)
Tempo de resposta mximo para determinadas atividades.
Fatores que afetam o desempenho do sistema:
Fatores Internos
Fatores Externos

Denise F. Togneri

FATORES INTERNOS QUE AFETAM O

DESEMPENHO

24

Projeto fsico dos arquivos:

objetivo: minimizar tempo gasto no acesso a discos
projeto fsico dos arquivos deve ser bem feito.
Compresso ou compactao de dados:
elimina espaos no utilizados e diminui tamanho do
arquivo
importante para comunicao de dados (transferncia de
arquivos) entre processadores
importante para economia de espao em disco
Deve haver algoritmo de compactao/descompactao
eficientes.
Denise F. Togneri

12

FATORES INTERNOS QUE AFETAM O

DESEMPENHO

Reorganizao de arquivos
ordenao para facilitar a busca
Reorganizao de ndices
reorganizao da rvore B ou B+ de forma que a altura
volte a ser a mnima possvel.
Limpeza de arquivos e histrico:
o projeto deve prever eliminao peridica de registros
que no precisem mais ser utilizados ou cuja
probabilidade de acesso seja remota. Pode ser feita por
limpeza de arquivos: exclui do BD as informaes
desnecessrias
histrico de arquivos: transferncia para outro meio
magntico ou outra rea de disco ainda necessrias
para eventuais consultas, mas principalmente para
atender fins legais, fiscais ou estatsticos.
Denise F. Togneri

FATORES INTERNOS QUE AFETAM O

DESEMPENHO

25

26

Utilizao da computao cliente/servidor

distribuio da computao entre estaes cliente (frontend) e servidor (back-end)

Vantagens: reduo do trfego na rede, customizao

das mquinas segundo aptido de cada uma, liberao do
servidor para atender outros clientes.
Desvantagens: custo de pessoal especializado nessa
computao, confiabilidade da arquitetura com grande
nmero de produtos de fornecedores diferentes com
problemas de integrao.
Denise F. Togneri

13

FATORES EXTERNOS QUE AFETAM O

DESEMPENHO

27

So aqueles que no so da alada do projeto, mas podem

interferir no desempenho do sistema, tornando necessrio
interceder junto s pessoas responsveis.
Reorganizao da memria de massa
com a incluso de novas registros, memria no contgua
alocada para um arquivo, degradando desempenho em
funo de maior movimentao da cabea de
leitura/gravao dos discos.
necessria uma reorganizao peridica dos arquivos.

Denise F. Togneri

FATORES EXTERNOS QUE AFETAM O

DESEMPENHO

28

Sintonia da aplicao com o Sistema Operacional e

com o SGBD
parametrizao do SGDB e do SO influenciam bastante o
desempenho.
Scheduling
processos longos devem rodar fora dos horrios de maior
utilizao
processos que consomem CPU (CPU bound) devem ser
monitorados
1 mquina para desenvolvimento e outra para produo
Denise F. Togneri

14

CRITRIOS DE QUALIDADE: SEGURANA

CONTRA ACESSOS INDEVIDOS

29

Objetivo: no permitir que pessoas no autorizadas

tenham acesso ao sistema ou aos dados, protegendo-os
contra exposio, alterao ou destruio desautorizada.
Para atingir este objetivo, projetar:
Procedimentos de segurana (preveno)
controle de acesso: identificao, autenticao
(password, voz, impresso digital) e restrio do acesso
s operaes autorizadas.
criptografia: transformam as informaes
armazenadas ou que trafegam na rede ilegveis para
quem no conhece a chave de decodificao. No
entanto, degrada o desempenho.
vises: filtros em nvel de banco de dados ou de
funes.

Denise F. Togneri

CRITRIOS DE QUALIDADE: SEGURANA

CONTRA ACESSOS INDEVIDOS

30

Deteco da ocorrncia de violaes

procedimento de monitorao que armazene o cdigo do
usurio que acessou o sistema e as operaes por ele
realizadas.
Criao de uma atividade tecnolgica chamada auditoria

Denise F. Togneri

15

CRITRIOS DE QUALIDADE: SEGURANA

CONTRA ACESSOS INDEVIDOS

31

Algumas recomendaes para a segurana do sistema

cada usurio deve ter um cdigo de identificao nico e

intransfervel, com uma autenticao que s seja por ele
manipulada e devendo ser periodicamente alterada
senhas secretas com no mnimo quatro e no mximo oito
caracteres, com letras e nmeros. No exibi-las quando de
sua digitao e se ocorrer um determinado nmero de
tentativas infrutferas de acesso, cancelar o acesso.
As atividades de um usurio no sistema devem ser
definidas por um usurio responsvel pelo sistema
(proprietrio dos dados)
Denise F. Togneri

CRITRIOS DE QUALIDADE: SEGURANA

CONTRA ACESSOS INDEVIDOS

32

Matriz de classes de usurios x operaes autorizadas

Documenta o nvel de autorizao adotado no projeto.

OPERAES
AUTORIZ.

CLASSE
CLASSE
DIGITADOR ADMINIST

Entrada de
Dados

Consultas

CLASSE
OPERADOR

CLASSE
AUDITOR

Auditoria
Atividades
Tecnolgicas

X
X

Denise F. Togneri

16

CRITRIOS DE QUALIDADE:
INTERATIVIDADE E CONFIABILIDADE

33

INTERATIVIDADE (FACILIDADE DE USO)

Deve ser garantida atravs de um bom projeto de
interface com o usurio
CONFIABILIDADE (SEGURANA CONTRA PERDAS)
Preservao da disponibilidade do sistema e da
integridade das informaes armazenadas.
Deve-se estar atento a:
Restries de Integridade
Recuperao de Falhas
Controle de Concorrncia
Denise F. Togneri

34
CRITRIOS DE QUALIDADE: CONFIABILIDADE
(SEGURANA CONTRA PERDAS)

1 - Restries de Integridade:
para garantir que as informaes armazenadas no BD sejam
filtradas a partir de regras estabelecidas, mantendo-se vlidas e
corretas.
Ex: domnio de atributos, integridade referencial --> chave
estrangeira.
2 - Recuperao de Falhas:
cabe ao projetista prever possveis falhas e definir sua forma de
recuperao (restaurar o BD a um estado de consistncia correto).
Transao: seqncia de operaes tratadas como uma unidade
atmica e portanto indivisvel. As operaes recuperveis devem
estar dentro de transaes. Fim de uma transao dado por um
commit ou um rollback.
Denise F. Togneri

17

35
CRITRIOS DE QUALIDADE: CONFIABILIDADE
(SEGURANA CONTRA PERDAS)

2 - Recuperao de Falhas:
Tipos de Falhas:
humana: digitao ou operao do sistema,
de transao: overflow aritmtico, run time erros ou
diviso por zero
de sistema: falha de hardware, queda de energia,
desligamento da mquina
de disco
de comunicao: queda da linha.
de software: erro de desenvolvimento (anlise, projeto
ou programao)
Denise F. Togneri

36
CRITRIOS DE QUALIDADE: CONFIABILIDADE
(SEGURANA CONTRA PERDAS)

2 - Recuperao de Falhas:
Deteco de Falhas:
o SGBD pode revelar se a ltima sada do sistema foi
normal/ anormal.
uma atividade tecnolgica de auditoria deve ser
prevista, para varrer os arquivos e apontar possveis
inconsistncias.

Recuperao de Falhas:
procedimento que desfaa ou refaa as operaes
realizadas.
Se no houver procedimento na equipe de suporte,
esta atividade tecnolgica deve ser prevista.
Denise F. Togneri

18

37
CRITRIOS DE QUALIDADE: CONFIABILIDADE
(SEGURANA CONTRA PERDAS)

2 - Recuperao de Falhas:
Mecanismos de Preveno de Falhas:
Registros de headers em arquivos: se a fita ou
disquete for colocada invertida, o SO detecta
Backup: se for feito pela equipe de suporte, o
projetista no precisa projetar esta atividade
tecnolgica. Se for feito pelo usurio, sim.
Log: para garantir recuperao aps ltimo backup.
Disk Mirror: espelhamento consiste em fazer
gravao simultnea em dois discos magnticos. Caso
haja defeito em um, o outro pode ser utilizado.
Denise F. Togneri

38
CRITRIOS DE QUALIDADE: CONFIABILIDADE
(SEGURANA CONTRA PERDAS)

3 - Controle de Concorrncia

Podem acontecer 3 problemas: perda de atualizaes,

dependncia de uma transao no confirmada e anlise
inconsistente.
Para evitar esta anomalia ---> utiliza-se o mtodo de Bloqueio.
Bloqueio: antes de acessar um objeto, a transao tenta
bloque-lo. O bloqueio pode ser exclusivo ou compartilhado.
O Bloqueio pode acontecer:
antes da leitura: problema do cafezinho do usurio
antes da gravao: problema a integridade dos dados
durante a releitura: na maioria dos casos a melhor
soluo. Causa problema de overhead, por causa da
releitura.
Denise F. Togneri

19

39
CRITRIOS DE QUALIDADE: MANUTENIBILIDADE
(FACILIDADE DE ALTERAO)

Facilidade de alterao futura

Alteraes podem ter origem em:
Erros de especificao e/ou projeto
Novas necessidades do usurio: a alterao deve comear
no modelo de anlise
Alteraes no ambiente tecnolgico do usurio: o projeto
deve ser revisto, mas no a anlise.

Denise F. Togneri

40
CRITRIOS DE QUALIDADE: MANUTENIBILIDADE
(FACILIDADE DE ALTERAO)

Aes:
adoo de uma metodologia
adoo de normas e padres: padres de interface (telas,
teclas, relatrios, mensagens) ou de codificao (
nomenclatura de programas, arquivos, telas, mdulos,
nome de variveis, etc)
documentar
modularizar

Denise F. Togneri

20

41

CRITRIOS DE QUALIDADE: ECONOMIA

Custo adequado ao escopo do software.

Custos decorrentes do projeto tecnolgico:
custos da elaborao do projeto tecnolgico, custos da programao,
custos operacionais, custos da manuteno
A diminuio dos custos pode ser alcanada atravs de:
boa documentao
utilizao de ferramentas CASE
utilizao de padres de projeto
Reutilizao
reutilizao parcial de programa: cpia de um programa j
existente e alterao do cdigo por cima. Problema: introduo de
erros
Reutilizao de mdulo de dentro do prprio projeto (em tempo
de anlise - processo em um DFD ou em tempo de projeto - DEM)
Reutilizao de mdulo de uma biblioteca
Reutilizao de projeto
Denise F. Togneri

DOCUMENTAO DO PROJETO

42

21

DOCUMENTAO DO PROJETO SEGUNDO

PRESSMAN (1997)

43

I - Escopo
A - Objetivos do Sistema
B - Principais requisitos de software
C - Restries de projeto, limitaes
II - Projeto de Dados
A - Objetos de Dados e Estruturas de Dados resultantes
B - Estruturas de arquivos e de banco de dados
1 - Estrutura de arquivos externos (a - Estrutura Lgica; b Descrio de registros lgicos; c - Mtodos de acesso)
2 - Dados globais
3 - Referncias cruzadas de objetos de dados e arquivos
III - Projeto de Arquitetura
A - Reviso de dados e fluxos de controle
B - Estrutura derivada de programas (a partir do modelo de anlise;
utilizar um grfico hierrquico)
Denise F. Togneri

DOCUMENTAO DO PROJETO SEGUNDO

PRESSMAN (1997)

44

IV - Projeto de Interface
A - Especificao da interface homem-mquina
B - Regras de projeto da interface homem-mquina
C - Projeto de interface externa
1 - Interface para dados externos
2 - Interface para dispositivos ou sistemas externos
D - Regras de Projeto para interface interna
V - Projeto de Procedimentos (Componentes) - Para cada mdulo
A - Narrativa do processamento
B - Descrio da interface
C - Descrio da linguagem de projeto
D - Mdulos usados
E - Estruturas de dados interna
F - Comentrios/restries/limitaes
Denise F. Togneri

22

DOCUMENTAO DO PROJETO SEGUNDO

PRESSMAN (1997)

45

VI - Referncia cruzada de requisitos

uma matriz com objetivo de estabelecer que todos os requisitos
forem atendidos no projeto, bem como indicar que mdulos so crticos
para a implementao de requisitos especficos.
VII - Proviso de testes
1 - Guia geral para testes (guia geral para teste de mdulos individuais
e integrao de todo o pacote. Em alguns casos, uma especificao
detalhada de teste de procedimento feita em paralelo com o projeto.
Em tais casos, esta seo pode ser excluda)
2 - Estratgia de integrao (requisitos e consideraes especiais sobre
empacotamento do software, como por exemplo, limitao de
memria, bem como abordagem a ser usada para transferncia do
software para o site do cliente).
3 - Consideraes especiais
VIII - Notas especiais
IX Apndices
(incluir aqui o manual preliminar de instalao/operao).

Denise F. Togneri

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER (1995)

46

Segundo Xavier (1995, p. 95), a documentao do projeto

composta do
Manual do Sistema
Manual do Usurio.

Denise F. Togneri

23

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER: MANUAL DO SISTEMA

47

I - ndice
II- Propsito do Sistema
III - Projeto Tecnolgico

III.1- As Fronteiras do Sistema

III.1.1 - Limites da automatizao
III.1.2 - Interfaces com o mundo exterior

III.2 - Quadro de Alocao em Processadores (QAP)

III.3 - Requisitos de Implementao

III.3.1 - Ambiente de hardware e software para o desenvolvimento e operao
do sistema.
III.3.2 - Requisitos para a manutenibilidade
a) Padronizao de cdigos
b) Atividades tecnolgicas necessrias
III.3.3 - Requisitos para a interatividade
a) Padro de telas e relatrios
b) Atividades tecnolgicas necessrias (ex. help)
III.3.4 - Requisitos para a performance
a) Tempo de resposta exigido pelo usurio (se houver)
b) Atividades tecnolgicas necessrias (ex. reorganizao de arquivos,
limpeza de arquivos e reorganizao de ndices).

Denise F. Togneri

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER: MANUAL DO SISTEMA

48

III.3 - Requisitos de Implementao

III.3.5 - Requisitos para a confiabilidade
a) Mnimo tempo entre falhas (se houver)
b) Mximo tempo inoperante (se houver)
c) Atividades manuais necessrias (se houver) (ex. guarda de planilhas
para o caso de perdas de arquivos)
d) Falhas possveis e suas recuperaes
e) Mecanismo de controle de concorrncia (para sistemas multiusurios)
f) Atividades tecnolgicas necessrias (ex. recuperao de arquivos;
backup e recuperao de ndices)
III.3.6 - Requisitos para a segurana contra acessos indevidos
a) Descrio dos dispositivos de segurana contra acessos
b) Atividades tecnolgicas necessrias (ex. auditoria; controle de
usurios e alterao de senha)
III.3.7 - Requisitos para a economia
a) Custos envolvidos
b) Normas para a reutilizao de mdulos
III.4 - Quadro de Alocao de Tarefa (QAT)
III.5 - Quadro Estimativa de Memria Secundria (QEMS)
Denise F. Togneri

24

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER: MANUAL DO SISTEMA

49

III.6 - DEM (1 por tarefa)

III.6.1 - Diagrama(s)
III.6.2 - Especificao de cada mdulo
III.6.3 - Layouts de telas e relatrios

III.7 - Projeto fsico de arquivos

III.7.1 - Nomes fsico (cdigo) e lgico (alias) dos arquivos
III.7.2 - Especificao da composio dos registros (nomes dos campos, tipo,
tamanho e descrio do contedo, quando necessrio)
III.7.3 - Organizao do arquivo e ndices (se for o caso)
III.7.4 - Localizao fsica (disco rgido, diretrio, etc)

III.8 - Matrizes
III.8.1 - Matriz classes de usurios x operaes autorizadas (se o QAT no
representar as autorizaes)
III.8.2 - Matriz mdulos acionadores x mdulos reutilizados
III.8.3 - Matriz mdulo x arquivos acessados
IV - Mtricas de qualidade e produtividade
(neste item devem ser apresentadas algumas mtricas de qualidade e produtividade
aferidas pelo grupo durante o desenvolvimento)
V - Consideraes Finais
(quaisquer comentrios e/ou sugestes do grupo para a metodologia utilizada e para os
Denise F. Togneri
futuros trabalhos)

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER: MANUAL DO USURIO

50

I- Propsito do Sistema (escopo)

II - Ambiente do Sistema
III - Instrues para a instalao do sistema
IV - Instrues para uso do sistema
IV.1 - Entrando e saindo do sistema
IV.2 - Padro de telas
IV.3 - Padro de relatrios
IV.4 - Padro de teclas
IV.5 - Padro de mensagens
IV.6 - Utilizao do help
IV.7 - Relao das consultas e relatrios disponveis
V - Segurana do sistema
V.1 - Descrio das classes de usurios
V.2 - Operaes permitidas por classe de usurio
V.3 - Utilizao da senha
Denise F. Togneri

25

DOCUMENTAO DO PROJETO SEGUNDO

XAVIER: MANUAL DO USURIO

51

VI - Algumas caractersticas do sistema

neste ponto, devem ser explicadas algumas atividades essenciais do
sistema, cuja utilizao merea ateno.
VII - Manuteno do sistema
VII.1 - Melhoria da performance do sistema
VII.2 - Poltica de backup
VII.3 - Mecanismos para a recuperao de informaes
VIII - Consideraes finais

Denise F. Togneri

52

REFERNCIAS
ISO/IEC 9126. Information Technology - Software Product Evaluation - Quality
characteristics and guidelines for their use. Genebra: ISO/IEC, 1991.
FALBO, Ricardo de A. Automatizao do Processo de Desenvolvimento de
Software. In: ROCHA, Ana R. C. da. (Org.). Qualidade de Software: seleo de
textos. Curitiba: CITS, 1996. p. 71-88.
PAULK, Mark C., CURTIS, Bill et al. Capability Maturity Model, Version 1.1. IEEE
Software, p. 18-27, jul. 1993.
PRESSMAN, Roger S. Software Engineering: a practitioners approach. 4.ed.
New York: McGraw-Hill, 1997.
______. Engenharia de Software. 5.ed. Rio de Janeiro: McGraw-Hill, 2002.
TSUKUMO, Alfredo et al. Qualidade de Software: uma Viso Geral sobreAvaliao
e Melhoria. In: ROCHA, Ana R. C. da. (Org.). Qualidade de Software: seleo
de textos. Curitiba: CITS, 1996. p. 45-69.
THAYER, H. Richard, DORFMAN, Merlin. (Org.) Software Requeriments
Engineering. 2 ed. Los Alamitos, California: IEEE Computer Society, p.128-149,
1997.
XAVIER, C.M. da S., PORTILHO, C. Projetando com qualidade a tecnologia
em sistemas de informao. Rio de Janeiro: LTC, 1995.
Denise F. Togneri

26