Estimativas de Software

Transcrição

1 CURSO: Bacharelado em Sistemas de Informação DISCIPLINA: Projeto e Desenvolvimento de Software PERÍODO: 5º ANO LETIVO: 2008/1º Sem PROFESSOR: Anderson Dutra Moura Material: Estimativas de Software Estimativas de Software O problema de se estimar um projeto de software envolve em sua grande maioria a previsão de quatro variáveis: o tamanho, o esforço, os prazos e a qualidade. O esforço é normalmente obtido através do cálculo do tamanho; o prazo e o custo são obtidos a partir do esforço; a qualidade é obtida por meio de um conjunto de fatores que vai muito além do tamanho, do esforço e dos prazos e custos. Estimativas de Esforço e Prazo Para estimar tamanho, esforço e prazo é necessário que seja selecionada uma abordagem, para obtenção de estimativa. As abordagens existentes podem ser divididas em: Modelos paramétricos: assumem a existência de uma relação matemática entre tamanho, esforço e prazo. Tal relação é afetada por parâmetros de performance. Os relacionamentos são baseados em situações teóricas ou fatos históricos. Modelos baseados em atividades: também chamada de estimativa bottom up, Esta modalidade consiste em enumerar atividades e estimar esforço e prazo para cada uma delas. Analogia: esta técnica baseia-se na comparação das características do projeto com a de outros projetos concluídos. As diferenças são identificadas e as mudanças necessárias são introduzidas no processo. Relações simples de estimativas: é uma simplificação dos modelos paramétricos. Neste caso, utilizam-se relações matemáticas simples baseadas em fatos históricos, ao invés de relações matemáticas abrangentes. Estimativas de Tamanho As medidas de tamanho de software surgiram com o objetivo de estimar esforço (número de pessoas/hora) e o prazo associado ao desenvolvimento de sistemas. A seguir serão descritas algumas técnicas existentes: APF Métrica mais antiga e mais utilizada no mundo Padrão internacional desde 2002 Não requer o uso de notação padrão, mas é baseada no modelo funcional e independente de tecnologia Largamente discutida na literatura É suportada pelo IFPUG e diversos grupos nacionais de usuários e bases históricas de contagens realizadas UCP Métrica relativamente nova e pouca utilizada Ainda não alcançou o nível de padronização e nem foi incorporada em ferramentas populares Baseada no modelo de casos de uso Tem aumentado o uso e a publicação de estudos na literatura O Modelo de casos de uso ainda não possui bons históricos de produtividade

2 Possui regras de contagem padronizadas Não há padrões para descrever casos de uso, há dúvidas na contagem de casos de uso incluídos e estendidos e para determinar o nível apropriado de detalhe para cada transação do caso de uso È mais utilizada no final das fases de Utilizado na fase inicial do projeto análise e projeto Visão do usuário Visão do usuário Alto nível de maturidade Em fase de amadurecimento É subjetiva e possui diferença entre É subjetiva e possui diferença entre contadores contadores Oferece treinamento e certificação Ainda não oferece treinamentos e certificação Linhas de Código: A técnica de mensuração por linhas de código (LOC Lines of Code) é uma das medidas mais antigas para se determinar o tamanho, esforço e, conseqüentemente, produtividade no desenvolvimento de software. Ela consiste basicamente na contagem da quantidade do número de linhas de código de um programa de software. Análise de Pontos de Função (APF): A técnica de Análise de Pontos de Função APF é a técnica mais utilizada no mercado para mensuração do tamanho de projetos de desenvolvimento e melhoria de sistemas. Esta técnica consiste na determinação do tamanho funcional do sistema através da visão do usuário, independentemente da tecnologia utilizada. A unidade de medida utilizada na determinação do tamanho do sistema é o Ponto de Função. Mark II (ou MK II): Técnica que visa melhorar a escala de tamanho funcional, contando mais apuradamente a complexidade de processamento interno de Sistemas de Informações Gerenciais. Uma das principais diferenças entre APF e MK II é que a primeira técnica conta arquivos lógicos uma vez para cada parte de software sendo mensurada, enquanto que a MK II conta tipos de entidade toda vez que elas são referenciadas em cada transação lógica. Segundo o manual do MK II, as duas métricas pontuam similarmente os projetos com até 400 pontos de função. Ultrapassando esse valor, a tendência é que a métrica MK II pontue valores maiores que a APF. Feature Points: Nessa técnica, além das funções de dados e funções de transação, existe um item de análise de algoritmos. Ela se propõe resolver as dificuldades que a técnica de Análise de Pontos de Função apresenta quando conta sistemas em tempo real de controle de processos, e outros que apresentam alta complexidade algorítmica. Use Case Points (UCP): Técnica proposta para medir o tamanho de projetos de software orientados a objeto, o Use Case Points (ou Pontos por Caso de Uso) explora o modelo e a descrição do caso de uso, substitui algumas características técnicas propostas pela APF, cria os fatores ambientais e propõe uma estimativa de produtividade. A desvantagem é que só pode ser utilizado por empresas que adotem os casos de uso como forma de expressão dos requisitos. A Empresa, Processos e Atividades A organização em que este estudo prático foi realizado, é uma empresa de desenvolvimento de software que busca obter o nível 2 do CMM. Sua estrutura é divida em departamentos: Administrativo, Comercial (vendas), Suporte Técnico, Desenvolvimento e Controle de Qualidade do Produto. Os softwares desenvolvidos pela empresa são voltados para a gestão de empresas e automação dos processos, focando-

3 se principalmente na área de supermercados, lojas de departamentos e materiais de construção. Os processos e fluxos de tarefas realizados serão discutidos e detalhados nos próximos itens. Tarefas Para controle das tarefas realizadas na empresa, desenvolveu-se uma ferramenta de workflow que possibilita todo o controle do fluxo de tarefas, desde a criação desta pelos clientes ou colaboradores, até a sua finalização. A figura acima ilustra os possíveis fluxos de tarefas de acordo com a realidade da empresa. No contexto de sua atuação, uma tarefa é definida como uma solicitação de cliente (seja ela de dúvida, análise, de desenvolvimento de recursos, etc), como uma solicitação dos próprios colaboradores, como um item a ser analisado e discutido, como projetos ou propostas da própria organização, enfim, como todo e qualquer item que envolva a execução de atividades por parte de uma ou mais unidades funcionais da empresa. Nas situações mais comuns, ocorre a abertura de uma tarefa por meio de uma solicitação de cliente (esta abertura pode ser realizada tanto pelo próprio cliente através da ferramenta disponível na web, quanto pelos agentes, analistas de suporte técnico, ou qualquer outro colaborador da empresa). Esta tarefa passa pelo suporte técnico que a resolve nos casos de seu tipo ser de dúvida, atualização ou solicitações do gênero. Se a tarefa exigir a implementação ou alteração de uma solução, ela entra para o planejamento de versão, que engloba todo o processo de desenvolvimento definido pela empresa (estaremos detalhando este processo em um item específico). Após concluída a implementação, ocorre a homologação pelo CQP controle de qualidade do produto, e então a entrega da solução ao cliente. Somente as solicitações que exigirem implementação ou alteração de software é que passarão pelos setores de desenvolvimento e controle de qualidade. Existem casos em que a solicitação chega ao desenvolvimento, mas a solução não necessariamente é o desenvolvimento de um

4 software para o cliente, mas sim uma alteração em seus processos, uma reestruturação de suas atividades. Processo de Desenvolvimento O Processo de Desenvolvimento (PD) definido pela empresa visa a melhoria contínua dos produtos e processos, e conseqüentemente, o alcance do nível 2 do CMM. Sua definição foi realizada para se ajustar às necessidades da organização, de forma que proporcione o maior beneficio possível, com o menor impacto em termos de custos para a empresa. Sua principal característica é um conjunto de etapas ou fases bem definidas, de responsabilidades claramente distribuídas e de tarefas corretamente especificadas. O processo de desenvolvimento caracteriza-se por ser iterativo e incremental, utilizando uma forma de organização estruturada em versões de produto. Na figura 2, apresenta-se um esquema das etapas de desenvolvimento do processo de desenvolvimento. O processo de desenvolvimento abrange todas as tarefas que são criadas e que de alguma forma, exigem o desenvolvimento ou alteração de um recurso de software para serem finalizadas. O fluxo destas tarefas é controlado pela ferramenta de workflow da empresa, que orienta e trata cada fase do PD. A Realização de Estimativas no Processo de Desenvolvimento As estimativas de software realizadas dentro do PD são necessárias para a construção dos cronogramas, definições de escopo de versão, previsão de alocação de recursos, de pessoas, e realização de orçamentos. Uma correta e bem realizada estimativa é fundamental para a qualidade do processo, do produto e para a viabilidade da execução das atividades. Seguindo o processo de desenvolvimento adotado pela empresa, toda solicitação que é analisada para entrar em escopo de versão, para identificação do problema ou proposta de solução, recebe uma estimativa de tempo para sua conclusão. Este tempo multiplicado por um valor pré-determinado como custo hora/homem de trabalho para a empresa, retorna o custo total relacionado à solicitação em discussão. Para o processo de desenvolvimento, a quantidade em Tempo é essencial, o gerenciamento, controle e negociação quanto ao Custos financeiros, é de responsabilidade do departamento Comercial\Administrativo. Verificação de Estimativas Nos processos da empresa toda estimativa realizada propicia um feedback para a realização de novas estimativas. Isto não seria possível sem o controle e a análise do

5 tempo previsto versus o tempo realizado para cada solicitação desenvolvida. Para obter estas informações, antes mesmo da realização de uma pré-estimativa pelos analistas de requisitos, o tempo aplicado por cada colaborador da empresa para a resolução de uma solicitação, já está sendo contabilizado. No momento em que uma nova solicitação (tarefa) é iniciada, o sistema de controle da empresa inicia a contagem de tempo que a mesma utiliza em cada fase do fluxo de atividades, até a sua conclusão. Este controle permite saber quanto tempo a tarefa ficou no suporte técnico com o analista X, antes de ser encaminhada para análise de requisitos; qual o período utilizado para a realização da análise, para a implementação, testes, até o encerramento da solicitação. O controle fornecido é por fase\etapa do processo, pela(s) pessoa(s) responsável(eis) em desempenhar a tarefa, e por execução global, correspondendo ao tempo total que a tarefa consumiu desde a sua criação, até sua conclusão. Estas informações permitem analisar o quão corretas as estimativas estão sendo realizadas, quais os principais pontos de gargalo no processo, quais foram os responsáveis pela execução das atividades, e principalmente, possibilitam a geração de conhecimento que servirá como base para a realização de novas estimativas, mais corretas, consistentes e eficientes. Estimativas de Software Utilizando a Técnica de UCP A técnica de Use Case Points (UCP) foi escolhida justamente por possibilitar a realização de estimativas de software logo no inicio dos processos de desenvolvimento. Como especificado na descrição do PD, as estimativas são fundamentais para a organização e planejamento de todas as atividades ligadas ao desenvolvimento de software, e isto exige que no inicio do processo, seja realizada uma estimativa que oriente todo esse controle. A principal dificuldade em realizar uma estimativa no inicio do processo de desenvolvimento, é a não estabilidade dos requisitos e a ausência de informações sobre os mesmos. Mesmo com a utilização de uma técnica desenvolvida com este propósito, que é o caso da UCP, a atividade de realizar estimativas continua muito dependente da experiência das pessoas envolvidas, e do conhecimento armazenado pela empresa sobre a realização de estimativas. Para demonstrar a realização de estimativas será considerada a solicitação de uma implementação de um recurso relacionado ao gerenciamento de promoções de vendas, caracterizada como uma melhoria para o sistema já utilizado pelo solicitante. Não serão descritos os casos de uso desta solicitação nem os seus requisitos de forma detalhada, o objetivo é demonstrar a utilização da planilha e os cálculos realizados. UUCP (Unadjusted Use Case Points): Peso Total NãoAjustado Neste item, são determinados os pesos dos atores e dos principais casos de uso. O peso total não ajustado (UUCP) é determinado pela somatória dos dois pesos, conforme demonstram as tabelas 1 e 2.

6 Os valores da coluna Fator obedecem a seguinte definição: Atores: Ator Simples Peso 1: Outro sistema acessado através de uma API de programação; Ator Médio Peso 2: Outro sistema interagindo através de um protocolo de comunicação, como TCP/IP ou FTP; Ator Complexo Peso 3: Um usuário interagindo através de uma interface gráfica (stand alone ou Web) Casos de Uso: Se o caso de uso for considerado simples isto é, conter uma interface com usuário simplificada e utilizar apenas uma entidade em um banco de dados caso de uso é considerado fácil e tem peso 5. Se o caso de uso envolve uma interface mais trabalhada e utiliza-se de duas ou mais entidades de banco de dados, ele é definido como médio e recebe um peso 10. E se o caso de uso envolver 3 ou mais entidades em um banco de dados e contiver uma interface mais complexa, este é considerado complexo e recebe um peso 15. O índice de UUCP (Unadjusted Use Case Points) é obtido pela soma dos pesos atribuídos aos casos de uso e aos atores: 15+2 = 17

7 Fatores de Ajustes Técnicos TCF Na tabela 3 realiza-se o cálculo dos ajustes técnicos (TCF), que influenciarão no resultado final da estimativa. O resultado TCF final é a soma de todos os Pesos Estimados. Estes pesos são obtidos pela multiplicação da coluna Peso (cujos valores são definidos pela técnica) pela coluna Avaliação (definida pelo analista). Os valores 0,6 e 0,01 também são pré-definidos pela técnica. Fatores Ambientais EF Estes fatores de ajuste correspondem ao nível de disponibilidade do recurso no decorrer do projeto. Assim, determinar que um fator tem nível de influência alta (atribuir a ele o valor 5), significa que este fator está presente no projeto como um todo e influencia seu desenvolvimento. Por outro lado, a atribuição de um valor de influência zero (nenhuma influência) a um fator, indica que o mesmo não está presente no processo de desenvolvimento.

8 O cálculo do Fator EF é realizado da mesma forma que o Fator TCF. Os valores 1,4 e 0,03 também são pré-definidos pela técnica juntamente com os Pesos da primeira coluna. Cálculo do Porte do Sistema UCP Esforço Custo O cálculo do UCP final, que corresponde ao porte do sistema sugerido pela técnica, é obtido pela fórmula UCP = UUCP x TCF x EF, resultado da multiplicação dos pesos dos atores e dos casos de uso, pelos fatores de ajustes técnicos e ambientais. No exemplo utilizado, obteve-se um UCP de 8 (17 * 0,66 * 0,71). A Produtividade é definida pela empresa, correspondendo ao número de horas para cada ponto de UCP para determinar assim, o esforço necessário em horas/homem para a realização da tarefa. Podemos estimar o tempo necessário para o desenvolvimento do projeto calculando-se uma média de 20 horas de trabalho por Ponto de Caso de Uso (UCP), experiências práticas no uso desta técnica demonstram uma variação entre 15 e 30 horas por ponto. Para os processos de realização de estimativas na empresa, adotou-se o valor de 17,00 horas por UCP, conforme demonstra a tabela 5.

9 O custo em valores pode ser obtido pela multiplicação entre as horas sugeridas e o valor pré-definido pela organização (R$ 35,00 na tabela 5), resultando numa estimativa de desenvolvimento de 136 horas/homem e um custo de R$ 4.760,00. Análise da Utilização da Técnica de UCP O cálculo de estimativas através da técnica de UCP demonstrou-se útil principalmente para fornecer uma base do custo consumido em desenvolver novos sistemas, recursos ou módulos, dos quais a empresa não dispõe de informações e nem de experiências já realizadas em um foco semelhante. A grande vantagem encontrada está na orientação que a realização dos cálculos exibidos nas tabelas 1 a 5 pode proporcionar, que combinada com as experiências e projetos já desenvolvidos e monitorados, possibilita a geração de estimativas mais precisas e seguras. Porém, um dos principais pontos fracos encontrados na prática é justamente a grande variação na estimativa realizada frente à pequenas alterações nos pesos utilizados para o cálculo, bem como a sua grande sujeição à experiência e opiniões pessoais dos analistas que a realizam. Devido à organização que a empresa estudada mantém, seus controles e processos bem definidos e inclusive pela capacidade das pessoas envolvidas, a utilização de critérios menos rigorosos para a definição de estimativas pode ser indicada. Porém, é necessária uma técnica mais precisa, adequada e realista, aplicável em pequenos e médios projetos, e que seja mais independente do conhecimento prévio de seus usuários. Análise da Técnica de UCP Como proposta de refinamento da técnica de UCP, propõem uma variação na técnica para estabelecer o valor de horas por UCP. Esta variação sugere que a presença de certos atributos influencia diretamente a média de horas por ponto calculado, utilizando a seguinte lógica: Conta-se a quantidade de fatores técnicos entre T1 e T6 (ver a tabela 3) que receberam nível de influência maior que 3; e então soma-se o valor obtido à quantidade de fatores ambientais entre E7 e E8 (ver tabela 4) que receberam valor de influência menor que 3.

10 O somatório indica a quantidade sugerida de horas por ponto de caso de uso a ser adotada no projeto, sendo a média sugerida de: 20 horas por ponto, para um resultado de 2 ou menor. 28 horas por ponto, caso o somatório resulte em 3 ou horas por ponto, para valores maiores que 4. Nos casos em que a sugestão é de 36 horas, os autores sugerem que o projeto seja revisto, que os requisito e casos de uso sejam reavaliados, e principalmente que os fatores técnicos e ambientais sejam estudados, pois talvez seja necessário realizar um treinamento de pessoal, uma adequação de tecnologia ou revisão dos requisitos especificados, de modo que se torne possível garantir um melhor aproveitamento de recursos, e principalmente, uma redução no cronograma previsto.