Aulas de Análise de Sistemas PDF

Prof. ALFREDO BOENTE, PhD.
professor@boente.eti.br
ANLISE DE SISTEMAS
Sobre o Professor
Ps-Doutorado:
Epistemologia, Lgicas e Teorias da Mente pelo HCTE/UFRJ/RJ/Br.
Doutorado:
Engenharia de Produo pela COPPE/UFRJ/RJ/Br.
Data Processing pela AWU/Iowa/USA.
Mestrado:
Administrao e Desenvolvimento Empresarial pela UNESA/RJ/Br.
Ciencias de la Computacin pela Universidad de Habana/Ciudad Universitaria/Cu.
Software Engineering AWU/Iowa/USA.
Especializao:
Anlise de Sistemas, Docncia Superior, Tecnologia em Banco de Dados, Cincias da
Computao, Administrao Escolar, Programao de Computadores.
Graduao:
Tecnologia em Processamento de Dados - Anlise e Projeto de Sistemas
Objetivo da Disciplina
Capacitar o aluno nos processos existentes de desenvolvimento
de sistemas e nas metodologias e prticas utilizadas para
modelagem e especificao de sistemas de informao atravs
da viso essencial de anlise e projeto e sistemas.
Ementrio Bsico
Introduo a Anlise de sistemas: Conceituao e fundamentos.
Ciclo de desenvolvimento de sistemas. Viso do Projeto de
Sistemas. Modelagem de sistemas de informao. Modelagem
essencial de sistemas. Modelagem funcional de sistemas.
Estudos de Casos.
Bibliografia Recomendada
CALIU, P.S. Anlise e Projeto de Sistemas Essencial: Teoria e
Prtica. So Paulo: Makron Books, 2008.
GANE, C. Desenvolvimento rpido de Sistemas. Rio de Janeiro:
LTC, 1989.
GANE, C., TRISH, S. Anlise Estruturada de Sistemas. Rio de
Janeiro: LTC, 1989.
POMPILHO, S. Anlise Essencial: Guia Prtico de Anlise de
Sistemas. Ed. IBPI, 1995
YOURDON. E. Anlise Estruturada Moderna. So Paulo:
Campus, 1989.
Bibliografia Recomendada
PHILL, R.S.V. System Analisys and Design: Concepts, Practice
and Smart Solutions. New York: Spring, 2009.
SILVEIRA, T.E.; FILHO, S.A.L. Anlise e Projeto de Sistemas de
Informao: da teoria prtica. Rio de Janeiro: Elsevier, 2010.
VINNY, M.O.; TOMAZ, R.E.F. Projeto, Anlise e Implementao
de Sistemas com Linguagem C#. 2 ed. Porto Alegre: Bookman,
2008.
Critrios de Avaliao
A1: Trabalhos realizados (2,0)
Prova (8,0)

A2: Trabalho realizados (2,0)
Prova (8,0)

A3: Prova Terica (10,0)
Atividade de Pesquisa

Pesquisa: Tcnicas e Abordagens de Anlise e Projeto
de Sistemas de Informao: Caractersticas, vantagens e
desvantagens.

Estrutura do Trabalho
1. Introduo
2. Desenvolvimento
2.1. Aaaa aaaaa
2.2. Bbbbb bbb
2.n. ( ... )
3. Comparativo entre as Tcnicas e Abordagens
4. Concluso
5. Referncias

Grupo de at 4 componentes (ABNT)
Introduo
O desenvolvimento de software uma atividade de crescente
importncia na sociedade contempornea. A utilizao de
computadores nas mais diversas reas do conhecimento
humano tem gerado uma crescente demanda por solues
computadorizadas.
importante observar que, associada ao acrscimo da
demanda, a evoluo do hardware tem sido mais acentuada,
disponibilizando aos usurios mquinas cada vez mais velozes e
com maior capacidade de processamento.
Introduo
Neste contexto, identificou-se, j na dcada de 70, uma
situao crtica no desenvolvimento de software, a chamada
Crise do Software, onde Roger Pressman, a caracterizava pelos
seguintes fatos:
demanda muito superior capacidade de desenvolvimento;
qualidade insuficiente dos produtos; e
estimativas de custo e tempo raramente cumpridas nos projetos.
Visando melhorar a qualidade dos produtos de software e
aumentar a produtividade no processo de desenvolvimento,
surgiu a rea de pesquisa denominada Engenharia de Software.
Introduo
A Engenharia de Software busca organizar esforos no
desenvolvimento de ferramentas, metodologias e ambientes de
suporte ao desenvolvimento de software.
Dentre as principais atividades de um processo de
desenvolvimento de software, destaca-se a atividade de
anlise e especificao de requisitos, na qual os requisitos de
um sistema so levantados e modelados, para s ento ser
projetada e implementada uma soluo.
Anlise e Especificao de
Requisitos
Um completo entendimento dos requisitos do software
essencial para o sucesso de um esforo de desenvolvimento de
software. A atividade de anlise e especificao de requisitos
um processo de descoberta, refinamento, modelagem e
especificao.
O escopo do software definido no planejamento do projeto
refinado em detalhe, as funes e o desempenho do software
so especificados, as interfaces com outros sistemas so
indicadas e restries que o software deve atender so
estabelecidas.
Requisitos
Modelos dos dados requeridos, do controle e do
comportamento operacional so construdos.
Finalmente, critrios para a avaliao da qualidade em
atividades subsequentes so estabelecidos.
Os principais profissionais envolvidos nesta atividade so o
engenheiro de software (muitas vezes chamado analista) e o
cliente / usurio.
Requisitos
A etapa de Elicitao de Requisitos (ou Especificao de
Requisitos) independente de paradigma, uma vez que trata os
requisitos do sistema sob uma perspectiva externa.
Entretanto, a atividade de Anlise, que modela as estruturas
internas de um sistema, completamente dependente do
paradigma adotado no desenvolvimento.
Especificao de Requisitos
Tcnicas de Levantamento de Requisitos
Em todo desenvolvimento de software, um aspecto
fundamental a captura dos requisitos dos usurios.
Para apoiar este trabalho, diversas tcnicas podem ser
utilizadas.
Iremos abordar algumas dessas tcnicas de levantamento de
requisitos utilizada na atividade de Anlise e Projeto de
Sistemas.
Amostragem
Em um levantamento de requisitos, geralmente um
engenheiro de software se depara com duas importantes
questes:
Entre os muitos relatrios, formulrios e documentos gerados pelos
membros de uma organizao, quais devero ser objeto de
investigao?
Pode haver um grande nmero de pessoas afetadas pelo sistema de
informao proposto. Quais delas devem ser entrevistadas,
observadas ou questionadas?
Servindo de base para todas as tcnicas de levantamento de
requisitos, entre elas investigao, entrevistas e observao,
esto as decises cruciais dizendo respeito a o que examinar e
quem questionar ou observar.
Estas decises podem ser apoiadas por uma abordagem
estruturada chamada amostragem.
Amostragem o processo de seleo sistemtica de
elementos representativos de uma populao. Quando os
elementos selecionados em uma amostragem so analisados,
pode-se assumir que esta anlise revelar informaes teis
acerca da populao como um todo.
diminuir custos;
acelerar o processo de levantamento de informaes;
eficincia: a informao tende a ser mais apurada, j que menos
elementos podem ser analisados, mas estes podem ser analisados
com mais detalhes;
reduzir tendncias.
O Processo da Amostragem
H quatro passos que um engenheiro de software deve seguir
para projetar uma boa amostra:
1. Determinar os dados a serem coletados ou descritos: Definir o que
coletar e para que, isto , que tipo de tcnica de levantamento de
informao ser usado depois. Coletar dados irrelevantes representa
perda de tempo.
2. Determinar a populao a ser amostrada (o que / quem): No caso
de documentos definir quais documentos investigar e de que
perodo/intervalo. No caso de pessoas, estabelecer a que nvel da
organizao pertencem ou se so pessoas de fora.
3. Escolher o tipo da amostra.
4. Decidir sobre o tamanho da amostra.
Os dois primeiros passos dizem respeito ao contexto do
desenvolvimento. Os dois ltimos referem-se tcnica de
amostragem propriamente dita e so detalhados a seguir.
Tipos de Amostra:
Amostra de Convenincia: irrestrita, no utiliza
probabilidades, mais fcil e, geralmente, apresenta
resultados irreais. Ex: aviso chamando os interessados a
participar de uma reunio.
Amostra Intencional: a escolha feita com base em
critrios pr-estabelecidos pelo engenheiro de software,
sem levar em conta probabilidades. uma amostra
apenas moderadamente confivel. Ex: engenheiro de
software escolhe, para entrevista, um grupo de
indivduos que aparentam ter conhecimento e interesse
no novo sistema.
Amostra Randmica Simples: necessrio ter em mos
uma lista da populao a ser amostrada (documentos ou
pessoas) para garantir que cada elemento tem igual
chance de ser selecionado. Geralmente, no prtica,
especialmente para documentos e relatrios.
Amostra Randmica Complexa: pode ser de trs tipos:
Amostra sistemtica: o tipo mais simples de amostragem que
leva em conta probabilidades. Consiste em se pegar sempre o k-
simo elemento da populao. Pode introduzir tendncias.
Amostra Estratificada: a abordagem mais importante para um
engenheiro de software. Identifica sub-populaes e escolhe
elementos dentre essas subpopulaes. Muito til quando se
deseja usar diferentes tcnicas de levantamento de informao
para sub-grupos especficos. Ex: coletar informaes de pessoas
de diferentes nveis da organizao.
Amostra de Grupos: consiste em selecionar um grupo para ser
estudado. Ex: selecionar um ou duas filiais de uma organizao,
assumindo que espelham o comportamento de todas filiais.
Tamanho da Amostra
O tamanho da amostra depende substancialmente do custo
envolvido e do tempo requerido para se proceder a
investigao, entrevista ou questionrio posteriormente. O
clculo do tamanho da amostra varia, ainda, em funo do tipo
de informao que se deseja obter.
Quando a informao desejada for quantitativa, h dois
procedimentos bsicos de clculo, dependentes do tipo de
informao que se deseja obter:
Valores: quando se deseja saber quantidades (valores) reais,
por exemplo o nmero de erros de preenchimento de um
determinado formulrio, o tamanho da amostra pode ser
calculado da seguinte forma:
Percentuais: quando se deseja saber propores ou
percentuais, por exemplo o percentual de pessoas em uma
organizao que pensa de um certo modo, o tamanho da
amostra pode ser calculado da seguinte forma:
Quando as informaes a serem coletadas forem qualitativas,
melhor tentar obt-las atravs de entrevistas. Entretanto, no
h frmulas mgicas para ajudar engenheiros de software a
determinar quantas pessoas entrevistar em uma organizao.
Esta deciso deve ser baseada no tempo gasto para se
proceder uma entrevista. Uma boa regra de bolso,
independentemente do tamanho da organizao, consiste em
entrevistar pelo menos trs pessoas em cada nvel da
organizao e uma pessoa por rea funcional.
Investigao
Muitas vezes, algumas informaes so difceis de serem
obtidas atravs de entrevistas ou observao. Tais informaes
revelam, tipicamente, um histrico da organizao e sua
direo. Nestes casos, devemos utilizar investigao, isto ,
anlise de documentos.
Atravs de investigao, podemos obter mais facilmente
informaes, tais como tipos de documentos e problemas
associados, informao financeira e contextos da organizao.
Tais informaes so difceis de serem obtidas atravs de
outras tcnicas de levantamento de requisitos, tais como
entrevistas ou observao.

Anlise de Documentos Quantitativos
Documentos com formato pr-determinado, tais como
relatrios e formulrios, trazem informaes muito teis a um
engenheiro de software. Estes documentos tm um propsito
especfico e um pblico-alvo.
Relatrios de desempenho, por exemplo, podem mostrar
metas de uma organizao, a distncia em relao meta e a
tendncia atual.
Relatrios usados no processo de tomada de deciso mostram
informaes compiladas e podem incorporar algum
conhecimento sobre a estratgia da organizao.
Fichas (registros) proveem atualizaes peridicas do que est
ocorrendo no negcio.
Um engenheiro de software pode inspecionar uma ficha para:
(i) checar erros em quantidades e totais,
(ii) procurar oportunidades de melhorar o desenho da
ficha,
(iii) observar nmero e tipos de transaes e
(iv) procurar instncias onde a introduo de um
sistema computadorizado pode simplificar o trabalho (clculos,
por exemplo).
Formulrios, assim como fichas, so muito teis para o
levantamento de requisitos.
Devem ser inspecionados tanto formulrios oficiais quanto
no oficiais em uso.
Exemplares de formulrios em branco devem ser coletados,
procurando-se observar o tipo, propsito e o pblico alvo.
Deve-se, ainda, verificar quem realmente recebe o formulrio.
Ao se examinar formulrios preenchidos, observar se:
(i) h itens no preenchidos,
(ii) h formulrios nunca usados,
(iii) h formulrios no oficiais usados regularmente e
(iv) os formulrios so preenchidos pelas pessoas
certas.
Na investigao de formulrios preenchidos, possvel
detectar problemas como:
(i) a informao no flui como planejado,
(ii) pontos de gargalo no processamento de formulrios,
(iii) trabalho duplicado desnecessariamente, e
(iv) falta de viso do fluxo global da informao, isto ,
porque um formulrio preenchido e quem o utilizar.
Anlise de Documentos Qualitativos
Documentos sem formato pr-determinado, tais como
memorandos, quadros de aviso e manuais, tambm so teis
para o levantamento de requisitos, uma vez que mostram como
os membros de uma organizao so engajados nos processos
da mesma.
A anlise de documentos qualitativos deve envolver as
seguintes tarefas:
Examinar documentos para identificar como os elementos da
organizao so referenciados e, assim, conhecer a organizao.
Identificar disputas (entre departamentos ou com outras empresas)
e, assim, conhecer a poltica da organizao.
Identificar termos que aparecem repetidamente em documentos e
caracterizem o que bom ou ruim para a organizao.
Reconhecer a existncia de senso de humor nos documentos, o que
pode indicar o tipo dos membros da organizao (por exemplo,
conservadores, ...).
Ao analisar memorandos (inclusive os eletrnicos), d
preferncia queles enviados para toda a organizao. Observe
quem enviou e quem recebeu. Memorandos, tipicamente
fluem horizontalmente ou de cima para baixo e provem uma
ideia clara de valores, crenas e atitudes dos membros da
organizao.
Na investigao de sinais e quadros de aviso, procure por
indcios que apontem a cultura da organizao. Ex: Segurana
em 1o Lugar.
Finalmente, ao analisar manuais e polticas organizacionais,
procure identificar como as coisas devem funcionar, como as
metas estratgicas da organizao devem ser atingidas e
verifique se estes passos esto sendo seguidos ou no.
Tanto na anlise de dados qualitativos quanto de dados
quantitativos, procure observar no s os documentos
correntes, mas tambm documentos arquivados.
Entrevistas
Uma entrevista de levantamento de informaes uma
conversa direcionada com um propsito especfico, que utiliza
um formato pergunta-resposta. Os objetivos de uma
entrevista incluem:
obter as opinies do entrevistado, o que ajuda na descoberta dos
problemas-chave a serem tratados;
conhecer os sentimentos do entrevistado sobre o estado corrente do
sistema;
obter metas organizacionais e pessoais; e
levantar procedimentos informais.
Entrevista x Investigao
Fatos obtidos em uma investigao podem explicar o
desempenho passado.
Metas projetam o futuro. Entrevistas so importantes para se
determinar metas.
O Processo de uma Entrevista
Em uma entrevista, o engenheiro de software est,
provavelmente, estabelecendo um relacionamento com uma
pessoa estranha a ele.
Portanto, importante que ele:
construa, rapidamente, uma base de confiana e entendimento;
mantenha o controle da entrevista;
venda a ideia do sistema, provendo ao entrevistado as
informaes necessrias.
Uma entrevista envolve as seguintes etapas principais:
(a) planejamento,
(b) conduo e
(c) elaborao de um relatrio da entrevista.
Planejamento
O planejamento de uma entrevista envolve os seguintes
passos:
1. Estudar material existente sobre os entrevistados e suas
organizaes. Procure dar ateno especial linguagem usada pelos
membros da organizao, procurando estabelecer um vocabulrio
comum a ser usado na elaborao das questes da entrevista. Este
passo visa, sobretudo, otimizar o tempo despendido nas entrevistas,
evitando-se perguntar questes bsicas e gerais.
2. Estabelecer objetivos. De maneira geral, h algumas reas sobre as
quais um engenheiro de software desejar fazer perguntas relativas
ao processamento de informao e ao comportamento na tomada
de deciso, tais como fontes de informao, formatos da informao,
frequncia na tomada de deciso, estilo da tomada de deciso, etc.
3. Decidir quem entrevistar. importante incluir na lista de
entrevistados pessoas chave de todos os nveis da organizao
afetados pelo sistema. A pessoa de contato na organizao pode
ajudar nesta seleo. Quando necessrio, use amostragem.
4. Preparar a entrevista. Uma entrevista deve ser marcada com
antecedncia e deve ter uma durao entre 45 minutos e uma hora.
5. Decidir sobre os tipos de questes e a estrutura da entrevista. O
uso de tcnicas apropriadas de questionamento o corao de
uma entrevista.
6. Decidir como registrar a entrevista. Entrevistas devem ser
registradas para que informaes obtidas no sejam perdidas logo
em seguida. Os meios mais naturais de se registrar uma entrevista
incluem anotaes e o uso de gravador.
Tipos de Questes
Questes podem ser de trs tipos bsicos:
Questes subjetivas: permitem respostas abertas. Ex: O que voc
acha de ...? Explique como voc ...?
Vantagens:
Provem riqueza de detalhes.
Revelam novos questionamentos.
Colocam o entrevistado a vontade.
Permitem maior espontaneidade.
Desvantagens:
Podem resultar em muitos detalhes irrelevantes.
Perda do controle da entrevista.
Respostas muito longas para se obter pouca informao til.
Podem dar a impresso de que o entrevistador est perdido, sem
objetivo.
Questes objetivas: limitam as respostas possveis. Ex: Quantos ...?
Quem ...? Quanto tempo ...? Qual das seguintes informaes ...?
Vantagens:
Ganho de tempo, uma vez que vo direto ao ponto em questo.
Mantm o controle da entrevista.
Levam a dados relevantes.
Desvantagens:
Podem ser maantes para o entrevistado.
Podem falhar na obteno de detalhes importantes.
No constroem uma afinidade entre entrevistador e entrevistado.
Questes de aprofundamento: permitem explorar os detalhes de
uma questo. Podem ser subjetivas ou objetivas. Ex: Por que? Voc
poderia dar um exemplo? Como isto acontece?
Problemas na Elaborao de Questes
Questes capciosas: tendem a levar o entrevistado a responder de
uma forma especfica, isto , so tendenciosas. Ex: Sobre este
assunto, voc est de acordo com os outros diretores, no est?
Opo mais adequada: O que voc pensa sobre este assunto?
Duas questes em uma: O entrevistado pode responder a apenas uma delas, ou
pode se confundir em relao pergunta que est respondendo. Ex: O que voc
faz nesta situao e como?
Estrutura da Entrevista
Diz respeito organizao das questes em uma sequncia
lgica. H 4 formas de se estabelecer a sequncia das questes:
Entrevista No Estruturada: No h uma definio da
sequncia das questes. De acordo com o andar da entrevista,
caminhos possveis so avaliados e a sequncia estabelecida.
Requer mais tempo.
Vale ressaltar que, ainda que a sequncia das questes no
seja definida a priori, as questes devem ser definidas
antecipadamente, ou seja, o planejamento necessrio.
Registro da Entrevista
importante registrar os principais aspectos de uma entrevista
durante a sua realizao. No planejamento, deve-se definir
como isto ser feito. H duas formas principais, cujas vantagens
e desvantagens so apresentadas a seguir:
Gravador: requer a permisso do entrevistado.
Vantagens:
Registro completo da entrevista.
Rapidez e melhor desenvolvimento.
Reproduo para outros membros da equipe.
Desvantagens:
Pode deixar o entrevistado pouco a vontade.
Pode deixar o entrevistador distrado.
Pode haver necessidade de transcrever a fita.
Anotaes
Vantagens:
Mantm o entrevistador alerta.
Pode ser usado para fornecer um roteiro para a entrevista.
Mostra interesse e preparao do entrevistador.
Desvantagens:
Perda do andamento da conversa.
Excessiva ateno a fatos e pouca a sentimentos e opinies.
Conduo da Entrevista
Um dia antes, entre em contato com o entrevistado para
confirmar o horrio e o local da entrevista.
Chegue um pouco antes do horrio marcado.
Apresente-se e esboce brevemente os objetivos da entrevista.
Relembre o entrevistado de que voc estar registrando
pontos importantes. Se for usar gravador, coloque-o em local
visvel.
Diga ao entrevistado o que ser feito com as informaes
coletadas e reassegure seu aspecto confidencial.
A entrevista deve durar entre 45 minutos e uma hora.
Quando estiver incerto sobre uma questo, pea para o
entrevistado dar definies ou outros esclarecimentos. Use
questes de aprofundamento.
Ao trmino da entrevista, pergunte se h algo mais sobre o
assunto que o entrevistado ache importante voc saber.
Faa um resumo da entrevista e d suas impresses globais.
Informe o entrevistado sobre os passos seguintes.
Pergunte se h outra pessoa com a qual voc deveria
conversar.
Quando for o caso, marque nova entrevista.
Relatrio da Entrevista
O relatrio ou ata da entrevista deve capturar a essncia da
entrevista. Escreva o relatrio to rpido quanto possvel para
assegurar qualidade.
Registre entrevistado, entrevistador, data, assunto e objetivos.
Diga se os objetivos foram alcanados e aponte objetivos para
entrevistas futuras. Registre, ainda, os pontos principais da
entrevista e sua opinio.
Questionrios
O uso de questionrios constitui uma tcnica de levantamento
de informaes que permite ao engenheiro de software obter
de vrias pessoas afetadas pelo sistema (corrente ou proposto)
informaes, tais como:
Posturas: o que as pessoas na organizao dizem querer;
Crenas: o que as pessoas pensam ser realmente verdade;
Comportamento: o que as pessoas fazem;
Caractersticas: propriedades de pessoas ou coisas.
Um questionrio pode ter objetivos distintos, em funo de
sua aplicao, tais como:
Procurar quantificar o que foi levantado em entrevistas.
Determinar como um sentimento (expresso em uma entrevista)
realmente difundido ou limitado.
Examinar uma grande amostra de usurios do sistema para sentir
problemas ou levantar questes importantes, antes de se programar
entrevistas.

H muitas similaridades entre estas duas tcnicas. De fato,
pode ser til utilizar as duas abordagens em conjunto:
procurando refinar respostas no claras de um questionrio em uma
entrevista;
projetando um questionrio com base no que foi levantado em uma
entrevista.
Questionrios: Quando Usar?
As pessoas esto espalhadas por toda a organizao.
H um grande nmero de pessoas envolvidas no projeto do sistema
e necessrio saber que proporo de um dado grupo aprova ou
desaprova uma particular caracterstica do sistema proposto.
Em estudos exploratrios, quando se deseja saber uma opinio
global antes de se definir qualquer direo especfica para o projeto.
Etapas do Processo de Uso de Questionrios
Assim como as entrevistas, para se empregar questionrios,
um conjunto de passos deve ser realizado, envolvendo pelo
menos planejamento, aplicao e anlise.

Planejamento
No planejamento de um questionrio, devem ser levados em
considerao aspectos relacionados com a redao das
questes, escalas, formato e ordem das questes.
Redao das Questes
Uma vez que questionrios e entrevistas seguem uma
abordagem pergunta-resposta, seria bastante razovel pensar
que a consideraes feitas para entrevistas aplicam-se tambm
para questionrios. Contudo, importante ressaltar que h
diferenas fundamentais entre estas tcnicas e, portanto, novos
aspectos devem ser considerados.
Em primeiro lugar, entrevistas permitem interao direta com
o entrevistado a respeito das questes e seus significados.
Em uma entrevista, o engenheiro de software pode refinar
uma questo, definir um termo obscuro, alterar o curso do
questionamento e controlar o contexto de modo geral. Isto no
necessariamente verdade para um questionrio e, portanto, o
planejamento de um questionrio e de suas questes deve ser
mais cuidadoso.

Um questionrio deve:
ter questes claras e no ambguas,
ter fluxo bem definido,
ter administrao planejada em detalhes, e
levantar, antecipadamente, as dvidas das pessoas que iro
respond-lo.

Questes Subjetivas
Quando for utilizar questes subjetivas em um questionrio,
antecipe o tipo de resposta que voc espera obter.
Estas questes devem ser restritas o suficiente para guiar as
pessoas, de modo que respondam de uma maneira especfica.
Tome cuidado com perguntas que permitam respostas muito
amplas, pois isto pode dificultar a comparao e a
interpretao dos resultados.
Questes subjetivas devem ser usadas em questionrios para
levantar opinies sobre algum aspecto do sistema ou em
situaes exploratrias.
Questes Objetivas
Questes objetivas devem ser utilizadas em um questionrio:
quando o engenheiro de software capaz de listar as possveis
respostas ou
para examinar uma grande amostra de pessoas.
Respostas a questes objetivas podem ser mais facilmente
quantificadas. Respostas a questes subjetivas so analisadas e
interpretadas de maneira diferente. A tabela a seguir compara
o uso de questes objetivas e subjetivas em questionrios.
Linguagem Utilizada: Diretrizes
Sempre que possvel, use o vocabulrio das pessoas que iro
responder. Prime pela simplicidade.
Utilize perguntas simples e curtas.
Evite redao tendenciosa.
Garanta que as questes esto tecnicamente precisas antes de
inclui-las no questionrio.
Para verificar a linguagem utilizada, aplique o questionrio
antecipadamente em um grupo piloto, pedindo ateno
adequabilidade dos termos empregados.
Escalas
So usadas para medir um atributo ou caracterstica. A razo
para se utilizar escalas permitir medio ou julgamento.
Escalas so geralmente arbitrrias e podem no ser nicas, por
exemplo, temperatura:
o
C,
o
F, K.
H quatro tipos bsicos de escalas: nominal, ordinal, de
intervalo e de razo.
Tipos de Escala: Quando usar?
de Razo: os intervalos so iguais e h um zero absoluto.
de Intervalo: os intervalos so iguais, mas no h um zero absoluto.
Ordinria: no possvel assumir que os intervalos so iguais, mas as
classes podem ser colocadas em uma ordem.
Nominal: deseja-se classificar coisas, mas estas no podem ser
ordenadas.
Problemas na Construo de Escalas
Lenidade: a pessoa responde a todas as questes do mesmo jeito.
Soluo: mover a categoria para a esquerda ou direita.
Tendncia Central: a pessoa responde tudo na mdia. Soluo:
criar uma escala com mais pontos, ajustar os descritores ou tornar as
diferenas menores nos extremos.
Efeito Aurola: a impresso formada em uma questo levada
para outra.

Soluo: mesclar questes sobre objetos diferentes.
Projeto do Questionrio
Estilo
Um formulrio bem projetado (aspectos de estilo) pode
aumentar taxa de respostas. As seguintes diretrizes podem ser
teis na hora de se projetar um questionrio:
Deixe amplos espaos em branco para atrair as pessoas.
Deixe espao suficiente para as respostas das questes subjetivas.
Em questes com escala, pea para fazer um crculo na resposta.
Use os objetivos do questionrio para ajudar a determinar o formato
(inclusive instrues).
Seja consistente no estilo. Coloque instrues sempre no mesmo
local em relao ao leiaute do questionrio, para facilitar a
localizao das instrues. Use letras maisculas e minsculas nas
perguntas e apenas letras maisculas nas respostas.

Ordem das Questes
Para ordenar as questes, considere os objetivos e, ento,
determine a funo de cada questo para atingir esses
objetivos.
Use um grupo piloto para auxiliar ou observe o questionrio
com olhos de respondedor.
Algumas orientaes devem ser seguidas:
As primeiras questes devem ser de interesse dos respondedores.
Agrupe itens de contedo similar e observe tendncias de
associao.
Coloque os itens de menor controvrsia primeiro.
Aplicao do Questionrio
A primeira questo a ser definida : quem deve responder o
questionrio?
A deciso de quem deve responder o questionrio feita em
conjunto com o estabelecimento dos seus objetivos.
Quando houver muitas pessoas aptas a responder o
questionrio, use amostragem.
Mtodos de Aplicao
Reunir todos os respondedores em um mesmo local para a aplicao
do questionrio.
Vantagens:
100% de retorno
Instrues uniformes
Resultado rpido
Problemas:
Pode ser difcil reunir todas as pessoas.
O respondedor pode ter coisas importantes a fazer.
Analista entrega e recolhe cada questionrio individualmente.
Vantagens:
Boa taxa de resposta
Problemas:
Desperdcio do tempo do analista.
O respondedor pode ser identificado.
Respondedor administra o questionrio.
Vantagens:
Anonimato garantido.
Respostas mais reais.
Problemas:
Taxa menor de respostas. Este problema pode ser minimizado,
mantendo-se uma lista de respondedores e controlando a
devoluo.
Por correspondncia. til somente para alcanar pessoas
distribudas geograficamente.
Observao:
Observar o comportamento e o ambiente do indivduo que
toma decises pode ser uma forma bastante eficaz de levantar
informaes que, tipicamente, passam desapercebidas usando
outras tcnicas.
Tomadas de deciso ocorrem em diversos nveis da
organizao: operacional, gerencial e estratgico e, portanto,
importante observ-las em todos os nveis que tenham
interao com o sistema.
Atravs da observao possvel capturar:
o que realmente feito e no apenas o que documentado ou
explicado.
o relacionamento entre o tomador de deciso e outros membros
da organizao.
A observao usada para:
obter informaes sobre o tomador de deciso e seu ambiente,
que no so capturadas por outras tcnicas.
confirmar ou negar informaes de entrevistas e/ou questionrios.
Alguns pontos importantes devem ser realados: o analista
deve saber o que observar, quem observar, quando, onde,
porque e como.
Observao do Comportamento
Permite observar como um gerente obtm, processa, compartilha e
usa a informao para executar seu trabalho.
No planejamento da observao do comportamento, o
seguintes passos devem ser realizados:
1. Decidir o que observar (atividades).
2. Decidir em que nvel de detalhe a atividade deve ser
observada.
3. Preparar material para a observao.
4. Decidir quando observar
Amostragem de Horrios: perodos para observao
escolhidos aleatoriamente. Evita tendncias, mas no permite a
observao completa de um evento e to pouco de um evento
pouco frequente.
Amostragem de Eventos: observao de eventos completos.

O ideal combinar estas duas abordagens.
A observao deve ser registrada. Para tal, na preparao do
material para a observao, as seguintes abordagens podem
ser empregadas:
Pares de adjetivos: estabelea pares de adjetivos que capturem
adequadamente o comportamento do indivduo durante a tomada
de deciso, tais como, decidido/indeciso, confidencial/no
confidencial etc.
Categorias: defina previamente categorias de atividades e durante a
observao anote sua ocorrncia ou no. Ex: O Gerente instrui
subordinados; questiona subordinados; l informao externa;
processa informaes.
Scripts: Para cada indivduo observado, escreva uma lista de
atividades por ele desempenhadas. O tomador de deciso o
ator, que observado atuando, isto , tomando decises.

Observao de Ambiente Fsico
O tomador de deciso influencia e influenciado pelo seu
meio fsico. A observao do ambiente fsico tem uma forte
analogia com a crtica de filmes.
Muitas vezes, possvel observar particularidades do
ambiente fsico que confirmam ou negam narrativas
encontradas em entrevistas e questionrios.
Uma forma sistemtica de se proceder uma observao do
ambiente fsico a chamada observao estruturada do
ambiente. Ela sistemtica porque prov uma abordagem
padro para anlise de elementos que influenciam a tomada de
deciso, permitindo que vrios engenheiros de software
utilizem uma mesma base.
Dentre os elementos a serem observados, destacam-se:
Localizao do escritrio em relao a outros escritrios: Escritrios
de fcil acesso tendem a aumentar a frequncia de interao e o
fluxo de mensagens informais. Grupos de escritrios encorajam o
compartilhamento de informaes.
Escritrios de difcil acesso tendem a aumentar a frequncia
de mensagens orientadas a tarefas.
Mveis e publicaes em geral: revelam necessidade de informao
interna ou externa.
Outros: vestimentas, equipamentos etc.
Prototipao
A prototipao uma tcnica valiosa para se obter
rapidamente informaes especficas sobre requisitos de
informao do usurio. Tipicamente, a prototipao permite
capturar os seguintes tipos de informao:
Reaes iniciais do usurio: Como o usurio se sente em relao ao
sistema em desenvolvimento? Reaes ao prottipo podem ser
obtidas atravs da observao, entrevistas, questionrio ou relatrio
de avaliao.
Sugestes do usurio para refinar ou alterar o prottipo: guiam o
engenheiro de software na direo de melhor atender as
necessidades dos usurios.
Inovaes: novas capacidades, no imaginadas antes da interao
com o prottipo.
Informaes para reviso de planos: estabelecer prioridades e
redirecionar planos.
Abordagens para a Prototipao
Prottipo no-operacional: apenas as interfaces de entrada e sada
so implementadas; o processamento propriamente dito no. til
para avaliar certos aspectos do sistema quando a codificao
requerida pela aplicao custosa e a noo bsica do que o
sistema pode ser transmitida pela anlise de suas entradas e sadas.
Prottipo arranjado s pressas: o prottipo possui toda a
funcionalidade do sistema final, mas no foi construdo com o devido
cuidado e, portanto, sua qualidade e desempenho so deficientes.
Prottipo primeiro de uma srie: um sistema piloto desenvolvido
para ser avaliado antes de ser distribudo. til quando o sistema ser
implantado em vrios locais diferentes.
Prottipo de caractersticas selecionadas: apenas parte das
caractersticas do sistema final so implementadas. O sistema vai
sendo construdo em partes: cada prottipo aprovado passa a ser
um mdulo do sistema.
Prototipao como Alternativa para o Ciclo de Vida no
Desenvolvimento de Sistemas
Quando um modelo de ciclo de vida clssico (sequencial
linear) utilizado, dependendo do tamanho do sistema, o
tempo requerido para completar o ciclo pode ser muito grande
e os requisitos dos usurios podem ser alterados, fazendo com
que o sistema entregue no satisfaa as necessidades dos
usurios.
Usando a prototipao como uma alternativa para o ciclo de
vida de desenvolvimento de um sistema, possvel capturar
mais rapidamente se os requisitos colocados sobre o software
esto em conformidade com o requerido pelos usurios.
De fato, a rigor, a abordagem de prottipo de caractersticas
selecionadas no deveria ser considerada prototipao, mas
sim parte da estratgia de um desenvolvimento incremental ou
evolutivo.
Contudo, as outras trs abordagens poderiam ser utilizadas
em um desenvolvimento com ciclo de vida com prototipao.

Decidindo quando e que tipo de Prototipao usar
Considerar:
Tipo do problema a ser resolvido (domnio do problema, tipo do
sistema)
Soluo a ser apresentada pelo sistema (tecnologia a ser empregada
domnio da soluo)
Novidade (em termos de tecnologia e do domnio do problema)
Complexidade (considerar clareza dos requisitos e tamanho do
sistema)
Diretrizes para o Desenvolvimento de um Prottipo
Trabalhe com mdulos gerenciveis: para fins de prototipao no
necessrio e muitas vezes, nem desejvel, construir um sistema
completo.
Construa o prottipo rapidamente: a construo de um prottipo na
fase de anlise e especificao de requisitos no pode consumir
tempo em demasia, caso contrrio perde sua finalidade. Para
acelerar a construo, use ferramentas adequadas.
Modifique o prottipo em iteraes sucessivas: o prottipo deve ser
alterado em direo s necessidades do usurio. Cada modificao
requer uma nova avaliao.
Enfatize a interface com o usurio: as interfaces do prottipo devem
permitir que o usurio interaja facilmente com o sistema. Um
mnimo de treinamento deve ser requerido. Sistemas interativos
com interfaces grficas so muito indicados prototipao.
Usurios na Prototipao
Usurios so fundamentais na prototipao. Para capturar as
reaes dos usurios em relao ao prottipo, outras tcnicas
de levantamento de informao devem ser usadas em
conjunto. Durante a experimentao do usurio com o
prottipo, utiliza-se a observao.
Para capturar opinies e sugestes, podem ser empregados,
alm da observao, entrevistas e questionrios.
Problemas da Prototipao
Gerncia do projeto: Normalmente, vrias iteraes so necessrias
para se refinar um prottipo. Sob esta tica, surge uma importante
questo: quando parar? Se esta questo no for tratada com
cuidado, a prototipao pode se estender indefinidamente.
importante, pois, delinear e seguir um plano para coletar, analisar e
interpretar as informaes de realimentao do usurio.
Considerar o prottipo como sendo o sistema final: a qualidade pode
no ter sido apropriadamente considerada.
Vantagens da Prototipao
Permite alterar o sistema mais cedo no desenvolvimento,
adequando-o mais de perto s necessidades do usurio (menor
custo de uma alterao).
Permite descartar um sistema quando este se mostrar inadequado
(prottipo de viabilidade).
Possibilidade de desenvolver um sistema que atenda mais de perto
as necessidades e expectativas dos usurios. Permite uma interao
com o usurio ao longo de todo o ciclo de vida do desenvolvimento.
Atividade Prtica

em Campo: Fazer o levantamento de requisitos para a
elaborao de um sistema de informao que tenha por
objetivo automatizar:
Uma pizzaria XYZ OU
Uma farmcia ABC OU
Uma padaria WKY OU
Uma construtora RJZ OU
Um escritrio de advocacia FMI OU
Um consultrio odontolgico DNT OU
Uma funerria MRT OU
Uma clnica veterinria C&G

Grupo de at 4 componentes (ABNT)
Anlise Essencial
Introduo
A etapa de anlise e especificao de requisitos, geralmente
chamada de anlise de sistemas, um processo de
comunicao entre engenheiros de software (analistas de
sistemas) e os clientes/usurios do sistema, com o objetivo de
definir detalhadamente o propsito e os requisitos de um
produto de software.
Os requisitos de um sistema compreendem o conjunto de
caractersticas que o sistema deve possuir para atingir seu
propsito.
Anlise Essencial
A anlise de sistemas um processo de transmisso de
conhecimento e, assim sendo, envolve trs etapas:
aprendizado: aprender sobre o domnio do problema onde o sistema
ser inserido;
estruturao e representao dos requisitos do sistema: consiste na
modelagem do sistema propriamente dita;
validao dos requisitos com o usurio.
Anlise Essencial
Ao longo do processo, o analista enfrenta o desafio de lidar
com a complexidade, isto , situaes complexas do mundo
real devem ser entendidas e representadas de forma simples,
para facilitar a compreenso e validao.
Para tal, preciso delimitar a rea de estudo, subdividir o todo
complexo em partes inteligveis e gerenciveis, extrair as
caractersticas essenciais da realidade e modelar essas
caractersticas para mostrar o relacionamento entre seus
componentes.
Anlise Essencial
A anlise de sistemas , em ltima instncia, uma atividade de
construo de modelos.
Um modelo uma representao de alguma coisa do mundo
real, uma abstrao da realidade, ou seja, representa uma
seleo de caractersticas do mundo real, que so relevantes
para o propsito com o qual o modelo foi construdo.
Anlise Essencial
Modelos so ferramentas fundamentais no desenvolvimento
de sistemas. Sistemas so modelados para:
possibilitar o estudo do comportamento do sistema;
facilitar a comunicao entre os componentes da equipe de
desenvolvimento (e clientes e usurios);
possibilitar a discusso de correes e modificaes com o usurio;
formar uma documentao do sistema.
Um modelo enfatiza um conjunto de caractersticas da
realidade, que corresponde dimenso do modelo.
Anlise Essencial
Alm da dimenso que um modelo enfatiza, modelos possuem
nveis de abstrao.
O nvel de abstrao de um modelo diz respeito ao grau de
detalhamento com que as caractersticas do sistema so
representadas.
Em cada nvel h uma nfase seletiva nos detalhes
representados.
Anlise Essencial
No caso dos sistemas de informao, geralmente, so
considerados trs nveis:
conceitual: considera caractersticas do sistema independentes do
ambiente computacional (hardware e software) no qual o sistema
ser implementado. Essas caractersticas so dependentes
unicamente das necessidades do usurio.
lgico: caractersticas dependentes de um determinado tipo de
sistema computacional. Essas caractersticas so, contudo,
independentes de produtos especficos.
Anlise Essencial
fsico: caractersticas dependentes de um sistema computacional
especfico, isto , uma linguagem e um compilador especfico, um
sistema gerenciador de bancos de dados especfico, o hardware de
um determinado fabricante etc.
Nas primeiras etapas do processo de desenvolvimento
(levantamento de requisitos e anlise), o engenheiro de
software representa o sistema atravs de modelos conceituais.
Nas etapas posteriores, as caractersticas lgicas e fsicas so
representadas em novos modelos.
Anlise Essencial
O mtodo de Anlise Essencial de Sistemas preconiza que, de
uma forma geral, um sistema deve ser modelado atravs de
trs dimenses:
dados: diz respeito aos aspectos estticos e estruturais do sistema;
controle: leva em conta aspectos temporais e comportamentais do
sistema;
funes: considera a transformao de valores.
Anlise Essencial
Em relao ao grau de abstrao, a Anlise Essencial considera
dois nveis: o nvel essencial e o nvel de implementao,
representados, respectivamente, pelos seguintes modelos:
Modelo Essencial: representa o sistema num grau de
abstrao completamente independente de restries
tecnolgicas.
Modelo de Implementao: passa a considerar as restries
tecnolgicas impostas pela plataforma de hardware e software
a ser utilizada para implementar o sistema.
Anlise Essencial
Podemos perceber que o modelo de implementao no
corresponde a um modelo de anlise propriamente dito, uma
vez que considera aspectos de implementao, caracterstica
marcante da fase de projeto.
De fato, na abordagem da Anlise Essencial, este modelo
corresponde a uma espcie de zona nebulosa entre as fases de
anlise e de projeto. Por considerarmos que um modelo
considerando aspectos da plataforma de implementao
melhor caracterizado na fase de projeto, neste texto, no
trataremos do modelo de implementao.
Anlise Essencial
De acordo com Pompilho (2002) os conceitos introduzidos
pelo mtodo de Anlise Essencial endereavam inicialmente as
duas principais dificuldades que os analistas enfrentavam com
a aplicao da Anlise Estruturada: a distino entre requisitos
lgicos e fsicos, e a ausncia de uma abordagem para
particionar o sistema em partes to independentes quanto
possvel, de modo a facilitar o processo de anlise.
Anlise Essencial
Durante muito tempo, houve grandes debates entre os
profissionais de desenvolvimento de sistemas sobre por qual
perspectiva se deveria comear a especificao de um sistema:
pelos dados ou pelas funes?
Os argumentos, igualmente vlidos, exploravam consideraes
como:
dados so mais estveis que funes...,
sem um entendimento das funes a serem desempenhadas pelo
sistema, como definir o escopo e os dados necessrios?
Anlise Essencial
A Anlise Essencial procurou estabelecer um novo ponto de
partida para a especificao de um sistema: a identificao dos
eventos que o afetam.
Um dos problemas mais relevantes na especificao como
efetuar seu particionamento.
A Anlise Estruturada prope um particionamento atravs de
uma abordagem top-down
Anlise Essencial
Embora esta seja uma boa maneira de se atacar um problema
complexo, na prtica, esta abordagem no se mostrou eficiente
como estratgia de projeto para a decomposio de sistemas.
A Anlise Essencial prope uma outra forma de
particionamento, a qual baseada nos eventos, e que tem
demonstrado ser mais efetiva do que a abordagem top-down,
pois torna mais fcil a identificao das funes e entidades
que compem o sistema.
Anlise Essencial
A Anlise Essencial de Sistemas, atravs da tcnica de
particionamento por eventos, oferece uma boa estratgia para
modelar o comportamento do sistema, visando satisfazer os
requisitos do usurio, pressupondo-se que dispomos de
tecnologia perfeita e que ela pode ser obtida a custo zero,
conforme afirma Xavier (2005).
Apesar de introduzir novos conceitos e novas abordagens, a
Anlise Essencial preservou todos os modelos da Anlise
Estruturada.
Anlise Essencial
De fato, embora diferentes, a melhor maneira de encarar a
Anlise Essencial consider-la uma evoluo da Anlise
Estruturada. A seguir, os principais conceitos da Anlise
Essencial so apresentados.
Tecnologia Perfeita
Durante a fase de anlise, o analista deve abstrair-se da
tecnologia que dever ser utilizada na implementao do
sistema.
Anlise Essencial
Para orientar essa abstrao, a Anlise Estruturada recomenda
que o analista, durante a fase de anlise, concentre-se apenas
nos aspectos lgicos do sistema, evitando pensar nos aspectos
fsicos. O problema dessa abordagem que a diferena entre
aspectos lgicos e fsicos no clara.
Partindo do princpio que os aspectos fsicos de um sistema
esto ligados tecnologia de implementao, a Anlise
Essencial emprega uma abstrao de uma tecnologia de
implementao, denominada tecnologia perfeita, para facilitar
a tarefa de identificar os detalhes lgicos do sistema.
Anlise Essencial
A tecnologia perfeita no possui limitaes, isto , existe um
processador perfeito, capaz de executar qualquer
processamento, tudo instantaneamente, sem qualquer custo,
sem consumir energia, sem gerar calor, sem jamais cometer
erros ou parar de funcionar, e um repositrio perfeito, capaz de
armazenar quantidades infinitas de dados e de ser acessado
instantaneamente por qualquer processador, da forma que for
mais conveniente.
Naturalmente, no existe uma tecnologia de implementao
com tais caractersticas.
Anlise Essencial
Ento, qual a utilidade dessa abstrao?
Quando o analista pensa em aspectos fsicos, ele est, na
verdade, tentando identificar (e resolver) as limitaes de uma
determinada tecnologia. Pensamentos tpicos do gnero so:
quanto de espao em disco vou precisar? qual o melhor mtodo de
acesso aos dados, considerando as funes do sistema? que
capacidade de processamento devo necessitar? Contudo, nenhuma
dessas preocupaes so prprias da fase de anlise.
Anlise Essencial
Considerando agora que a tecnologia que ser utilizada na
implementao do sistema perfeita, todas as perguntas
anteriores deixam de ter importncia, isto , no preocupam
mais o analista.
Portanto, para distinguir um requisito lgico de um requisito
fsico, utilizando a abstrao de tecnologia perfeita, formule a
seguinte pergunta ao identificar um requisito qualquer: Para
atender ao seu propsito, o sistema necessitar possuir essa
capacidade ou essa caracterstica, mesmo considerando que
ele ser implementado em uma tecnologia perfeita?
Anlise Essencial
Se a resposta for sim, esse requisito verdadeiro e deve ser
modelado.
O analista de sistemas deve deter-se ao foco de negcio da
organizao contratante, pois o sistema que ele ir modelar
dever estar de acordo com o escopo do projeto que,
certamente, apontar, no s os requisitos do futuro sistema,
mas tambm para o objetivo organizacional da instituio.
Anlise Essencial
Requisito Verdadeiro e Requisito Falso
Uma caracterstica ou capacidade que um sistema deve
possuir para atender ao seu propsito, mesmo considerando
que ser implementado em uma tecnologia perfeita, dita um
requisito verdadeiro. O conjunto de requisitos verdadeiros
compreende a essncia do sistema.
Um requisito falso, por outro lado, uma capacidade ou
caracterstica que o sistema no precisa possuir para atender
ao seu propsito, caso ele disponha de uma tecnologia de
implementao perfeita.
Anlise Essencial
Evento e Resposta
Evento e resposta so nomes genricos de interaes entre o
ambiente externo e o sistema.
Um evento pode ser definido informalmente como um
acontecimento do mundo exterior que requer do sistema uma
resposta.
Corresponde a alguma mudana no ambiente externo que
funcionar como um estmulo para o sistema, isto , o sistema
deve responder a este estmulo para atender ao seu propsito.
Anlise Essencial
Uma resposta o resultado da execuo de um conjunto de
aes no sistema, como consequncia do reconhecimento pelo
sistema de que um evento ocorreu. Uma resposta tipicamente
pode ser:
um fluxo de dados saindo do sistema para uma entidade externa;
uma mudana de estado em um depsito de dados (incluso,
excluso ou alterao);
um fluxo de controle saindo de uma funo para ativar uma outra.
Quando um evento ocorre, produzido um estmulo para o
sistema.
Anlise Essencial
Ao receber o estmulo, o sistema compreende que o evento
ocorreu e ativa os processos necessrios para produzir a
resposta.
Os eventos so classificados em quatro tipos diferentes,
dependendo da maneira como ocorrem e da natureza do
estmulo que produzem:
Evento orientado por fluxo de dados: provocado por uma
entidade externa, a qual envia dados para o sistema.
Anlise Essencial
O estmulo produzido por esse tipo de evento a chegada de
um fluxo de dados que vai ativar uma funo.
Os eventos externos so nomeados da seguinte forma:
(Entidade externa que provocou o evento) + (ao verbo na voz
ativa) + (estmulo fluxo de dados enviado ao sistema)
Ex.:
Cliente envia pedido.
Cliente cancela pedido.
Anlise Essencial
Evento orientado por controle: o estmulo provocado por este
evento a chegada ao sistema de um fluxo de controle, o qual
apenas notifica o sistema da ocorrncia do evento.
Pode haver fluxos de dados complementares associados ao
evento, mas no atravs da chegada do fluxo de dados que o
sistema toma conhecimento da ocorrncia do evento.
Esse tipo de evento pode ser nomeado de duas maneiras,
tendo por base a origem do evento:
Anlise Essencial
Caso 1 Uma entidade externa envia um comando (fluxo de
controle) para o interior do sistema, ativando uma funo.
(Entidade externa que provocou o evento) + (ao verbo na voz
ativa) + (complemento)
Ex.:
Gerente solicita relao de clientes.
Diretoria autoriza o pagamento de uma fatura.
Anlise Essencial
Caso 2 Uma funo ativada por um fluxo de controle
oriundo de outra funo interna.
(Sujeito) + (ao verbo na voz passiva)
Ex.:
Nvel de reabastecimento do estoque de um produto atingido.

Evento temporal: aquele em que o estmulo a chegada ao
sistema da informao de haver passado um determinado
intervalo de tempo.
Anlise Essencial
Esses eventos estimulam as aes que o sistema tem de
executar em datas previamente conhecidas, isto ,
diariamente, mensalmente etc.

o tempo passa e chega o momento do sistema
fazer alguma coisa

Anlise Essencial
Pode haver fluxos de dados complementares associados ao
evento, mas no atravs da chegada destes que o sistema
toma conhecimento da ocorrncia do evento.
Os eventos temporais podem ser nomeados como abaixo:
( hora de) + (ao) + (complemento)
Ex.:
Mensalmente, emitir relatrio de vendas. ou
hora de emitir relatrio mensal de vendas.
Anlise Essencial
Independentemente dos tipos de eventos classificados pela
Anlise Essencial, devemos, a partir do levantamento de
requisitos, criar uma Lista de Eventos, com TODOS os possveis
eventos, independentemente de seu tipo, que faro parte
integrante do Sistema proposto.
LISTA DE EVENTOS
Cadastrar funcionrio
Cadastrar cliente
Locar veculo
Controlar pagamento
Anlise Essencial
Atividades Essenciais
So todas as tarefas que o sistema deve executar para atender
completamente ao seu propsito, mesmo considerando que ele
ser implementado em uma tecnologia perfeita.
Uma atividade essencial deve executar todo o conjunto de
aes necessrias para responder completamente a um e
somente um evento.
Anlise Essencial
As atividades essenciais subdividem-se em:
Atividades Fundamentais: produzem uma informao que
parte do propsito declarado do sistema. Assim sendo, o
propsito do sistema atendido pelas atividades
fundamentais, as quais produzem as respostas externas do
sistema.
Atividades Custodiais: criam e mantm a memria necessria
execuo das atividades fundamentais, adquirindo dados do
ambiente externo ao sistema e os armazenando nos depsitos
de dados.
Anlise Essencial
As respostas que so internas ao sistema so produzidas pelas
suas atividades custodiais.
Quando uma atividade executa tarefas dos dois tipos, ela
denominada atividade composta.
As atividades compostas produzem respostas internas e
externas.
Os diferentes tipos de atividade essencial esto representados
na figura a seguir:
Anlise Essencial

Como as atividades essenciais respondem completamente a
um e somente um evento, a comunicao entre elas ser feita
sempre via memria e nunca diretamente.
Anlise Essencial
Essa caracterstica da comunicao entre atividades essenciais
torna o particionamento por eventos uma abordagem
adequada para dividir o problema em partes independentes.

Memria Essencial
Consiste no conjunto mnimo de dados que deve ser
armazenado pelo sistema, para atender ao seu propsito,
considerando que ele ser implementado em uma tecnologia
perfeita.
Anlise Essencial
O modelo normalmente utilizado para modelar a memria
essencial o Modelo de Entidades e Relacionamentos (MER).
Nos DFDs, a memria essencial representada pelos
depsitos de dados.
Para derivar os depsitos de dados do DFD a partir do MER,
utilize a seguinte correspondncia: cada entidade e
relacionamento com atributos do MER ser um depsito de
dados do DFD.
Anlise Essencial
Para manter a abstrao da tecnologia perfeita consistente, os
depsitos de dados no armazenam chaves estrangeiras
(atributos determinantes transpostos entre entidades) para
representar um relacionamento entre entidades, pois essa
uma caracterstica especfica dos bancos de dados relacionais,
uma tecnologia nada perfeita.
Lembre-se que, na fase de anlise, a tecnologia de
implementao ainda no foi selecionada e deve ser
considerada perfeita.
Anlise Essencial
Para indicar que o relacionamento entre entidades existe, sem
no entanto definir como ele ser implementado, a
representao dos acessos das atividades de custdia
memria essencial deve obedecer seguinte regra geral: ao
criar ou excluir um relacionamento ou uma entidade que
participa de um relacionamento, mostre o acesso aos depsitos
de dados que correspondem ao relacionamento e s entidades
que participam do relacionamento.
A prxima figura mostra a representao grfica desses
acessos.
Anlise Essencial
Anlise Essencial
Especificao da Essncia do Sistema
A Anlise Essencial sugere a construo de dois modelos
principais, o modelo essencial e o modelo de implementao.
Conforme discutido anteriormente, entendemos que apenas o
modelo essencial deve ser objeto da fase de anlise e, assim,
discutiremos apenas a especificao da essncia do sistema.
Anlise Essencial
A especificao da essncia do sistema, produto da fase de
anlise, composta de dois modelos, como mostra a prxima
figura:
Modelo Ambiental: define a fronteira entre o sistema e o resto
do mundo.
Modelo Comportamental: define o comportamento das partes
internas do sistema necessrio para interagir com o ambiente.
Anlise Essencial
Anlise Essencial
Explorando o Modelo Ambiental
Representa o que o sistema deve fazer para atender ao
ambiente. composto dos seguintes produtos:
Propsito do Sistema: enuncia a finalidade do sistema. Pode ser
acompanhado de uma breve descrio do contexto do sistema (mini-
mundo).
Lista de Eventos: lista de eventos aos quais o sistema deve
responder. Deve conter, pelo menos, o nome do evento, o estmulo e
a resposta externa do sistema.
Anlise Essencial
Diagrama de Contexto: representa o sistema como um nico
processo e suas interaes com o ambiente. Pode ser acompanhado
de um dicionrio de dados.
A declarao de propsito (objetivos) do sistema deve ser
elaborada em poucas frases, simples e precisas, em linguagem
destituda de vocabulrio tcnico, de modo a ser entendida
pelos usurios do sistema e pela administrao da empresa, em
geral.
No deve fornecer detalhes sobre como o sistema dever
operar.
Anlise Essencial
A elaborao da lista de eventos o passo principal desta
etapa do desenvolvimento, uma vez que os eventos constituem
a parte fundamental de um sistema. De fato, o primeiro passo
na especificao de um sistema identificar a quais eventos do
mundo exterior ele dever ocorrer.
Uma vez definidos os eventos, possvel construir o Diagrama
de Contexto do sistema, mostrando como ele responde a todos
os eventos externos relevantes.
Finalmente, pode ser til elaborar uma descrio de como o
sistema responder a cada evento.
Anlise Essencial
Explorando o Modelo Comportamental
Representa o que o interior do sistema deve fazer para
atender ao ambiente. Deve conter os seguintes produtos:
Diagrama de Entidades e Relacionamentos
Diagramas de Fluxos de Dados Particionados por Eventos: Para
cada evento do sistema, deve ser construdo um DFD. Assim, a
quantidade de diagramas deve ser equivalente ao nmero de
eventos na lista.
Anlise Essencial
Diagramas de Transio de Estados: Representa o comportamento
das entidades e relacionamentos com atributos ao longo do tempo.
Ser construdo um DTE para cada entidade ou relacionamento com
atributo do DER que possuir comportamento significativo, isto ,
possuir mais de um estado ao longo de seu ciclo de vida.
Diagramas de Fluxos de Dados Organizados em Nveis
Hierrquicos:
representa os processos em nveis hierrquicos, a partir do diagrama
zero. Os processos do diagrama zero so obtidos atravs do
agrupamento de atividades essenciais dos DFDs particionados por
eventos. Um critrio de agrupamento bastante razovel considerar
o grau de coeso e acoplamento entre atividades essenciais.
Anlise Essencial
As seguintes heursticas podem ser utilizadas, em conjunto
ou em separado:
Procurar agrupar em um nico processo todas as atividades
essenciais que acessam um determinado depsito de dados,
verificando se o processo resultante desse agrupamento
adequado para representar uma das funes do sistema.
Agrupar todas as atividades de custdia referentes a um
mesmo depsito de dados.
Anlise Essencial
Procurar identificar uma funo do sistema, agrupando
atividades essenciais que interagem com uma mesma entidade
externa.
Representar no DFD-zero, um processo para cada uma das
funes do negcio.
Agrupar as atividades essenciais aos processo para os quais as
suas aes mais contribuem.
Anlise Essencial
Usando esta abordagem para a construo de diagramas
hierrquicos, adotamos uma estratgia middle-out (do meio
para fora), onde, a partir dos eventos, estabelecemos
atividades essenciais (meio) para depois agrup-las em nveis
superiores (para cima) e, em seguida, especific-las e, se
necessrio, explodi-las (para baixo).
Dicionrio de Dados: descreve os dados representados no
MER, nos DFDs e nos DTEs.
Anlise Essencial
Especificao da Lgica dos Processos: descreve a lgica dos
processos do DFD que no foram detalhados em diagramas de
nvel inferior (lgica dos processos primitivos).
Como podemos perceber, a Anlise Essencial faz uso
praticamente das mesmas tcnicas de modelagem da Anlise
Estruturada, a saber a Modelagem de Dados (utilizando
modelos de Entidades e Relacionamentos), a Modelagem
Funcional (utilizando Diagramas de Fluxo de Dados DFDs) e a
Modelagem de Controle (utilizando Diagramas de Transio de
Estados).
Anlise Essencial
Isso bastante natural, j que a Anlise Essencial , de fato,
uma extenso da Anlise Estruturada.
Anlise Essencial
Anlise Essencial
Modelagem Funcional
A partir deste momento, passaremos a nos preocupar com a
modelagem das funes que o sistema dever executar para
atender aos anseios dos usurios do sistema.
A tcnica mais difundida para esta finalidade a utilizao de
Diagramas de Fluxo de Dados - DFDs.
Um Diagrama de Fluxo de Dados, conforme proposto
originalmente, uma ferramenta top-down para modelagem
de processos.
Anlise Essencial
Representa um sistema como uma rede de processos
interligados entre si por fluxos de dados e depsitos de dados.
O DFD utiliza-se de quatro smbolos grficos, visando
representar os seguintes componentes: Processos, Fluxos de
Dados, Depsitos de Dados e Entidades Externas.
Atravs da utilizao desses quatro componentes, podemos
representar satisfatoriamente os processos e interaes entre
os elementos de um sistema.
Anlise Essencial
Anlise Essencial
Um DFD mostra as fronteiras do sistema: aquilo que no for
uma Entidade Externa, ser interno ao sistema, delimitando
assim a abrangncia do sistema. uma ferramenta
particularmente til para a modelagem de sistemas por
mostrar todas as relaes entre dados (armazenados e que
fluem no sistema) e os processos que manipulam e
transformam esses dados.
Devemos lembrar que esta uma tcnica de modelagem
conceitual e, portanto, no deve estar presa a nenhuma
plataforma computacional de implementao.
Anlise Essencial
Processos
Representam as transformaes e manipulaes feitas sobre
os dados em um sistema e correspondem a procedimentos ou
funes que um sistema tem de prover.
A ocorrncia de um evento de um dos seguintes tipos deve
ser representada como um processo em um DFD:
Anlise Essencial
Anlise Essencial
Um processo representado por um crculo, com uma
sentena simples (verbo + objetos) em seu interior e,
opcionalmente, um identificador (nmero).
A sentena deve tentar descrever o melhor possvel a funo a
ser desempenhada, sem ambiguidades.
Devem ser evitados nomes muito fsicos (p. ex., gravar,
imprimir, ...) ou muito tcnicos (p. ex., apagar, fazer backup, ...) .
Os processos representados em um DFD no precisam ser
necessariamente funes a serem informatizadas.
Anlise Essencial
Muitas vezes, para se prover um entendimento mais completo
do sistema, processos manuais ou mistos (parte manual, parte
informatizada) so representados.

Fluxos de Dados
Fluxos de dados so utilizados para representar a
movimentao de dados atravs do sistema.
Anlise Essencial
So simbolizados por setas, que identificam a direo do fluxo,
e devem ter associado um nome o mais significativo possvel,
de modo a facilitar a validao do diagrama com os usurios.
Esse nome deve ser um substantivo que facilite a identificao
do dado (ou pacote de dados) transportado.
Um fluxo de dado em um DFD pode ser considerado como um
caminho atravs do qual podero passar uma ou mais
estruturas de dados em tempo no especificado.
Anlise Essencial
Anlise Essencial
Depsitos de Dados
Depsitos de dados so pontos de reteno permanente ou
temporria de dados, que permitem a integrao entre
processos assncronos, isto , processos realizados em tempos
distintos. Sem nos comprometermos quanto ao aspecto fsico,
representam um local de armazenamento de dados entre
processos.
Um depsito de dados representado por um retngulo sem a
linha lateral direita, com um nome e um identificador
(opcional) em seu interior.
Anlise Essencial
Um depsito de dados no se altera quando um pacote de
informao sai dele atravs de um fluxo de dados. Por outro
lado, um fluxo para um depsito representa uma das seguintes
aes:
uma incluso, isto , um ou mais novos pacotes de informao esto
sendo introduzidos no depsito;
uma atualizao, ou seja, um ou mais pacotes esto sendo
modificados, sendo que isso pode envolver a alterao de todo um
pacote, ou apenas de parte dele;
uma excluso, isto , pacotes de informao esto sendo removidos
do depsito.
Anlise Essencial
Anlise Essencial
Entidades Externas
Entidades externas ou terminadores so fontes ou destinos de
dados do sistema.
Representam os elementos do ambiente com os quais o
sistema se comunica. Tipicamente, uma entidade externa
uma pessoa (p.ex. um cliente), um grupo de pessoas (p. ex. um
departamento da empresa ou outras instituies) ou um outro
sistema que interaja com o sistema em questo. Uma entidade
externa deve ser identificada por um nome e representada por
um retngulo.
Anlise Essencial

Uma vez que os terminadores so externos ao sistema, os
fluxos de dados que os interligam aos diversos processos
representam a interface entre o sistema e o mundo externo.
Anlise Essencial
Exemplo 1 de Diagrama de Fluxo de Dados
Anlise Essencial
Exemplo 2 de Diagrama de Fluxo de Dados
Anlise Essencial
Exemplo 1 de Diagrama de Contexto
Anlise Essencial
Exemplo 2 de Diagrama de Contexto
Anlise Essencial
Exemplo Diagrama Entidade-Relacionamento
Anlise Essencial
Exerccio de Fixao:
Escolha um tema de trabalho para, a partir de um mini-
mundo, fazer o levantamento de requisitos do sistema
proposto, buscando modelar o que se pede:
Lista de Eventos
Diagrama de Contexto
Diagrama de Fluxo de Dados particionado por evento
Diagrama Entidade-Relacionamento

Aulas de Análise de Sistemas PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aulas de Análise de Sistemas PDF

Transféré par

Droits d'auteur :

Formats disponibles

Prof. ALFREDO BOENTE, PhD.

Vous aimerez peut-être aussi