Estimativa / Viabilidade



Documentos relacionados
Estimativa / Viabilidade

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

Análise Estruturada de Sistemas

Pontos de Função. André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos. Engenharia de Software Mestrado Ciência da Computação - UFMS

Engenharia de Requisitos Estudo de Caso

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.

Termo de Abertura Sistema de Vendas de Pizzas Online (PizzaWeb) - Versão 1.0

ERP Enterprise Resource Planning

Engenharia de Software II

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função

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

Análise de Pontos por Função

Estimativas de software

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

Importância do GED. Implantação de um Sistema de GED

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

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

Planejamento de Projetos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( )

Implantação de um Processo de Medições de Software

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas

Análise de Requisitos

SOFTWARE PROFIT 2011.

Tecnologia e Sistemas de Informações

Plano de Gerenciamento do Projeto

Conceitos de Banco de Dados

SAV Sistema de Aluguel de Veículos I - DOCUMENTO DE REQUISITOS Versão 1.00

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

Plano de Gerenciamento das Aquisições Exemplo 1

Engenharia de Software

P4-MPS.BR - Prova de Conhecimento do Processo de Aquisição do MPS.BR

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

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira

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

Sistemas de Gerenciamento de Banco de Dados

Objetivos. Engenharia de Software. O Estudo de Viabilidade. Fase do Estudo de Viabilidade. Idéias chave. O que Estudar? O que concluir?

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira

Abordagens. Ao redor do computador. Ao redor do computador. Auditoria de Sistemas de Informação. Everson Santos Araujo

Módulo 12 Gerenciamento Financeiro para Serviços de TI

APOO Análise e Projeto Orientado a Objetos. Requisitos

Engenharia de Requisitos

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Roteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos

Módulo 4: Gerenciamento de Dados

TÉCNICAS DE ESTIMATIVAS DE CUSTOS ANÁLISE POR PONTOS DE FUNÇÃO. Alessandro Kotlinsky Deise Cechelero Jean Carlos Selzer. Resumo

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Governança de TI. ITIL v.2&3. parte 1

Os Sistemas de Informação para as Operações das Empresas e o Comércio Eletrônico Simulado Verdadeiro ou Falso

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena

Extração de Requisitos

Padrões de Qualidade e Métricas de Software. Aécio Costa

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:

MÉTRICAS DE SOFTWARE

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Orientações iniciais. FATTO Consultoria e Sistemas -

ENGENHARIA DE SOFTWARE I

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

MANUAL DE UTILIZAÇÃO MASTER VENDAS

INICIAÇÃO DO PROJETO PLANEJAMENTO PRELIMINAR. Engenharia de Software INE Planejamento de projetos de SW. O Planejamento de projetos de SW

ENGENHARIA DE SOFTWARE

Feature-Driven Development

SOFTWARE PROFIT 2011.

Requisitos de Software

Service Level Management SLM. Gerenciamento de Níveis de Serviço

Requisitos de Software

ESTUDO DE VIABILIDADE. Santander, Victor - Unioeste Aula de Luiz Eduardo Guarino de Vasconcelos

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA

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

GOVERNO DO ESTADO DO PARÁ MINISTÉRIO PÚBLICO DE CONTAS DOS MUNICÍPIOS DO ESTADO DO PARÁ MPCM CONCURSO PÚBLICO N.º 01/2015

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

A ESCOLHA DE SISTEMA PARA AUTOMAÇÃO DE BIBLIOTECAS. A decisão de automatizar

Requisitos de Software

ENGENHARIA DE SOFTWARE

Análise de Ponto de Função

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Introdução à Computação

Aplicações da FPA em Insourcing e Fábrica de Software

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

Modelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

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

2 Diagrama de Caso de Uso

Projeto de Sistemas I

Modelagem de Sistemas Prof. Marcos Roberto e Silva

UML - Unified Modeling Language

Engenharia de Software

Manual de utilização do sistema OTRS (Atendimento) Cliente Externo

CONSULTA AO MERCADO RFP REQUEST FOR PROPOSAL ÍNDICE

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

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

Desenvolvimento de Soluções de e-business. Objetivos do Capítulo

Transcrição:

Estimativa / Viabilidade Todos os projetos são viáveis desde que tenham ilimitados recursos e tempo infinito! Leitura: Sommerville (Cap7-25-26) Pressman (Cap15-20-21-22-23) Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 1

Objetivos Compreender os fundamentos dos custos e dos preços de software e a complexa relação entre eles. Conhecer tipos de métricas utilizadas para avaliar a produtividade de software. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 2

Estudo de viabilidade O estudo de viabilidade decide se vale a pena construir o sistema. Baseado na coleta e na análise de informações e na elaboração de relatórios. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 3

Estudo de viabilidade Um estudo breve, com foco nos benefícios, custos e necessidades, que checa: Se o sistema contribui para os objetivos gerais da organização? Se o sistema pode ser implementado usando a tecnologia atual dentro das restrições de custo e de prazo? Se o sistema pode ser integrado com outros sistemas já em operação? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 4

Estudo de viabilidade Questões que podem ser abordadas: O que acontece se o sistema não for implementado? Quais são os problemas com os processos atuais? Como o sistema proposto pode ajudar? É necessária a adoção de nova tecnologia ou o desenvolvimento de novas habilidades? Quais facilidades devem ser fornecidas pelo sistema? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 5

Tipos de viabilidade Viabilidade TÉCNICA Viabilidade ECONÔMICA Viabilidade OPERACIONAL Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 6

Tipos de viabilidade Viabilidade TÉCNICA Estudo da função, do desempenho e das restrições que possam afetar a capacidade de se conseguir um sistema aceitável.» Ex. Sistema implantado utilizando a tecnologia atual; Tempo de resposta 3seg Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 7

Tipos de viabilidade Viabilidade ECONÔMICA Calcule o custo de cada alternativa; Os benefícios contrabalançam os custos?; Análise de custo / benefício considere somente alternativa de retorno positivo. Viabilidade OPERACIONAL Verificar se o sistema pode ser implementado; Usuário pode opor-se a um serviço terceirizado? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 8

Lista de alternativas Os aspectos funcionais de cada alternativa devem ser verificados e pontuados pela complexidade de implementação. Se duas funcionalidade têm a mesma funcionalidade de implementação e a mesma prioridade de negociação, a mais simples é a melhor. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 9

Lista de alternativas (cont.) As alternativas tecnicamente viáveis podem ser apresentadas ao usuário para verificar se ele rejeita alguma delas ( viabilidade operacional). As alternativas viáveis devem ser apresentadas ao cliente, incluindo-se considerações sobre vantagens e desvantagens de cada uma. Deve-se apresentar uma recomendação da melhor solução para o problema, com um estudo de custo-benefício detalhado. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 10

Estimativas Grau de estrutura do projeto Complexidade Incerteza Medida relativa Medidas quantitativas (nível/projeto e código) Facilidade com que as funções podem ser dispostas Tamanho do esforço Precisão e a eficácia das estimativas Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 11

Estimativas As estimativas têm por objetivo determinar os gastos necessário para produzir um software. Estimativas e elaboração do cronograma são atividades interdependentes. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 12

Estimativas Questões fundamentais: Quanto esforço é requerido para completar uma atividade? Quantos dias ou meses são necessários para completar uma atividade? Qual o custo total de uma atividade? Quão produtiva é a equipe de desenvolvimento? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 13

Estimativas Estimativas dos recursos necessários Custo de estrutura: hardware, software e manutenção. Custo de logística: viagem e treinamento Custo de esforço humano: salários e encargos dos profissionais envolvidos no projeto. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 14

Estimativas Fatores que afetam a estimativa do preço do Software: Oportunidade de mercado Incerteza quanto ao custo Condições contratuais Volatilidade dos requisitos Saúde financeira Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 15

Estimativas Fatores que afetam a estimativa do preço do software Oportunidade de mercado Incerteza quanto ao custo Condições contratuais. pode-se estabelecer um preço baixo para iniciar em um novo segmento do mercado. o preço pode embutir um lucro acima do normal para compensar despesas não previstas. o preço pode ser menor (se o fornecedor puder usar o produto em outros projetos) ou maior (se for obrigado a bancar eventuais riscos) que o habitual. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 16

Estimativas Fatores que afetam a estimativa do preço do software Volatilidade dos requisitos Saúde financeira pode justificar um preço mais baixo (se houver possibilidade de cobrar por mudanças) ou mais alto (se o preço acertado não puder ser ajustado). fornecedores podem baixar o preço para conseguir o contrato (obtendo um lucro menor). Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 17

Produtividade / Métricas A produtividade em um sistema de manufatura pode ser medida pela contagem do número de unidades produzidas, dividindo-se o resultado pelo número de pessoa-hora necessário para a produção. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 18

Fatores que afetam a produtividade Experiência O conhecimento do domínio da aplicação afeta favoravelmente a produtividade. Qualidade do processo O processo de desenvolvimento utilizado afeta significativamente a produtividade. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 19

Fatores que afetam a produtividade Tamanho do projeto Quanto maior o projeto mais complexas as interações e comunicações entre as pessoas. Suporte à tecnologia Um ambiente adequado facilita o desenvolvimento. Ex. uso do CASE. Ambiente de trabalho O ambiente de trabalho afeta favoravelmente a produtividade Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 20

Produtividade / Métricas O que é medição? É o processo de descrever atributos de entidades, por meio da associação de números e símbolos que atendam a um conjunto de regras definidas claramente. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 21

Produtividade / Métricas Exemplo: Entidade: Clima Atributo: Temperatura Entidade: Software Atributo: Tamanho» Métrica: KLOC (Milhares de Linhas de Código) Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 22

Produtividade / Métricas Importância da medição de software: fornecer aos gerentes e engenheiros de software um conjunto de informações tangíveis para:»planejar o projeto;»realizar estimativas;»gerenciar e controlar os projetos com maior precisão. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 23

Métricas Métricas históricas»obtidas a partir de experiências anteriores da equipe Métricas empíricas»dados estatísticos de diferentes equipes Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 24

Métricas Medidas indiretas -» Permitem quantizar aspectos como a funcionalidade, complexidade, eficiência, manutenibilidade, dentre outros. Medidas diretas» É aquela que não envolve nenhum outro atributo ou entidade para se chegar na medida desejada. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 25

Métricas Medidas diretas» Exemplo: altura de uma pessoa» Exemplo de medidas diretas em engenharia de software: Tamanho do código fonte (medido em linhas de código) Duração do processo de teste Número de defeitos descoberto durante o processo de teste Tempo de programação de uma rotina (em horas) Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 26

Métricas MEDIDAS DO SOFTWARE MEDIDAS DIRETAS Custo Esforço Linhas de Código Velocidade de Execução Memória Nro de Erros MEDIDAS INDIRETAS Funcionalidade Qualidade Complexidade Eficiência Confiabilidade Manutenibilidade Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 27

Métricas Classificação das Métricas enfoca características do software (complexidade, modularidade) conformidade com os requisitos implícitos e explícitos do usuário enfoca a saída do processo de eng. de software computam medidas diretas do software computam medidas indiretas do software atuação das pessoas; seus relacionamentos com Técnicas de Qualidade de Produtividade Orientadas ao Tamanho Orientadas à Função Orientadas ao Ser Humano Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 28 ferramentas Engenharia e métodos de Softawre 3º Edição / Roger Pressman

Produtividade Relacionadas a Tamanho do Código As primeiras tentativas de se medir o tamanho de um sistema (1996) levou em consideração as LOCs (Lines Of Code- Linhas de Código). Forte dependência da linguagem no uso desta técnica. Como considera-se o tempo total do projeto, esta medida envolve as fases de análise, projeto, teste, documentação, além da codificação. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 29

Produtividade Relacionadas a Tamanho do Código Não existe uniformidade com relação à unidade de medida. Algumas propostas medem toda e qualquer declaração, outras apenas declarações executáveis, outras ainda medem as linhas escritas (incluindo ou não comentários). É difícil (e imprecisa) a comparação entre linguagens e ambientes de programação diferentes. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 30

Utilização de Métricas Projeto Esforço $ KLOC Págs.docum. Erros Pessoas (pessoa/mês) proja-01 24 168 12.1 365 29 3 projb-04 62 440 27.2 1224 86 5 projc-03 43 314 20.2 1050 64 6 MÉTRICAS DERIVADAS PRODUTIVIDADE = QUALIDADE = CUSTO = DOCUMENTAÇÃO = KLOC / Pessoas-mês Erros / KLOC $ / KLOC Págs.docum. / KLOC Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 31

Produtividade Tempo de desenvolvimento (exem) Linguagem Análise Projeto Codificação Testes Documentação Código assembly Linguagem de alto nível 3 sem 5 sem 8 sem 10 sem 2 sem 3 sem 5 sem 5 sem 5 sem 2 sem Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 32

Produtividade Tempo de desenvolvimento (exem) Tamanho Esforço (pessoa-semana) Produtividade Código assembly 5000 linhas 28 semanas 714 linhas/mês Linguagem de alto nível 1500 linhas 20 semanas 300 linhas/mês Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 33

Produtividade Pontos de Funções FPA Function Point Analysis Os pontos por função (proposto por Albrecht (1979 - aperfeiçoado em 1983) são usados como uma medida da funcionalidade do código. São independente da linguagem de implementação e são apropriados para sistemas com predominância de funções de entrada e saída. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 34

Produtividade Ponto por Função FPA Function Point Analysis A técnica de FPA mede o que é o sistema e não como será, ou foi, desenvolvido Um dos principais conceitos relativos a FPA é que as funções devem ser contadas a partir da perspectiva do usuário e não do analista ou programador. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 35

Linhas de Código x Pontos por Função A relação entre linhas de código e pontos por função depende da linguagem de programação Linguagem de Programação LOC/PF (Média) Assembly 300 COBOL 100 FORTRAN 100 Pascal 90 Ada 70 Linguagens Orientadas a Objeto 30 Linguagens de Quarta Geração 20 Geradores de Código 15 Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 36

Exemplo: Tamanho do projeto atual é 500 pontos por função; Custo histórico para um projeto semelhante foi $10 por pontos por função. Custo total esperado Produtividade Relacionadas a Pontos por Função $10 ($ / Pontos por Função) x 500 PF = $ 5.000 dólares. Cálculos semelhantes poderiam ser efetuados para o cronograma, a duração e as horas Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 37

Produtividade Pontos por Função FPA Function Point Analysis Pontos por função é baseada em medidas indiretas sobre a complexidade do software. O grupo responsável pela padronização denomina-se IFPUG (International Function Point Users Group, 2000). Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 38

Produtividade Relacionadas a Pontos por Função Um ponto por função não é (mede) uma característica única. Ele é calculado medindo-se ou estimando-se as seguintes características:» entrada e saídas externas» interações com o usuário» interfaces externas» arquivos utilizados pelo sistema» Cada uma dessas características é individualmente avaliada em termos da complexidade e recebe um peso que varia de de 3, para entradas externas simples, a 15, para arquivos externos complexos Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 39

Produtividade Relacionadas a Pontos por Função A contagem dos pontos por função é feita em duas etapas. Primeiro obtém-se uma contagem não ajustada: multiplicando a quantidade de elementos de cada característica pelo peso da característica, somando-se todos os valores obtidos: [ PFna = Soma( num. elem. dado tipo x peso) ] PFna Ponto por Função não ajustada Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 40

Produtividade Relacionadas a Pontos por Função Parâmetros Qte Simples Médio Complexos Total Num. de entradas de usuários Num. de saídas p/ usuários Num. de consultas do usuários x 3 4 6 = x 4 5 7 = x 3 4 6 = Num. de arquivos x 7 10 15 = Num. de interfaces externas x 5 7 10 = Pontos por função não ajustados (Fi) = Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 41

Produtividade Relacionadas a Pontos por Função PF = PFna x (0.65 + 0.01 x Soma(Fi)) onde Fi (1 <= i <= 14) são 14 fatores de ajuste avaliados segundo uma escala de 0 (não importante) a 5 (essencial). (Pressman tab2.1). Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 42

MÉTRICA ORIENTADA À FUNÇÃO - PF Responder as questões 1-14, considerando a escala de 0 a 5: influência 0 1 2 3 4 5 nenhuma pouca moderada média significante essencial 1. O sistema exige backup e recuperação confiáveis? 2. É requerida comunicação de dados? 3. Existem funções de processamento distribuído? 4. O desempenho é crítico? 5. O sistema funcionará num sistema operacional existente e intensamente utilizado? 6. São requeridas entrada de dados on-line? 7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações? Produtividade Relacionadas a Pontos por Função 8. Os arquivos são atualizados on-line? 9. Entradas, saídas, arquivos e consultas são complexos? 10. O processamento interno é complexo? 11. O código é projetado para ser reusával? 12. A conversão e a instalação estão incuídas no projeto? 13. O sistema é projetado para múltiplas instalações em diferentes organizações? 14. A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 43

Produtividade Relacionadas a Pontos por Função QUESTÕES 1. O sistema exige backup e recuperação confiáveis? 2. É requerida comunicação de dados? 3. Existem funções de processamento distribuído? 4. O desempenho é crítico? 5. O sistema funcionará num sistema operacional existente e intensamente utilizado? 6. São requeridas entrada de dados on-line? 7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 44

Produtividade Relacionadas a Pontos por Função 8. Os arquivos são atualizados on-line? 9. Entradas, saídas, arquivos e consultas são complexos? 10.O processamento interno é complexo? 11.O código é projetado para ser reusával? 12.A conversão e a instalação estão incluídas no projeto? 13.O sistema é projetado para múltiplas instalações em diferentes organizações? 14.A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário? Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 45

Estudo de caso - Hotel Objetivo do sistema. Este sistema será utilizado para uma rede de hotéis. Cada hotel terá um ou vários terminais que permitirão as operações básicas de um hotel, podendo o cliente reservar e cancelar um apartamento através da Web, terá também comunicação com outro hotéis da mesma rede de modo a consultar sobre disponibilidade de vagas. Este sistema também faz interface com outros dois sistemas internos do hotel: controle de restaurante e controle de tarifação de telefone. As funções básicas de controle são: cadastro de cliente,gerenciamento de reservas e ocupações, gerenciamento de pagamento, emissão de nota fiscal, emissão relatórios contábeis e reservas pela Web. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 46

Estudo de caso Hotel Requisitos funcionais Entrada para cadastro de cliente (nome, endereço, e-mail, data de chegada, data de saída, classificação do cliente, documento). Consultas, reservas e cancelamento de reserva através da Web. Cadastro de apartamento: tipo de quarto (suíte, standard, duplo, ar-condicionado), cidade ou local. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 47

Estudo de caso Hotel Requisitos funcionais Cadastro de salas e auditório. Cadastro de despesas Controle de ocupação de apartamento (reservado ou entrada do hóspede). Controle de limpeza dos apartamentos. Preços diferenciados para alta temporada e baixa temporada. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 48

Estudo de caso Hotel Requisitos funcionais Descontos para clientes VIP e grupos. Recebimento de pagamento (tipo de pagamento cheque, dinheiro, cartão, parcelado, moeda estrangeira). Registrar situações de pagamento (cheque compensado, transferência realizada, parcelado, em dinheiro, ou moeda estrangeira). Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 49

Estudo de caso Hotel Requisitos funcionais Emissão de nota fiscal (podendo ser separado por itens: hospedagem, restaurante, lavanderia, etc). Emissão da fatura parcial (somente para consulta). Emissão de relatórios contábeis. Relatórios de ocupação. Relatórios parciais de consulta. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 50

Estudo de caso Hotel Requisitos funcionais Consulta o nome do cliente (se já existente). Gerar relatórios estatísticos (média de dias que o cliente se hospeda, gastos médios, itens mais consumidos nos restaurantes). Serviços de mala direta (podendo selecionar os clientes e enviar mensagens via e-mail ou imprimir cartas para serem enviados posteriormente via correio. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 51

Estudo de caso Hotel Requisitos funcionais Pesquisa dos clientes no banco de dados segundo alguns tipos de critérios (freqüência que o cliente se hospeda, preferência de apartamentos, preferência de local, tipo de serviços utilizados, estadia de negócios ou turismo, faixa etária, procedência). Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 52

Estudo de caso Hotel Requisitos funcionais Serviços adicionais são também incluídos no sistema: telefone, TV paga, acesso à internet, 'frigobar', lavandeira, serviço de lanche e café da manhã. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 53

Estudo de caso Hotel Requisitos não funcionais Serviços adicionais são também incluídos no sistema: telefone, TV paga, acesso à internet, 'frigobar', lavandeira, serviço de lanche e café da manhã. Conexão para consultas e reservas de vagas em outros hotéis do grupo. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 54

Estudo de caso Hotel Requisitos não funcionais Tempo de resposta desejável menor que 10 segundos para consultas de vagas em outros hotéis da rede. Utilização de computadores PC de mercado. Sistema operacional Windows XP ou mais recente. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 55

Estudo de caso Hotel Requisitos não funcionais Utilização da linguagem JAVA. Portabilidade para novos hardwares e sistemas operacionais (quando forem lançadas novas versões de sistema operacional). Interface gráfica fácil de usar 'tipo Windows' para entrada de dados e operação Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 56

Estudo de caso Hotel Requisitos não funcionais Procedimento de backup do cadastro de clientes e ocupação e dados correntes. Senha de acesso ao sistema. Deverão ter senhas diferentes para recepcionistas, camareiras, gerentes e proprietário de modo que cada usuário tenha acesso restrito a certas informações. Sistema 'no-break' em caso de queda de energia Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 57

Estudo de caso Hotel Requisitos não funcionais O produto pode ser desenvolvido em etapas, mas deverá ter as funcionalidades básicas na primeira versão (gerenciar reservas e ocupação de apartamentos, cadastro de clientes, controle de pagamento, emissão de relatórios, e reservas pela Web). O prazo de desenvolvimento para as funcionalidades básicas é de 6 meses. Auxiliadora Freire Fonte: Engenharia de Software 6º - 8º Edição / Ian Sommerville 2000-2007 Slide 58