Os atores presentes
no desenvolvimento de
sistemas




Desafio: escrever, ensaiar e contar uma história
interessante em no máximo 5 minutos.
um patrocinador – o que sabe ler e narrar uma
história; seu objetivo é apresentar muito bem a
história.
um administrador – o que produz o show;
preocupa-se com o tempo e faz as coisas
acontecerem; se a folha de produção não for
entregue em 15 minutos, não ganha ponto.
um projetista – o criador da história que o
patrocinador conta; o objetivo dele é que a história
seja interessante.
um controlador de qualidade que aprova a história
a ser contada; seu objetivo é se divertir.
O usuário




entende do problema
para ele, um bom sistema é aquele que o
ajuda a resolver todos os seus problemas.
não se preocupa com o custo de
desenvolvimento.
não se preocupa com o prazo de
desenvolvimento.
Projetista





pode ser o líder do projeto, ou o programador,
ou até mesmo o analista de sistemas
é quem entende dos aspectos técnicos do
desenvolvimento de sistemas.
sabe programar
sabe metodologia de desenvolvimento
o melhor sistema é aquele que é simples e que
faça o mínimo possível.
O patrocinador







é o campeão do sistema
defende a realização da empreitada
se a empreitada for bem sucedida,
fica com os louros da vitória.
se a empreitada for mal sucedida,
joga a culpa nos desenvolvedores.
para ele, o melhor sistema é aquele que dá
grandes resultados para a empresa.
O administrador


Preocupa-se com o custo do
desenvolvimento
Para ele, o melhor sistema é aquele que
tem o custo previsto no orçamento.
Fatores que afetam
positivamente o desenvolvimento
de sistemas
Especificação e Projeto de
Sistemas
Bom entendimento dos problemas





quem sabe qual é o problema?
é o usuário do aplicativo.
é fundamental que haja envolvimento dos
usuários.
Por exemplo: fazer uma reunião toda segundafeira das 9h às 12h para discutir o aplicativo com
os usuários.
apresentar os problemas e principalmente ouvir
os usuários.
Apoio dos gerentes de alto nível


toda iniciativa de mudança precisa ter um
campeão interno, um patrocinador.
um plano de mudanças que leve mais do
que um mês para ser implantado precisa
de um campeão, geralmente um elemento
da alta gerência.
Projeto simples e direto




KISS – keep it simple, simple.
se o público-alvo não está entendendo o
que está acontecendo, não conte com ele.
a mudança deve ser incentivada.
uma interação eficaz com o sistema
merece prêmios.
Gerenciamento planejado das
mudanças



uma alteração num aplicativo propaga-se
para outros setores da empresa.
todos os afetados devem obter
treinamento bem preparado e adaptado
ao uso que faz do sistema.
treinamento é feito em horário do
expediente, na hora do trabalho e é
trabalho.
Utilização de técnicas consagradas


Programar requer técnica.
Existem metodologias de
desenvolvimento.
Problemas potenciais
Resolver o problema errado





não envolver o usuário
não mostrar o que já foi feito para
aprovação do usuário
não pedir a aprovação do usuário
não preparar a especificação do sistema
não pedir a aprovação do usuário para a
especificação do sistema.
Definição mal-feita




a especificação foi mal preparada.
a especificação não foi aprovada pelo
usuário.
a solução levou tanto tempo para ser
implementada que o problema mudou.
a comunicação é deficiente entre
desenvolvedores e usuários.
Projeto ambicioso demais



o estudo de viabilidade prévio foi mal
feito.
o trabalho de projeto foi mal
dimensionado.
o levantamento de recursos foi falho.
Falta de apoio da alta
administração



o lider do projeto se isolou.
os resultados obtidos não foram levados
para a alta administração.
faltou comunicação e senso político.
Falta de preocupação com a
manutenção futura




o programa foi várias vezes remendado ao
longo do desenvolvimento.
o lider mudou ao longo do
desenvolvimento.
os programadores não seguiram um estilo
único de programação.
não foi gerada documentação do sistema.
O que é manutenção de um
sistema?



um sistema não sofre desgaste.
a necessidade de manutenção surge em
reação a algo inesperado.
o inesperado pode ser



um “bug” do sistema (um erro)
uma mudança nas regras
uma situação inesperada
Tipos de manutenção

um “bug” no sistema:
 manutenção corretiva

uma mudança nas regras:
 manutenção preventiva
 uma
situação inesperada:
 manutenção adaptativa



Quem deve executar a manutenção?
Quem deve testar um sistema?
O que é um teste bem sucedido?
O que é um teste bem sucedido?

Um teste bem sucedido é aquele que
consegue detetar erros no sistema.
Quem deve testar um sistema?

O programador do sistema é a pessoa
menos adequada para ser o testador,
porque até inconscientemente ele vai
procurar não encontrar erros na sua obra.
Quem deve executar a
manutenção?

A manutenção deve ser feita por qualquer
um, exceto pelo programador, que deve
emitir documentação técnica no nível
necessário para que seja prescindível
durante a fase de manutenção e possa se
dedicar a outras tarefas mais impolgantes.
Exercício
Desafio: escrever, ensaiar e contar uma história
interessante em no máximo 5 minutos.

Montar equipes com




um patrocinador – o que sabe ler e narrar uma
história; seu objetivo é apresentar muito bem a
história.
um administrador – o que produz o show; preocupase com o tempo e faz as coisas acontecerem; se a
folha de produção não for entregue em 10 minutos,
não ganha ponto.
um projetista – o criador da história que o
patrocinador conta; o objetivo dele é que a história
seja interessante.
um controlador de qualidade que aprova a história a
ser contada; seu objetivo é se divertir.
Avaliação, análise e projeto de
sistemas
Avaliação
Análise
Projeto
Operação
Implementação
Construção e
Teste
Avaliação




Trata-se da verificação rápida da
viabilidade de se investir no
desenvolvimento
viabilidade técnica
viabilidade financeira
viabilidade de oportunidade e época
Requisitos essenciais da avaliação







descrição sucinta do sistema em 10 linhas
objetivos do sistema proposto
declaração de viabilidade técnica
plano de trabalho
levantamento dos recursos previstos
levantamento dos resultados esperados
declaração de viabilidade financeira
Avaliação – características
importantes



deve ser rápida
ancora um idéia, uma noção
produtos da fase:


se o sistema for viável: declaração de
viabilidade e plano de trabalho
se o sistema não for viável: declaração de
inviabilidade e recomendações para o futuro.
Plano de trabalho



atividades a serem realizadas, fase a fase
recursos previstos para cada atividade
produtos desejados de cada atividade
Reunião de conclusão do estudo de
viabilidade

formalização do compromisso de tocar o
projeto adiante
Análise do sistema

trata-se da especificação da arquitetura do
sistema, envolvendo:




entradas
saídas
interfaces em geral entre o usuário e o
sistema
interfaces em geral entre o sistema e outros
sistemas externos
Especificação de sistemas



É um documento que define como se deseja que
uma aplicação funcione para o usuário.
Detalha o que a aplicação fará, como será a
interface entre o usuário e o sistema e como
serão apresentados os resultados.
Facilita o trabalho do programador, que só
precisará se preocupar com a lógica interna.
Aspecto formal da especificação



A especificação define o que o cliente
deseja receber.
Ela facilita a comunicação entre o
programador e o cliente.
Ela aumenta a visibilidade do produto final
a ser entregue.
Perguntas a serem respondidas
pela especificação



O que é a aplicação a ser desenvolvida?
O que deve fazer a aplicação a ser
desenvolvida? Quem utilizará a aplicação?
Quais são as metas quantitativas a serem
atingidas pela aplicação? Existe um
modelo (ou anti-modelo) para a aplicação
a ser desenvolvida?
As 4 ETAPAS DA ESPECIFICAÇÃO




Descrição do ambiente do problema
Definição do domínio do sistema
Especificação do fluxo de informações
Layout dos elementos de interface
Definição do ambiente do problema


Uma breve descrição dirigida para o
programador, dando uma idéia geral dos
tipos de transação que ocorrem no
ambiente em questão.
Dependendo do tipo de aplicação, a
descrição pode ter alguns parágrafos ou
algumas páginas.
Definição do escopo da aplicação


Estabelece o que deve fazer parte da
aplicação e o que não deve fazer parte
dela.
Idealmente, a melhor forma de
estabelecer o escopo é através de um
Diagrama de Fluxo de Dados (DFD), onde
o lado exterior à aplicação está
representado por entidades externas.
Especificação do fluxo de
informações




Quais são os produtos da aplicação?
De que se compõe cada produto, isto é,
quais são os dados de saída?
Para se conseguir os dados de saída, quais
devem ser os dados de entrada?
Como e quando serão fornecidos os dados
de entrada?
Layout dos elementos de interface
Elementos de interface:
 Relatórios
 Telas de consulta
 Telas de entrada de dados
 Planilhas para preenchimento prévio
O que a analista queria
O que o projetista sugeriu
O primeiro protótipo
A implementação
A versão instalada
O que o usuário de fato queria