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

Apresentação em tema: "Análise e Projeto de Sistemas I Profa. Ana Karina Barbosa Fevereiro/2007."— Transcrição da apresentação:

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

2 Análise e Projeto de Sistemas Orientado a Objetos - a disciplina Avaliação –1 o Exercício Escolar - Prova –2 o Exercício Escolar - Projeto em grupo Metodologia –Aulas Expositivas –Anotações de aula –Listas de Exercícios –Acompanhamento de Projeto

3 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.

4 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.

5 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.

6 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.

7 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.

8 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?

9 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

10 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.

11 Ciclo de Vida Clássico - Modelo Cascata Análise Projeto Codificação Teste

12 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

13 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.

14 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.

15 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álise Projeto Codificação Teste tempo Análise Projeto Codificação Teste

16 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.

17 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.

18 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.

19 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.

20 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

21 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.

22 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.