Análise e Projeto de Sistemas
I
Profa. Ana Karina Barbosa
Fevereiro/2007
Análise e Projeto de Sistemas Orientado
a Objetos - a disciplina

Avaliação
– 1o Exercício Escolar - Prova
– 2o Exercício Escolar - Projeto em grupo

Metodologia
–
–
–
–
Aulas Expositivas
Anotações de aula
Listas de Exercícios
Acompanhamento de Projeto
O que constitui um sistema de informática?
SISTEMA
SOFTWARE
HARDWARE
BASE DE DADOS
REDES
O software é a parte programável de um sistema de
informática. Ele é um elemento central: realiza estruturas
complexas e flexíveis que trazem funções, utilidade e valor ao
sistema. Mas os outros componentes são indispensáveis.
Foco da Disciplina
Análise e Projeto do Software.
 Na prática, o analista será chamado
com freqüência a resolver questões
pertinentes aos outros componentes do
sistema ou, no mínimo, encontrar quem
as resolva. Alguma proficiência nas
respectivas disciplinas lhe será
necessária.

Realidade de Hoje
Grande demanda para desenvolvimento
de aplicações não triviais.
 Rápida evolução tecnológica.
 Tempo de desenvolvimento deve ser
curto.
 Falta de tempo para amadurecimento
dos profissionais.
 Equipes grandes.

Algum problema?









Software que não atende aos requisitos.
Software com bugs.
Tempo e orçamento estourados.
Entendimento não preciso das necessidades do
usuário.
Dificuldade na mudança dos requisitos.
Módulos que não se encaixam perfeitamente.
Dificuldade de manutenção dos sistemas.
Descoberta tardia de sérios problemas no projeto.
Performance inadequada.
Por que esses problemas
acontecem?









Gerência de requisitos insuficiente.
Comunicação ambígua e insuficiente.
Arquiteturas frágeis.
Complexidade dos sistemas.
Inconsistência entre requisitos, projeto e
implementação não detectados.
Testes insuficientes.
Avaliação subjetiva da situação dos projetos.
Propagação de mudanças descontrolada.
Automação insuficiente.
Como tratar as causas dos
problemas?

Seguir um processo de desenvolvimento.
O QUE É UM PROCESSO?
Um conjunto de passos parcialmente
ordenados, constituídos por atividades,
métodos, práticas e transformações,
usado para atingir uma meta

É fundamental a definição de quem faz o quê,
quando e como.
Características de um processo
eficiente

Orienta o desenvolvimento, operação e
manutenção do software.
 Reduz risco e aumenta previsibilidade.
 Permite controle sobre o desenvolvimento dentro de custos, prazos e níveis de
qualidade desejados.
O PONTO DE PARTIDA PARA A ARQUITETURA DE
UM PROCESSO É A ESCOLHA DE UM MODELO DE
CICLO DE VIDA
Ciclo de Vida Codifica-remenda




Os desenvolvedores começam a codificar prontamente.
À medida que os erros vão aparecendo, estes vão sendo
remendados.
Não exige sofisticação técnica nem gerencial.
Modelo de alto risco, impossível de gerir e que não permite
assumir compromissos confiáveis.
Ciclo de Vida Clássico - Modelo
Cascata
Análise
Projeto
Codificação
Teste
Modelo Cascata

Análise (Investigação)
– Para criar o sw de uma aplicação, é
necessária uma descrição do problema e
dos seus requisitos - o que é o problema e
o que o sistema deve fazer

Projeto (Solução)
– Enfatiza uma solução lógica, ou seja,
como o sistema deverá ser construído a
fim de atender os requisitos estabelecidos
Modelo Cascata

Codificação
– Nesta etapa, o projeto deve ser traduzido em uma
forma legível por máquina. Se o projeto for
executado detalhadamente, a codificação pode
ser executada mecanicamente.

Testes
– O processo de realização de testes concentra-se
nos aspectos lógicos internos do software,
garantindo que todas as instruções sejam
testadas. Sâo realizados testes para descobrir
erros e garantir que a entrada definida produza
resultados reais que concordem com os
resultados exigidos.
Modelo Cascata - Observações

Manutenção
– O software sofrerá mudanças depois que for
entregue ao cliente. Ocorrerão mudanças porque
erros foram encontrados, porque o sw deve ser
adaptado a fim de acomodar mudanças em seu
ambiente externo ou porque o cliente exige
acréscimos funcionais ou não-funcionais. A
manutenção de sw reaplica cada uma das etapas
precedentes do ciclo de vida a um programa
existente.

Análise X Projeto
– A divisão entre análise e projeto é vaga, por isso
não é de grande valia ser rígido quanto ao que se
constitui um passo de análise e um passo de
projeto.
Aplicação do modelo cascata
iterativamente
Análise
Análise
Projeto
Projeto
Codificação
Codificação
Teste
Teste
tempo





O sistema é desenvolvido por incrementos (subconjunto da
funcionalidade do sistema).
Versão executável é produzida ao final de cada iteração
Cada iteração inclui integração e teste.
O levantamento de requisitos da primeira iteração envolve a
definição do escopo do projeto como um todo. Iterações seguintes
incluem o detalhamento de requisitos já levantados ou até mesmo
levantamento de novos requisitos.
Em geral, uma iteração deve durar entre 2 semanas a 2 meses,
dependendo da duração total do projeto e experiência da equipe.
Características do modelo
iterativo






Riscos críticos são resolvidos antes que
grandes investimentos sejam realizados.
Permite feedback dos usuários desde cedo.
Teste e integração são atividades contínuas.
Pequenos objetivos, foco em curto-prazo.
Progresso é medido de forma mais concreta.
Implementações parciais podem ser
implantadas.
Modelagem Visual na Análise e
Projeto





Facilita entendimento.
Facilita comunicação entre a equipe.
Diminui ambiguidade. Diferentes membros da
equipe possam comunicar decisões sem
ambigüidade.
Facilita a gerência da complexidade.
O uso de uma ferramenta para a construção
dos diagramas facilita bastante o trabalho de
equipe.
UML - Linguagem de Modelagem
Unificada





Orientada a objetos.
Serve para especificar, modelar e
documentar um sistema.
Desenvolvida por Jim Rumbaugh, Grady
Booch e Ivar Jacobson.
Padronizada pela OMG (Object Management
Group).
Adotada como padrão na indústria de sw.
Análise de sistema

A análise de sistema é realizada com os
seguintes objetivos em mente:
– Identificar as necessidades do usuário.
– Avaliar a concepção do sistema quanto a sua
exeqüibilidade.
– Executar a análise econômica e técnica.
– Atribuir funções ao hardware, ao software, às
pessoas, ao banco de dados e aos demais
elementos do sistema.
– Estabelecer as restrições de prazo e de custo.
– Criar uma definição de sistema que constitua a
base para todo o trabalho de engenharia
subseqüente.
Análise de sistema

Quanto esforço deve ser despendido na
análise e definição de sistemas?
– Variáveis: o tamanho e complexidade do
sistema, área de aplicação, usuário final,
obrigações contratuais, etc.
– De 20 a 40% na análise do sistema
Análise de sistema

Quem o faz?
– Um analista experiente e bem treinado deve dirigir
a maioria das tarefas.
– O analista trabalha em conjunto com o pessoal
administrativo e técnico do cliente e com a equipe
de desenvolvimento de sistema.
– Para projetos muito grandes, uma equipe de
analistas de sistemas pode ser formada para
dirigir cada tarefa de análise.
Análise de sistema

Por que é tão difícil?
– Um conceito nebuloso deve ser
transformado em um conjunto concreto de
elementos tangíveis.
– Desentendimento, omissão, inconsistência
e erro são passíveis de acontecer.
– A percepção do sistema pode modificar-se
à medida que a atividade progride.