ANÁLISE E PROJETO DE SISTEMAS
Sumário
1.
A NATUREZA DOS SISTEMAS......................................................................................................................................................3
1.1. DEFINIÇÃO DE SISTEMAS ...............................................................................................................................................................3
1.2. SISTEMAS NATURAIS ......................................................................................................................................................................3
1.3. SISTEMAS FÍSICOS ..........................................................................................................................................................................3
1.4. SISTEMAS VIVOS ............................................................................................................................................................................3
1.5. SISTEMAS FEITOS PELO HOMEM .....................................................................................................................................................4
1.6. SISTEMAS AUTOMATIZADOS ..........................................................................................................................................................4
1.6.1.
COMPONENTES DE UM SISTEMA AUTOMATIZADO ......................................................................................................................4
1.6.2.
TIPOS DE SISTEMAS AUTOMATIZADOS........................................................................................................................................5
1.6.2.1.
SISTEMAS ON-LINE.................................................................................................................................................................5
1.6.2.2.
SISTEMAS DE TEMPO REAL .....................................................................................................................................................5
1.6.2.3.
SISTEMAS DE APOIO À DECISÃO .............................................................................................................................................6
1.6.2.4.
SISTEMAS DE PLANEJAMENTO ESTRATÉGICO .........................................................................................................................6
1.6.2.5.
SISTEMAS BASEADOS NO CONHECIMENTO .............................................................................................................................6
1.6.2.6.
DATA WAREHOUSE ................................................................................................................................................................6
2.
O ANALISTA DE SISTEMAS ..........................................................................................................................................................8
2.1.
3.
CARACTERÍSTICAS DO ANALISTA DE SISTEMAS..............................................................................................................................8
O QUE É ANÁLISE? .........................................................................................................................................................................9
3.1. A ANÁLISE DE SISTEMAS CLÁSSICA ................................................................................................................................................9
3.2. A PASSAGEM PARA ANÁLISE ESTRUTURADA ..................................................................................................................................9
3.3. A ANÁLISE ESTRUTURADA ...........................................................................................................................................................10
3.3.1.
OBJETIVOS DA ANÁLISE ESTRUTURADA ...................................................................................................................................10
3.3.2.
CARACTERÍSTICAS DA ANÁLISE ESTRUTURADA .......................................................................................................................10
4.
METODOLOGIA - VISÃO GERAL..............................................................................................................................................11
4.1. OBJETIVOS DA METODOLOGIA .....................................................................................................................................................11
4.2. PROPOSTAS DA METODOLOGIA ESTRUTURADA ............................................................................................................................11
4.2.1.
CARACTERÍSTICAS DA METODOLOGIA ESTRUTURADA .............................................................................................................12
5.
CICLO DE VIDA DO PROJETO ESTRUTURADO ...................................................................................................................13
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
5.8.
5.9.
6.
O USUÁRIO......................................................................................................................................................................................18
6.1.
6.2.
6.3.
6.4.
6.5.
6.5.1.
6.5.2.
6.5.3.
7.
A CLASSIFICAÇÃO DOS USUÁRIOS POR TIPO DE FUNÇÃO ..............................................................................................................18
USUÁRIOS OPERATIVOS: ..............................................................................................................................................................18
USUÁRIOS SUPERVISORES: ...........................................................................................................................................................19
USUÁRIOS EXECUTIVOS: ..............................................................................................................................................................20
A CLASSIFICAÇÃO DOS USUÁRIOS POR NÍVEL DE EXPERIÊNCIA ..................................................................................................21
USUÁRIOS AMADORES:............................................................................................................................................................21
USUÁRIOS NOVATOS: ..............................................................................................................................................................21
USUÁRIOS PERITOS:.................................................................................................................................................................21
TÉCNICAS DE ENTREVISTAS E DE COLETADEDADOS.................................................................................................................22
7.1.
7.2.
7.3.
7.4.
8.
ATIVIDADE 1: LEVANTAMENTO ...................................................................................................................................................13
ATIVIDADE 2: ANÁLISE DE SISTEMAS ..........................................................................................................................................14
ATIVIDADE 3: PROJETO................................................................................................................................................................14
ATIVIDADE 4: IMPLEMENTAÇÃO ..................................................................................................................................................14
ATIVIDADE 5: GERAÇÃO DE TESTES.............................................................................................................................................14
ATIVIDADE 6: CONTROLE DE QUALIDADE....................................................................................................................................14
ATIVIDADE 7: DESCRIÇÃO DOS PROCEDIMENTOS ........................................................................................................................15
ATIVIDADE 8: PREPARAÇÃO DA BASE DE DADOS INICIAL ............................................................................................................15
ATIVIDADE 9: INSTALAÇÃO .........................................................................................................................................................15
TIPOS DE ENTREVISTAS ...............................................................................................................................................................22
PROBLEMAS OCORRIDOS NAS ENTREVISTAS ...............................................................................................................................22
DIRETRIZES PARA REALIZAÇÃO DE ENTREVISTAS .......................................................................................................................24
FORMAS ALTERNATIVAS DE COLETA DE DADOS .........................................................................................................................25
FERRAMENTAS DE MODELAGEM DA ANÁLISEESTRUTURADA.................................................................................................26
8.1.
CARACTERÍSTICAS DE UMA FERRAMENTA DE MODELAGEM ÚTIL AO ANALISTA ........................................................................26
1. A natureza dos sistemas
1.1.
Definição de sistemas
Não podemos falar de análise de sistemas, antes de ter uma clara ideia do que seja um sistema. O dicionário
Webster's apresenta várias definições:
1. um grupo de itens que interagem entre si ou que sejam interdependentes, formando um todo unificado como
(a) um grupo de corpos que interagem entre si sob influência de forças relacionadas Exemplo: sistema
gravitacional
(b) uma mistura de substâncias em equilíbrio ou que tende para o equilíbrio Exemplo: sistema termodinâmico
(c) um grupo de órgãos do corpo que desempenham, em conjunto, uma ou mais funções vitais Exemplo: sistema
digestivo
(d) o corpo, considerado como uma unidade funcional
(e) um grupo de objetos ou forças naturais relacionadas entre si Exemplo: sistema fluvial
(f) um grupo de dispositivos ou uma organização em rede, principalmente para distribuição de algum produto
ou servindo a um propósito comum
Exemplo: sistemas telefónico, de aquecimento, rodoviário, de processamento de dados
2. um conjunto organizado de doutrinas, ideias ou princípios, habitualmente previsto para explicar a
organização ou funcionamento de um conjunto sistemático
Exemplo: sistema mecânico de Newton
3. (a) um procedimento organizado ou estabelecido
Exemplo: toques de digitação
(b) uma maneira de classificar, simbolizar ou esquematizar Exemplo: sistema decimal
4. sociedade organizada ou situação social
Exemplos: Movimento dos Sem-Terra, Central Única dos Trabalhadores, Racismo A partir dessas definições,
nota-se que existem muitos tipos de sistemas.
Na realidade, o dicionário apresenta definições classificadas por categoria. Como nosso interesse são os sistemas de
processamento, isso significa que para facilitar, também devemos dividir todos os sistemas em duas categorias:
sistemas naturais e sistemas feitos pelo homem.
1.2.
Sistemas naturais
A maioria dos sistemas não é feita por pessoas. Eles são encontrados na natureza, e de modo geral, servem a seus
próprios propósitos. É conveniente dividi-los em dois subsistemas: sistemas físicos e sistemas vivos.
1.3.
Sistemas físicos
Existem muitos exemplos de sistemas físicos, tais como:
• Sistemas estelares: galáxias, sistemas solares, etc.
• Sistemas geológicos: rios, cadeias de montanhas, etc.
• Sistemas moleculares: DNA.
Os sistemas físicos são interessantes de serem estudados porque, como humanos intrometidos que somos, por vezes,
tentamos modificá-los. Desenvolvemos também, diversos sistemas, incluindo-se aí os sistemas em computadores, que
devem interagir harmoniosamente com os sistemas físicos.
1.4.
Sistemas vivos
Os sistemas vivos, naturalmente, abrangem as indeterminadas espécies de animais e plantas em nossa volta e nós, a espécie
humana. Essa categoria também inclui hierarquias de organismos vivos individuais, como ervas, rebanhos, tribos, grupos
sociais, empresas e nações.
Muitos sistemas feitos pelo homem interagem com os sistemas vivos - por exemplo, os marca-passos
computadorizados interagem com o coração humano. Em alguns casos os sistemas automatizados estão sendo
projetados para substituir sistemas vivos. Em outros casos, os pesquisadores consideram os sistemas viventes
(conhecidos como computadores orgânicos) como componentes de sistemas automatizados.
Os sistemas vivos e os feitos pelo homem são, muitas vezes, parte de um conjunto de sistemas maiores, e quanto mais
soubermos acerca deles, melhores analistas de sistemas seremos.
1.5.
Sistemas feitos pelo homem
Alguns sistemas são construídos, organizados e mantidos por seres humanos.
• Sistemas sociais: organizações de leis, doutrinas, costumes, etc.
• Uma coleção organizada e disciplinada de ideias: o sistema decimal para organização de livros em
bibliotecas (Dewey), o sistema para perda de peso (Vigilantes do Peso), etc.
• Os sistemas de transporte: redes rodoviárias, canais, linhas aéreas e semelhantes.
• Sistemas de comunicações: telefones, telex, sinais de fumaça, etc.
• Sistemas de manufatura: fábricas, linhas de montagem, etc.
• Sistemas financeiros: contabilidade, inventários, livros razão, controle de estoque, entre outros.
Hoje, a maioria desses sistemas usa computadores; na verdade muitos deles não poderiam sobreviver sem os
computadores. É importante ressaltar que esses sistemas já existiam antes que surgissem os computadores; alguns deles,
na realidade, não estão ainda totalmente computadorizados e podem permanecer assim por muitas décadas mais. Outros
contêm um ou mais componentes computadorizados.
A questão de, se um sistema feito pelo homem deve ou não ser computadorizado, tem que ser avaliada; isso não é algo
que deva ser tomado por certo.
Por que alguns sistemas de informação não devem ser automatizados? Existem muitas razões, mas aqui estão as mais
comuns:
Custo: Nem sempre é verdade que os computadores sejam mais rápidos e mais baratos do que o modo
"antigo".
Conforto: um sistema automatizado pode ocupar espaço em demasia, fazer excessivo ruído, gerar muito
calor ou consumir muita energia. Isso está se tornando menos verdadeiro com a penetrante influência dos
microprocessadores, mas é um fator a considerar.
Segurança: o usuário pode achar que o sistema automatizado não seja suficientemente seguro, podendo
preferir que suas importantes e sigilosas informações sejam fisicamente protegidas debaixo de chaves.
Manutenção: o usuário pode argumentar que não há ninguém na organização que possa manter o
hardware e/ou software do computador, de forma que ninguém estaria capacitado a efetuar modificações e
melhoramentos.
Política: a comunidade de usuários pode achar que os computadores são uma ameaça aos seus
empregos, ou que tornam seu trabalho tedioso e "mecânico", ou podem ter uma dúzia de outras razões
que o analista pode considerar como irracionais. Mas, como o sistema pertence aos usuários, a opinião deles
está acima de tudo. Se eles não desejarem um sistema automatizado, farão o que for possível para que o sistema
fracasse caso ele lhes seja imposto.
Se a solução automatizada realmente for a melhor solução, deve ser feito um trabalho de conscientização, para que
os usuários vejam as vantagens da automação.
A principal tarefa do pessoal ligado a análise, desenvolvimento e processamento de sistemas é analisar ou estudar o
sistema para determinar-lhe a essência: o resultado exigido, independentemente da tecnologia utilizada em sua
implantação.
1.6.
Sistemas automatizados
Sistemas automatizados são sistemas feitos pelo homem, que interagem com, ou são controlados por um ou mais
computadores. A sociedade moderna apresenta muitos exemplos diferentes de sistemas automatizados, mas todos eles
possuem componentes comuns.
1.6.1. Componentes de um sistema automatizado
• Hardware: unidades físicas de um sistema (equipamento) - Terminal, impressora, vídeo, teclado, disco, etc.
• Software: programas, como sistemas operacionais (DOS, Unix, VMS), banco de dados (Xbase, Access, SyBase,
Oracle), programas aplicativos (Word, Excel, Lotus 1,2,3), etc.
• Pessoas (peopleware): aquelas que usam ou operam o sistema. Fornecem dados de entrada ou utilizam as
informações de saída, as que desempenham atividades de processamento manual em um sistema.
• Dados: informações que o sistema conserva por um período de tempo.
• Procedimentos: determinações e instruções formais para a operação do sistema.
As técnicas para analisar, modelar, projetar e implementar sistemas automatizados são geralmente as mesmas,
qualquer que seja a aplicação, ou seja, podem ser usadas em sistemas comerciais, militares, industriais, etc..
1.6.2. Tipos de sistemas automatizados
•
•
•
•
•
•
Sistemas On-Line
Sistemas de Tempo-Real
Sistemas de Apoio à Decisão
Sistemas de Planejamento Estratégico
Sistemas Baseados no Conhecimento
Data Warehouse
1.6.2.1. Sistemas on-line
São sistemas onde as informações disponíveis estão sempre atualizadas, ou seja, no momento que há uma alteração de
dados, elas ficam imediatamente disponíveis para serem utilizadas.
Normalmente os usuários se conectam ao sistema por meio de terminais que podem estar próximos ou a centenas ou
milhares de quilômetros de distância do computador que processa e armazena os dados.
Características de sistemas on-line:
Os dados são introduzidos no sistema de processamento e dele recebidos remotamente. Isto é, os usuários
interagem com o computador através de terminais que podem estar localizados a centenas de quilômetros de
outros terminais e do próprio computador;
O armazenamento dos dados (arquivos ou banco de dados) é organizado de tal forma que uma recuperação ou
modificação de uma informação ocorra rapidamente e sem necessidade de acessar outros dados do sistema. Isto está em
flagrante contraste com os sistemas batch (lotes), comuns nas décadas de 60 e 70, onde as informações eram
normalmente recuperadas na modalidade seqüencial. O sistema lia todos os registros do banco de dados, processando-os
e atualizando-os, conforme houvesse alguma atividade.
Num sistema on-line o usuário interage diretamente com o computador, portanto exige que o analista planeje
cuidadosamente a interface homem-máquina. A comunicação de um sistema on-line com as pessoas, ou seja, o modo de
conexão entre eles, pode ser feita através de linhas telefônicas, satélites, rádios (micro ondas), etc.
Exemplos de sistemas on-line:
• Caixa automática de um banco;
• Reserva de passagens aéreas;
• Home banks.
1.6.2.2. Sistemas de tempo real
São sistemas que têm como compromisso receber, processar ou enviar informações num limite de tempo pré
determinado.
Características de sistemas de tempo real:
Muitos consideram sistemas de tempo real uma variação de sistemas on-line, usando esses termos indiferentemente. Evidente
que, de alguns sistemas on-line (sistemas bancários, reserva de passagens, controle de estoque) se espere uma resposta às
mensagens digitadas no terminal em um ou dois segundos.
Porém, a expressão "tempo pré-determinado" na definição de sistema de tempo real, normalmente quer dizer em
milissegundos e às vezes em microssegundos.
Sistemas de tempo real podem interagir tanto com pessoas quanto com o ambiente.
A preocupação de um analista de sistema de tempo real é que, se o computador não responder com suficiente rapidez,
os dados que chegarem poderão se perder irremediavelmente, ou um míssil poderá se desviar tanto de sua trajetória, que não
se conseguirá recuperá-lo, ou um processo industrial irá pêlos ares.
Em contraste com isso, um sistema on-line que não reaja com suficiente rapidez nada mais fará do que tornar seus usuários
impacientes e irritados.
Exemplos de sistemas de tempo real:
• Orientação de mísseis
• Comutação telefônica
• Monitoração de pacientes em hospitais
• Controle de misturas, temperatura e pressão em indústrias químicas
• Controle de reação em usinas atômicas.
1.6.2.3. Sistemas de apoio à decisão
A maioria dos sistemas automatizados de informação construídos nos últimos 30 anos era de sistemas operativos,
conhecidos como de processamento de ações e que incluem os sistemas de pagamento, de entrada de pedidos, de
contabilidade e sistemas industriais. Como foram construídos há muito tempo, já estão desatualizados e por isso, novos
sistemas operativos têm sido desenvolvidos nas maiores empresas, por todo o mundo.
À medida que os atuais sistemas operativos prosseguem em seu rumo cambaleante, muitas empresas estão
concentrando a atuação em um novo tipo de sistema: o de apoio à decisão.
Características de sistemas de apoio à decisão:
Esses sistemas de processamento, como o próprio termo sugere, auxiliam gerentes e outros profissionais
("funcionários do conhecimento" de uma organização) a tomarem decisões inteligentes e bem informadas sobre vários
aspectos da operação;
Eles não só recuperam e apresentam dados, mas também executam diversas análises matemáticas e estatísticas sobre os
dados;
Têm também a aptidão de apresentar as informações sob várias formas gráficas (tabelas, diagramas, etc.) bem como
relatórios convencionais.
Exemplos de sistemas de apoio à decisão:
Programas de planilhas eletrônicas (ex.: Lotus 1,2,3, Excel);
Sistemas de análise estatística;
Programas de previsões mercadológicas e outros.
1.6.2.4. Sistemas de planejamento estratégico
Esses sistemas não são programas de computador, mas uma complexa combinação de atividades e procedimentos,
executados por pessoas utilizando informações de fontes externas (pesquisa de mercado e outras) e de dados internos
de sistemas operativos e de apoio de decisão de uma empresa.
Os sistemas de planejamento estratégico são usados pêlos diretores para avaliar e analisar a missão da empresa.
Planejamento estratégico é um conceito que se tornou popular durante a segunda guerra mundial, embora obviamente
muitas empresas já fizessem isso, há muito tempo.
1.6.2.5. Sistemas baseados no conhecimento
Uma expressão relativamente nova na indústria do processamento é "sistema especialista" ou "sistema baseado no
conhecimento". Esses sistemas utilizam técnicas desenvolvidas dentro do campo da inteligência artificial, e têm como
meta imitar o desempenho humano em uma ampla variedade de tarefas "inteligentes".
Os sistemas baseados no conhecimento, como é óbvio, contêm grande quantidade de conhecimentos variados para utilização
em determinada tarefa.
Os sistemas especialistas são sistemas baseados numa determinada área (medicina, engenharia, administração, etc.), num
determinado conhecimento, embora os dois nomes sejam muitas vezes empregados indistintamente.
O sistema especialista é um programa que utiliza uma base de dados de conhecimentos em áreas específicas e através
do relacionamento desses dados e outras técnicas, propõe soluções que possam auxiliar o profissional numa determinada área.
1.6.2.6. Data warehouse
O aprimoramento dos sistemas de apoio à decisão, de planejamento estratégico e baseados no conhecimento, deu origem ao
chamado DATA WAREHOUSE.
O velho banco de dados submeteu-se a uma plástica, vestiu roupa nova, ganhou as ruas e faz a cabeça dos
"funcionários do conhecimento" no mundo inteiro: é o data warehouse, a mais recente ferramenta de apoio à decisão,
que, integrada ao hardware e software específicos, permite armazenamento/tratamento de informações históricas, e tem
importância estratégica no apoio a decisões em ocasiões específicas.
Em se tratando de aplicações, a coleção de exemplos não tem fim:
•
Uma loja de departamentos, sabendo que boa parte das fraldas descartáveis é vendida a pais no caminho entre o
escritório e a casa, em especial às sextas-feiras, aproveitou essa informação para desembaraçar-se do estoque
remanescente de cervejas importadas, exibindo-as em gôndolas ao lado de artigos para bebés.
•
Uma indústria de móveis para crianças, a partir de informações recolhidas das notas fiscais emitidas pêlos
revendedores, mantém cadastrados no data warehouse todos os consumidores que compram berços e outras peças para
mobiliar quartos de bebés (nome, endereço, telefone, preferências de estilo, cores, etc.). Com isso, cinco anos
depois, dispara malas diretas, oferecendo à família, móveis desenhados para crianças maiores. As correspondências
impressas em rosa ou azul, de acordo com o sexo do bebé, cumprimentos pelo aniversário da criança (dados coletados
por vendedores treinados). Não pais, avós e padrinhos que resistam a esse apelo de marketing.
No Brasil os pioneiros do data warehouse são as instituições financeiras (Citibank e Tecban) visando melhorar o
desempenho das áreas de marketing, crédito, finanças em geral e treinamento de recursos humanos. Atrás dessas empresas, a
passos mais lentos e começando pela área de marketing, vem vindo indústrias como Ferrero Rocher, Gillete e Chapecó.
A falta de cultura, somada aos custos da implantação, desestimula maiores iniciativas no país. Mas as estatísticas indicam que
essa realidade tende a mudar rapidamente, à medida que aqui as empresas começam a descobrir essa tecnologia relacional
como ferramenta capaz de realizar o trinômio Competitividade/Produtividade/Lucratividade.
2. O analista de sistemas
É uma pessoa com amplos conhecimentos sobre aplicações de
computadores e racionalização de trabalho e que desenvolve
soluções para problemas de usuários, determina a
praticabilidade técnica e operacional dessas soluções e prevê os
custos do seu desenvolvimento e implementação.
Membro essencial de qualquer projeto de desenvolvimento de
sistemas, o analista executa um grande volume de trabalho por
ele mesmo, e dispende ainda mais esforço com os outros
participantes do projeto.
O analista de sistemas necessita de uma mistura equilibrada de
conhecimentos técnicos e de negócios, habilidades analítica e
para entrevistas e também uma boa compreensão do comportamento
humano.
2.1.
Características do analista de sistemas
Em geral, os analistas de sistemas, ao longo de seus estudos e da experiência adquirida na prática de suas atividades,
desenvolve e aprimora determinadas características:
• Habilidade com as pessoas para entrevistar usuários, mediar desentendimentos e sobreviver às inevitáveis
batalhas políticas que ocorrem em todos os projetos, mesmo nos mais triviais;
• Conhecimento de aplicações para compreender e apreciar as necessidades do usuário;
• Habilidade em processamento para compreender os potenciais usos do hardware e do software dos
computadores;
• Mente lógica e organizada',
• Capacidade de visualizar um sistema sob diferentes perspectivas e subdividi-lo em subsistemas de vários
níveis;
• Pensar em um sistema em termos abstratos e físicos.
3. O que é análise?
É o estudo de um problema, que antecede à tomada de uma ação.
No mundo dos sistemas computacionais, análise refere-se ao estudo de alguma área de trabalho ou de uma
aplicação, gerando, quase sempre, a especificação de um novo sistema.
A essência da análise consiste em identificar o problema certo e escolher uma alternativa de solução que seja viável. A
preocupação dominante da análise não é obter sucesso, mas evitar fracasso. Objetivos de uma boa análise:
• Solução certa para o problema certo
• Seleção de um objetivo ótimo
• Documentação do objetivo para posterior avaliação
• Previsão de custos e benefícios
• Obtenção de acordo entre as partes envolvidas
3.1.
A análise de sistemas clássica
Até o final dos anos 70, a maioria dos projetos de desenvolvimento de sistemas começava pela criação de um extenso
detalhamento sobre os requisitos do usuário. O analista documentava o que conhecia daqueles requisitos, em um maciço
conjunto de documentos, constituído principalmente de uma narrativa em linguagem inadequada. Essa especificação
funcional, padecia de alguns grandes problemas:
• Era monolítica: se não lêssemos até a última página, não entenderíamos o funcionamento de todo o sistema;
• Era redundante: a mesma informação era muitas vezes repetida em diversas partes diferentes do documento.
Assim, como uma pessoa com vários relógios dificilmente saberá que horas realmente são, uma
especificação funcional com a mesma informação repetida três ou quatro vezes gera dificuldades na atualização e
revisão dos requisitos, conduzindo a um grave problema: a inconsistência;
• Era ambígua: o detalhamento dos requisitos do usuário podia ser (e geralmente era) interpretado de modo diferente
por quem o lesse (usuários, analistas de sistemas, projetistas, programadores);
• De manutenção impossível: por todos os motivos descritos (e pelo longo período de "produção"), a
especificação funcional quase sempre estava obsoleta no final do processo de desenvolvimento do sistema (isto é,
quando o sistema entrava em operação);
• Excessivamente física e não lógica, isto é, voltada mais para a forma de funcionamento do sistema do que para a
função propriamente requerida;
• Tediosa de ler;
• Insuportável de escrever.
Isso significa que a maioria dos sistemas desenvolvidos durante os anos 60 e 70 não tem o registro atualizado de seus
objetivos, ou a que supostamente se propunham.
3.2.
A passagem para análise estruturada
Enquanto todos esses problemas estavam sendo debatidos, um conjunto de ideias já estava sendo adotado na área de
programação e projeto. Essas ideias, geralmente mencionadas como programação estruturada e projeto estruturado,
prometiam grandes melhorias na organização, codificação, testes e manutenção de programas e tinham se mostrado em geral,
um sucesso.
Porém, as empresas de processamento eletrônico de dados perceberam que não havia como escrever brilhantes programas e
nem como projetar sistemas altamente modulares se não soubessem realmente o que os sistemas deveriam fazer.
Na verdade, alguns analistas mais "difíceis" argumentavam que a programação e o projeto estruturados possibilitavam algumas
equipes de projeto chegar a um desastre com maior rapidez que nunca - construíam uma brilhante solução para o problema
errado!
Como resultado houve um movimento gradual - gradual porque os analistas e programadores levaram cerca de dez anos para a
aceitar estas novas técnicas, rumo as especificações funcionais que fossem:
• GRÁFICAS: compostas por vários diagramas, apoiados por material textual detalhado;
• MODULARIZADAS: ou seja, divididas de forma que as partes individuais da especificação possam ser lidas
independentemente de outras.
• DE REDUNDÂNCIA MÍNIMA: para que as alterações possam ser efetuadas em apenas uma parte da
especificação.
Essa abordagem deu origem a Análise Estruturada, utilizada atualmente na maioria das empresas de desenvolvimento de
sistemas. As que ainda preparam especificações do tipo "novela vitoriana", estão em minoria, e como os dinossauros, se
extinguirão em algum momento.
Como qualquer campo da ciência, a análise de sistemas passou por uma série de modificações evolutivas nos últimos
anos.
3.3.
A análise estruturada
Análise Estruturada é uma técnica para especificar o sistema. Essa técnica usa ferramentas gráficas de
documentação, para gerar um novo tipo de especificação - a Especificação Estruturada.
A Análise Estruturada define O QUE o sistema faz, facilitando o projeto (que define COMO o sistema funciona) e o teste
(que define SE o sistema funciona).
3.3.1. Objetivos da análise estruturada
»
•
•
•
Facilitar a comunicação e a interação entre usuários e analistas para especificar os sistemas.
Simplificar a apresentação, o entendimento e a resolução dos processos.
Tratar os problemas por ordem de importância.
Definir as entradas, saídas e principalmente, a função do sistema.
3.3.2. Características da análise estruturada
• Gráfica, utiliza símbolos, tornando o sistema de mais fácil compreensão
• Particionada (ou modular), permitindo uma visão geral, seguida de visões concentradas e detalhadas de uma
área determinada (especificação do geral para o particular - Top Down)
• Fácil manutenção, pois a redundância é mínima
• Interativa, comunicação clara e direta entre os participantes do projeto
• Lógica, e não física. A especificação estruturada concentra-se no que o sistema fará e não como será
implantado. É independente de linguagem ou sistema operacional.
• Precisa, porque identifica o problema
• Concisa, porque define um objetivo a ser atingido
4. Metodologia - Visão geral
Para sermos analistas eficientes, precisamos de algo além de ferramentas de modelagem; precisamos de
METODOLOGIA.
Os projetos de desenvolvimento de sistemas são iniciados como resultado de um entendimento verbal entre usuários e o
pessoal de projeto (que pode ser o analista de sistemas, programador, operador de computador) e o trabalho se estende
desde a análise de sistemas até o projeto e implementação, correndo através de diversas fases.
A Metodologia determina quando e de que maneira as coisas devem acontecer e quais as regras que serão seguidas.
Deve ser feita de um modo simples para qualquer pessoa entrosar-se com a atividade de desenvolvimento de um
sistema.
Metodologia é um conjunto organizado de técnicas que orienta uma
atividade.
Cada atividade exige técnicas apropriadas. Dependendo do
volume e complexidade das atividades, cada técnica necessita de
ferramentas específicas, em geral, software de apoio.
Algumas organizações adotam metodologias próprias, outras,
metodologias de "pacotes" desenvolvidas por firmas de
consultoria. Cada metodologia especifica a sequência das
atividades a serem seguidas no desenvolvimento do sistema, os
produtos a serem desenvolvidos em cada estágio, e os controles
administrativos a serem aplicados.
Os analistas devem contribuir para aprimorar a metodologia, mas não devem criar uma metodologia isolada dos
demais porque isto dificulta a comunicação.
4.1.
Objetivos da metodologia
Eficácia:
Desenvolver sistemas de acordo com as necessidades reais do usuário.
Eficiência:
Minimizar custos de desenvolvimento, implementação, documentação e de manutenção.
Ser eficaz c produzir um efeito, que de bom resultado. Eficiente é o agente efetivo da ação, a reação.
Metodologia de desenvolvimento de sistemas estruturados é um método geral que visa a construção de um sistema de
processamento de dados, baseado no projeto e na análise estruturada.
4.2.
Propostas da metodologia estruturada
Participação do Usuário:
Quem conhece o problema é o usuário. É muito importante que ele esteja envolvido em todas as atividades do
projeto, mesmo que seja só como ouvinte ou assistente.
Partir do problema geral para o particular:
Abordar o sistema de forma a não se perder em detalhes. Primeiro os aspectos essenciais, depois os particulares.
Essa maneira de enfocar um problema ou um sistema tem o nome de abordagem TOP-DOWN (de cima para
baixo).
Refinamentos sucessivos:
Um bom sistema é fruto de sucessivas correções e aprimoramentos de uma solução quase correta. E melhor estar
aproximadamente certo do que precisamente errado.
Flexibilidade:
Os projetos devem ser construídos de maneira a suportar mudanças que se fizerem necessárias. As situações mudam
e as estimativas também podem ser alteradas.
Ênfase nos dados:
Os dados são propriedade da empresa e não das aplicações. Os arquivos não devem ser exclusivos dos sistemas para
evitar redundâncias e inconsistências. É viável a utilização de arquivos e dados já definidos, para não tê-los duas vezes
em lugares diferentes.
Uso de ferramentas de alto nível:
A tendência é de disponibilidade de ferramentas cada vez mais potentes e mais baratas para aumentar a
produtividade de analistas e projetistas. Com isso os custos de hardware/software decrescem.
4.2.1. Características da metodologia estruturada
• Supõe que o problema esteja bem definido.
• Supõe que o problema possa ser descrito através de diagramas e estruturas bem definidas.
• Usa intensivamente as técnicas de: Análise Estruturada, Análise de Dados, Projeto Estruturado,
Programação Estruturada, Testes Estruturados.
A metodologia estruturada, então, cria uma sequência a ser seguida, que é tratada como Ciclo de Vida do Projeto.
5. Ciclo de vida do projeto estruturado
Cada vez mais as organizações estão adotando um único ciclo de vida de projeto uniforme - também conhecido
como plano de projeto ou metodologia de desenvolvimento de sistemas, que contém nove atividades: levantamento das
informações, análise de sistemas, projeto, implementação, geração de testes, controle de qualidade, descrição de
procedimentos, conversão de banco de dados e instalação.
Qual o propósito de ter-se um ciclo de vida de projeto?
1. Definir â$ atividades a serem executadas (descrição correta de todas as etapas);
2. Introduzir consistência entre muitos projetos de desenvolvimento de sistemas da mesma organização;
3. Introduzir pontos de verificação para o controle de decisões.
O ciclo de vida do projeto pode organizar as atividades do gerente (do projeto) tornando mais provável que os
problemas sejam atacados no momento apropriado.
5.1.
Atividade 1: Levantamento
É o estudo de viabilidade ou estudo inicial das atividades.
Tipicamente, começa quando um usuário solicita que uma ou mais partes de sua
atividade sejam automatizadas.
Principais Objetivos:
• Identificar usuários:
Identificar os usuários responsáveis pela requisição do novo sistema e
a
partir dessa relação desenvolver um "escopo" inicial do sistema. Escopo é a abrangência, intenção, propósito do
sistema.
• Identificar deficiências:
Identificar as atuais deficiências no ambiente do usuário.
Exemplos, no caso de existir algum software implantado:
O hardware do sistema atual é confiável?,
A manutenção do sistema atual é possível? Existe mão-de-obra disponível?,
Como é o tempo de resposta do sistema atual?,
Os relatórios satisfazem gerências e operacionais?
• Estabelecer metas e objetivos:
Definir datas limites, custos e o propósito do novo sistema.
• Determinar se é possível automatizar:
Determinar a viabilidade de automatização do sistema, sugerindo alguns esquemas, dentro do seu
orçamento e planos.
• Preparar uma previsão do projeto:
Estabelecer o tempo que será gasto na condução do restante das tarefas, estimando vantagens e
desvantagens para cada solução.
• Obter o parecer e o comprometimento do usuário e da administração:
Documentar os requisitos do usuário e as restrições dentro das quais o sistema deverá ser construído. Submeter
essa documentação ao conhecimento e aprovação do pessoal envolvido.
5.2.
Atividade 2: Análise de sistemas
O principal propósito da atividade de análise de sistemas é transformar a combinação entre as
informações obtidas do usuário e os objetivos do novo sistema em uma especificação
estruturada. O desenvolvimento da descrição formal do que o novo sistema deve fazer,
independe da natureza dos equipamentos, das linguagens ou softwares que serão usados para
satisfazer as necessidades.
Principais Objetivos:
• Buscar informações:
Agrupar de forma coerente as informações obtidas na atividade Levantamento (atividade 1).
• Entrevistar o usuário:
Tomar conhecimento das atividades atuais do usuário, o que ele deseja do novo sistema e que
restrições o sistema deve ter.
Resultados da Análise:
1. Relatório custo x benefício por atividade
2. Requisitos de base de dados (informações)
3. Necessidades físicas (hardware, software, peapleware)
4. Necessidades para conversão do sistema
5. Especificação funcional do sistema.
5.3.
Atividade 3: Projeto
Em cada tarefa especificada, a atividade Projeto ocupa-se com o desenvolvimento de uma seqüência apropriada de módulos
de programas (imaginando o sistema acontecendo e definindo por onde começar e o que deve ser feito depois, até a última
ação) e interfaces entre esses módulos, para implementar a especificação criada na atividade Análise (atividade 2).
Nesta atividade aparecem um dos principais problemas, pêlos quais ou usuário está interessado: a especificação das tarefas
manuais que terão que ser realizadas por ele (a chamada fronteira homem-máquina) e como será a comunicação entre ele e
a máquina, de que maneira e em que seqüência ele fornecerá os dados ao computador e como receberá os resultados do
processamento (a chamada interface homem-máquina).
A fronteira homem-máquina separa as partes do modelo que devem ser executadas por uma pessoa (como uma atividade
manual) das partes que devem ser implementadas em um ou mais computadores. Estabelece as tarefas do usuário que serão
necessárias para "alimentar" o sistema, os dados que ele deverá fornecer para que o sistema comece a funcionar (os
chamados dados de entrada ou simplesmente, entradas).
A interface homem-máquina é uma descrição de como e em que seqüência as entradas serão fornecidas pêlos usuários ao
computador (ex.: projetos de tela, diálogo on-line entre usuários e computador), bem como o formato e a seqüência das
saídas fornecidas pelo computador ao usuário.
E basicamente a definição da maneira que homem e máquina conversarão ou se relacionarão.
5.4.
Atividade 4: Implementação
O sistema, depois de visto como um todo, é modulado, ou seja, dividido em partes mais simples. A atividade de
implementação inclui a codificação (programação estruturada) e a integração das partes do sistema, gerando o
resumo completo do sistema final.
Nessa atividade o analista de sistemas não está envolvido, embora existam alguns projetos (e algumas organizações) onde a
análise de sistemas, o projeto e a implementação são feitos pela mesma pessoa.
5.5.
Atividade 5: Geração de testes
A especificação estruturada deve conter todas as informações necessárias para definir
um sistema aceitável do ponto de vista do usuário. Uma vez gerada a especificação, deve-se
gerar um grupo de testes de aceitação. A preparação dos testes pode ocorrer em paralelo com
as atividades de projeto (atividade 3) e implementação (atividade 4).
5.6.
Atividade 6: Controle de qualidade
Controle de Qualidade é conhecido também como teste final de aceitação, e exige como entrada, os dados do
teste de aceitação da atividade de geração de testes (atividade 5) e o sistema integrado produzido pela atividade
implementação (atividade 4).
Algumas pessoas se referem a essa atividade como controle de qualidade em vez de garantia de qualidade.
Independentemente da terminologia, é importante esta atividade para garantir que o sistema apresentará o nível
apropriado de qualidade. É importante fazer o controle de qualidade em todas as atividades do projeto para assegurar
que elas estão sendo realizadas dentro do padrão de qualidade da organização.
A atividade de controle é o teste final da qualidade do sistema.
5.7.
Atividade 7: Descrição dos procedimentos
Outra atividade importante a ser realizada é a geração da documentação do sistema que é
composta basicamente por: manual do usuário, manual técnico do sistema e manual
de operação.
O manual do usuário descreve como o usuário deve proceder para se relacionar
com o sistema. No manual do usuário estão definidos quais são os documentos de
entrada, como e em que prazo deverão ser preenchidos esses documentos.
O manual de operação contém instruções aos operadores de sistema sobre a
maneira de tratamento das informações: localização de arquivos, programas,
periodicidade de execução de determinadas rotinas,
distribuição de relatórios, etc.
O manual técnico, como o próprio nome diz, contém todas as informações técnicas do sistema: a descrição de todos os
programas (inclusive a listagem deles), de todos os arquivos e de todos os procedimentos relativos ao sistema. Ele é uma
referência para programadores e analistas tanto na elaboração de sistemas novos quanto na atualização dos que j á
existem.
É necessário conservar a documentação correia e atualizada por tanto tempo quanto o sistema durar. A correção da
documentação deve ser feita antes que o sistema seja posto em operação.
O analista deve certificar-se de que, quando um sistema entrar em operação, todos os documentos relativos a ele
estejam completos, consistentes, correios e atualizados. Além dessa certeza, precisa estar seguro de que existe
facilidade para executar modificações continuadas nesses documentos.
Não se pode conservar atualizado um sistema e a documentação a ele associada se essa documentação não estiver
correta.
"Não convém que a especificação estruturada tenha sido inscrita para sempre com uma pena de aço inoxidável em
placas de pedra como uma permanente recordação para futuras gerações."
5.8.
Atividade 8: Preparação da base de dados inicial
Essa atividade prepara os dados que iniciarão o sistema e exige como entrada, o banco de dados atual do usuário
bem como as definições produzidas pela atividade projeto (atividade 3).
Caso o sistema novo seja resultado de atualizações de um sistema automatizado já existente, a base de dados anterior
deve ser aproveitada para ser utilizada no novo sistema. Os dados existentes devem ser convertidos de acordo com as
especificações do novo sistema.
Não havendo base de dados automatizada, é necessário então,
para dar a carga inicial ao sistema, digitar as informações iniciais.
Conversão é a tarefa de passar os atuais arquivos, formulários e
dados do usuário para o formato requerido pelo novo sistema.
Um plano de conversão deve ser elaborado, de preferência, assim
que o modelo de implementação do usuário esteja pronto. Pode
haver a necessidade de além da conversão dos arquivos,
conversão de programas e procedimentos.
5.9.
Atividade 9: Instalação
Após os testes e a preparação dos dados é necessário o treinamento.
Treinamento é a tarefa final da equipe de desenvolvimento de sistemas. Um plano de treinamento deve ser
desenvolvido no início do projeto e precisa estar pronto ao mesmo tempo (ou antes) que o sistema esteja apto
para entrar em operação.
A atividade de treinamento tem como base as documentações produzidas pela
atividade Descrição dos Procedimentos (atividade 7), o banco de dados
convertido, produzido pela atividade Preparação da Base de Dados (atividade 8), e
a aprovação da qualidade do sistema, produzida pela atividade de Controle de
Qualidade (atividade 6)
Instalação do novo sistema pode ser uma atividade rápida, desde que a localização
dos equipamentos já esteja preparada e a localização do usuário, principalmente no
caso de sistemas on-line, esteja bem definida.
No caso de um sistema distribuído, de grande porte, pode haver uma única e
centralizada localização do computador e dezenas ou mesmo centenas de terminais
distribuídos. Desse modo, pode ser necessário instalar o sistema (e os dados) por
estágios, de acordo com uma escala previamente preparada.
Em alguns casos, a instalação poderá ser simplesmente uma "passagem" noturna para o novo sistema, sem
nenhuma comemoração ou fanfarra; em outros casos, a instalação poderá ser gradual, com grupos alternados
de usuários, recebendo manuais e simulando o uso do novo sistema até estarem seguros e começarem realmente a
utilizá-lo.
Não existe a obrigatoriedade de que toda a atividade deva terminar antes do início da atividade seguinte. Ao
contrário, algumas atividades podem ser interligadas c executadas ao mesmo tempo. É por esse aspecto não
seqüencial que usa-se a palavra atividade no ciclo de vida do projeto estruturado, em lugar da palavra mais
convencional fase. O termo fase refere-se tradicionalmente a um período de tempo de um projeto em que uma
e somente uma atividade é executada.
Para melhor entendimento da execução das atividades do ciclo de vida de um projeto, (e também para sua
familiarização com exemplos gráficos, embora esse assunto ainda não tenha sido abordado), é importante que
você veja a figura a seguir: ela é um fluxo de dados e não um fluxograma, pois não existe seqüência no
desenvolvimento das atividades.
A figura somente nos informa a(s) entrada(s) necessária(s) a cada atividade e a(s) saída(s) produzida(s). Como
agentes ou pessoas envolvidas tem-se: Usuários, Direção e Operadores.
O
ciclo
de
vida
do
projeto envolve, além das atividades, indivíduos que, embora exercendo funções diferentes, possuem características
comuns. São os usuários, diretores ou gerentes e o pessoal da operação. Todos fornecem entradas à equipe do projeto e são
os últimos receptores do sistema.
O primeiro e mais importante integrante do projeto de desenvolvimento de um sistema é o usuário, que deve ser tão bem
analisado c entendido, quanto as próprias requisições e objetivos a serem alcançados. À ele está reservado um tópico à parte.
Diretores ou gerentes (dirigentes) são os que definem os recursos que serão destinados ao projeto, algumas restrições dentro das
quais o sistema deverá ser construído, exigindo permanente garantia de que o projeto se manterá dentro dessas restrições.
Este conjunto de indivíduos engloba gerentes, diretores e supervisores.
Pessoal da operação é composto por programadores (que transformam as definições do analista ou projetista em um
conjunto de instruções executáveis) e operadores (responsáveis pelo centro de processamento, pela rede de
comunicações, pela segurança do hardware e dos dados do computador, bem como pela execução dos programas e
manipulação da saída das impressoras e monitores de vídeo).
6.
O usuário
É a pessoa ou grupo de pessoas para quem o sistema é construído, e que será
entrevistada muitas vezes pelo analista, para que sejam entendidas as
características que o novo sistema deverá ter.
A maioria dos usuários não se refere a eles mesmos como "usuários", pelo
fato da palavra ser freqüentemente utilizada em um diferente contexto,
para identificar os consumidores de drogas. Em algumas empresas o
problema foi evitado com a utilização dos termos "cliente" ou "proprietário"
para identificar o usuário. O usuário é o "proprietário" no sentido de que
recebe ou herda o sistema depois de pronto e é o "cliente" cm pelo menos
dois importantes aspectos: assim como em tantas outras atividades, "o
cliente sempre tem razão" não importando quão exigente ou desagradável
seja, e, o cliente, afinal de contas, é quem paga pelo sistema e tem o direito
ou a possibilidade de se recusar a pagar se não ficar satisfeito com o produto
recebido.
Na maioria dos casos» é muito fácil identificar o usuário, pois normalmente é a pessoa que emite uma solicitação formal
de um sistema. Mas existem situações em que a identidade do verdadeiro usuário é desconhecida ou em que o analista de
sistemas tem pouca ou nenhuma oportunidade de interagir diretamente com ele. É o caso de sistemas elaborados por
consultorias ou empresas de software, onde a interação entre as partes (empresa cliente e consultoria) é feita por agentes
contratantes ou setores administrativos. É evidente que situações assim provocam mal-entendidos.
Para que o usuário seja entendido e para que o analista possa transmitir suas idéias ao usuário é necessário
estabelecer o contato direto entre usuário e analista. Mesmo que outras pessoas estejam envolvidas como
intermediárias, é importante que haja reuniões regulares, frente a frente com a pessoa que irá receber o sistema. Se não for
possível a comunicação direta com o usuário, a documentação produzida pelo analista de sistemas torna-se ainda mais
importante e por isso deve ser objetiva e deve representar exatamente o comportamento do novo sistema.
Um dos equívocos freqüentemente cometidos por pessoas da área de processamento é imaginar que todos os usuários
são iguais. "Usuário" no singular implica na interação com apenas uma pessoa; mesmo quando é óbvio que mais de um
usuário está envolvido, existe a tendência de imaginá-los como um grupo humano indistinto e sem forma. Dizer que
um usuário é diferente do outro pelo aspecto da personalidade, do tipo físico, da experiência e dos interesses c uma
declaração simples. Mas existem diferenças importantes entre usuários, que um analista de sistemas deve ter em mente quanto
ao:
• tipo de função
• nível de experiência.
6.1.
A classificação dos usuários por tipo de função
Em um projeto se gasta tempo entrevistando usuários para estabelecer os requisitos do sistema. Mas, que usuários? De que
nível? Isso, naturalmente, depende do projeto e da doutrina da empresa, mas o analista interage com três tipos principais
de funções: usuários operativos, supervisores e executivos.
6.2.
Usuários operativos:
São os funcionários burocratas, operativos e administrativos que provavelmente terão contato diário com o novo
sistema (a menos que esteja sendo construído um sistema de apoio à decisão, caso em que o analista pode ter
pouco ou nenhum contato com esse grupo). Assim, em uma grande organização, o analista pode entrevistar
secretárias, agentes de seguros, despachantes de cargas, pessoal da entrada de pedidos e “assistentes” de todos os
tamanhos, e cores. No caso de um sistema de tempo real o analista falará com usuários operativos cujos títulos serão
engenheiros, físicos, operários de fábricas, pilotos, telefonistas, etc..
Características dos usuários operativos:
•
Interesse pelas funções que o sistema executará em relação ao seu
relacionamento com ele:
Os exemplos são:
• Que tipo de teclado terá que usar para se comunicar com o sistema?
• Que tipo de terminal será usado? Será ofuscante?
• Como o sistema avisará quando cometer um erro?
• Como serão distribuídas as informações nos relatórios?
E assim por diante.
Pode não parecer mas são problemas que devem ser levados em consideração. Os
usuários operativos talvez não tenham poder ou autoridade para aprovar o projeto de desenvolvimento de um sistema,
mas se eles o sabotarem ou simplesmente não o utilizarem, o novo sistema terá fracassado.
Isso quer dizer que o analista de sistemas deve ser autorizado a se comunicar diretamente com o usuário
operativo.
• Conhecimento apenas das tarefas que executam (visão "local" do sistema) e das pessoas com quem tem contato
direto:
Os usuários operativos podem não conhecer muito bem a estrutura da empresa e podem ter dificuldade em
descrever como suas atividades se encaixam na organização como um todo. Isso ocorre ou por falta de interesse deles
ou por falta de explicações do usuário supervisor. Uma consequência dessa situação é que o analista deve ser capaz de
desenvolver modelos do sistema que possibilitem tanto as visões locais (descrição de uma pequena parte do sistema,
independentemente das outras partes) como as visões globais (ideia geral de todo o sistema, evitando detalhes).
• Tendência em imaginar os sistemas em termos físicos, em termos de quais equipamentos serão usados para
implementar o sistema e como será implementado:
As discussões abstratas sobre funções e elementos de dados do sistema podem ser cansativas e difíceis para os usuários
operativos. É mais fácil ele imaginar que tipo de equipamento ou tecnologia deveria ser utilizada para o funcionamento
do sistema. Diante disso o analista pode achar necessário conversar com o usuário exclusivamente em termos que
lhe sejam familiares e a partir daí, fazer um modelo do que o sistema deve fazer, sem se importar com a tecnologia.
6.3.
Usuários supervisores:
São os funcionários em atividades de supervisão, que geralmente chefiam um
grupo de usuários operativos e são responsáveis por seus desempenhos. Eles
podem ter o título de supervisores mas também podem ter os de gerente, chefe de
grupo, chefe de seção, encarregado de setor, etc..
Características dos usuários supervisores:
• Conhecimento do serviço feito por seus subordinados operativos:
Muitos dos usuários supervisores eram originalmente usuários operativos que
foram promovidos à atual posição. Assim, eles geralmente conhecem o serviço
feito por seus subordinados e portanto, sabem suas necessidades, preocupações
e perspectivas.
• Orientado às condições orçamentarias:
O usuário supervisor é muitas vezes avaliado pelo desempenho de sua equipe em relação ao tempo gasto e ao
orçamento. Também pode ocorrer que um novo sistema possa auxiliá-lo controlar o desempenho de cada usuário
operativo. Por esse enfoque de eficiência operativa o usuário supervisor pode estar prevendo que o novo sistema
reduzirá o número de funcionários operativos ou evitará o aumento do pessoal quando o volume de trabalho crescer.
• Atitude de intermediário:
O usuário supervisor age muitas vezes como intermediário entre o analista de sistemas e o usuário operativo,
argumentando que os usuários operativos são muito ocupados para desperdiçarem o tempo conversando com
analista.
• Define requisitos e detalha orientações comerciais:
É com o usuário supervisor que o analista terá seu principal contato. Ele pode ser um membro passivo da equipe (no
sentido de só participar quando entrevistado), um componente de tempo integral ou até o gerente do projeto.
6.4.
Usuários executivos:
Normalmente não estão diretamente envolvidos nos projetos de desenvolvimento de
sistemas, a menos que o projeto seja muito grande ou muito importante que produza grande
impacto na organização. No caso de um projeto normal, o usuário executivo está dois ou
três níveis acima das atividades associadas ao projeto.
Características dos Usuários executivos:
• Autoridade financeira:
Os usuários executivos podem ter a iniciativa do projeto mas, provavelmente
servirão como autoridade financeira para as solicitações de projetos que se
originem nos níveis inferiores da organização.
• Não ajudam definir requisitos do sistema:
Usuários executivos normalmente não foram usuários operativos, ou, se o tiverem sido, foi há tanto tempo que
qualquer experiência que pudessem ter já está desatualizada. Dessa forma eles não estão em posição de ajudar definir
requisitos do sistema para os que realmente o utilizarão diariamente. A exceção é o sistema de apoio à decisão, que é
o mais utilizado pêlos usuários executivos e supervisores.
• Interesse nos aspectos estratégicos de lucros e perdas:
Normalmente, os usuários executivos não estão preocupados com problemas operativos (como custos de
transação, tipo de teclado, reflexos de tela, conservação de funcionários). O que eles esperam atingir são novos
mercados, novos produtos ou novas vantagens competitivas que obterão com o novo sistema.
• Têm visão global do sistema:
Os usuários do nível executivo estão mais interessados no resultado geral do sistema, não se interessando pêlos
detalhes. Por isso, é importante a utilização pêlos analistas, de ferramentas de modelagem de sistemas que
ofereçam uma visão geral do sistema para usuários executivos, e partes detalhadas para os usuários operativos.
• Capacidade de lidar com modelos abstratos:
Os usuários executivos interessam-se mais pêlos modelos abstratos por estarem habituados a lidar com modelos
financeiros, mercadológicos, organizacionais e de engenharia. Não estão interessados nos modelos "físicos" do novo
sistema, portanto, o analista não deve aborrecê-los com excesso de detalhes.
Usuários por tipo de função
Usuário Operativo
Usuário Supervisor
Usuário Executivo
Tem visão local
Pode ou não ter visão local
Tem visão global
Executa a função do sistema
Conhece a operação
Tem iniciativa sobre o projeto
Tem visão física do sistema
Orientado por considerações orçamentárias
Não tem experiência operativa
Muitas vezes age como intermediário
Tem preocupações estratégicas
6.5.
A Classificação dos Usuários por Nível de Experiência
Deveria ser óbvio que diferentes usuários tivessem níveis de experiência diferentes. É comum analistas de sistemas
imaginarem que todos os usuários desconheçam termos de processamento de dados. Isso talvez fosse válido há
muitos anos atrás, mas atualmente podemos distinguir usuários amadores, novatos e verdadeiros peritos em
processamento.
6.5.1. Usuários Amadores:
São os que nunca viram um computador e que exclamam que não entendem nada de
computadores. Eles podem sentir dificuldade em compreender a "linguagem" utilizada pelo
analista de sistemas para descrever os recursos, funções e características do sistema a ser
desenvolvido. O analista deve evitar o uso de termos técnicos e de representações abstratas do
sistema.
6.5.2. Usuários Novatos:
São pessoas que já participaram de um ou dois projetos de desenvolvimento de sistemas ou os que
tem computador em casa e já escreveram um ou dois programas em uma linguagem qualquer.
Esse usuário alardeia que sabe exatamente o que deseja que o sistema faça, que tipo de tecnologia
(equipamentos e linguagens) deverá ser utilizada e está disposto a apontar todos os erros
cometidos pelo analista no último projeto. As sugestões do usuário novato até podem ser corretas,
mas é prematuro decidir sobre hardware, software, linguagem de programação e banco de dados
antes que os verdadeiros requisitos do sistema tenham sido documentados.
6.5.3. Usuários Peritos:
Existem alguns usuários que realmente conhecem análise de sistemas, bem como a tecnologia dos
computadores. É muito bom para o analista trabalhar com esse tipo de usuário. O único problema
que pode haver é o usuário e o analista se empolgarem nas discussões sobre ferramentas e técnicas da
análise de sistemas e esquecerem que o objetivo real é a elaboração de um sistema que
funcione!
Usuários por nível de experiência
Usuário Novato
Usuário Amador
Nunca viu computador
Sente dificuldade para entender a
linguagem do analista
Diz que não entende nada de
computadores
Usuário Perito
Já participou de alguns projetos ou
tem computador em casa
Já escreveu um programa
Conhece realmente a tecnologia
dos computadores
Diz que sabe dizer exatamente o
que deseja do sistema
Pode dar sugestões corretas, mas
normalmente fora de hora.
Dá sugestões coerentes e oportunas
7. Técnicas de Entrevistas e de ColetadeDados
As entrevistas são feitas durante a atividade "análise de sistemas" do projeto de desenvolvimento de um sistema.
São entrevistados usuários, gerentes, auditores, programadores e várias outras pessoas que fazem parte do projeto
de desenvolvimento ou manutenção do sistema.
Por que as entrevistas são feitas durante a análise de sistemas?
• Para coletarmos informações:
O analista necessita de informações sobre o comportamento atual do sistema a ser
modificado ou sobre os requisitos do sistema a ser desenvolvido. Essas
informações estão "guardadas" na cabeça de alguma ou algumas pessoas.
• Para certificarmos nossa própria compreensão:
O analista precisa estar certo de que compreendeu o comportamento do sistema
atual ou os requisitos do novo sistema. Essa compreensão é adquirida através das
combinações da informações obtidas nas entrevistas efetuadas.
• Para executarmos o estudo custo x benefício:
O analista, através das combinações entre as informações colhidas, executa o
estudo da viabilidade do desenvolvimento do projeto levando-se em consideração
o custo (orçamento) e os benefícios proporcionados (resultados).
7.1.
Tipos de Entrevistas
A forma mais comum de entrevistas é a reunião pessoal e direta entre um analista de sistemas (acompanhado ou
não por mais um ou dois analistas do mesmo projeto) e o usuário final (ou mais interlocutores).
Durante a entrevista, as informações são anotadas por um dos entrevistadores, ou por um(a) secretário(a) ou
ainda, podem ser gravadas. As informações numa entrevista podem ser obtidas solicitando aos
entrevistados que respondam por escrito a um questionário, ou que descrevam por escrito os requisitos do
sistema. Um videocassete também pode ser usado para registrar uma entrevista.
Por solicitação do analista de sistemas, as entrevistas podem ser
conduzidas por especialistas, como peritos em industria, psicólogos
comportamentais e negociadores. Nesse caso o analista participa
como assistente.
Em 1977 a EBM apresentou o JAD ( Joint Application Development
-Desenvolvimento Conjunto de Aplicativos) uma forma especializada
de entrevistas que enfatiza e acelera o trabalho em equipe entre o usuário
e os técnicos. Os principais usuários e o pessoal da análise de
sistemas agrupam-se em uma intensiva reunião para determinar os objetivos do sistema e as transações
comerciais a serem suportadas. Eles são liderados ou supervisionados por um especialista treinado, que pode
conduzir o grupo para objetivos bem definidos. Os resultados incluem um protótipo do sistema proposto.
7.2.
Problemas Ocorridos nas Entrevistas
Falhas na atividade de levantamento das informações ou mal-entendidos entre usuário final e analista são
responsáveis por 50% dos erros de um projeto de desenvolvimento de sistemas.
Tem-se observado que a maioria dos problemas que ocorrem no desenvolvimento de um sistema não envolve
hardware ou software, mas sim o peopleware. Os maiores problemas são encontrados nas entrevistas e os mais
comuns são:
Entrevistar a pessoa errada:
Devido a problemas e interesses organizacionais, o analista corre o risco de ser levado a falar com o
perito oficial da função, que demonstra nada saber dos verdadeiros requisitos do sistema.
Entrevistar no momento errado:
Mesmo falando com o usuário certo, a entrevista pode ocorrer durante um período que o usuário
esteja muito ocupado ou envolvido com outros problemas emergenciais.
Fazer perguntas erradas: (e obter respostas erradas)
A diferença de vocabulário, experiências, percepções, valores, etc. existente entre analista
usuário facilita o erro na comunicação. É fácil o analista fazer uma pergunta racional sobre o
sistema e o usuário não entender absolutamente nada, sem os dois perceberem o fato. É fácil
também, o usuário dar algumas informações ao analista e este, por sua vez, nada entender. As
ferramentas de modelagem são uma tentativa de fornecer uma linguagem comum e sem
ambiguidades para diminuir esses mal-entendidos.
Criar ressentimentos:
Podem ser criados ressentimentos recíprocos onde: o usuário pode deduzir que o objetivo do novo
sistema é tomar-lhe o emprego e o analista pode ressentir-se do modo como o usuário responde às
suas perguntas. Podem existir várias razões para o usuário não sentir-se à vontade em relação ao analista
e vice-versa, o que torna a comunicação muito mais difícil.
Discutir problemas de implementação e não os requisitos:
Isso normalmente ocorre quando o usuário está direcionado para os termos de implementação do sistema
atual e conhece alguma coisa de tecnologia de computadores. O analista deve lembrar que não é sua
obrigação, em uma entrevista de análise, discutir sobre características de implementação do
sistema, a não ser que sejam muito importantes.
Confundir sintomas com problemas:
A queixa do usuário é um sintoma ou um problema, dependendo do relacionamento dela com os
parâmetros do sistema. O importante é descobrir o problema, e tratá-lo dentro dos limites do
sistema.
Dificuldade do usuário em explicar o que ele quer:
O usuário pode ser incapaz de explicar o que quer do sistema ou mudar de opinião sobre o que ele
mesmo já definiu. Quanto maior for esse problema, mais importante torna-se a prototipação ou
utilização de modelos gráficos.
Desentendimento entre usuários de mesmo nível, subordinados e chefes:
Essa situação coloca o analista no papel de mediador, negociador entre as partes em
desentendimento. O analista não pode abdicar desse papel; ele deve conduzir todos a uma sala, e
conversando, tentar chegar a um consenso.
7.3.
Diretrizes para Realização de Entrevistas
Desenvolver um plano geral de entrevistas:
É muito importante descobrir quem deve ser entrevistado. Para auxiliar o analista é interessante que se tenha
um organograma da empresa que mostre as pessoas da organização usuária, bem como a hierarquia
entre elas. No organograma pode não aparecer a pessoa que mais sabe a respeito de algum aspecto do
sistema por ser um funcionário operacional. Mas aparecem os superiores que indicam o caminho ao
analista. É necessário também, conversar com os usuários na sequência adequada e na ordem certa. É o caso
de funções desempenhadas simultaneamente por duas pessoas; é interessante que essas duas pessoas sejam
entrevistadas também simultaneamente.
Obter autorização para falar com os usuários:
Em organizações menores ou informais essa autorização não é necessária. Porém, em empresas
grandes, não é politicamente comum realizar entrevistas sem prévia autorização. A autorização virá
do encarregado de um setor usuário ou do representante nomeado pela equipe de
desenvolvimento que terá essa função.
Planejar a entrevista:
É necessário o planejamento da entrevista para que se faça um bom uso do tempo. O analista deve
compreender que está tomando tempo do usuário e que ele (ou o chefe dele) pode achar que está
desperdiçando tempo.
Colete, antes da entrevista, tantos dados relacionados ao assunto quanto for possível; prepare suas
perguntas antecipadamente e se possível, remeta-as ao usuário com um ou dois dias de antecedência; marque uma
reunião posterior para certificar-se de seu próprio entendimento e das reais necessidades do usuário.
Os dados colhidos serão manipulados, documentados, analisados, e passarão para uma notação que o usuário pode
nunca ter visto. Daí faz-se necessária a reunião posterior a entrevista, permitindo que você certifique-se que:
• não cometeu nenhum engano em seu entendimento;
• o usuário não mudou de opinião;
• o usuário entende a notação ou representação gráfica dessas informações.
Utilizar ferramentas adequadas:
Pode ser conveniente usar ferramentas de modelagem, mas sem abusos, pois o objetivo das
ferramentas é facilitar as discussões e não complicá-las.
Tentar enxergar em quais informações o usuário está mais interessado:
A ordem em que o analista obtém as informações costuma não ter muita importância, mas pode
significar muito para o usuário. Deixe o usuário começar a entrevista por onde ele preferir. Alguns
desejarão começar pêlos relatórios, outros poderão estar mais interessados nas informações de
entrada, e outros ainda preferirão falar sobre os detalhes dos dados de um depósito de dados. É
importante enxergar os requisitos do sistema da perspectiva desses usuários, e manter essa
perspectiva em mente durante a entrevista.
Usar um estilo adequado de entrevistar:
Fazer perguntas detalhadas não é fácil. É bom conhecer alguns estilos para extrair as informações
necessárias:
Relacionamentos: Peça ao usuário para explicar a relação entre o assunto que está em discussão e as
demais partes do sistema. Se ele estiver falando sobre uma função peca-lhe que explique seu
relacionamento com outras funções. Isso não só auxilia você a descobrir mais detalhes como o
ajudará a descobrir interfaces e relacionamentos entre os dados e processos.
Pontos de vista alternativos: Peça ao usuário que descreva o ponto de vista de outros usuários (seu chefe ou seu
subordinado) em relação ao que está sendo discutido.
Detalhamento: Solicite do usuário uma descrição informal sobre o que você estiver interessado. Dependências:
Pergunte ao usuário se a existência do item em discussão depende de alguma outra coisa.
Confirmação: Diga ao usuário o que você acha que ouviu ele dizer, usando suas próprias palavras e peça
confirmação.
Como disse William Davis (1983):
"Sua atitude em relação à entrevista é importante na determinação de seu sucesso ou fracasso. Uma entrevista não
é uma competição. Evite ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não uma
tentativa de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nem indiretamente. Uma
entrevista não é um julgamento. Faça perguntas detalhadas, mas não faça perguntas para confirmar outras
respostas. Lembre-se que o entrevistado é o perito e que é você que precisa de respostas. Para concluir, de
modo algum critique a credibilidade de outras pessoas."
7.4.
Formas Alternativas de Coleta de Dados
As entrevistas não são o único meio de coletarmos informações sobre um sistema. Podemos citar ainda:
• Questionários: Podem ser remetidos questionários escritos para os usuários ou setores que interagem
com o sistema.
• Demonstrações feitas por fornecedores: Solicitar demonstrações de sistemas prontos, desenvolvidos
por fornecedores de hardware ou software pode auxiliar não só na decisão pelo produto, como
também revelar funções e dados que não haviam sido notados pelo analista.
• Visitas a outras instalações: É interessante visitar outras empresas do mesmo ramo que possuem
sistemas semelhantes ao que está em desenvolvimento. Combine a visita para obter informações
diretas sobre as características e aptidões do sistema.
• Pesquisa externa: Se você estiver desenvolvendo um sistema para uma nova aplicação e
trabalhando com usuários que não são experientes na descrição de requisitos, talvez seja
interessante tentar obter informações em sociedades profissionais ou em periódicos e livros
técnicos, e em relatórios de pesquisas.
8. Ferramentas de Modelagem da AnáliseEstruturada
Existem diferentes tipos de modelos que podemos desenvolver.
O termo modelo representa um conceito que você tem usado por toda sua vida. Veja!
Exemplos de Tipos de Modelos:
Mapas:
modelos bidimensionais do mundo em que vivemos
Globos:
modelos tridimensionais do mundo em que vivemos
Fluxogramas:
representações esquemáticas de decisões e sequência de atividades
Desenhos Arquitetônicos:
representações esquemáticas de edifícios ou pontes
Maquetes:
representações tridimensionais de edifícios ou pontes
Pautas Musicais:
representações gráficas/textuais das notas musicais e tempo de uma peça musical.
Por que devemos construir modelos do sistema que será desenvolvido?
Para realçar ou enfatizar as características mais importantes de um sistema, e poder comunicar-nos de
uma maneira clara com o usuário e com a equipe de desenvolvimento, impedindo distrações com
aspectos irrelevantes do sistema.
A maior parte do trabalho do analista de sistemas envolve a modelagem do sistema que o usuário deseja. Os
modelos de análise de sistemas são, na maior parte, representações abstratas daquilo que eventualmente se tornará
uma combinação de hardware e software de computadores.
Assim, o analista usa ferramentas de modelagem para focalizar a atenção nas características importantes do sistema,
discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco e verificar se realmente
entendeu o ambiente e necessidades a serem supridas, de uma maneira que possa se fazer entender pêlos projetistas e
programadores que construirão o sistema.
Nem todas as ferramentas de modelagem cumprem essas finalidades. Uma descrição narrativa de 500 páginas dos
requisitos do usuário (que é, na realidade um modelo) torna:
• completamente obscuras todas as características do sistema;
• a construção do sistema mais cara do que o próprio modelo e
• difícil o entendimento pelo analista, sobre as reais necessidades do sistema.
8.1. Características de uma Ferramenta de Modelagem Útil ao Analista
• O analista pode utilizar qualquer modelo que lhe seja útil conforme a situação em que se encontrar.
• Diferentes usuários podem precisar de diferentes ferramentas de modelagem pela experiência anterior ou por
considerarem certos diagramas confusos e inibidores.
• Diferentes projetos podem exigir diferentes ferramentas face aos padrões de documentação impostos
por organizações externas.
• Diferentes tipos de sistemas podem exigir modelos diferentes para realçar adequadamente as
características importantes.
Qualquer ferramenta a ser utilizada deve ter as seguintes características:
• Ser gráfica;
• Permitir que o sistema possa ser visualizado de forma subdividida (modular), seguindo a abordagem Top
Down (da forma geral para o específico);
• Permitir desenvolver a modelagem do sistema com a mínima redundância;
• Ajudar o leitor a prognosticar o comportamento do sistema;
• Ser de fácil interpretação.
A maioria das técnicas e ferramentas de modelagem de sistemas mais conhecidas apoia-se em gráficos. O uso
de gráficos não é obrigatório em um modelo de sistema, porém, o velho ditado popular de que "uma figura vale por
mil palavras" é uma boa justificativa para se dar preferência aos gráficos em lugar de textos narrativos.
Isso não significa que uma figura possa descrever, necessariamente tudo sobre um sistema. Geralmente
usamos gráficos para identificar os componentes de um sistema e as interfaces entre eles.
Os outros detalhes (respostas para "Quantos?", "Em que seqüência?", etc.) são apresentados em documentos
textuais de apoio. Mais à frente veremos os seguintes documentos textuais: Dicionário de Dados e
Especificação do Processo.
Isso não significa que todos os analistas de sistemas devam usar o conjunto de ferramentas de modelagem
orientadas para gráficos e textos apresentados neste material.