PROJETO
ESTRUTURADO
Prof° Mozart de Melo Alves Jr.
EMENTA


Metodologia de Desenvolvimento de Sistemas.
Análise da Situação Atual e dos Requisitos do
Sistema. Ciclo de Vida de Sistemas. Análise
Essencial de Sistemas. Diagrama de Fluxo de
Dados. Dicionário de Dados. Descrição de
Funções Primitivas. Estudo de Casos com a
aplicação da Análise Essencial de Sistemas.
caracterização e aplicação de metodologias e
ferramentas de modelagem de sistemas
orientados a objetos - UML
O PAPEL DE UM ANALISTA


Ser o elo entre o usuário e o computador
Deverá entender e avaliar as
necessidades e expectativas de cada
usuário, a fim de que estas sejam
organizadas e especificadas segundo
uma formalidade técnica.
ADMINISTRADOR
(Respostas sempre e para ontem, geralmente é o dono)
Analista de Sistema
Usuário
(Dinamizar o Serviço)
tem influência na direta
derruba ou ajuda o sistema
Pessoal Técnico
(Performance Plataforma)
elo técnico entre o analista
e a empresa
O REQUISÍTOS DE UM
ANALISTA








Iniciativa
Criatividade
Concentração
Persuasão
Autoconfiança
Ação conciliadora
Espírito de Grupo
Sensibilidade







Persistência
Determinação
Flexibilidade
Percepção
Clareza de
Raciocínio
Simplicidade
Comunicativo
A Maior desvantagem
em estabelecer uma
lista de requisitos, é
que jamais encontrase alguém que venha
a possuir todos eles.
OBSERVAR ALGUMAS DIRETRIZES







Procure ser aceito profissionalmente, do nível mais
alto ao mais baixo da empresa.
Tente entender o que o cliente “Quer Dizer” e não o
que “Você Pensa” que ele quer dizer.
Escute muito primeiro, fale muito pouco depois
(desenvolva grandes orelhas e boca pequena)
Esteja sempre familiarizado com os últimos
progressos da tecnologia de informação e
compreenda como aplicá-los.
Seja capaz de explicar conceitos complexos em
termos simplificados fale a linguagem da empresa.
Conheça a área de negocio, para a qual
desenvolverá sistemas.
Analise sempre a relação custo (Benefício, Utilizando
alternativas viáveis).
Sistemas de Informações

A necessidade é a mãe das invenções

Em conseqüência do crescimento da
importância da informação, surgiu a
necessidade de gerenciar informações de uma
forma adequada e eficiente e, desta
necessidade, surgiram os denominados
sistemas de informações.
Sistemas de Informações



Um SI é uma combinação de pessoas, dados,
processos, interfaces, redes de comunicação e
tecnologia que interagem com o objetivo de dar
suporte e melhorar o processo de negócio de
uma organização com relação às informações.
Gerando Vantagens do ponto de vista
competitivo.
Objetivo principal e final da construção de um
SI: adição de valor – Aumentando a
produtividade ,
Sistemas de Software


Um dos componentes de um SI é denominado
sistema de software.
Compreende os módulos funcionais
computadorizados que interagem entre si para
proporcionar a automatização de diversas
tarefas.
Modelagem de sistemas

Característica intrínseca do desenvolvimento
de sistemas de software: complexidade de
desenvolvimento.
Sistemas de Software

Uma analogia...
Casa de
Cachorro
Casa
Aumento da complexidade
Arranha-Ceús
Complexidade


Na construção de sistemas de software,
assim como na construção de sistemas
habitacionais, também há uma gradação
de complexidade.
A construção desses sistemas necessita de
um planejamento inicial.
Modelos


De uma perspectiva mais ampla, um
modelo pode ser visto como uma
representação idealizada de um sistema a
ser construído.
Maquetes de edifícios e de aviões e
plantas de circuitos eletrônicos
são apenas alguns exemplos
de modelos.
Razões para construção
de modelos




Gerenciamento da complexidade inerente
ao desenvolvimento de software (pode
haver modelos de um mesmo sistema,
cada modelo descrevendo uma
perspectiva do sistema a ser construído).
Comunicação entre as pessoas envolvidas.
Redução dos custos no desenvolvimento(
é muito mais fácil destruir uma maquete
do que uma parede).
Predição do comportamento futuro do
sistema(laboratório).
Diagramas



No contexto de desenvolvimento de
software, correspondem a desenhos
gráficos que seguem algum padrão lógico.
Esses desenhos são normalmente
denominados diagramas.
Um diagrama é uma apresentação de uma
coleção de elementos gráficos que
possuem um significado predefinido.
Diagramas



Diagramas fornecem uma representação concisa
do sistema. “uma figura vale por mil
palavras”.
No entanto, modelos também são compostos de
informações textuais.
Dado um modelo de uma das perspectivas de
um sistema, diz-se que o seu diagrama,
juntamente com a informação textual associada,
formam a documentação deste modelo.
Modelagem de Software
A modelagem de sistemas de software
consiste na utilização de notações gráficas
e textuais com o objetivo de construir modelos
que representam as partes essenciais de um
sistema, considerando-se diversas perspectivas
diferentes e complementares
O Processo de
Desenvolvimento
de Software
Sendo um sociólogo, constatei que o
desenvolvimento de software é um processo
social altamente cooperativo.
Jorg Strubing, 1991
“Software is hard…”




Porcentagem de projetos que terminam
dentro do prazo estimado: 10%
Porcentagem de projetos que são
descontinuados antes de chegarem ao
fim: 25%
Porcentagem de projetos acima do custo
esperado: 60%
Atraso médio nos projetos: um ano.
Chaos Report (1994)
“Software is hard…”





Software pago mas não entregue: 29.7%
Software que pode ser usado quando
entregue: 2%
Software entregue mas nunca usado:
47%
Software usado mas posteriormente
modificado ou abandonado: 19%
Software que podia ser usado após feitas
mudanças: 3%
GAO Survey (1992)
Processo de Desenvolvimento


Compreende as atividades necessárias
para definir, desenvolver, testar e manter
um produto (sistema) de software.
Tentativas de lidar com a complexidade e
de minimizar os problemas envolvidos no
desenvolvimento de software.
Objetivos de um Processo de
Desenvolvimento




Definir quais as atividades a serem
executadas ao longo do projeto;
Quando, como e por quem tais atividades
serão executadas;
Prover pontos de controle para verificar o
andamento do desenvolvimento;
Padronizar a forma de desenvolver
software em uma organização.
Atividades típicas






Levantamento de requisitos
Análise de requisitos
Projeto
Implementação
Testes
Implantação
Participantes do processo







Gerentes de projeto
Analistas
Projetistas
Arquitetos de software
Programadores
Clientes
Avaliadores de
qualidade
Participantes do usuário

A participação do usuário é importante.
Modelos de ciclo de vida
Modelo de Ciclo de Vida


Um ciclo de vida corresponde a um
encadeamento específico das fases para
construção de um sistema.
Dois modelos de ciclo de vida:


modelo em cascata
modelo iterativo e incremental.
Modelo de Ciclo de Vida em
Cascata

Tendência na progressão seqüencial
entre uma fase e a seguinte.
Modelo de Ciclo de Vida em
Cascata


Projetos reais raramente seguem um
fluxo seqüencial.
Assume que é possível declarar
detalhadamente todos os requisitos antes
do início das demais fases do
desenvolvimento.


propagação de erros pelas as fases do
processo.
Uma versão de produção do sistema não
estará pronta até que o ciclo do projeto
de desenvolvimento chegue ao final.
Modelo de ciclo de vida iterativo e
incremental




Divide o desenvolvimento de um produto
de software em ciclos.
Em cada ciclo de desenvolvimento,
podem ser identificadas as fases de
análise, projeto, implementação e testes.
Cada ciclo considera um subconjunto de
requisitos.
Esta característica contrasta com a
abordagem clássica, na qual as fases são
realizadas uma única vez.
Modelo de ciclo de vida iterativo e
incremental

Desenvolvimento em “mini-cascatas”.
Modelo de ciclo de vida iterativo e
incremental


Iterativo: o sistema de software é
desenvolvido em vários passos similares.
Incremental: Em cada passo, o sistema
é estendido com mais funcionalidades.
Modelo iterativo e incremental –
Vantagens e Desvantagens
Incentiva a participação do usuário.
 Riscos do desenvolvimento podem ser
mais bem gerenciados.
 Um risco de projeto é a possibilidade de

ocorrência de algum evento que cause
prejuízo ao processo de desenvolvimento,
juntamente com as conseqüências desse
prejuízo.
 Influências: custos do projeto,cronograma,
qualidade do produto, satisfação do cliente,
etc.
 Mais difícil de gerenciar
Ataque aos riscos

“Se você não atacar os riscos [do
projeto] ativamente, então estes irão
ativamente atacar você.” (Tom Gilb).


Ou seja, a abordagem incremental e iterativa
aconselha que as partes mais arriscadas sejam
consideradas inicialmente.
Não se esconda dos riscos (como um avestruz).
Análise Essencial
Desenvolver sistemas de informação não é
desenvolver programas
Motivado,
normalmente
por
“necessidades
de
última
hora”,
situações de emergência, necessidades
não antecipadas, (enfim ingerências,
desorganização,
falta
de
planejamento)
as
empresas
se
lançam na aventura de construir
remendos para alicerçar suas bases
para
tomadas
de
decisão,
e
normalmente, tornam-se reféns dos
aspectos que seguem:
38





Não
há
planejamento
de
qualquer
natureza,
isto
compromete,
futuras
expansões, integrações e visão corporativa.
Apenas uma pessoa detém o “conhecimento”
sobre determinado desenvolvimento
Esta “memória do conhecimento” começa
a apresentar problemas quando há um
crescimento do sistema.
Normalmente há problemas quando se
trata de efetuar manutenção naquilo que
foi desenvolvido
Em geral não há qualquer documentação
sobre o desenvolvimento, assim, qualquer
intervenção no mesmo, requer a leitura dos
programas fontes para se entender o que o
sistema faz exatamente
39
“ o objetivo básico do estabelecimento de
um
método
padronizado
no
desenvolvimento de sistemas é obter
maior consistência no trabalho, melhor
qualidade oferecida ao usuário, maior
facilidade no treinamento de novos
Analistas,
eliminação
das
perdas
acarretadas por caminhos sem saída
e,
sem dúvida, melhor controle dos
resultados obtidos no desenvolvimento de
sistemas.”
BALLESTERO ALVAREZ (1990)
40
O método que revela o estado da prática atual
é a chamada Análise Essencial. Na Análise
Essencial, deve-se considerar perfeito o ambiente
tecnológico onde será implementado o software a
ser
projetado
(princípio
da
neutralidade
tecnológica). Isto significa considerar que a
memória do computador é infinita, seu tempo de
resposta é instantâneo, ele não para (não trava),
não
tem
custo,
ou
seja,
é
infalível.
Este aspecto propicia a análise pensar em uma
solução ideal, no desenho do software, fazendo
com que não sejam considerados certos requisitos
impostos pelas restrições tecnológicas.
41
O método da Análise Essencial é uma evolução
da Análise Estruturada, a qual o antecedeu. Pode-se
sublinhar alguns fatores de seu uso:


Um dos mais
atualmente.
utilizado
métodos
Princípio da Abstração
– Este aspecto permite resolver o problema,
separando os aspectos que estão ligados a
certa realidade, visando representá-los de
forma simplificada e geral.

Princípio da divisão.
– Para resolver um problema, o mesmo é
dividido em um conjunto de problemas
menores, que são mais fáceis de serem
compreendidos e resolvidos.
42
O caminho da
Análise Essencial
43
Domínio do Problema

O primeiro momento, de altíssima importância é
delimitar exatamente o que se espera do sistema
a ser desenvolvido. Trata-se de estabelecer seus
limites fronteiriços, exatamente o que deverá ser
feito.
Por exemplo, alguém pode solicitar seus serviços para
informatizar
um hotel. Mas veja, um hotel é sem
dúvida um macro problema. Ele é composto de várias
facetas que podem ser informatizadas, como o controle
da locação de quartos, o controle financeiro (contas a
pagar/receber), a folha de pagamento dos funcionários,
a contabilidade do hotel, enfim, é necessário que você
verifique se a expectativa de quem o contratou é
realmente informatizar todas estas facetas.
44
Todos os aspectos envolvidos no
problema
devem
ser
levantados,
pessoas
devem
ser entrevistadas,
documentos devem ser avaliados, o
fluxo de trabalho deve ser entendido.
Você deverá sair desta fase sendo
quase
um
especialista
sobre o
assunto que deverá informatizar, ou
seja, no mínimo saberá todos os
eventos e dados essenciais relativos ao
assunto.
45
Vantagens da
Análise Essencial
A Análise Essencial começa pelo modelo
essencial, o que equivale, na Análise
Estruturada, começar diretamente pelo
modelo lógico proposto.
A
Análise
Estruturada
aborda
duas
perspectivas do sistema - função e dados -,
ao passo que a Análise Essencial aborda três
perspectivas - função, dados e controle.
 Na Análise Estruturada o particionamento é
feito através da abordagem top-down,
enquanto
na
Análise
Essencial,
o
particionamento é por eventos

Componentes da
Análise Essencial
Modelo
Ambiental
Declaração de
Objetivos
Diagrama de
Contexto
Análise
Essencial
Modelo
Comportamental
Lista de Eventos
DFD
Particionado
Diagrama ER
Normalização
Dicionário
de
Dados
Especificação dos Requisitos

Modelo Ambiental
– Você poderá definir qual a relação do sistema a ser
desenvolvido com o ambiente no qual ele estará
inserido.
– Define a fronteira entre o sistema e o resto do mundo

Modelo Comportamental
– Trabalho se volta para definição interna do sistema.
Serão
especificados todos os processos que irão
compor o sistema. Haverá também a definição do
modelo de dados que será utilizado para armazenar as
informações por ele manipuladas.

Projeto ( Design)
– Esta parte do trabalho cuidará das especificações
referentes as limitações impostas pela tecnologia, a
distribuição dos processos de acordo com os lugares
onde serão executados.
48
Ferramentas
O Analista de Sistemas,
deverá utilizar algumas
ferramentas que o
ajudarão a trilhar o seu
caminho.
Entrevistas


A reunião pode ter um momento de
questionamentos, na busca de
informações; ou seja, uma entrevista,
normalmente sem qualquer conotação de
rigor ou formalidade como o termo pode
sugerir.
Entrevistas portanto, são situações inseridas
nas relações humanas que não estão sujeitas
a regras ou fórmulas exatas. Mas, pode
ser útil que o Analista de Sistemas tenha
em mente alguns aspectos, relacionados a
esta atividade que poderão ajudar na sua
execução.
50
O objetivo de uma entrevista (para a
análise de sistemas) é o de coleta de
informações sobre o sistema a ser desenvolvido.
Talvez, seja esta a fonte mais rica de
conhecimentos
sobre o sistema que deverá
ser feito. Ajuda nos aspectos chaves do
sistema
bem
como esclarece
pontos
contraditórios do mesmo, ou, em alguns
casos, torna o aspecto mais contraditório, o
que é algo também importante de se conhecer.
Verifica-se posicionamentos pessoais acerca das
questões envolvidas (omissões, medo, desvios).
 Não
raro, haverá a necessidade de se
entrevistar diversas vezes uma ou várias
pessoas, para se chegar a informação desejada.

51
Como Preparar uma Entrevista
Alguns cuidados devem ser tomados:
 Clareza
de sua finalidade
 Identificação de perguntas chaves
 Repasse de documentação formal (se
houver)
52


Quando se tratar de aspectos gerais sobre um
assunto, a pessoa mais indicada para se buscar esta
informação é a gerência. Quando o interesse for
para assuntos que exijam maior riqueza de
detalhes, o ideal
é
entrevistar
uma
pessoa
operacional, que esteja no seu dia a dia, envolvida com
aquele aspecto. Mas, lembre-se da hierarquia da
empresa, primeiro fale com o supervisor a quem a
pessoa estiver locada. Isto envolve desde aspectos
políticos até um fator de motivação para que a
pessoa fale melhor sobre o assunto, visto que “o
chefe a indicou por ser a melhor funcionária que
domina aquela questão...”.
Programe a entrevista de acordo com a disponibilidade
do entrevistado.
53
Toda entrevista bem conduzida,
formal ou não, possui três aspectos:

Abertura
– procure estabelecer uma atmosfera amigável
para a comunicação, informe sobre o objetivo.

Corpo
– se caracteriza por ser a entrevista propriamente dita.
– Certifique-se de que entendeu o que lhe foi
transmitido. Um meio indicado é o repasse (deixa
ver se entendi, então quer dizer que...).

Fecho
– procure manter a atmosfera de comunicabilidade.
Esteja atento ao horário para evitar qualquer
transtorno ao entrevistado. Agradeça a colaboração,
mesmo que o encontro tenha sido infrutífero e
54
distante do planejado.
Entrevista
não
é
julgamento,
disputa do saber ou concorrência
com o entrevistado. Lembre-se
sempre
que
a
pessoa
é
a
especialista
no
que
faz
e
você apenas busca informações.
Procure distinguir fatos de opiniões
pessoais.
55
Modelo de entrevista segundo
Gaus e Weinberg (1989)
1. O primeiro conjunto de questões de
contexto livre focaliza o cliente, as metas
globais e os benefícios. Por exemplo o
analista poderia perguntar
a. Quem está por trás da solicitação deste trabalho ?
b. Quem vai usar a solução?
c. Qual será o benefício econômico ?
d. Há outra fonte para solução ?
56
Modelo de entrevista segundo
Gaus e Weinberg (1989)
2. O conjunto de questões a seguir permite
ao analista entender melhor o problema
e ao cliente verbalizar suas percepções
sobre a solução :
a. Quais problemas a solução vai resolver ?
b. Você pode me mostrar o ambiente ( estrutura
física) ?
57
Modelo de entrevista segundo
Gaus e Weinberg (1989)
3. O conjunto final de questões focaliza a
efetividade da reunião (metaquestão)
a. É a pessoa adequada para responder as questões ?
b. As repostas são oficiais ?
c. Eu estou fazendo pergunta demais ?
d. Alguém mais pode me dar informação adicional ?
e. Eu deveria perguntar mais alguma coisa ?
58