MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R



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

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

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

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project projeto

Manual Geral do OASIS

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

PROJETO DE FÁBRICA DE SOFTWARE

PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES?

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

Sistema de Controle de Solicitação de Desenvolvimento

Trabalho Interdisciplinar. MS Project

A Disciplina Gerência de Projetos

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

Processos de Desenvolvimento de Software

NORMA ISO/IEC Isac Aguiar isacaguiar.com.br

Manual de Utilização ZENDESK. Instruções Básicas

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

Plano de Gerenciamento do Projeto

Programa de Capacitação em Gestão do PPA Curso PPA: Elaboração e Gestão Ciclo Básico. Elaboração de Planos Gerenciais dos Programas do PPA

Feature-Driven Development

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

3. Fase de Planejamento dos Ciclos de Construção do Software

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

SISTEMAS DE GESTÃO São Paulo, Janeiro de 2005

SISTEMA DE GESTÃO PARA CURTUMES

1 Sumário O Easy Chat Conceitos Perfil Categoria Instalação O Aplicativo HTML...

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

Análise de Pontos por Função

Clique no botão para iniciar o treinamento TAREFAS CONTRAT OS RELACIO NAMENT CONFIGURAÇÕES. A ideia é usar os próprios ícones do CGW.

UML - Unified Modeling Language

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

SERVICE DESK MANAGER SDM. Manual do Sistema - DPOI

ENGENHARIA DE SOFTWARE I

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

Pag: 1/20. SGI Manual. Controle de Padrões

Redmine. Simplificando a gestão de projetos

MANUAL DE IMPLANTAÇÃO SISTEMA DE INVENTÁRIO CACIC GOVERNO FEDERAL SOFTWARE PÚBLICO

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

Processo Unificado (RUP)

O Processo Unificado: Captura de requisitos

OI CONTA EMPRESA MANUAL DO USUÁRIO (exceto Administradores de Conta)

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Introdução. 1. Introdução

Importação de Itens através de Planilha de Dados

SUMÁRIO Acesso ao sistema... 2 Atendente... 3

Projeto de Sistemas I

II. FASE DE PLANEJAMENTO define a maturidade do entendimento do escopo e, o desenvolvimento do Plano do Projeto PP.

Engenharia de Software II: Desenvolvendo o Orçamento do Projeto. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

PLANEJAMENTO OPERACIONAL: RECURSOS HUMANOS E FINANÇAS MÓDULO 16

Manual do Almoxarifado SIGA-ADM

Manual do usuário. v1.0

W Projeto. Gerenciamento. Construindo a WBS e gerando o Cronograma. Autor: Antonio Augusto Camargos, PMP 1/12

Passo a Passo do Cadastro Produtos no SIGLA Digital

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

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

Planejamento e Gerenciamento de Software. Tema 3. Gerência de Projetos Profa. Susana M. Iglesias

Sistema de Compras TV Globo

QFD: Quality Function Deployment QFD: CASA DA QUALIDADE - PASSO A PASSO

Resolução da lista de exercícios de casos de uso

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

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

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

1) MANUAL DO INTEGRADOR Este documento, destinado aos instaladores do sistema, com informações de configuração.

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

Estima de pontos de caso de uso Trabalho substitutivo ao Projeto Integrador

Microsoft Project 2003

Exportação e Importação de Orçamentos

ISO/IEC 12207: Gerência de Configuração

Redmine. Simplificando a gestão de projetos

Padronização de Documentação de Sistemas. Projeto a ser desenvolvido no âmbito da Gerência de Sistemas/GGTIN e ANVISA

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

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

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula:

Software. Gerenciamento de Manutenção

Dadas a base e a altura de um triangulo, determinar sua área.

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

Como conduzir com sucesso um projeto de melhoria da qualidade

OI CONTA EMPRESA MANUAL DO USUÁRIO

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

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

Documento de Requisitos

Versão Melhorias Melhorias Versão 6.0.1

Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.

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

GARANTIA DA QUALIDADE DE SOFTWARE

MÉTRICAS DE SOFTWARE

e-ouv Passo-a-passo Sistema de Ouvidorias do Poder Executivo Federal Junho, 2015 Controladoria-Geral da União

Gerenciamento de Projeto: Monitorando e Controlando o Projeto II. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

PLANO DE GERANCIAMENTO DO RELEASE Release:

CONSULTA AO MERCADO RFI REQUEST FOR INFORMATION CONSOLIDAÇÃO DE DÚVIDAS APRESENTADAS

Receber intimações: poderão receber intimações em processos eletrônicos nos quais estejam vinculados.

SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO

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

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

Emissão de Nota Fiscal de Serviço Eletrônica

Transcrição:

ENCARTE R Estimativa de de Software Estimativa de de Software: Contratação de Serviços de Fábrica de Software Página 1 de 10

SUMÁRIO 1 REFERÊNCIAS... 3 1 INTRODUÇÃO... 3 3.1 ESTIMATIVA PRELIMINAR... 4 3.2 ESTIMATIVA INTERMEDIÁRIA... 4 3.3 MEDIÇÃO FINAL... 4 2 ESTIMATIVA BASEADA EM HORA DE SERVIÇO TÉCNICO (HST)... 5 3.1 O MÉTODO DE CÁLCULO... 5 1. ATORES... 5 2. DESCRIÇÃO... 5 3 MANUAL: ESTIMATIVA BASEADA EM HST... 6 3.1 PLANILHA ESTIMATIVA... 6 3.1.1. ITEM 1... 7 3.1.2. ITEM 2... 7 3.1.3. ITEM 3... 7 3.1.4. ITEM 4... 7

1 REFERÊNCIAS KARNER, G. Use Case Points: resource estimation for Objectory projects. Objective Systems SF AB (copyright owned by Rational/IBM), 1993 Roteiro de Métrica SISP, COCOMO,1981 - Construtive Cost Model, BOEHM, Barry W., Prentice Hall, 1981 Anda, B, Dreiem, H, Sjoberg, D, Jorgesen, M, Estimating Development Effort based on Use Cases Experiences from Industry. In M. Gogolla, C. Kobryn (Eds.): UML 2001 The Unified Modeling Language, Modeling Languages, Concepts, and Tools, 4th International Conference, Toronto, Canada, October 1-5, 2001, LNCS 2185, Springer-Verlag, pp. 487-502. 1. INTRODUÇÃO As estimativas do produto e do processo são a base para o planejamento do projeto de software. As estimativas fornecem dados que permitem prever o tempo necessário e os custos do projeto. Não é possível elaborar cronograma e orçamento sem o uso de estimativas. Para determinar o tempo de desenvolvimento, é necessário estimar a duração das atividades do software. Estimativas da duração do software dependem do tamanho do software que é necessário produzir e da produtividade dos profissionais alocados. Estimativas são realizadas com base em métricas. Métricas de tamanho, duração, produtividade e esforço estão entre as mais utilizadas. Para fazer as estimativas, pode-se optar por duas estratégias: Métricas com base no histórico do órgão Métricas estatísticas de diferentes órgãos As métricas históricas funcionam bem quando a organização é estável e já possui informações coletadas em anos de experiência. Para isso, é fundamental que exista um processo de gerenciamento do projeto cuidadoso e que todos os dados sejam obtidos para serem analisados e avaliados. Com isso, pode-se estimar como a equipe irá produzir, a partir de casos anteriores semelhantes. As estimativas podem ser realizadas por especialistas, que atribuem valores com base em suas experiências de projetos anteriores. Neste caso, podem-se utilizar analogias com projetos anteriores e estimar quais seriam os valores para o novo projeto. As métricas estatísticas são elaboradas por empresas especializadas que obtêm dados de diversas organizações de desenvolvimento de software. Estes dados devem levar em consideração as diversas condições e características que causem impacto no desenvolvimento do software. Com base nestes valores, os especialistas elaboram tabelas, fórmulas e algoritmos que podem ser aplicados no planejamento de um processo de software. Isto permite que as organizações de desenvolvimento possam elaborar o seu planejamento ajustando os valores as suas próprias condições. Os métodos algorítmicos para a realização de estimativas oferecem uma opção mais independente e objetiva. Um exemplo desses métodos são as estimativas de esforço. Esses métodos estão centrados no tamanho do software e da produtividade da equipe, por exemplo: Esforço = Produtividade*Tamanho O esforço é entendido como a quantidade de horas de trabalho a ser executada nas atividades de desenvolvimento do projeto que entregará, ao seu final, o produto/serviço de software, podendo ser apurado utilizando-se diversos métodos que estão disponíveis no mercado. O Ministério da Integração Nacional (MI) desenvolveu um método que foi baseado no método de Estimativa baseada em complexidade de Casos

de Uso: O processo de estimativa de esforço é realizado através da aplicação da complexidade das funcionalidades do software. As estimativas de esforço constituem um processo constante durante o desenvolvimento de software. Ele deve ser executado no início dos projetos (estimativas iniciais) e com base em requisitos preliminares, que identificam as funcionalidades contidas no escopo do software. As estimativas devem ser revisadas constantemente à medida que o desenvolvimento percorra seu ciclo de vida, a fim de verificar valores, apoiar a correção de desvios e avaliar o andamento do projeto de forma clara e objetiva. Ao final do desenvolvimento, é importante medir o tamanho final do produto de software entregue, assim como as apurações dos esforços realizados durante a sua construção. Tais medições geram valores que auxiliam no entendimento do contexto produtivo ocorrido em cada caso e retroalimenta a base histórica do MI, com dados que servem para a validação e aprimoramento de todo o processo de estimativas. O momento onde as estimativas e medições serão refeitas, dependerá do ciclo de vida de cada projeto em particular, mas são importantes os seguintes pontos de controle: 1.1. ESTIMATIVA PRELIMINAR Objetivo: Subsidiar estimativas para produzir os artefatos iniciais do projeto (predefinição do escopo do sistema e com o estabelecimento da linha de base da medição durante todo o ciclo de vida dentro da organização). Neste momento, o artefato disponível, geralmente, é apenas o DOD Documento de Oficialização da Demanda. 1.2. ESTIMATIVA INTERMEDIÁRIA Objetivo: Conferir estimativas preliminares ou intermediárias a partir dos resultados obtidos pela análise de requisitos do sistema (verificação do escopo do sistema). Podem ser realizadas tantas estimativas intermediárias quantas forem necessárias dependendo do tamanho e do formato do ciclo de vida do desenvolvimento de software, segundo suas iterações. Entradas: Documentação disponível do sistema: A documentação de apoio à contagem pode variar dependendo do ponto de execução em que o projeto se encontrar. o Modelo de Dados, Visão, Glossário, Diagrama de casos de uso, detalhamento de casos de uso e Protótipos. 1.3. MEDIÇÃO FINAL Objetivo: Realizar a estimativa do produto de software entregue ao usuário. Entradas: o Modelo de Dados, Visão, Glossário, Diagrama de casos de uso, detalhamento de casos de uso e Sistema em produção.

Em seguida serão apresentados os detalhamentos de como o MI Ministério da Integração Nacional realiza as suas estimativas de software. 2. ESTIMATIVA UTILIZADA PELA MI A estimativa utilizada pelo MI baseia-se no conceito da Técnica de Pontos por Casos de Uso. A análise de sistemas Orientados a Objetos já utiliza, comumente, os diagramas de Casos de Uso (Use Cases) para descrever as funcionalidades do sistema de acordo com a forma de utilização por parte dos usuários. A técnica de estimativa do MI foi criada para permitir que seja possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como subsídio para o cálculo. O Ministério da Integração Nacional possui um sistema para aplicação da Técnica de Pontos de Caso de Uso e que armazena o histórico de projetos de software do órgão. As Ordens de Serviço são abertas e gerenciadas pelo sistema que realiza a estimativa do projeto no inicio e permite que novos cálculos de estimativa sejam realizados ao longo da execução do projeto. Conforme método de cálculo descrito no item 3.1. 2.1. O MÉTODO DE CÁLCULO Uma vez que os casos de uso do sistema sejam identificados, é possível estimar-se o tamanho do software como um todo, baseando-se em um conjunto simples de métricas e modificadores. Os passos necessários para a geração da estimativa por Pontos de Caso de Uso são descritos a seguir: Passo 1: Identificação dos atores dos casos de uso O primeiro passo no cálculo do sistema é classificar a quantidade de atores envolvidos em cada caso de uso. A classificação de atores utiliza a tabela 1. Foi identificado como boa prática, na identificação dos atores que um número maior do que 3 (três) implicará na sua revisão e possível divisão do caso de uso. ATORES DESCRIÇÃO 1 Um sistema acessado através de uma API de programação, por exemplo. 2 Outro sistema interagindo através de um protocolo de comunicação, como WebService, TCP/IP ou FTP ou outra API Humano Um usuário interagindo através de uma interface gráfica (stand-alone ou Web) Tabela 1. Pesos de Atores Passo 2: Classificando os Casos de Uso Uma vez identificado os atores dos casos de uso, deve-se fazer a classificação destes. Para fins de cálculo, dividimos os casos de uso em três níveis de complexidade, de acordo com o número de fluxos envolvidos em seu processamento e com a associação dos atores que participam dos casos de uso. Por fluxos, entende-se como um conjunto de fluxos que devem ser realizados no caso de uso. Por exemplo: fluxo principal e fluxo alternativo. A tabela 2 mostra a classificação dos Casos de Uso de acordo com a quantidade de fluxo e de atores. Atores

Fluxos 1 2 Humano +3 1-4 Simples Simples Médio Dividir 5-6 Simples Médio Complexo Dividir 7-8 Médio Complexo Complexo Dividir +9 Dividir Dividir Dividir Tabela 2. Classificação dos casos de uso Foi identificada como boa prática nos episódios de casos de uso que tenham mais de 9 fluxos que os mesmos devem ser revistos, pois, podemos ter mais de um processo de negócio associado. Após a classificação dos casos de uso, será calculada a sua quantidade de Horas de Serviço Técnico (HST). Para calcular a quantidade de HST do sistema somam-se os HSTs identificados para cada caso de uso de acordo com a sua classificação. O valor total de HST foi calculado de acordo com a complexidade dos casos de uso, conforme apresentado no Item 2 da Figura 1. Para realizar este cálculo, o MI dispõe de uma Planilha denominada - Modelo - Planilha de HST.xltx, conforme apresentado na seção 3. A COSIS mantém atualizada, desde 2012, uma base histórica da execução dos seus projetos quanto ao escopo, ao esforço, ao custo e ao prazo. De acordo com estes dados, originou-se o trabalho de medição e análise para formar a base histórica dos seus projetos. 3. MANUAL: ESTIMATIVA BASEADA EM HST Esta seção tem como objetivo descrever passo a passo o arquivo Modelo - Planilha de HST.xltx. A Planilha possui 3 abas (planilhas): Leia-me: um informativo sobre as instruções referentes aos cálculos que serão realizados; Identificação: descrição sobre o projeto e tipo de Estimativa; Estimativa: Planilha que mostrará os casos de uso, assim como estimativas, complexidades, atores envolvidos, e fases. A partir da descrição acima, as abas 1 e 2 são apenas descrições e deverão ser preenchidas de acordo com o processo. Já a aba 3 identificada como Estimativa será melhor descrita para facilitar o manuseio de suas informações, como descrito no item 3.1 Planilha estimativa: 3.1 PLANILHA ESTIMATIVA A planilha estimativa possui a seguinte visão (figura 1). É importante reforçar que a tabela de Lista de Casos de Uso do projeto é a mais relevante visto que as demais tabelas serão preenchidas a partir dessa tabela. Sendo assim, seu preenchimento deve ser feito e revisado, para garantir que os cálculos estejam corretos: Fluxos Atores ITEM 1 1 2 Humano +3 1-4 Simples Simples Médio Dividir 5-6 Simples Médio Complexo Dividir 7-8 Médio Complexo Complexo Dividir

+9 Dividir Dividir Dividir ITEM 2 Simples Médio Complexo HST por Tecnologias ITEM 3 Total de UC por Tipo 1 1 0 Tecnologia Simples Médio Complexo HST 48 96 136 Java 48 96 136 HST ajustados 120 PHP 30 60 85 Lista de Casos de Uso do Projeto % Atores Fluxos Classificação HST Pronto ITEM 4 UC.001 UC.001 0% 2 1-4 48 48,00000 UC.002 UC.002 25% 2 5-6 96 72,00000 UC.003 UC.004 UC.005 UC.006 Figura 1 Informações das Funcionalidades 3.1.1. ITEM 1 O item 1 apresenta como os casos de uso são classificados quanto a sua complexidade em relação às quantidades de fluxos e atores. 3.1.2. ITEM 2 O item 2 mostra um resumo da medição a partir do momento que os casos de uso são classificados. 3.1.3. ITEM 3 O item 3 mostra a quantidade de HST por tecnologia e por complexidade para o desenvolvimento de um caso de uso no ciclo de desenvolvimento de Software do MI. Os valores foram obtidos a partir da base histórica de projetos; 3.1.4. ITEM 4 O item 4 Lista de casos de uso é o principal, pois lista todos os casos de uso do projeto. O cálculo da quantidade de HST será definido a partir das configurações presente nas colunas Atores e Fluxos. Veremos abaixo essa tabela mais sucintamente: A primeira coluna indica o número do Caso de Uso e a segunda coluna seu nome.

% Pronto: Essa coluna definirá o quanto daquele Caso de Uso já está pronto, ou seja, será utilizada nos casos de manutenção de uma funcionalidade. É importante respeitar os seguintes fatores de Pronto: Percentual de Pronto Explicação 50% Quando estiver fora da garantia e a funcionalidade foi feita pela mesma empresa 25% Quando estiver fora da garantia e a funcionalidade foi feita por outra empresa Atores: A coluna deverá ser selecionada com a quantidade de atores do Caso de uso, se é 1 a 2, ou se é uma pessoa, um ator humano. Esse campo irá influenciar no cálculo de HST para o Caso de Uso. Fluxos: Deverá ser selecionada a quantidade de Fluxos do Caso de Uso. A seleção desse campo auxiliará os campos seguintes, para a definição de quantos HST possui o Caso de Uso. HST: Essa coluna também é preenchida automaticamente e mostrará a quantidade de HSTs que aquele Caso de Uso possui efetivamente. Após a tabela, onde serão inseridos os fluxos e a descrição de todos os Casos de Uso do projeto, será visível uma outra tabela que mostrará através das fases do projeto os gastos, a disciplina, o esforço perfil e os produtos que serão entregues, como pode ser visto na Tabela 1: Fases Quantidade de HST estimada: 226 Disciplina Esforço (%) Esforço (HST) 1,00% 2,00 Perfil Produtos Cronograma Gerência de Projeto 1,00% 2,00 Relatório de Status Concepção 1,00% 2,00 Plano do Projeto Desenvolvimento Engenharia de 6,00% 14,00 1,00% 2,00 Total Fase: 22,00 R$ 0,00 5,00% 11,00 Gerência de Projeto 3,00% 7,00 Engenharia de 8,00% 18,00 1,00% 2,00 Documento de Visão Glossário Relatório de Status Atualização de Cronograma Especificação de Caso de Uso Lista de Mensagens

4,00% 9,00 2,00% 5,00 2,00% 5,00 Especificação de Interface Matriz de rastreabilidade Regra de Negócio Análise e Projeto Implementação 3,00% 7,00 Arquiteto de SW Documento de Arquitetura 10,00% 23,00 AD Modelo de Dados 5,00% 11,00 Desenvolvedor Protótipo 27,00% 61,00 Desenvolvedor Código fonte Encerramento Testes (VER e VAL) 4,00% 9,00 Testes Roteiro de Teste 4,00% 9,00 Testador Evidência testes Implantação 2,00% 5,00 Documentador Manual do usuário Total Fase: 182,00 R$ 0,00 Gerência de Projeto 2,00% 5,00 Integração 4,00% 9,00 Desenvolvedor Relatório de Status build Plano de Implantação Implantação 4,00% 9,00 Desenvolvedor Manual de Produção Total Fase: 23,00 R$ 0,00 Tabela 2 - Quadro Programática do Projeto Cada coluna possui um objetivo: Quantidade estimada de HST: Esse campo será preenchido segundo as descrições estabelecidas na tabela de Listagem de Caso de Uso, consolidando todos os Casos de Uso descritos. Fases: Irá mostrar o que será entregue nas fases do projeto, assim como os envolvidos e o quanto de HST que será gasto. Disciplina: Cada fase possui disciplinas, que serão listadas nessa coluna; Esforço: Mostra a porcentagem do esforço gasto por disciplina; Esforço (HST): Mostra a quantidade em HST do esforço gasto por disciplina; Perfil: Cada disciplina possui um perfil associado. Essa coluna mostrará o perfil do envolvido na disciplina; Produtos: Essa coluna listará, por disciplina, quais produtos serão entregues; Valor do Produto: Mostrará o valor em reais daquela disciplina; Ao final de todas essas divisões, necessárias para saber onde cada HST está sendo investido, ainda serão exibidas algumas tabelas que demonstrarão melhor a quantidade de HST necessária e envolvidos do projeto: A tabela representada pela Tabela 2 ilustra a fase e os perfis envolvidos, além do faturamento que poderá ser feito por fase. Além disso, apresenta uma linha de esforço total onde mostra por perfil dos envolvidos a quantidade de HST e a quantidade em Reais de custo por perfil.

Fases Gestão Análise Desenvolvimento Dias Faturamento por Fase Concepção 0,00 0,00 0,00 R$ 0,00 Desenvolvimento 0,00 0,00 0,00 R$ 0,00 Encerramento 0,00 0,00 0,00 R$ 0,00 Esforço Total 0,00 0,00 0,00 R$ 0,00 Custo por Perfil R$ 0,00 R$ 0,00 R$ 0,00 Tabela 3 - Faturamento por fase Ainda poderá ser visto a quantidade de horas que cada fase do projeto necessitará para ser concluída (Tabela 3): Fases Concepção Desenvolvimento Encerramento Horas Tabela 4 - Dias por fases A Tabela 4 mostra, a partir das tabelas anteriores, a quantidade total de horas do projeto, o prazo e a equipe ideal para a sua execução. Assim como em meses, a duração e a quantidade de envolvidos no total. Sendo assim, tem-se uma visão geral do projeto. Nesta planilha, utilizou-se uma inflator de 50% para cada HST, ou seja, considerou-se que para cada uma HST agregado no projeto necessitou-se de 1,5 hora de trabalho. Qtda de Horas 78,00 PRAZO E EQUIPE IDEAL Prazo Ideal: Prazo ideal comprimido 25%: Equipe Ideal para prazo comprimido: Meses Meses Pessoas Tabela 5 - Prazo e Equipe Ideal É importante informar que a planilha é um exemplo e que outras abas poderão ser inseridas para complementar alguma pendência ou dúvida relativa ao funcionamento como, por exemplo, uma planilha de Fatores de Ajuste.