Concepção e Elaboração



Documentos relacionados
Análise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN

Engenharia de Software I

Sumário. Uma visão mais clara da UML

O Processo de Desenvolvimento de Software

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

Processo de Desenvolvimento de Software. Engenharia de Software.

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

Engenharia de Software III

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Modelos de Sistemas Casos de Uso

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

APOO Análise e Projeto Orientado a Objetos. Requisitos

Feature-Driven Development

Engenharia de Software na Prática Hélio Engholm Jr.

Requisitos. Sistemas de Informações

Prototipação de Software

Análise e Projeto Orientados a Objetos Aula IX Modelo Conceitual do Sistema (Modelo de Domínio) Prof.: Bruno E. G. Gomes IFRN

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Projeto de Sistemas I

Histórico da Revisão. Data Versão Descrição Autor

Introdução à Engenharia de Software

Análise e Projeto Orientados por Objetos

2 Diagrama de Caso de Uso

Engenharia de Requisitos

Engenharia de Sistemas Computacionais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Modelagem de Casos de Uso (Parte 1)

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Persistência e Banco de Dados em Jogos Digitais

Diagramas de Sequência e Contrato das Operações

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

Tópicos Especiais em Sistemas de Telecomunicações IV

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

Universidade Paulista

Levantamento, Análise e Gestão Requisitos. Aula 12

SISTEMA GERENCIADOR DE BANCO DE DADOS

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Engenharia de Requisitos Estudo de Caso

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

Gerenciamento de Projeto

Modelode Domínio: Identificando. Prof. Anderson Cavalcanti UFRN-CT-DCA

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

MASTER IN PROJECT MANAGEMENT

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

Modelo Entidade-Relacionamento

Notas de Aula 04: Casos de uso de um sistema

O Oficina Integrada é um sistema completo para o controle e gerenciamento de oficinas mecânicas. É o primeiro e único software que controla o fluxo

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

Project and Portfolio Management [PPM] Sustainable value creation.

O Processo Unificado

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO

1 UML (UNIFIED MODELING LANGUAGE)

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Engenharia de Software I

F.1 Gerenciamento da integração do projeto

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Gerenciamento de Projeto: Criando o Termo de Abertura III. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Modelo para Documento de. Especificação de Requisitos de Software

Gerenciamento de Riscos do Projeto Eventos Adversos

Roteiro. BCC321 - Banco de Dados I. Conceitos Básicos. Conceitos Básicos. O que é um banco de dados (BD)?

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Modelo para Documento de. Especificação de Requisitos de Software

ENGENHARIA DE SOFTWARE I

MÉTRICAS DE SOFTWARE

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

UML - Unified Modeling Language

Programa do Módulo 2. Processo Unificado: Visão Geral

Banco de Dados. Microsoft Access

Análise Estruturada de Sistemas

Processos de Desenvolvimento de Software

Engenharia de Software I

Wilson Moraes Góes. Novatec

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes:

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

MSc. Daniele Carvalho Oliveira

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Ajuda ao SciEn-Produção O Artigo Científico da Pesquisa Experimental

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

Documento de Arquitetura

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Transcrição:

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração

Estudo de Caso: Terminal de Ponto de Venda Objetivo: Definir um dos estudos de caso usado na disciplina

O Sistema TPV Um TPV é um sistema computadorizado usado para registrar vendas e cuidar de pagamentos; é tipicamente usado em vendas a varejo. Ele inclui componentes de hardware, tais como um computador e um leitor de código de barras, e o software para rodar o sistema.

O Sistema TPV Cliente Terminal de Ponto de Vendas (TPV) Caixa

O Sistema TPV TPV tem interfaces com várias aplicações de serviço: Aplicação de cálculo de imposto de renda Aplicação de controle de estoque Devem ser tolerantes a falhas Um TPV deve dar suporte de forma incremental a múltiplos e variados terminais e interfaces no lado do cliente. Um TPV é um sistema comercial que pode ser vendido a diferentes clientes, com necessidades diferentes em termos de regras de negócio.

Arquitetura É um sistema de informação típico e pode ser visualizado em várias camadas: Apresentação: interface gráfica, janelas. Lógica da aplicação (ou do negócio) - objetos do domínio do problema: representam os conceitos do domínio do problema que atendem aos requisitos do sistema. Ex: venda. Lógica da aplicação objetos de serviços : objetos e subsistemas de uso geral que fornecem serviços técnicos de apoio. São independentes da aplicação e podem ser reutilizados por outros sistemas. Armazenamento mecanismo de armazenamento persistente. Ex: BDOO ou BD Relacional

A Análise e o projeto orientado a objetos são geralmente mais relevantes para a modelagem das camadas da lógica da aplicação e das camadas de serviço.

Arquitetura (cont.) Nesta abordagem, as janelas da interface não contém código que trata da lógica ou do processamento da aplicação a camada de interface é fina (cliente magro, ou leve). As solicitações de tarefas são repassadas para outras camadas.

Estratégia de Desenvolvimento e Aprendizado Iterativos Primeiro ciclo: funções principais da aplicação. É apresentado o conjunto central de tópicos da análise, padrões de projeto OO e da notação UML. Ciclos posteriores: expansão das funcionalidades do sistema. Introduz-se novas idéias, notações UML e novos padrões de projeto OO.

As fases de Concepção e Elaboração

Concepção Passo inicial curto, no qual explora-se as seguintes questões: Qual é a visão e o caso de negócio para o projeto? Ele é viável? Devemos construir ou comprar? Estimativa de custo aproximada: qual a ordem de grandeza? Devemos continuar ou parar?

A concepção, em uma frase: Conceber o escopo do produto, a visão e o caso de negócio. O problema principal a ser resolvido, em duas frases: Os interessados no projeto do sistema tem um consenso básico sobre A visão do projeto? Vale a pena investir em uma investigação séria?

Compreensão dos Requisitos (Concepção e Elaboração)

Concepção e Elaboração Definir Rascunho do Plano Criar Relatório de Investigação Preliminar Definir Requisitos Registrar termos no Glossário Implementar Protótipo Definir Casos de Uso Definir rascunho do modelo conceitual Definir rascunho da arquitetura do sistema Refinar plano

Entendimento dos Requisitos Objetivos: Criar os artefatos da fase de engenharia de requisitos Identificar e categorizar as funções do sistema Identificar e categorizar os atributos do sistema e relacioná-los com as funções

Relacionamento entre os artefatos das fases concepção e elaboração Concepção Relatório de Investigação Preliminar Protótipos Elaboração Especificação de Requisitos Casos de Uso a. Todos os de alto nível b. Alguns essenciais expandidos Diagrama de Casos de Uso Elaborar:... 3. Definir requisitos... Orçamento, Cronograma Depende de Esboço do modelo Conceitual Glossário Engenharia de Requisitos

REQUISITOS Requisitos são uma descrição das necessidades de um produto. Objetivo da fase de requisitos: identificar e documentar o que realmente é necessário O artefato Documento de Especificação de Requisitos deve conter: Descrição Geral do Sistema Clientes Objetivos do Sistema Funções do Sistema Atributos do Sistema

Funções do Sistema São o que o sistema deve fazer. Exemplo: autorizar o pagamento por cartão de crédito. As funções devem ser identificadas e listadas em agrupamentos lógicos coesos. Geralmente devem ser escritas da forma: O sistema... deve... fazer <X> Cada função pode ser expressa em termos de um ou mais requisitos que o sistema deve atender.

Atributos do Sistema São qualidades não funcionais do sistema Ex: facilidade de uso que são freqüentemente confundidas com funções Em geral, podem ser aplicados para qualquer sistema. São também chamados de requisitos não funcionais ou requisitos de qualidade

Atributos do Sistema São características ou dimensões do sistema; não são funções. Ex: Facilidade de uso, tolerância a falhas, tempo de resposta, custo de venda, metáfora da interface, etc. Podem aplicar-se a todas as funções ou ser específicos de uma função particular ou grupo de funções.

Atributos do Sistema (Cont) Tem associado um conjunto de detalhes do atributo, que podem ser discretos, imprecisos ou simbólicos. Exemplos: tempo de resposta = psicologicamente apropriado; metáfora da interface = (gráfica, colorida, baseada em formulário)

Atributos do Sistema (cont) Podem ter também restrições de limites, que são condições de limite obrigatórias, usualmente o intervalo numérico de valores de um atributo. Exemplo: tempo de resposta = máximo de 5 segundos

Categorias de Funções Forma de priorizar as funções Identificar funções que são assumidas como necessárias, mas que consomem tempo e recursos.

Tipos de Funções Evidente ou Visível (E): deve ser executada e o usuário tem conhecimento que ela foi executada. Oculta (O): deve ser executada, mas não é visível para o usuário. Isso vale para muitos serviços técnicos de infra-estrutura, tal como salvar a informação em um dispositivo permanente de armazenamento. São frequentemente esquecidas durante a fase de coleta de requisitos Enfeite/Decoração/ (D): Opcional; sua adição não afeta significativamente outras funções.

Exemplo de Requisitos: TPV Descrição Geral O propósito deste projeto é criar um terminal de ponto de vendas (TPV) para ser usado em lojas de varejo.

Clientes ObjectStore, Inc., uma multinacional que comercializa objetos

Objetivos O objetivo geral é aumentar a automatização das compras (checkout) para permitir serviços e processos comerciais mais rápidos, melhores e mais baratos. Tipicamente, isso inclui: Checkout (passagem pelo caixa) mais rápido para o cliente Verificação e identificação rápida do cliente Análise rápida e precisa do crédito Controle automático do estoque

Funções Básicas R1.1 Registrar a venda em andamento (corrente), isto é, os itens comprados. (Evidente) R1.2 Calcular o total da venda corrente, incluindo os cálculos de impostos e de cupons de desconto. (Evidente) R1.3 Capturar a informação de um item adquirido, usando o código, obtido por um leitor de código de barra, ou pela entrada manual do código do produto, usando o código universal de produto (CUP ou UPC). (Evidente)

Funções Básicas (cont.) R1.4 Reduzir a quantidade em estoque quando a venda for finalizada (Oculta) R1.5 Registrar as venda completadas (Oculta) R1.6 O Caixa deve abrir o caixa (log in) com um identificador (ID) e uma senha para poder usar o sistema (Evidente) R1.7 Fornecer um mecanismo de armazenamento permanente (Oculta)

Funções Básicas (cont) R1.8 Fornecer mecanismos de comunicação inter-processos e intersistemas (Oculta) R1.9 Exibir a descrição e o preço do R1.9 Exibir a descrição e o preço do item registrado (Evidente)

Funções de Pagamento R2.1 Tratar os pagamentos em dinheiro; capturar a quantia recebida e informar o troco (Evidente). R2.2 Tratar o pagamento por cartão de crédito: captar a informação do cartão de crédito por um leitor de cartões ou uma entrada manual e autorizar o pagamento com o serviço de autorização de crédito (externo) da loja via conexão por modem (Evidente)

Funções de Pagamento (cont.) R2.3 Tratar os pagamentos com cheque; capturar o CPF por entrada manual e autorizar o pagamento com o serviço de autorização de crédito da loja (externo) via conexão por modem (Evidente) R2.4 Registrar os pagamentos por crédito no sistema de contas a receber da loja, uma vez que o serviço de autorização de crédito deve à loja a quantia oferecida como pagamento (Oculta)

Atributos (requisitos não funcionais) do Sistema em especificações de funções R1.9 Exibir a descrição e o preço do item registrado (Evidente) Tempo de resposta: Max 5s Obrigatório Metáfora da interface: saída baseada em formulário Obrigatório saída colorida Desejável R2.4 Registrar os pagamentos por crédito no sistema de contas a receber da loja (Oculta) Tolerância a falhas: deve registrar no sistema de contas a receber em 24h, mesmo em caso de falhas elétrica ou de hardware Obrigatório Tempo de Resposta: Max 10s Obrigatório

Outros artefatos da fase de requisitos Requisitos e Equipes de ligação lista das pessoas que deveriam estar envolvidas no levantamento dos requisitos Grupos afetados lista de pessoas afetadas pelo sistema (desenvolvimento ou utilização) Hipóteses coisas que serão assumidas como verdadeiras. Riscos problemas que podem levar ao fracasso do sistema

Outros artefatos da fase de requisitos Dependências outras pessoas, sistemas e produtos, dos quais este projeto depende Glossário definição de todos os termos relevantes Casos de Uso descrições narrativas dos processos do domínio. Esboço do modelo conceitual um modelo de conceitos relevantes e seus relacionamentos