Engenharia de Software.

Documentos relacionados
Análise e Projeto Orientado a Objetos

06/02/2014. Engenharia de requisitos. Requisitos de Software. Capítulo 6. O que é um requisito? Objetivos. Abstração de requisitos (Davis)

Requisitos de Software

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Engenharia de Software

Requisitos de Software

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

SOFTWARE REQUIREMENTS

Requisitos de Software

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Análise de Requisitos

Análise e Projeto Orientado a Objetos

Análise de sistemas. Engenharia de Requisitos

ENGENHARIA DE SOFTWARE

MODELAGEM DE SISTEMA Apresentação

Análise de Sistemas AULA 05 BCC Noturno - EMA908915A

21/09/2012. Elicitação de Requisitos. Projeto de Interface Homem- Máquina. Prof. Esp. MBA Heuber G. F. Lima. Técnicas etipos de Requisitos

Engenharia de Requisitos

Engenheiros de software (algumas vezes conhecidos no mundo da TI como engenheiros de sistemas ou analistas ) e outros interessados no projeto

Requisitos de Sistemas

Marcelo Henrique dos Santos

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

001 - Atividade de Engenharia de requisitos

Análise e projeto de sistemas

Engenharia de Software. Arthur Mariano L NETO Aula 05

2

Engenharia de Requisitos

LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES

1. INTRODUÇÃO A MODELAGEM DE DADOS

Requisitos de Software

Engenharia de Software ENGENHARIA DE REQUISITOS

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

Documento de Requisitos*

Sistema Mobi-Lar Engenharia de Software

Visão Geral do RUP (Rational Unified Process)

Agenda TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS. Aula 3 21/08/2012

Aula 4 Engenharia de Requisitos

Prof. Esp. Fabiano Taguchi

UnoTech Soluções em Histórico da Revisão Data Versão Descrição Autor 27/05/ 1.0 Construção do Documento Carlos GG Flor Página 2

Introdução à Engenharia de Software

Instituto Federal de São Paulo Campus Presidente Epitácio. Disciplina: História da Ciência e da Tecnologia

Requisitos de Software

Engenharia de Software

Introdução à Qualidade de Software

Engenharia de Software. Projeto de Arquitetura

Engenharia de Software

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPI JOÃO CÂMARA RATIONAL UNIFIED PROCESS - RUP

Engenharia de Software

Análise e Projeto de Sistemas de Informação (APSI)

Verificação e Validação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1

Capítulo 4. Engenharia de requisitos. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Capítulo 4 Engenharia de Requisitos 1

Gerência de Projetos de Software. Prof. Dr. João Dovicchi INE / CTC / UFSC.

SISCOP. Documento de Requisitos SISTEMA DE CONTROLE DE PEDIDOS. Versão 1.3

Projeto Disciplinar de Infra-Estrutura de Software SISCOMI MERCADOS Y.YAMADA

Gerência de Projetos e Qualidade de Software. Prof. Walter Gima

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Declaração de Escopo

3. Engenharia dos requisitos de software

Processo. Processo unificado. Principais Características do UP. Principais Características do UP RUP. Unified Process (Processo Unificado)

Engenharia de Requisitos

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Engenharia de Software II

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Prova Discursiva Engenharia de Software

CAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS. Tereza Gonçalves Kirner

Documento de Visão versão 1.0 Desenvolvimento do Sistema de Gestão de Documentos Doc Manager Cliente: São José Agroindustrial Representante do

O PLANEJAMENTO PRELIMINAR

Rational Unified Process (RUP)

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

Análise de Requisitos. Tema 4. Análise de Requisitos Profa. Susana M. Iglesias

QUALIDADE DE SOFTWARE

INSTITUTO FEDERAL DE CIÊNCIA E TECNOLOGIA DE SÃO PAULO PROJETO SOLUTION MARKET'S

Documento de Especificação de Sistema IngreSys

ISO/IEC Processo de ciclo de vida

Capítulo 4. Engenharia de requisitos Pearson Prentice Hall. Todos os direitos reservados. slide 1

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

Aula 01 Revisão Geral Banco de Dados I Conceito de Banco de Dados e SGBD

As Visões. Visões arquiteturais (revisão)

Disciplina - Requisitos. Grupo Yuni Luiz Eduardo Káthia

PROJETO INTEGRADOR Levantamento de Requisitos

PROJETO DE BANCO DE DADOS

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Do Papel ao ECM. Aquisição e Implantação de Projetos ECM

Plano de Testes VideoSystem

Requisitos de Sistemas

Prof. Emiliano S. Monteiro

Engenharia de Software

Atividades típicas do processo de desenvolvimento

Análise de Sistemas Aula 4

Professor Emiliano S. Monteiro

Qualidade de software. Prof. Emiliano Monteiro

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

Paradigmas da Engenharia de Software AULA PROF. ABRAHAO LOPES

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

Processo de Desenvolvimento

DOCUMENTAÇÃO SISTEMA DE ADMINISTRAÇÃO DE CONSULTÓRIO MÉDICO

Transcrição:

Engenharia de Software Prof. Raquel Silveira O que é (Rational Unified Process)? É um modelo de processo moderno derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software associado. Tem como objetivo garantir a produção de software de alta qualidade que está de acordo com as necessidades dos seus usuários finais com um cronograma e custo previsível. Captura as principais boas práticas modernas da Engenharia de Software. -Fases do O ciclo de vida de um sistema consiste de quatro fases: Concepção Elaboração Construção Transição tempo Concepção (define o escopo do projeto) Elaboração (define os requisitos e a arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema) MODELAGEM DE NEGÓCIOS -Disciplinas do Modelagem do negócio Requisitos Análise & Projeto Implementação Testes Implantação Gerenciamento e planejamento Gerencia de configuração e mudanças Ambiente Objetivos: - Entender a estrutura e dinâmica da organização. - Entender os problemas e identificar as melhorias em potencial. 1

-O processo de estabelecer os serviços que o cliente requer a partir de um sistema e as restrições sob as quais ele opera e é desenvolvido. -Os próprios requisitos são as descrições dos serviços de sistema e das restrições que são geradas durante o processo de engenharia de requisitos. O que é um requisito? Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição de sistema para uma especificação matemática funcional. Isto é inevitável quando os requisitos podem servir uma função dual: Pode ser a base para uma proposta de um contrato portanto deve ser aberta para interpretação; Pode ser a base para o contrato em si portanto deve ser definido em detalhe; Ambas as declarações podem ser chamadas requisitos. Tipos de requisitos usuário Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições operacionais. Escritos para os clientes. sistema Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor. - Como seria descrito o requisito de usuário e o requisito de sistema de uma operação de Saque? Requisitos funcionais: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Requisitos não funcionais Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. domínio Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio. 2

REQUISITOS FUNCIONAIS - Descrevem a funcionalidade ou serviços de sistema. - Dependem do tipo de software, dos usuários esperados e o tipo de sistema onde o software é usado. - Requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer mas os requisitos funcionais de sistema devem descrever os serviços de sistema em detalhe. Um sistema de biblioteca fornece uma interface única para uma série de artigos em bibliotecas diferentes. Os usuários podem pesquisar, baixar e imprimir estes artigos para estudo pessoal. - Quais os requisitos funcionais podemos identificar neste sistema? REQUISITOS NÃO-FUNCIONAIS - Estes definem propriedades e restrições de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos de armazenamento. Tipos de Requisitos Não-Funcionais Requisitos nãofuncionais Requisitos Requisitos produto organizacionais externos - Restrições são capacidade de dispositivos de E/S, representações de sistema, etc. funcilidade de uso eficiência confiabilidade portabilidade Requisitos éticos interoperabilidade Requisits legais - Requisitos não funcionais podem ser mais críticos do que os requisitos funcionais. Se estes não forem atendidos, o sistema é inútil. desempenho espaço implementa;áo entrega padrões seguran;a privacidade O cliente afirma que o sistema deve ser rápido, não podendo ultrapassar uma média de 3 segundos por operação. Além disso o idioma do sistema deve ser português e inglês. -Quais os requisitos não-funcionais podemos identificar este sistema? -Que outros requisitos não-funcionais podemos sugerir? Meta x Requisitos Requisitos não funcionais podem ser muito difíceis de definir precisamente e requisitos imprecisos podem ser difíceis de verificar. Meta: Uma intenção geral do usuário tal como facilidade de uso. Requisito não funcional verificável Uma declaração usando alguma medida que pode ser objetivamente testada. Metas são úteis para desenvolvedores quando exprimem as intenções dos usuários do sistema. 3

Exemplo: Meta x Requisitos. Medidas de Requisitos Meta do sistema: O sistema deve ser fácil de ser usado por todos os usuários e ser organizado de modo que os erros dos usuários sejam minimizados. Requisito não-funcional verificável Os usuários devem ser capazes de usar todas as funções do sistema depois de um treinamento de 2 horas. Após esse treinamento, o número médio de erros cometidos pelos usuários não deve exceder dois por dia. Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Medida Transações processadas/segundo Tempo de resposta de usuário/evento Tempo de atualização da tela Kbytes Número de chips de RAM Tempo de treinamento Número de frames de ajuda Tempo médio de falha Probavilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade -De que forma podemos definir um requisito de velocidade e de confiabilidade - Derivados do domínio de aplicação e descrevem características de sistema que refletem o domínio. - Podem restringir os requisitos funcionais existentes ou estabelecer como cálculos especificos devem ser realizados. - Se os requisitos de domínio não forem satisfeitos, o sistema pode não funcionar. Exemplo: Devido às restrições de direitos autorais, alguns documentos devem ser excluídos imediatamente na chegada. Dependendo dos requisitos de usuário, esses documentos serão impressos localmente no servidor de sistema para serem encaminhados manualmente para o usuário ou direcionados para uma impressora de rede. Problemas Entendimento: - Requisitos são expressos na linguagem do domínio de aplicação; - Isso não é, freqüentemente, compreendido pelos engenheiros de software que estão desenvolvendo o sistema. Implícito - Especialistas em domínio compreendem a area tão bem que não pensam em tornar os requisitos de domínio explícitos. 4

Requisito 1. O relatório deve ser gerado em no máximo 10 segundos. 2. O sistema deve ser capaz de emitir um relatório de controle de estoque. 3. O percentual do lucro deve ser calculado da seguinte forma: Preço de venda Média de preço de compra das últimas 10 compras 4. O sistema deve possuir restrição das funcionalidades de acordo com o usuário. 5. O sistema deve ser instalado em máquina cliente com capacidade mínima de 2Gb de disco disponível. 6. O sistema deve possuir um cadastro de produtos que permita inserir, atualizar, remover e pesquisar os produtos. 7. O sistema deve ser internacionalizável. Tipo Dada a seguinte especificação, defina os requisitos funcionais, nãofuncionais e de domínio. Sistema de controle de cheques O banco X está renovando seu sistema de cheques e precisa armazenar informações de seus clientes, assim como dos cheques e todas as transações realizadas para o cheque. A quantidade máxima de passos para realizar uma transação não deve ultrapassar 3 menus. O banco possui um cálculo matemático que define a taxa de juros caso o cheque não seja compensado. A quantidade mínima de memória por máquina deve 1Gb. O sistema deve possuir segurança de acesso dos usuários através da autenticação por meio de teclado virtual. 5