AULA_01

Prévia do material em texto

Centro Universitário Jorge Amado - UNIJORGE
Analise de Sistemas de 
Informações Comerciais
_________________________________________________________________________________________________
Keller S. Araújo – kellersa@ig.com.br
OBJETIVO
 Analisar e projetar sistemas de informação baseados
nas técnicas de orientação a objetos e Análise Essencial.
_________________________________________________________________________________________________
Keller S. Araújo – kellersa@ig.com.br
OBJETIVO ESPECÍFICOS
 Evolução do ciclo de desenvolvimento de software
◦ Crise do software.
 Engenharia de requisitos
 Paradigma da Análise Estruturada e Essencial
 Ferramentas da Análise Estruturada
 Modelo Ambiental
 Modelo Comportamental
 Histórico da Análise e Projeto de Sistemas de Informação
 Paradigma da Orientação a Objetos
 Introdução à Análise e Projeto Orientado a Objetos
 Linguagem de Modelagem UML
◦ Diagrama de caso de uso
◦ Diagrama de atividades
◦ Diagrama de sequência
◦ Diagrama de estados
_________________________________________________________________________________________________
Keller S. Araújo – kellersa@ig.com.br
ATIVIDADES
 AV1
◦ Exercícios em sala – Estudos de caso.
◦ Projeto – Parte 1 – Entrega e Apresentação em 08/04/2014 – 4,0
◦ Prova – 11/04/2014 – 6,0
◦ 2ª chamada – 02/05/2014
◦ Seminário – Entrega 15/04/2014 Min. 7p., Máx. 10p. – 10,0
◦ Modelo SBC
 AV3
◦ Exercícios em sala – Estudos de caso.
◦ Prova – 06/06/2014 – 6,0
◦ Projeto – Parte II – Apresentação em 10/062014. – 4,0 
◦ 2ª chamada – 20/06/2014
PROVA FINAL – 04/07/2014
______________________________________________________________________________________________
Keller S. Araújo – kellersa@ig.com.br
REFERÊNCIAS
 PRESSMAN, Roger S. Engenharia de software – 5ed. –
Rio de Janeiro: McGraw-Hill,2002.
 PÁDUA, Wilson de; Engenharia de Software: 
Fundamentos, Métodos e padrões. Segunda edição. Ed. 
LTC.
 SOMMERVILLE, Ian; Engenharia de software – 8ª edição 
– São Paulo. Ed. Pearson.
 GANE, C. & SARSON, T. Análise Estruturada de Sistema. 
Rio de Janeiro. LTC. 1993.
 JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. 
UML: Guia do Usuário. Campus, 2000.
 SANTOS, Rafael; Introdução à Programação Orientada a 
Objetos usando Java. Editora Campus, 2003.
_________________________________________________________________________________________________
Keller S. Araújo – kellersa@ig.com.br
PORQUÊ 
ANÁLISE/MODELAGEM?
CENÁRIO INICIAL
 Desenvolvimento informal e não suficiente.
 Requisitos não atendidos.
 Módulos difíceis de integrar.
 Erros descobertos tardiamente.
 Desempenho insatisfatório.
 Equipes sem esforço coordenado.
 Atraso no cronograma.
 Custo acima do previsto.
PROBLEMAS
 Definição de requisitos insuficiente.
 Ambiguidade na comunicação.
 Política de teste de baixa qualidade.
 Baixo controle de mudanças.
 Automação insuficiente.
CRISE DO SOFTWARE (1968)
Custo de hardware
Custo de software
CRISE DO SOFTWARE
 INÍCIO
◦ Programação era uma forma de arte.
◦ Poucos métodos formais eram aplicados.
◦ Esquema baseado em tentativa e erro.
◦ Mundo indisciplinado.
 ATUALMENTE
◦ Software é o item de maior custo.
◦ Porquê a demora na conclusão, se são aplicados métodos e
ferramentas.
◦ Porquê há tantos erros?
◦ Porquê é difícil medir nossos erros?
◦ Necessidade de atualização das aplicações.
◦ Empresas e outsourcing.
ENGENHARIA 
DE SOFTWARE
“Desenvolvimento de software com alta qualidade 
dentro de custos adequados”
PROCESSOS DE SOFTWARE
QUALIDADE
FERRAMENTAS
MÉTODOS
PROCESSO
 Especificação de software – definição de 
funcionalidades e restrições.
 Desenvolvimento de software – o software é 
projetado e programado de acordo com a 
especificação.
 Validação de software – o software é verificado 
para garantir que é o que o cliente deseja.
 Evolução de software – o software é adaptado à 
mudanças.
PRINCIPAIS ATIVIDADES EM UM 
PROCESSO DE SOFTWARE
 Especificação de software – definição de 
funcionalidades e restrições.
PRINCIPAIS ATIVIDADES EM UM 
PROCESSO DE SOFTWARE
Análise, Projeto e Programação.
 A análise se preocupa com a modelagem
para o domínio da aplicação.
 O projeto se preocupa com o
desenvolvimento de um modelo de sistema
que implemente os requisitos definidos pela
análise.
 A programação se preocupa com a
implementação do Projeto usando uma
linguagem de programação.
Análise, Projeto e Programação.
A análise se preocupa com a
modelagem para o domínio
da aplicação.
ESPECIFICAÇÃO DE 
REQUISITOS
CONCEITOS BÁSICOS.
Estabelecer um rumo a partir dos
requisitos de software.
Informação soltas e desconectas.
Linguagem natural.
Descobrir entre as etapas a serem
percorridas, aquelas mais
importantes do ponto de vista do
cliente;
CONCEITOS BÁSICOS
 REQUISITO
◦ Descrevem os serviços fornecidos pelo sistema.
◦ Indicam as restrições operacionais.
◦ Refletem as necessidades do cliente.
REQUISITOS PODEM SER...
 Uma declaração abstrata, de alto nível, de 
uma função do sistema.
 Uma restrição.
 Uma definição detalhada, 
matematicamente formal, de uma função.
ESPECIFICAÇÃO DE REQUISITOS DE 
SOFTWARE (SRS)
 A definição oficial do que é exigido dos desenvolvedores do
sistema.
 Deve incluir requisitos do usuário e especificações
detalhadas de requisitos do sistema.
 Pode ser adaptado às necessidades do sistema.
 É imprescindível para os softwares desenvolvidos pro
empresas terceiras.
USUÁRIOS NA SRS
Clientes do 
sistema
Engenheiros de 
manutenção de 
sistema
Gerentes
Engenheiros de 
sistema
Engenheiros de 
teste de sistema
Usam os requisitos para compreender qual sistema será
desenvolvido.
Usam o documento de requistos para planejar um pedido
de proposta para o sistema e planejar o processo de
desenvolvimento do sistema.
Especificam e leem os requisitos para verificar se eles
atendem às suas necessidades. Os clientes especificam as
mudanças nos requisitos.
Usam os requisitos para desenvolver testes de validação
para o sistema.
Usam os requisitos para compreender o sistema e os
relacionamentos entre suas partes.
ESTRUTURA PARA SRS.
Exemplo trab AV1.doc
EXERCÍCIO 
Em grupo de 4 alunos (2 desenvolvedores e 2 usuários),
simular uma reunião para especificação de requisitos de um
Sistema de Controle de Biblioteca (use seus conhecimentos
sobre o processo da Biblioteca para fazer o papel de
usuário).
 Ao término da “reunião”, crie um documento com:
◦ Nome do sistema
◦ Áreas envolvidas
◦ Objetivos do sistema
◦ Restrições
◦ Descrição funcional