Baixe o app para aproveitar ainda mais
Prévia do material em texto
Medidas do Esforço de Desenvolvimento de Software Aula 7 Prof. Horácio Ribeiro 1 Na aula anterior iniciamos métodos de estimativas do software - Avaliações com base estatística - cocomo 2 Estudo de casos Sistema de Manutenção de Clientes Descrição do sistema: Em um sistema de manutenção de clientes um usuário (funcionário de empresa) registra as entradas, alterações, exclusões e saídas (relatório) dos dados relativos a um cliente da empresa no sistema. Qualquer usuário da empresa poderá acessar o sistema e efetuar o cadastramento. (Não haverá controle de acesso no sistema). Será emitido um relatório de todos os clientes cadastrados e dos dados de um determinado cliente. Estudo de casos com ponto função Características do sistema: - O sistema irá permitir o acesso sem restrições para qualquer usuário da empresa, não havendo portanto, controle de acesso. - Não existe qualquer interface com outros sistemas existentes - Deverão ser cadastrados os seguintes dados de um cliente: Nome, endereço, Cidade , CEP , Telefone , Email e Observações. - O nome do cliente, endereço, cidade, CEP e email são obrigatórios e deverão ser sempre informados Casos de uso identificados A tecnologia usada no sistema para manutenção de cliente será de implementação em um site (processamento nas nuvens) usando a linguagem PHP (com suporte a objetos) envolvendo 3 camadas : camada de dados , camada de aplicação e camada de apresentação. Determinar Funções do tipo dado O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que possui a seguinte estrutura: Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas: É um grupo lógico de dados identificável pelo usuário ?Sim. É mantido por um processo elementar dentro da fronteira da aplicação ?Sim. A aplicação possui somente um ALI. Número de Tipos de Dados (TD) - é um campo único, reconhecido pelo usuário, não repetido. (7 tipos de dados ) Número de Tipos de Registros (TR) - é um subgrupo de tipo de dados, reconhecido pelo usuário, componente de um ALI ou AIE (1 Registro Lógico). Determinar Funções do tipo dado ALI e AIE devemos classificar a função de acordo com sua complexidade funcional Tipos de Dados Tipos de Registros < 20 20 - 50 > 50 1 Baixa Baixa Média 2 - 5 Baixa Média Alta > 5 Média Alta Alta Tipo de Função Baixa Média Alta Arquivo Lógico Interno - ALI 7 PF 10 PF 15 PF Arquivo de Interface Externa - AIE 5 PF 7 PF 10 PF funções do tipo dado para a aplicação é igual a 7 PF AIE - Arquivo de interface externa - é um grupo de dados logicamente relacionados que é usado pela aplicação entretanto sofre manutenção a partir de outra aplicação. A aplicação não tem nenhum AIE. Com contribuição de 0 PF. Determinar AIE As funções do tipo transação representam a funcionalidade fornecida ao usuário para atender os requisitos da aplicação. São classificadas como: Entradas Externas - EE - Processa as informações e/ou dados recebidos de fora da fronteira da aplicação Saídas Externas - SE - Envia dados ou informações para fora da fronteira da aplicação Consultas Externas - CE - Envia dados ou informações de controle para fora da fronteira da aplicação. Determinar as funções do tipo Transação Cada função do tipo transação deve ser classificada com relação a sua complexidade funcional em: Número de Arquivos Referenciados - AR - Um ALI lido ou mantido pela função do tipo transação ou um AIE lido pela função do tipo transação. Número de Tipos de Dado - TD - Um campo único, reconhecido pelo usuário, não repetido. Após determinar a quantidade de AR e TD da aplicação podemos definir a sua complexidade de acordo com as seguintes tabelas: Tabela de complexidade para Entradas Externas: Tipos de Dados Arquivos Referenciados < 5 5 - 15 > 15 < 2 Baixa Baixa Média 2 Baixa Média Alta > 2 Média Alta Alta Tipos de Dados Arquivos Referenciados < 6 6 - 19 > 19 < 2 Baixa Baixa Média 2 - 3 Baixa Média Alta > 3 Média Alta Alta Função Tipo AR TD Cadastro de Clientes - Incluir EE 1 7 - Alterar EE 1 7 - Excluir EE 1 7 - Listar SE 1 7 - Consultar CE 1 8 Vamos criar uma tabela para indicar as funções do tipo transação identificada e para cada uma delas a quantidade de AR e TD. (listar = 10 td SE - além dos campos de dados estamos estimando ou contando os comandos botão e mensagem ao usuário) (se não contar não fará diferença) Após determinar a complexidade das funções de transação podemos calcular sua contribuição de acordo com a tabela abaixo: Tipo de Função Baixa Média Alta Entrada Externa - EE 3 PF 4 PF 6 PF Saída Externa - SE 4 PF 5 PF 7 PF Consulta Externa - CE 3 PF 4 PF 6 PF Abaixo temos a tabela que exibe as funções do tipo Transação para a aplicação manutenção de clientes. Função Tipo Complexidade PF Cadastro de Clientes - Incluir EE Baixa 3 - Alterar EE Baixa 3 - Excluir EE Baixa 3 - Listar SE Baixa 4 - Consultar CE Baixa 3 Total dos Pontos de função para as funções de tipo transação da aplicação: 16 PF O total geral dos pontos de função não ajustados para a aplicação é de 23 PF ( 16 + 7 ) 16 PF Abaixo temos a tabela que exibe as funções do tipo Transação para a aplicação manutenção de clientes. Função Tipo Complexidade PF Cadastro de Clientes - Incluir EE Baixa 3 - Alterar EE Baixa 3 - Excluir EE Baixa 3 - Listar SE Baixa 4 - Consultar CE Baixa 3 Total dos Pontos de função para as funções de tipo transação da aplicação: 16 PF O total geral dos pontos de função não ajustados para a aplicação é de 23 PF ( 16 + 7 ) 16 PF Cálculo do fator de ajuste O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo: Característica Influência Característica Influência 1 4 8 0 2 0 9 2 3 0 10 0 4 3 11 4 5 0 12 3 6 0 13 0 7 0 14 4 Valor Total => 20 Uma equipe de profissionais respondeu e deu nota para os 14 características: As notas dadas para os itens foram: VFA = (20 x 00,1 ) + 0,65 = 0,85 O valor do fator de ajuste é igual a 0,85. Cálculo do fator de ajuste O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo: Característica Influência Característica Influência 1 4 8 0 2 0 9 2 3 0 10 0 4 3 11 4 5 0 12 3 6 0 13 0 7 0 14 4 Valor Total => 20 Uma equipe de profissionais respondeu e deu nota para os 14 características: As notas dadas para os itens foram: VFA = (20 x 00,1 ) + 0,65 = 0,85 O valor do fator de ajuste é igual a 0,85. Como estamos usando as regras do manual de contagem, que também são usadas por outras empresas. Isto nos facilita, pois se não tivermos uma base histórica podemos buscar informações em outras empresas a fim de subsidiar sua estimativa. Na nossa empresa O esforço em horas é obtido pela formula (já por indicadores estatísticos) Esforço Total (horas ) = PF * índice de produtividade (os índices de produtividade podem ser expressos em Horas/PF ou PF/mês ). A aplicação em questão que possui 22,95 PF , se o índice de produtividade da empresa ou equipe for de 10 horas/PF o esforço demando seria algo em torno de 229,5 horas. Assim o projeto demandará 229 horas para ser desenvolvido (considerado apertado). Com base na informação de 229 horas e sabendo-se o custo da equipe por hora podemos definir o preço Nesta aula: Outra formas de estimativa em modelos dinâmicos; Estimativas Putnam; Outros métodos voltado para ponto função; Estimativas com métodos ágeis Categorias Nº de organizações Percentual(%) Linhas de código ( LOC ) 25 5,6 Pontos por função (Function Point) 43 9,6 Outras métricas 26 5,8 Não utiliza 363 81,4 Base 446 100 Considerando a pesquisa realizada pela Secretaria de Política de Informática – SEPIN , em 2001, cujo resultado é apresentado na tabela Importância do assunto 23 Estimar software O planejador deve estimar três coisas antes do início do projeto: Quantotempo durará Quanto esforço será exigido Quantas pessoas estarão envolvidas E também: Recursos de hardware e recursos de software necessários 24 Técnicas Técnicas para desenvolver estimativas envolvem: decomposição modelagem empírica ferramentas automatizadas 25 técnicas Técnicas empíricas usam expressões derivadas de dados históricos, para o esforço e o tempo, com o objetivo de prognosticar essas quantidades para o projeto. Ferramentas automatizadas implementam um modelo empírico específico. Estimativas de projeto precisas geralmente fazem uso de pelo menos duas técnicas diferentes de estimativas vistas. 26 Estimativas de Projetos de Software Estimativas de recursos, custos e programação de atividades exigem: conhecimento. Acesso a boas informações históricas. Coragem para se comprometer com as medidas quantitativas. 27 Estimativas de Projetos de Software Estimativas => carregam riscos inerentes Fatores que aumentam os riscos: Tamanho do projeto Complexidade baseada nos esforços passados Desestruturação do projeto Domínio de baixo risco 28 Estimativas Estimativas de Pontos por Função (PF) variáveis de estimativa - usadas para “classificar por tamanho” cada elemento do software. Como métricas de “base line”- coletadas a partir de dados históricos e usadas em conjunto com variáveis de estimativa para que se desenvolva projeções de custo e de esforço 29 Estimativas Método de estimativa do Esforço Passos (visão - PMI): Delineamento das funções do software Listagem das tarefas a serem executadas para cada função (análise, projeto, codificação e testes) Esforço estimado para cada tarefa em cada função (pessoa-mês) Taxas de mão de obra aplicadas em cada uma das tarefas Cálculo de custo e o esforço de cada função (e tarefa de engenharia de software) 30 Estimativas de Projeto de Software Modelos Empíricos de Estimativa Fórmulas construídas empiricamente para fornecer informações de planejamento de projeto. Dados Empíricos - resultam de uma amostra limitada de projetos. Modelos de software - não são apropriados para todas as classes de software Devem ser usados criteriosamente (usar mais de um método de avaliação) 31 Estimativas de Projeto de Software: Modelos de Recursos Modelos de Recursos são formados por uma ou mais equações empíricas que fornecem informações sobre: Esforço (pessoa-mês) Duração do projeto (meses cronológicos), etc. Alguns trabalham por fase do projeto 32 Estimativas de Projeto de Software: Modelos de Recursos Existem quatro classes de modelos de recursos (Basili) Modelos estáticos de variáveis simples. Modelos estáticos de múltiplas variáveis Modelos dinâmicos de múltiplas variáveis Modelos teóricos 33 Estimativas de Projeto de Software: Modelos Estáticos de Variáveis simples Recurso = C1 X (características Estimadas) Recurso: esforço duração do projeto tamanho da equipe páginas (linhas) de documentação C2 34 Estimativas de Projeto de Software: Modelos Estáticos de Variáveis simples Recurso = C1 X (características Estimadas) Características Estimadas linhas de código fonte (LOC)...PF esforço (se estimado) C1 e C2 - constantes derivadas de dados compilados de projetos passados. Exemplo: COCOMO (Constructive Cost Model) C2 35 Estimativas de Projeto de Software: Modelos Estáticos de Múltiplas Variáveis Recurso = C11e1 + C21e2 + ... Onde e1, e2, e3 ... São características do software Exemplo: C (homem mês) = 0,12*paginas +23,2*linhas +... 36 Estimativas de Projeto de Software: Modelos Dinâmicos de Múltiplas Variáveis projetam os requisitos de recursos como uma função do tempo recursos são definidos atribuindo-se uma porcentagem de esforço a cada passo do processo de software (desenvolvimento) O esforço distribuido, em grandes projetos, é mostrado na figura abaixo, reproduzida do professor Pressmam. modelo dinâmico de múltiplas variáveis que pressupõem a distribuição do esforço ao longo da existência de um projeto de desenvolvimento Estimativas de Projeto de Software: 39 Estimativas de Projeto de Software: Modelos Teóricos abordam teoricamente modelos dinâmicos de múltiplas variáveis Examina o software de forma minuciosa (ex. Números de operandos e operadores - modelo de estimativa de Putnam) método de Putnam que considera múltiplas variáveis e o ciclo de desenvolvimento do projeto Estimativas de Projeto de Software: Curva de Rayleigh-Putnam Com base em análise estatística Putnam relacionou o comportamento prazo e esforço com distribuição de Rayleight 42 Estimativas de Projeto de Software: Modelo de Putnam Equação de Software Curva de Rayleigh-Putnam Os pontos destacados representam a quantidade de recursos recursos = f( esforço, prazo) Curva de Rayleigh-Putnam Mesmo com as mudanças de tecnologias o gráfico mostra que existe uma região que é impossível a entrega no prazo Estimativas de projetos orientado a objetos (Pressman) O software orientado a objetos deve ter outra abordagem (6 passos) Desenvolver estimativas usando decomposição de esforço e análise FP; Desenvolver o diagrama de casos usos com o seu respectivo dicionário, e determinar a contagem de PF. - Reconhecer que o número de casos e uso podem modificar à medida que se desenvolve o projeto. 3.A partir do modelo determinar o número de classes. Tipo de interface Multiplicador Não IGI 2,0 Interface com o usuário baseado em texto 2,25 IGI 2,5 IGU complexa 3,0 Estimativas de projetos orientado a objetos (Pressman) 4 .Categorizar o tipo de interface para aplicação para as classes de apoio. Multiplicar o número de classes chaves pelo multiplicador para obter uma estimativa para o número de classes de apoio. Estimativas de projetos orientado a objetos (Pressman) 5.Multiplicar o número total de classes pelo número médio de unidades de trabalho por classes. Autores como Lorenz sugerem entre 15 a 29 pessoas dia por classe 6.Fazer a verificação cruzada em estimativas baseadas em classes multiplicando o número médio de unidades por caso e uso Estimativas com métodos ágeis Um projeto usando um processo de desenvolvimento ágil e feito como um conjunto de cenários de usuários. É possível desenvolver uma estimativa com razoável significado com os seguintes passos: 1.Cada cenário de usuário é considerado separadamente para a estimativa. 2.O cenário é composto de um conjunto de funções e tarefas de engenharia. de software. 3 a.Cada tarefa é estimada separadamente. b.O tamanho do cenário pode ser estimado em LOC, PF ou alguma outra medida orientada a volume Estimativas com métodos ágeis 4.a - As estimativas de cada tarefa são somadas para criar uma estimativa de cenário b - O volume de esforço é estimado para o cenário criado e depois é quantificado para o esforço necessário, a partir de dados históricos referentes a outros projetos 5.As estimativas de esforço para todos os cenários que devem implementar um incremento de software são somadas para definir a estimativa para o incremento. Normalmente a duração do desenvolvimento de um incremento é da ordem de 3-6 semanas. Estimativa usando Caso e USO PCU – Pontos por Caso de Uso – Foram criados por Gustav Karner em 1993 como uma adaptação específica dos Pontos de Função para medir o tamanho de projetos de software orientados a objeto. Explora o modelo e descrição do caso de uso, substituindo algumas características técnicas proposta pelos Pontos de Função. É um método simples e de fácil utilização, entretanto, mas ainda esta em fase de pesquisas e não existem regras de contagem padronizadas conclusões Não existe um modelo único. Deve-se desenvolver o modelo mais adequado a empresa Deve-se fazer sua carta gráficas. O modelo deve ser periodicamente revisto Deve-se validar por mais de um método É um aspecto estratégico para a empresa conclusões Cuidado com indicadores de mercado deve-se conhecer particularidades da coleta, forma de desenvolvimento, ferramentas...) conclusão A estimativa de tamanhode um projeto de software é uma atividade crítica pois tem um impacto tanto na solução técnica a ser adotada como no gerenciamento do projeto de software devendo ser efetuada não somente no início do projeto mas durante o ciclo de vida do projeto. Próxima aula a usar as estimativas e ponto função como instrumento de gestão. Vamos aprender a dimensionar receita e custos a partir de ponto função. Vamos aprender a utilizar estes valores se distribuem, no processo de desenvolvimento, na gestão do projeto e da empresa Definir métricas que sirvam de parâmetros para a gestão Até a próxima aula 55 Contactos: Professor Horacio ribeiro www.espacodoprofessor.com Email: profhoracioribeiro@gmail.com Aula 7 56 L = Ck.K1/3.td4/3, onde L = linha de código Ck = constante de estado de tecnologia Ck = 2.000 –ambiente de desenvolvimento pobre Ck = 8.000 – métodos em prática, documentação e revisões adequada Ck = 11.000 – ambiente ótimo (ferramentas e técnicas automatizadas) K = esforço (pessoa – ano) Td = tempo de desenvolvimento (anos) Novo arranjo: Esforço – K = L3/(ck3.td4)
Compartilhar