22
Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Embed Size (px)

Citation preview

Page 1: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Análise e Projeto de Sistemas I

Profa. Ana Karina BarbosaFevereiro/2007

Page 2: 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

Page 3: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

O que constitui um sistema de informática?

SISTEMA

SOFTWARE

BASE DE DADOS

HARDWARE

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.

Page 4: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 5: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 6: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 7: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 8: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Como tratar as causas dos problemas? Seguir um processo de desenvolvimento.

É fundamental a definição de quem faz o quê, quando e como.

Um conjunto de passos parcialmente ordenados, constituídos por atividades,

métodos, práticas e transformações, usado para atingir uma meta

O QUE É UM PROCESSO?

Page 9: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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 DEUM PROCESSO É A ESCOLHA DE UM MODELO DE CICLO DE VIDA

Page 10: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 11: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Ciclo de Vida Clássico - Modelo Cascata

Análise

Projeto

Codificação

Teste

Page 12: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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

Page 13: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 14: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 15: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

Aplicação do modelo cascata iterativamente

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.

AnáliseProjeto

CodificaçãoTeste

tempo

AnáliseProjeto

CodificaçãoTeste

Page 16: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 17: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 18: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 19: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 20: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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

Page 21: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.

Page 22: Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007

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.