DIEGO LIBERATO DELFINO JEFERSON DE SOUZA
DESENVOLVIMENTO DE UMA FERRAMENTA DE ESTIMATIVAS BASEADA EM PONTOS DE FUNÇÃO
TÍTULO DO TRABALHODFASDJSDJFHASDJKFHAJLKSULO DO TRABALHO
Palhoça 2010
JEFERSON DE SOUZA
DESENVOLVIMENTO DE UMA FERRAMENTA DE ESTIMATIVAS BASEADA EM PONTOS DE FUNÇÃO
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharelado em Ciência da Computação.
Orientador: Profa. Msc. Vera Rejane Niedersberg Schuhmacher
Palhoça 2010
DIEGO LIBERATO DELFINO JEFERSON DE SOUZA
DESENVOLVIMENTO DE UMA FERRAMENTA DE ESTIMATIVAS BASEADA EM PONTOS DE FUNÇÃO
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharelado em Ciência da Computação e aprovado em sua forma final pelo Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina.
Palhoça, _____ de ______________ de 2010.
______________________________________________________ Profª. Msc. Vera Rejane Niedersberg Schuhmacher.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Dr. Engº. Aran Bey Tcholakian Morales.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Drª. Maria Inés Castiñeira.
Dedicamos este trabalho às nossas famílias, fundamentais em nossas vidas.
AGRADECIMENTOS
Às nossas famílias, fonte inspiradora, na qual nos espelhamos e tomamos como exemplo.
À professora Vera Rejane Niedersberg Schuhmacher, nossa orientadora, por ter aceitado o convite, pela inestimável dedicação, atenção e paciência com que conduziu a orientação deste trabalho.
“Siga em frente corajosamente, porque a vitória sorri somente àqueles que não param no meio da estrada.” (Torres Pastorino).
RESUMO
Quando um projeto de software é planejado, são realizadas várias estimativas necessárias para a condução do restante do projeto. É nesta etapa inicial que são realizadas estimativas para determinar o tamanho do projeto de software, e a partir desta medida definir o esforço, custo e prazo do projeto. A ausência de estimativas em projetos de software pode causar, por exemplo, perdas de prazo, gastos excessivos, insatisfação do cliente e até mesmo o cancelamento do projeto. Diante da importância das estimativas nos projetos de software, percebeu-se que o estudo de técnicas de estimativa é um aspecto importante na formação de futuros profissionais da área de engenharia de software. O objetivo deste projeto foi desenvolver uma ferramenta que gerencie as estimativas de um projeto de software com base na técnica de Análise de Pontos de Função (APF). Esta ferramenta, além de gerar estimativas, também permite que futuros profissionais da área de software tenham contato com uma das técnicas de estimativa mais utilizadas em projetos de software. O trabalho teve início a partir do estudo e compreensão da técnica de Análise de Pontos de Função. A segunda etapa caracterizou-se pela identificação dos requisitos e modelagem do sistema proposto, tendo como base a metodologia de desenvolvimento ágil ICONIX. Após a modelagem, o sistema foi implementado, tendo como principais tecnologias a linguagem de programação Java e o sistema gerenciador de banco de dados MySQL. Por fim, o sistema foi validado pela professora orientadora, que sugeriu algumas mudanças e futuras adaptações.
ABSTRACT
When a software project is planned, are performed various necessary estimates for the conduction of the remain of the project. It is at this early stage that estimates are performed to determine the size of software project, and from this measure defines the effort, cost and duration of the project. The absence of estimates in software projects can cause, for example, loss of time, wastage, customer dissatisfaction and even the cancellation of the project. Given the importance of the estimates in software projects, it was noted that the study of estimation techniques is an important aspect in training future professionals in software engineering The objective of this project was to develop a tool that manages the estimates of a software project based on the technique of Function Point Analysis (FPA). This tool, in addition to generating estimates, also allows for future software professionals have contact with one of the estimation techniques used in most software projects. The work began with the study and understanding of the technique of Function Point Analysis. The second stage characterized for the identification of the requirements and modeling of the considered system, having as base the methodology of agile development ICONIX. After modeling, the system was implemented, having as main technologies to the Java programming language and the system manager database MySQL. Finally, the system was validated by the orienting professor, who suggested some changes and future adaptations.
Key words: Software, Estimates, Function Points.
LISTA DE ILUSTRAÇÕES
Figura 1 – Redução da incerteza durante o curso do projeto de software... 26
Figura 2 – Recursos de projeto ... 29
Figura 3 – Derivando Esforço, Cronograma e Custo. ... 32
Figura 4 – Processo de Estimativas. ... 32
Figura 5 – O processo de contagem: determinar o tipo de contagem. ... 47
Figura 6 – O processo de contagem: identificar a fronteira da aplicação e o escopo da contagem. ... 48
Figura 7 – O processo de contagem de ALI e AIE. ... 49
Figura 8 – Contar funções do tipo transação. ... 52
Figura 9 – Contagem de pontos de função não-ajustados. ... 55
Figura 10 – Determinar o valor do fator de ajuste ... 57
Figura 11 – Cálculo dos pontos de função ajustados. ... 57
Figura 12 – Proposta de Solução. ... 62
Figura 13 - Requisitos Funcionais. ... 66
Figura 14 - Requisitos Não-Funcionais... 69
Figura 15 – Diagrama de Pacotes. ... 70
Figura 16 – Interface do Menu Principal. ... 71
Figura 17 – Interface para a Consulta de Projetos. ... 72
Figura 18 – Interface para Cadastro de Projetos. ... 73
Figura 19 – Interface para Cálculo e Cadastro de Estimativas. ... 74
Figura 20 – Ator. ... 75
Figura 21 - Modelo de Caso de Uso – Pacote Apoio. ... 76
Figura 22 - Modelo de Caso de Uso – Pacote Análise de Pontos de Função. ... 83
Figura 23 - Diagrama de Robustez do Caso de Uso – Manter Cadastro de Projetos. ... 97
Figura 24 – Diagrama de Robustez do Caso de Uso – Consultar Informações dos Projetos Cadastrados... 97
Figura 25 – Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos (Inclusão). ... 98
Figura 26 – Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos (Alteração). ... 99
Figura 27 – Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos
(Exclusão). ... 100
Figura 28 – Diagrama de Seqüência do Caso de Uso – Consultar Informações dos Projetos Cadastrados... 101
Figura 29 – Diagrama de Classes Persistentes. ... 102
Figura 30 - Ambiente de desenvolvimento do sistema. ... 105
Figura 31 – Tela do Menu Principal. ... 107
Figura 32 – Tela de Consulta de Projetos. ... 108
Figura 33 - Tela de Cadastro de Projetos. ... 109
Figura 34 – Tela de Consulta de Valores Básicos. ... 110
Figura 35 – Tela de Cadastro de Valores Básicos. ... 111
Figura 36 – Tela de Consulta de Funções do Tipo Dados. ... 112
Figura 37 – Tela de Cadastro de Funções do Tipo Dados. ... 113
Figura 38 – Tela de Consulta de Funções do Tipo Transação. ... 114
Figura 39 – Tela de Cadastro de Funções do Tipo Transação. ... 115
Figura 40 – Tela de Consulta de Itens de Influência. ... 115
Figura 41 – Tela de Cadastro de Itens de Influência. ... 116
Figura 42 – Tela de Consulta de Estimativas. ... 117
LISTA DE QUADROS
Quadro 1 – Complexidade funcional de ALI e AIE. ... 50
Quadro 2 – Contribuição dos pontos de função não- ajustados das funções do tipo dados. .... 51
Quadro 3 – Complexidade funcional para entradas externas. ... 53
Quadro 4 – Complexidade funcional para saídas externas e consultas externas. ... 53
Quadro 5 – Contribuição dos pontos de função não-ajustados das funções do tipo transação. 55 Quadro 6 – Descrição dos Requisitos Funcionais. ... 68
Quadro 7 – Descrição do Ator. ... 75
Quadro 8 – Descrição dos Casos de Uso do Pacote Apoio. ... 77
Quadro 9 – Documentação do Caso de Uso – Manter Cadastro de Projetos. ... 79
Quadro 10 – Documentação do Caso de Uso – Consultar Informações dos Projetos Cadastrados... 79
Quadro 11 – Documentação do Caso de Uso – Manter Cadastro de Valores Básicos. ... 82
Quadro 12 – Documentação do Caso de Uso – Consultar Informações dos Valores Básicos Cadastrados... 83
Quadro 13 – Descrição dos Casos de Uso do Pacote Análise de Pontos de Função. ... 84
Quadro 14 – Documentação do Caso de Uso – Manter Cadastro de Funções do Tipo Dados. 86 Quadro 15 – Documentação do Caso de Uso – Consultar Informações das Funções do Tipo Dados Cadastradas. ... 87
Quadro 16 – Documentação do Caso de Uso – Manter Cadastro de Funções do Tipo Transação... 89
Quadro 17 – Documentação do Caso de Uso – Consultar Informações das Funções do Tipo Transação Cadastradas. ... 90
Quadro 18 – Documentação do Caso de Uso – Manter Cadastro de Itens de Influência. ... 92
Quadro 19 – Documentação do Caso de Uso – Consultar Informações dos Itens de Influência Cadastrados... 93
Quadro 20 – Documentação do Caso de Uso – Cálculo do Ponto de Função e Geração de Estimativa. ... 94
Quadro 21 – Documentação do Caso de Uso – Manter Cadastro de Estimativas. ... 95
Quadro 22 – Documentação do Caso de Uso – Consultar Informações das Estimativas Cadastradas. ... 96
1 INTRODUÇÃO ... 15 1.1 PROBLEMA ... 17 1.2 OBJETIVOS... 17 1.2.1 Objetivo Geral ... 18 1.2.2 Objetivos Específicos ... 18 1.3 JUSTIFICATIVA ... 18 1.4 ESTRUTURA DA MONOGRAFIA ... 19 2 ENGENHARIA DE SOFTWARE ... 21
2.1 PROCESSOS DE ENGENHARIA DE SOFTWARE ... 22
2.2 MODELOS DE PROCESSO DE SOFTWARE ... 23
2.3 MODELOS ÁGEIS DE PROCESSO DE SOFTWARE ... 24
2.4 CONSIDERAÇÕES SOBRE OS MODELOS DE PROCESSO DE SOFTWARE ... 25
3 ESTIMATIVAS DE SOFTWARE ... 26
3.1 O PROCESSO DE PLANEJAMENTO DE PROJETO ... 27
3.1.1 Escopo e Viabilidade do Projeto de Software ... 28
3.1.2 Recursos ... 28
3.1.2.1 Recursos Humanos ... 29
3.1.2.2 Recursos de Software Reusáveis ... 30
3.1.2.3 Recursos de Ambiente ... 30
3.1.3 Estimativas do Projeto de Software ... 31
3.1.4 Análise de Riscos ... 34
3.1.5 Cronograma ... 35
3.2 CONSIDERAÇÕES SOBRE AS ESTIMATIVAS DE SOFTWARE ... 36
4 MÉTRICAS DE SOFTWARE ... 38
4.1 MÉTRICAS DE TAMANHO DE SOFTWARE ... 40
4.1.1 Linhas de Código - LOC ... 40
4.1.2 Análise de Pontos de Função - APF ... 41
4.1.3 COCOMO e COCOMO II ... 41
4.1.4 Pontos de Caso de Uso - UCP ... 42
4.2 CONSIDERAÇÕES SOBRE AS MÉTRICAS DE SOFTWARE ... 43
5.1 A IMPORTÂNCIA DOS REQUISITOS NA CONTAGEM DE PONTOS DE FUNÇÃO 45
5.2 CONTAGEM DE PONTOS DE FUNÇÃO ... 46
5.2.1 Determinação do Tipo de Contagem ... 46
5.2.2 Escopo da Contagem e a Fronteira da Aplicação ... 47
5.2.3 Funções do Tipo Dados ... 48
5.2.3.1 Determinando a Complexidade ... 49
5.2.3.2 Contagem de Tipos de Dados ... 50
5.2.3.3 Contagem de Tipos de Registros... 51
5.2.3.4 Determinar a Contribuição... 51
5.2.4 Função do Tipo Transação ... 52
5.2.4.1 Determinando a Complexidade ... 53
5.2.4.2 Contagem para Arquivos Referenciados ... 53
5.2.4.3 Contagem de Tipo de Dados ... 54
5.2.4.4 Determinar a Contribuição... 55
5.2.5 Cálculo dos Pontos de Função Não-Ajustados ... 55
5.2.6 Fator de Ajuste ... 56
5.2.7 Cálculo dos Pontos de Função Ajustados ... 57
5.2.7.1 Projeto de Desenvolvimento ... 58
5.2.7.2 Projeto de Melhoria ... 58
5.2.7.3 Aplicação ... 59
5.3 CONSIDERAÇÕES SOBRE OS PONTOS DE FUNÇÃO ... 60
6 METODOLOGIA ... 61 6.1 METODOLOGIA DE PESQUISA ... 61 6.2 PROPOSTA DE SOLUÇÃO ... 62 6.3 ETAPAS... 63 6.4 DELIMITAÇÕES ... 63 7 MODELAGEM ... 65 7.1 ICONIX ... 65 7.2 REQUISITOS FUNCIONAIS ... 66 7.3 REQUISITOS NÃO-FUNCIONAIS ... 68 7.4 DIAGRAMA DE PACOTES ... 69 7.5 PROJETO DE INTERFACES ... 70
7.5.2 Modelo de Interface para Consulta ... 72
7.5.3 Modelo de Interface para Cadastro ... 73
7.5.4 Modelo de Interface para Cálculo e Cadastro ... 74
7.6 ATORES ... 75
7.7 MODELO DE CASO DE USO ... 75
7.7.1 Casos de Uso do Pacote Apoio ... 76
7.7.2 Casos de Uso do Pacote Análise de Pontos de Função ... 83
7.8 DIAGRAMA DE ROBUSTEZ ... 96
7.8.1 Diagrama de Robustez do Caso de Uso – Manter Cadastro de Projetos ... 97
7.8.2 Diagrama de Robustez do Caso de Uso – Consultar Informações dos Projetos Cadastrados ... 97
7.9 DIAGRAMA DE SEQÜÊNCIA ... 98
7.9.1 Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos (Inclusão) 98 7.9.2 Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos (Alteração) ... 99
7.9.3 Diagrama de Seqüência do Caso de Uso – Manter Cadastro de Projetos (Exclusão) ... 100
7.9.4 Diagrama de Seqüência do Caso de Uso – Consultar Informações dos Projetos Cadastrados ... 101
7.10 DIAGRAMA DE CLASSES ... 102
7.11 CONSIDERAÇÕES FINAIS SOBRE A MODELAGEM ... 103
8 DESENVOLVIMENTO E VALIDAÇÃO... 104
8.1 AMBIENTE DE DESENVOLVIMENTO ... 104
8.1.1 Java ... 105
8.1.2 MySQL ... 106
8.2 APRESENTAÇÃO DO SISTEMA ... 107
8.2.1 Tela do Menu Principal ... 107
8.2.2 Tela de Consulta de Projetos ... 108
8.2.3 Tela de Cadastro de Projetos ... 108
8.2.4 Tela de Consulta de Valores Básicos ... 109
8.2.5 Tela de Cadastro de Valores Básicos ... 110
8.2.6 Tela de Consulta de Funções do Tipo Dados ... 111
8.2.8 Tela de Consulta de Funções do Tipo Transação ... 113
8.2.9 Tela de Cadastro de Funções do Tipo Transação ... 114
8.2.10 Tela de Consulta de Itens de Influência ... 115
8.2.11 Tela de Cadastro de Itens de Influência ... 116
8.2.12 Tela de Consulta de Estimativas ... 116
8.2.13 Tela de Cadastro de Estimativas e Cálculo do Ponto de Função ... 117
8.3 PROBLEMAS ENCONTRADOS NO DESENVOLVIMENTO ... 118
8.4 VALIDAÇÃO ... 119
8.5 CONSIDERAÇÕES FINAIS SOBRE O DESENVOLVIMENTO ... 120
9 CONCLUSÕES E TRABALHOS FUTUROS ... 121
1 INTRODUÇÃO
Nas últimas décadas, os sistemas baseados em computador tem tido uma grande importância para as pessoas, empresas e outras instituições, que passaram a utilizá-los para apoiar e automatizar as suas atividades através do processamento de informações.
Nos primórdios da era do computador, os sistemas baseados em computador eram desenvolvidos com o foco do projeto quase todo no hardware, porque este era o item de maior custo no orçamento do sistema. O software, por outro lado, era projetado sob medida para cada aplicação e tinha uma distribuição relativamente limitada.
Com o passar dos anos, o hardware diminuiu de tamanho, aumentou o seu desempenho e, conseqüentemente, baixou o seu custo. Isto propiciou o aparecimento de sistemas baseados em computador mais sofisticados e que exigiam softwares mais complexos e diferenciados. O software passou, então, a ser o item de maior custo no orçamento dos sistemas e que requer maiores cuidados no seu processo de desenvolvimento.
O fato de o software ter se tornado maior e mais complexo fez surgir um conjunto de problemas ligados ao seu desenvolvimento. Dentre esses problemas, podemos destacar a imprecisão nas estimativas de prazo, custos excessivos, má qualidade no produto de software e, conseqüentemente, a insatisfação do cliente.
Diante de todos os problemas ligados ao desenvolvimento de software, os profissionais da área de software passaram a adotar os princípios da engenharia de software no desenvolvimento dos seus sistemas.
A engenharia de software estabelece o uso de sólidos princípios de engenharia que auxiliam no controle do processo de desenvolvimento de software e oferecem aos profissionais uma base para a construção de softwares confiáveis, com alta qualidade e que atendam aos requisitos do cliente. (BAUER, 1969 apud PRESSMAN, 2006 p. 17). Ela oferece um conjunto de métodos que permitem planejar e gerenciar todo o processo de desenvolvimento de software.
Segundo Pressman (2006, p. 18):
Os métodos de engenharia de software fornecem a técnica de “como fazer” para construir softwares. Eles abrangem um amplo conjunto de tarefas que incluem comunicação, análise de requisitos, modelagem de projeto, construção de programas, testes e manutenção. Os métodos de engenharia de software repousam num conjunto de princípios básicos que regem cada área da tecnologia e incluem atividades de modelagem e outras técnicas descritas.
De acordo com Pressman (2006), um projeto de software tem início a partir de um conjunto de atividades chamadas de planejamento do projeto. Quando um projeto de software é planejado, são realizadas várias estimativas de esforço, custo e prazo que serão necessárias para a condução do restante do projeto. Essas estimativas são feitas no início do projeto de software e acabam sendo atualizadas à medida que o projeto progride.
O autor explica que as estimativas utilizam medidas diretas e indiretas para auxiliar os profissionais a entender melhor o processo de engenharia de software. As medidas diretas incluem as linhas de código produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de tempo. As medidas indiretas incluem funcionalidades, qualidade, complexidade, eficiência e confiabilidade.
Determinar o tamanho do projeto de software é uma das primeiras estimativas a ser realizada, pois a partir desta medida é que são estimados o esforço, custo e prazo para o projeto. (GARMUS; HERRON, 2000 e LONGSTREET, 2002 apud FREIRE, 2008, p. 1).
Várias técnicas para estimar o tamanho dos projetos de software estão disponíveis na engenharia de software. Cada uma delas com as suas potencialidades e fragilidades.
Dentre as técnicas de estimativa disponíveis, encontra-se a técnica de Análise de Pontos de Função (APF).
Segundo Pressman (2006), a técnica de pontos de função realiza uma medida indireta do software, concentrando-se na sua funcionalidade. Estes pontos são derivados a partir de medidas estimadas de domínio da informação como número de entradas, saídas, arquivos de dados, consultas e interfaces externas, bem como valores de complexidade que são atribuídos a cada uma destas medidas.
Assim que forem calculados, os pontos de função serão usados para estimar o esforço, o custo e o prazo do projeto de software.
Peters e Pedrycz (2001) afirmam que com o aumento do tamanho dos projetos de software, qualquer erro de estimativa pode trazer grandes prejuízos ao projeto. A falta ou o excesso de recursos devido a estimativas erradas pode significar verdadeiras perdas em termos de tempo e de orçamento para as empresas que desenvolvem software.
Uma vez que os resultados das estimativas na etapa de planejamento têm grandes implicações no decorrer do projeto de software, a capacidade de realizá-las de modo adequado acaba sendo de grande importância no processo de engenharia de software.
1.1 PROBLEMA
As empresas que desenvolvem software e que não realizam estimativas em seus projetos ou realizam de forma incorreta podem apresentar grandes problemas.
A ausência de estimativas de esforço e prazo nos projetos de software, por exemplo, pode fazer com que a equipe fique sobrecarregada de trabalho e não consiga concluir o projeto na data prevista. Isto, além de manchar a imagem da organização, pode causar desmotivação na equipe.
Projetos realizados com custos excessivos devido a estimativas incorretas, também, podem trazer grades prejuízos financeiros, tanto para as empresas quanto para os clientes. Esses prejuízos, muitas vezes, chegam até a causar o cancelamento do projeto.
Uma pesquisa realizada pelo The Standish Group (2009) mostra que, apenas, 32% dos projetos de software são bem sucedidos, ou seja, são entregues no prazo estimado, dentro do orçamento e com as funções exigidas pelo cliente. Dos demais, 44% são finalizados com prazos e custos acima do estimado e 24% nem chegam a ser concluídos.
Diante da importância das estimativas nos projetos de software, o estudo de técnicas de estimativa que determinam o tamanho de um projeto de software e, a partir desta medida, definem o esforço, custo e prazo do projeto passa a ser um aspecto importante na formação de futuros profissionais da área de engenharia de software.
Como a técnica de Análise de Pontos de Função (APF) é, segundo Ramil e Lehman (2000 apud FREIRE, 2008, p. 1), uma das mais conhecidas e utilizadas para a realização de estimativas de tamanho em projetos de software, a carência de ferramentas gratuitas que possibilitem o cálculo dos pontos de função e que possam ser utilizadas, tanto por empresas como pelo meio acadêmico para estudos, também é um aspecto a ser considerado.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo deste projeto é desenvolver uma ferramenta que gerencie as estimativas de um projeto de software com base na técnica de Análise de Pontos de Função (APF).
1.2.2 Objetivos Específicos
O projeto possui os seguintes objetivos específicos:
Estudar e compreender a técnica de Análise de Pontos de Função (APF). Desenvolver uma ferramenta que determine o tamanho de um projeto de
software a partir do cálculo do número de pontos de função e, com isso, possa gerar estimativas de custo e prazo.
Apoiar, por meio de uma ferramenta, o processo decisório de alocação de recursos no desenvolvimento de software.
Possibilitar o uso acadêmico de uma ferramenta de estimativa de software que utilize a técnica de Análise de Pontos de Função.
Desenvolver uma ferramenta de estimativa no padrão open source, ou seja, com o código aberto.
1.3 JUSTIFICATIVA
A criação de uma ferramenta de estimativa permitirá uma gerência mais eficiente dos projetos de software através da realização do cálculo do tamanho do projeto de software. Esta medida servirá como base para a definição das estimativas de custo e prazo,
possibilitando um controle melhor dos riscos do projeto e a elaboração de cronogramas mais adequados à realidade da equipe de software.
A ferramenta também irá possibilitar que futuros profissionais da área de engenharia de software tenham contato com uma ferramenta que realize estimativas de software, utilizando a técnica de Análise de Pontos de Função (APF).
O fato de a ferramenta ser desenvolvida no padrão open source possibilitará que sejam feitas adaptações e melhorias na sua funcionalidade.
1.4 ESTRUTURA DA MONOGRAFIA
Este projeto está dividido em nove capítulos. A seguir será apresentada a estrutura do trabalho:
Capítulo 1 – Introdução: Este capítulo apresenta a introdução, problema, objetivos e justificativa do trabalho.
Capítulo 2 – Revisão Bibliográfica: Este capítulo apresenta aspectos relacionados à Engenharia de Software.
Capítulo 3 – Revisão Bibliográfica: Este capítulo apresenta aspectos relacionados à Estimativa de Software.
Capítulo 4 – Revisão Bibliográfica: Este capítulo apresenta aspectos relacionados às Métricas de Software.
Capítulo 5 – Revisão Bibliográfica: Este capítulo apresenta aspectos relacionados ao Ponto de Função.
Capítulo 6 – Metodologia: Este capítulo apresenta a metodologia de pesquisa, proposta da solução, etapas e delimitações do projeto.
Capítulo 7 – Modelagem: Este capítulo apresenta a metodologia utilizada para modelar o sistema proposto, bem como os diagramas necessários para a compreensão do mesmo.
Capítulo 8 – Desenvolvimento e Validação: Este capítulo apresenta as ferramentas e tecnologias utilizadas no desenvolvimento do sistema proposto, bem como a sua apresentação e validação.
Capítulo 9 – Conclusões e Trabalhos Futuros: Este capítulo apresenta as conclusões deste trabalho e sugestões para trabalhos futuros.
2 ENGENHARIA DE SOFTWARE
Segundo Sommerville (2003), a engenharia de software se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de sua especificação, passando pelo seu desenvolvimento, gerenciamento até a sua manutenção. Ela abrange todas as atividades envolvidas no projeto de software apresentado métodos eficazes para o seu desenvolvimento, com o objetivo de facilitar a produção em alta qualidade e com uma boa relação custo-benefício.
Para Peters e Pedrycz (2001), a engenharia de software é uma abordagem de engenharia necessária para evitar o caos no desenvolvimento de software, pois ela tem a característica de ser uma abordagem prática, ordenada e medida.
Os autores explicam que a engenharia de software é uma abordagem prática por utilizar métodos comprovados no seu desenvolvimento. É organizada por definir uma seqüência para as suas atividades durante o projeto. Finalmente, esta abordagem é medida através de métricas de software aplicadas aos produtos produzidos. O objetivo desta medida é estimar a qualidade, os custos e a confiabilidade dos produtos de software.
De acordo com Pressman (2006), a engenharia de software é composta por um conjunto de quatro camadas fundamentais que incluem os métodos, ferramentas, processos e a qualidade no desenvolvimento de software. Nos parágrafos seguintes, o autor dá uma breve explicação de cada uma destas camadas.
Os métodos de engenharia de software proporcionam os detalhes da construção do software e baseiam-se na idéia de desenvolver modelos gráficos para representar todos os processos envolvidos no projeto. Estes métodos envolvem tarefas como: planejamento, análise de requisitos, arquitetura, codificação, testes e manutenção.
As ferramentas de engenharia de software possibilitam que os métodos sejam automatizados. Elas podem ser integradas de modo que a informação criada por uma possa ser usada por outra.
Os processos de engenharia de software estabelecem o contexto em que os métodos serão aplicados no desenvolvimento de software. Os processos estabelecem os documentos que devem ser gerados e os controles que ajudam a assegurar a qualidade do produto de software.
A qualidade na engenharia de software leva a um processo contínuo de aperfeiçoamento, permitindo o desenvolvimento de abordagens cada vez mais efetivas para a construção de softwares.
2.1 PROCESSOS DE ENGENHARIA DE SOFTWARE
Segundo Pressman (2006), os processos de engenharia de software definem as atividades que serão realizadas para a construção do software com qualidade. Eles estabelecem a base para o controle gerencial de projetos de software e criam o contexto no qual os métodos e as ferramentas serão aplicados.
Sommerville (2003) explica que diferentes processos de software organizam as suas atividades de maneiras diversas e são descritos em diferentes níveis de detalhes. O tempo de duração das atividades varia do mesmo modo que os resultados de cada uma delas.
Pressman (2006) descreve o seguinte conjunto atividades que são comuns a todos os processos de software:
Comunicação: Esta atividade envolve a comunicação com o cliente e abrange o levantamento de requisitos e outras atividades relacionadas. Planejamento: É a atividade que descreve o plano de trabalho que será
realizado. Nessa descrição estão incluídas as tarefas técnicas a serem conduzidas, os riscos prováveis, além dos recursos necessários, custos do projeto e um cronograma de trabalho, definidos a partir da realização de estimativas.
Modelagem: Esta atividade inclui a criação de modelos que irão ajudar ao desenvolvedor entender melhor os requisitos do software e o projeto que irá satisfazer estes requisitos.
Construção: Esta atividade envolve a geração de código e os testes que deverão ser realizados para a verificação de erros.
Implantação: O software é entregue ao cliente, que avalia o produto e sugere modificações.
Pressman (2006) garante que estas cinco atividades genéricas podem ser usadas, tanto para o desenvolvimento de pequenos programas, como para criação de grandes
aplicações de engenharia de software. O autor afirma que os detalhes do processo de software são muito diferentes em cada caso, mas as atividades continuam sendo as mesmas.
2.2 MODELOS DE PROCESSO DE SOFTWARE
De acordo com Pressman (2006), nos últimos anos, os modelos de processo que enfatizam a definição, identificação e aplicação detalhada das atividades do processo de software, têm sido aplicados pelos profissionais da engenharia de software no desenvolvimento dos seus projetos.
“Um modelo de processo de software é uma descrição simplificada de um processo de software, que é apresentada a partir de uma perspectiva específica.” (SOMMERVILLE, 2003, p. 8).
Pressman (2006) explica que o objetivo dos modelos de processo de software é tornar os projetos mais gerenciáveis, os prazos e os custos mais previsíveis, além de guiar os engenheiros de software à medida que eles trabalham na construção do sistema. O autor também menciona o fato de que cada modelo de processo define um fluxo de trabalho de maneira diferente, isto é, as maneiras de como os elementos do processo se relacionam uns com os outros.
A engenharia de software propõe uma série de modelos de processos, também chamados de paradigmas de processo, sendo que alguns deles serão descritos a seguir:
Modelo em cascata: O modelo em cascata, também chamado de ciclo de vida clássico, requer uma abordagem sistemática e seqüencial para o desenvolvimento de software. Ele tem início com a atividade de especificação de requisitos, progredindo para o planejamento, modelagem, construção, implantação e manutenção. (PRESSMAN, 2006). Prototipação: A prototipação utiliza uma abordagem evolucionária, cujo objetivo é
compreender os requisitos do cliente e, com isso, desenvolver uma melhor definição dos requisitos do sistema. A prototipação está concentrada no desenvolvimento de experimentos de partes dos requisitos que não estejam bem compreendidos. (SOMMERVILLE, 2003).
Modelo espiral: O modelo espiral combina as melhores características, tanto do modelo cascata quanto da prototipação, com o intuito de tornar o desenvolvimento das versões de
software cada vez mais completas. O modelo é dividido em um conjunto de atividades que representam um segmento do caminho da espiral, e cada circuito em torno da espiral representa uma versão do sistema. (PRESSMAN, 2006).
RUP: O RUP (Rational Unified Process) é um processo de engenharia de software desenvolvido pela Rational Software Corporation que abrange todo o ciclo de desenvolvimento de software e fornece uma maneira disciplinada de atribuir tarefas e responsabilidades dentro de um ambiente de desenvolvimento de software. O processo do RUP é composto pelas fases de concepção, elaboração, construção e transição. Essas fases possuem objetivos específicos e fluxos de atividades que ocorrem dentro delas representados pelo diagrama UML (Unified Modeling Language). (DIDIER, 2003).
2.3 MODELOS ÁGEIS DE PROCESSO DE SOFTWARE
Segundo Pressman (2006), o ambiente moderno de negócios muda com tanta freqüência que não permite prever como um sistema baseado em computador irá evoluir com o passar do tempo. Existem casos em que não é mais possível definir todos os requisitos de um sistema antes do início do projeto. Os engenheiros de software precisam ser ágeis para lidar com um ambiente de negócios tão incerto e mutável.
O autor explica que, se os modelos de processos forem seguidos à risca e sem nenhuma adaptação pelos engenheiros de software, eles poderão aumentar o nível de burocracia para a construção dos sistemas e, conseqüentemente, criarem dificuldades para todos os envolvidos no projeto.
O autor comenta que, nos últimos anos, foram propostos modelos de processos que dão ênfase à agilidade do projeto e seguem uma série de princípios que levam a uma abordagem mais informal do processo de software. Esses modelos que, segundo o autor, enfatizam a agilidade e a adaptabilidade, são chamados de modelos ágeis de processos de software.
A seguir serão descritos alguns desses modelos ágeis de processos de software: XP: O XP (Extreme Programming) utiliza uma abordagem orientada a objetos como seu
paradigma de desenvolvimento. O modelo propõe a criação de um conjunto de histórias descritas pelo cliente, em que estarão as características e funcionalidades requeridas para o
software que será construído. Estas histórias serão aplicadas dentro do contexto das quatro atividades-chave que fazem parte do modelo: planejamento, projeto, codificação e testes. (PRESSMAN, 2006).
Scrum: O Scrum caracteriza-se por ser um modelo que favorece a auto-organização e a adaptação. As principais fases do Scrum, planejamento, sprint, e avaliação, correspondem, respectivamente, aos três estados evolutivos do modelo. O sprint é a fase de implementação do sistema que acontece com mudanças no próximo planejamento, com base nas conclusões da última avaliação. (BASSI FILHO, 2008).
ICONIX: O ICONIX pode ser entendido como com processo de desenvolvimento de software prático, localizado entre a complexidade do RUP e a simplicidade do XP e que trabalha a partir de protótipos de interface para identificação dos casos de uso. (SILVA, 2009) A abordagem ICONIX permite que sejam utilizados recursos da UML para completar os recursos usados nas fases do ICONIX, caso seja necessário. (SILVA et al., 2007). O ICONIX está divido em modelo estático e modelo dinâmico. Estes modelos possuem os seus próprios diagramas e podem ser desenvolvidos paralelamente. (MAIA, 2005 apud SILVA et al., 2007).
2.4 CONSIDERAÇÕES SOBRE OS MODELOS DE PROCESSO DE SOFTWARE
Sommerville (2003) explica que diferentes empresas fazem uso de diferentes modelos de processo para produzir o mesmo produto de software. No entanto, alguns modelos de processos são mais adequados a determinados tipos de aplicação do que outros.
Segundo Pressman (2006), os engenheiros de software costumam adaptar os modelos de processo às necessidades específicas do projeto que irão desenvolver. O autor explica que todos os modelos de processo acomodam as atividades genéricas de comunicação, planejamento, modelagem, construção e implantação, mas cada um deles aplica uma ênfase diferente a essas atividades.
Todos os modelos de processos apresentados anteriormente, tanto os modelos clássicos como os modelos ágeis, fazem uso das estimativas de software durante a sua atividade de planejamento para estimar o trabalho a ser feito, os recursos necessários e o tempo que vai decorrer do início ao fim do projeto.
3 ESTIMATIVAS DE SOFTWARE
Segundo Pressman (2006), um projeto de software tem início a partir de um conjunto de atividades chamadas de planejamento do projeto. Durante o planejamento, o gerente e a equipe de software estimam o trabalho a ser feito, os recursos necessários e o tempo que será gasto do início ao fim do projeto. Após a realização destas atividades, a equipe irá elaborar um cronograma que irá conter todas as tarefas do projeto, juntamente com as suas dependências e respectivos responsáveis.
Freire (2008) explica que a engenharia de software recomenda a realização de atividades de estimativa de tamanho, esforço, prazo e custo com o objetivo de melhorar o planejamento e o acompanhamento de projetos de software.
A capacidade de estimar com precisão pode ser a diferença entre o sucesso ou o fracasso em um projeto de desenvolvimento de software. (POTOK; VOUK, 1999 apud FREIRE, 2008, p. 27).
Peters e Pedrycz (2001) alertam para o fato de quanto maior o tamanho dos projetos, maiores são as probabilidades de erro nas estimativas, assim como os prejuízos advindos de alocação equivocada de recursos.
Segundo os autores, as estimativas de software convivem com um alto grau de incerteza, sendo que ela tende a diminuir ao longo do tempo, graças ao maior conhecimento adquirido pela equipe de software sobre os detalhes do projeto.
Figura 1 – Redução da incerteza durante o curso do projeto de software. Fonte: Peters e Pedrycz (2001, p. 480).
As estimativas de software exigem, segundo Pressman (2006), experiência, informações de projetos desenvolvidos anteriormente e a consciência de que o projeto será desenvolvido sob forte ameaça de riscos.
O autor explica que se o escopo do projeto é entendido de forma incorreta ou o cliente exige muitas mudanças nos requisitos, os riscos nas estimativas de software aumentam significativamente.
Para diminuir os riscos nas estimativas de software, o autor enumera uma série de passos sistemáticos:
É recomendável que a estimativa seja feita com o projeto num estágio mais avançado de desenvolvimento – esse passo é difícil de ser realizado, uma vez que, geralmente, não se dispõe de tempo para isso;
É importante tomar como base projetos semelhantes que já foram concluídos pela equipe de software.
Recorrer a técnicas de decomposição simples e fáceis de serem aplicadas. Utilizar modelos de estimativas baseados em fórmulas derivadas
empiricamente, ou seja, que utilizam dados de experiências de projetos anteriores.
Apesar das estimativas de software apresentarem incertezas e riscos, Pressman (2006) explica que elas fornecem a base para as demais atividades do planejamento do projeto e são responsáveis por uma engenharia de software bem-sucedida. Com isso, seria temerário começar um projeto sem elas.
3.1 O PROCESSO DE PLANEJAMENTO DE PROJETO
De acordo com Sommerville (2003), o planejamento do projeto tem início com a elaboração de um documento chamado de plano de projeto. Este documento deve conter as estrutura e o custo do projeto, os recursos disponíveis e um cronograma para a execução do trabalho. Nele, também, estarão contidos os eventuais problemas e restrições do projeto, assim como as possíveis soluções.
O autor explica que o plano de projeto deve ser revisado e melhorado à medida que o projeto é desenvolvido e melhores informações se tornem disponíveis.
A seguir, serão apresentadas as atividades que fazem parte do plano de projeto de software e que estão relacionadas com as estimativas.
3.1.1 Escopo e Viabilidade do Projeto de Software
Segundo Pressman (2006), o escopo do software descreve as principais funções e características do software que serão entregues ao cliente. Nele estão descritos os dados que entram e que saem, as interfaces com o usuário, as características de desempenho e as restrições que limitam o sistema. Essas informações são adquiridas por meio da comunicação com o cliente.
Putnam e Myers (1997 apud PRESSMAN, 2006, p. 522) explicam que após o estabelecimento do escopo, o gerente de projeto deve analisar a viabilidade do trabalho a ser desenvolvido. Esta atividade é realizada em conjunto com o processo de estimativa e tem como objetivo verificar a existência dos recursos necessários para o desenvolvimento do projeto, a possibilidade da empresa que irá desenvolver o software e do seu cliente terem condições financeiras para costear o projeto e a disponibilidade de tempo para concluir o projeto na data estipulada pelo cliente.
3.1.2 Recursos
De acordo com Pressman (2006), a segunda tarefa do planejamento de projeto é estimar os recursos necessários para o desenvolvimento de software.
O autor explica que os recursos de engenharia de software estão divididos em três principais categorias: pessoas, componentes de software reusável e o ambiente de desenvolvimento. Estes recursos são especificados segundo quatro características: descrição, disponibilidade, data de uso do recurso e prazo da alocação.
Figura 2 – Recursos de projeto. Fonte: Pressman (2006, p. 522).
3.1.2.1 Recursos Humanos
É impossível pensar em projeto de software sem que pessoas qualificadas estejam envolvidas. As pessoas são recursos indispensáveis no processo de desenvolvimento de software.
Elas podem ocupar diversos postos no ambiente de desenvolvimento, desde gerentes, engenheiros de software até administradores de banco de dados e programadores.
São efetuadas, segundo Pressman (2006), estimativas de esforço de desenvolvimento para que seja definida a quantidade de profissionais necessários para a execução de um projeto de software.
3.1.2.2 Recursos de Software Reusáveis
Bennatan (1992 apud PRESSMAN, 2006, p. 523) sugere quatro categorias de recursos de software que podem ser reutilizados à medida que o planejamento avança:
Componentes de prateleira: Software existente que pode ter sido adquirido por terceiros ou desenvolvido dentro da própria empresa em projetos anteriores.
Componentes de experiência plena: Projetos, especificações, códigos ou dados de testes já existentes, que foram desenvolvidos em projetos anteriores e que se assemelham ao projeto atual. Os membros da equipe de software possuem bastante experiência na aplicação desses componentes, e qualquer eventual modificação apresentará um baixo risco para o projeto. Componentes de experiência parcial: Projetos, especificações, códigos ou
dados de testes já existentes, que foram desenvolvidos em projetos anteriores e que se assemelham ao projeto atual, mas que exigem cautela em suas modificações. Os membros da equipe de software possuem experiência limitada na aplicação desses componentes, e qualquer eventual modificação apresentará um grau de risco considerável para o projeto. Componentes novos: Componentes especialmente construídos para o
projeto atual.
3.1.2.3 Recursos de Ambiente
O ambiente que apóia processo de engenharia de software é composto por todos os componentes de hardware e software utilizados no desenvolvimento dos projetos.
Pressman (2006) explica que o hardware fornece a plataforma que apóia ferramentas (software) necessárias para a realização das tarefas do projeto. Para realizar determinada tarefa, o projeto pode necessitar de máquinas diferentes, com diferentes configurações. Cada elemento de hardware deve ser especificado pelo planejador do projeto de software.
Igualmente ao hardware, os softwares também são utilizados como recurso para o desenvolvimento de outros softwares. Sommerville (2003) cita as ferramentas CASE (Computer-Aided Software Engineering) como exemplos de programas usados para dar apoio às atividades do projeto de software. Elas auxiliam na análise de requisitos, modelagem do sistema, geração de código, depuração e testes.
3.1.3 Estimativas do Projeto de Software
O processo de estimativas tem início com a determinação do tamanho do projeto de software. A partir do tamanho é possível determinar o esforço para construí-lo. Desse esforço, pode-se obter o cronograma e os custos do projeto. (VALENÇA, 2007).
Determinar o tamanho do software significa quantificar o trabalho a ser executado no desenvolvimento de um projeto usando uma determinada unidade de medida. Cada projeto pode ser estimado a partir do seu tamanho físico levando em conta, por exemplo, a especificação dos requisitos e a quantidade de linhas de código. Um projeto de software, também, pode ser estimado com base nas funcionalidades que o usuário obtém e na complexidade do problema que este software irá resolver. (FENTON; PFLEEGER, 1997; MCPHEE, 1999 apud FREIRE, 2008, p. 35).
Pressman (2006) afirma que a estimativa de um projeto de software será boa na mesma medida em que a sua estimativa de tamanho for bem realizada.
O cálculo do esforço para um projeto de software pode ser obtido a partir da estimativa de tamanho. O esforço pode ser entendido como a quantidade de trabalho necessária para completar uma atividade do projeto, sendo normalmente expresso em horas por pessoa. (PMBOK, 2004 apud FREIRE, 2008, p. 35).
O esforço de desenvolvimento de um projeto de software demanda um determinado prazo de execução que depende da quantidade de recursos alocados. A estimativa de prazo pode ser dada pela razão entre o esforço previsto e a quantidade de recursos alocados para o projeto. (FREIRE, 2008).
Segundo Sommerville (2003), o cálculo do custo total do projeto de software envolve os custos com hardware e software, custos com possíveis viagens e treinamentos e custos relativos ao esforço, ou seja, o pagamento da equipe do projeto.
Figura 3 – Derivando Esforço, Cronograma e Custo. Fonte: Valença (2007, p. 11).
Valença (2007) explica que para a realização de um processo adequado de estimativa devem ser levados em consideração as informações do escopo do projeto, prioridades, restrições e dados históricos de projetos anteriores.
O autor, também, afirma que a qualidade da estimativa depende de uma boa especificação dos requisitos iniciais do projeto. Ter habilidade para controlar as mudanças que ocorrem nestes requisitos ao longo da execução do projeto contribui muito para a obtenção de estimativas mais precisas.
Durante o ciclo de vida do software, as estimativas devem ser refeitas, pois, à medida que são obtidas mais informações sobre projeto, as estimativas tendem a melhorar. (PFLEEGER, 2007 apud FREIRE, 2008, p. 33).
Figura 4 – Processo de Estimativas. Fonte: Valença (2007, p. 10).
O processo de estimativa deve ser apoiado por uma técnica de estimativa. Esta técnica ou método de estimativa não constitui uma verdade absoluta, mas, sim, uma aproximação desta verdade em um determinado momento. Os métodos de estimativa devem ser revistos e calibrados com base no histórico das estimativas anteriores. (VALENÇA, 2007).
A seguir, serão descritas as técnicas de estimativas mais comuns.
Modelos paramétricos: Os modelos paramétricos assumem que existe um relacionamento matemático entre tamanho, esforço e cronograma e que estes relacionamentos são afetados por parâmetros mensuráveis. Estes modelos utilizam informações históricas de projetos anteriores para calcular as estimativas e usam o tamanho do software como base para estes cálculos. (MCGARRY et al., 2002 apud FREIRE, 2008, p. 29).
Analogia: A analogia tem como base a comparação entre projetos similares. Ela requer bastante conhecimento de ambos os projetos para que possam ser identificadas as principais diferenças e semelhanças. Essa técnica normalmente é realizada por um especialista com a ajuda de algoritmos de busca de projetos similares. (JORGENSEN; INDAHL; SJOBERG, 2003 apud FREIRE, 2008, p. 29).
Julgamento de especialistas: Essa técnica tem como base as experiências profissionais de especialistas que já trabalharam em projetos similares. Ela é muito útil na ausência de dados quantitativos. (FREIRE, 2008).
Modelo baseado em atividades: Essa técnica consiste em estimar tamanho, esforço, custo e prazo para atividades individuais. O valor global da estimativa é obtido através da soma das estimativas das atividades individuais. (MCGARRY et al., 2002 apud FREIRE, 2008, p. 29).
Relações simples de estimativas: Utilizam os modelos paramétricos de forma simplificada. Esses modelos têm como base os dados históricos de projetos anteriores e equações aritméticas simples, ao invés de modelos matemáticos complexos. (MCGARRY
et al., 2002 apud FREIRE, 2008, p. 29).
Sommerville (2003), ainda, descreve duas abordagens de estimativas que também podem ser usadas: top-down e botton-up.
Top-down: A abordagem top-down tem início a partir da análise do sistema como um todo. O responsável pela estimativa inicia a sua atividade examinando a funcionalidade geral do sistema. A partir dessa funcionalidade, ele calcula a estimativa das demais atividades e fases do projeto. Os custos com integração, gerenciamento de configurações e documentação também são levados em conta.
Botton-up: A abordagem botton-up tem início a partir da análise dos componentes. O sistema é decomposto em componentes menores, e é
calculada a estimativa para cada um deles. A estimativa total é calculada com base na soma das estimativas de todos os componentes.
Sommerville (2003) explica que cada técnica de estimativa tem os seus pontos fortes e fracos e que, em grandes projetos, é necessário utilizar várias técnicas para combinar os seus resultados. Caso os resultados sejam muitos diferentes, isso significa que as informações são insuficientes para se fazer a estimativa. É necessário obter mais informações e refazer as estimativas até que os resultados se igualem.
O autor também explica que é difícil produzir uma estimativa exata no estágio inicial do projeto. Isso ocorre, principalmente, pelo fato de que todos os requisitos do projeto ainda não são conhecidos. À medida que o projeto evolui e mais informações a seu respeito são obtidas, as estimativas também tendem a melhorar.
3.1.4 Análise de Riscos
De acordo com Sommerville (2003), prever os riscos que podem afetar um projeto ou a qualidade do software em desenvolvimento e tomar as medidas necessárias para evitá-los é uma tarefa importante do gerente de projeto.
O autor explica que os riscos podem ser entendidos como a probabilidade de que alguma circunstância adversa possa ocorrer ao longo do projeto.
Pressman (2006) enumera as seguintes categorias de riscos que podem afetar um projeto de software:
Riscos de projeto: Os riscos de projeto ameaçam o plano de projeto e compreendem os problemas potenciais orçamentários, de cronograma, de pessoal, de recursos e de requisitos.
Riscos técnicos: Os riscos técnicos ameaçam tanto a qualidade como a pontualidade do software e compreendem os problemas potenciais de projeto, implementação, interface e manutenção.
Riscos do negócio: Os riscos do negócio ameaçam a viabilidade do projeto de software e compreendem os potenciais problemas de construir um software que ninguém irá usar, construir um software que não serve para a
empresa ou que a equipe de vendas não sabe como vender ou então construir um software acima do orçamento previsto.
Segundo Sommerville (2003), o gerente de projeto é responsável por estimar os riscos do projeto, analisar o impacto desses riscos e tomar providências para evitá-los.
O autor descreve os seguintes passos para o gerenciamento de ricos em um projeto de software que pode ser feito com o auxílio das estimativas:
Identificação de riscos: Essa etapa procura descobrir os possíveis riscos do projeto.
Análise de riscos: Cada risco identificado é avaliado e julgado quanto a sua probabilidade e seriedade dentro do projeto.
Planejamento de riscos: Nessa etapa são definidas as estratégias para gerenciar os riscos considerados mais importantes.
Monitoramento de riscos: Monitorar os riscos significa avaliar constantemente cada risco identificado e verificar a possibilidade deles acontecerem futuramente ou não.
Sommerville (2003) explica que o gerenciamento de riscos é um processo que continua ao longo de todo o projeto. À medida que mais informações sobre os riscos do projeto se tornam disponíveis, eles têm que se reavaliados e novos planos de contingência devem ser elaborados.
3.1.5 Cronograma
Segundo Pressman (2006), a cronogramação de projeto de software é uma atividade que envolve a distribuição do esforço estimado pela duração planejada do projeto. Este esforço é divido em atividades ou tarefas específicas de engenharia de software juntamente com as suas interdependências.
O autor explica que o cronograma auxilia o gerente de projeto a identificar as tarefas críticas, a distribuir adequadamente as tarefas entre os membros da equipe e a monitorar o progresso do projeto controlando os seus atrasos.
Pressman (2006) apresenta alguns princípios básicos que orientam a cronogramação de projetos de software:
Compartimentalização: O projeto é decomposto em certo número de atividades ou tarefas gerenciáveis.
Interdependência: Devem ser criadas interdependências entre as tarefas que possuem esta necessidade.
Atribuição de tempo: Para cada tarefa deve se estabelecer a data inicial e a data de término.
Validação do esforço: Validar no cronograma a existência de todas as pessoas capacitadas necessárias para executar uma determinada tarefa. Responsabilidades definidas: Para cada tarefa do cronograma deve existir
um membro da equipe de software como responsável.
Resultados definidos: Para cada tarefa do cronograma deve haver um resultado que pode ser um módulo do projeto, por exemplo.
Marcos de referência definidos: O cronograma deve possuir marcos de referência, que seriam, por exemplo, as datas de entrega de cada módulo do sistema devidamente testados e aprovados.
Pressman (2006) explica que a cronogramação, assim como as demais atividades do plano de projeto, também evolui com o tempo. No início do planejamento, um cronograma é desenvolvido, contendo as principais atividades do projeto. À medida que o projeto avança, novas atividades são identificadas e passam a fazer parte do cronograma.
3.2 CONSIDERAÇÕES SOBRE AS ESTIMATIVAS DE SOFTWARE
As estimativas de software são tarefas extremamente importantes em qualquer projeto de software, pois são elas que irão determinar como o projeto será conduzido. Elas estão presentes na etapa de planejamento, compondo uma das atividades do plano de projeto e podendo também estar presentes em outras etapas do projeto.
De acordo com Pressman (2006), as estimativas de software não precisam ser conduzidas de modo aleatório, pois já existem técnicas úteis de estimativa que podem auxiliar os gerentes de projeto durante o processo de realização de estimativas de esforço, tempo e custo. Métricas de software contendo dados históricos de projetos anteriores também são
usadas, junto com as técnicas, para oferecer medidas quantitativas ao processo de estimativa de software.
O autor explica que, quando métricas de software abrangentes estão disponíveis para o projeto, as estimativas podem ser realizadas com maior segurança e com menor possibilidade de ocorrência de riscos.
No capítulo seguinte, serão apresentadas algumas das principais métricas utilizadas no processo de estimativa de projetos de software.
4 MÉTRICAS DE SOFTWARE
Segundo Pressman (2006), a medição pode ser aplicada ao processo, ao projeto e ao produto de software como sendo um mecanismo de avaliação objetiva. Ela pode estar presente no processo de software com o objetivo de melhorá-lo de forma contínua. Pode ser usada ao longo de um projeto de software para dar auxílio as estimativas e ao controle de qualidade, produtividade e do próprio projeto. E, finalmente, a medição pode ser aplicada na avaliação da qualidade dos produtos de software.
O autor explica que a medida de software é utilizada na engenharia de software para fornecer uma indicação quantitativa de dimensão, capacidade ou tamanho de algum atributo de um processo ou produto de software.
Na engenharia de software, o termo métrica de software também é constantemente utilizado. Essa métrica pode ser definida como uma medição quantitativa simples realizada em qualquer atributo do ciclo de vida do software. (FENTON; KAPOSI, 1987 apud PETERS; PEDRYCZ, 2001, p. 430).
Beiman (1995 apud PETERS; PEDRYCZ, 2001, p. 430) explica que a métrica de software permite que os engenheiros de software possam medir e prever os processos de software, os recursos utilizados no projeto e os artefatos necessários para o desenvolvimento. Essa métrica tem o objetivo de quantificar as propriedades de softwares planejados e já existentes.
Pressman (2006) classifica as métricas em três categorias:
Métricas de Processo: Estas métricas são coletadas no decorrer de vários projetos com o objetivo de fornecer um conjunto de indicadores que levam ao aperfeiçoamento dos processos ao longo prazo.
Métricas de Projeto: Estas métricas são aplicadas durante o processo de estimativa, onde métricas de projetos anteriores são utilizadas como base para o cálculo das estimativas de esforço e tempo do projeto atual.
Métricas de Produto: Diferentemente das métricas de processo e de projeto que são aplicadas no projeto como um todo, as métricas de produto estão focadas em atributos específicos de trabalho de engenharia de software e são coletadas à medida que as tarefas técnicas estão sendo conduzidas.
Métricas Diretas: Nas métricas diretas estão incluídas as linhas de código produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de tempo.
Métricas Indiretas: As métricas indiretas incluem funcionalidades, qualidade, complexidade, eficiência e confiabilidade.
De acordo com Sommerville (2003), a medição de software é realizada através da comparação dos valores obtidos com os valores padrão da empresa, para que se obtenham bases para gerar conclusões sobre a qualidade do software ou dos processos de software.
Pressman (2006) explica que os engenheiros de software coletam medidas e desenvolvem métricas para obtenção de indicadores. Estes indicadores fornecem a profundidade de visão necessária para que o gerente de projeto possa tomar as melhores decisões em relação ao processo, produto e ao próprio projeto de software.
O processo de medição é dividido, segundo Sommerville (2003), nos principais estágios a seguir:
Escolha de medições a serem feitas: São formuladas questões às quais as medições se destinam a responder, e as medições exigidas para responder a essas questões devem ser definidas.
Seleção de componentes a serem avaliados: Em alguns casos, podem ser avaliados os componentes mais importantes, que estão em uso quase constante.
Medição de características dos componentes: Os componentes selecionados são medidos e os valores das métricas computados.
Identificação de medidas irregulares: Uma vez realizadas as medições dos componentes, elas devem se comparadas entre si e com as medições precedentes, que tenham sido registradas em um banco de dados de medições para avaliar as possíveis irregularidades.
Segundo Pressman (2006), as medições permitem que os engenheiros de software descubram e corrijam problemas potenciais de forma prematura, evitando que se transformem em defeitos difíceis de serem resolvidos. O autor explica que a medição é uma ferramenta de gestão que serve para apoiar o gerente de projeto e a equipe de software na tomada de decisões que irão levar o projeto ao sucesso.
4.1 MÉTRICAS DE TAMANHO DE SOFTWARE
Segundo Freire (2008), avaliar o tamanho do software que será construído tem sido uma preocupação constante no contexto do desenvolvimento de software.
Pressman (2006) explica que determinar o tamanho do software é algumas vezes uma forma de encontrar um indicador para a complexidade do sistema que será projetado e quase sempre uma forma de encontrar um indicador para o aumento do esforço de codificação, integração e teste.
Para solucionar o problema de produzir estimativas com precisão, os engenheiros de software têm desenvolvido técnicas para compreender a relação que existe entre todos os fatores que afetam o esforço, o custo e o tempo no desenvolvimento de um projeto. (PFLEEGER, 2007 apud FREIRE, 2008, p. 37).
A seguir, serão apresentados alguns dos tipos de métricas mais utilizadas para calcular as estimativas de tamanho de software.
4.1.1 Linhas de Código - LOC
Segundo Peters e Pedrycz (2001), a técnica de mensuração por linhas de código (LOC - Lines of Code), ou de forma mais prática, milhares de linhas de código (KLOC), é a forma mais conhecida de medida de software, levando em consideração àquelas que são orientadas a tamanho.
A técnica LOC consiste na contagem do número de linhas de código fonte de um determinado programa de software. (MISIC; TESIC, apud FREIRE, 2008, p. 38).
Simon (2000 apud FREIRE, 2008, p. 38) explica que como a quantidade de linhas de código fonte é conhecida somente no final de um projeto de software, a estimativa deve ser feita, levando em consideração dados históricos de projetos anteriores.
De acordo com Pressman (2006), os defensores da técnica LOC alegam que as linhas de código estão presentes em qualquer projeto de software e podem ser facilmente contadas, além de existir um grande número de literatura as respeito do assunto. Por outro lado, os opositores argumentam que a técnica depende da linguagem de programação, que não
acomodam linguagens não procedimentais e que o seu uso na estimativa exige um nível de detalhamento que pode ser difícil de alcançar nas fases iniciais de um projeto de software.
4.1.2 Análise de Pontos de Função - APF
Segundo Freire (2008), a técnica de Análise de Pontos de Função (APF) foi desenvolvida por Allan Albrecht, em 1979, com a intenção de mapear as questões referentes à estimativa e à produtividade no desenvolvimento de softwares em ambientes heterogêneos.
A técnica AFP tem como objetivo medir o tamanho do software por meio da quantificação das funções implementadas sob o ponto de vista do usuário. (LONGSTREET, 2002 apud FREIRE, 2008, p. 39).
Pressman (2006) explica que o ponto de função é derivado a partir de uma relação empírica entre as medidas de contagem direta de domínio da informação e a avaliação de complexidade do software. Os valores de domínio da informação são definidos com base no número de arquivos, interfaces, entradas, saídas e consultas do sistema. Para cada um desses valores são atribuídos pesos para serem utilizados no cálculo do ponto de função.
O autor comenta que os defensores do ponto de função afirmam que a técnica é independente de linguagem de programação, e que é baseada em dados que são mais prováveis de serem conhecidos logo que o projeto começa a evoluir. Já, os opositores alegam que a técnica não é confiável pelo fato de que o cálculo é baseado em dados subjetivos.
4.1.3 COCOMO e COCOMO II
O modelo COCOMO (Constructive Cost Model) foi desenvolvido a partir de uma análise de banco de dados com 63 projetos de software, sendo que ele fornece fórmulas detalhadas para determinar o cronograma de um projeto, além do esforço de desenvolvimento e manutenção. (PETERS; PEDRYCZ, 2001).
Segundo Freire (2008), o COCOMO pode ser aplicado em várias fases do ciclo de desenvolvimento, fornecendo melhores resultados em estágios mais avançados do projeto. O autor explica que o modelo está dividido em três níveis de detalhe:
Básico: O esforço e o custo são calculados em função do tamanho do programa estimado em linhas de código.
Intermediário: Calcula o esforço de desenvolvimento levando em conta o tamanho do programa e os custos com equipe, hardware e atributos do projeto.
Detalhado: Este nível utiliza todas as características do nível intermediário juntamente com o impacto do custo em cada fase do projeto de software. Segundo Sommerville (2003), o modelo COCOMO II foi criado para substituir o COCOMO, que acabou ficando obsoleto por estar muito ligado ao processo clássico de desenvolvimento de software, sem considerar as possíveis mudanças que podem ocorrer durante um projeto.
Valença (2007) explica que o COCOMO II suporta projetos de software que utilizam modelos de desenvolvimento em espiral, incremental e orientado a objetos.
Sommerville (2003) divide o COCOMO II em três níveis:
Nível inicial de prototipação: Estimativas com base em pontos por objeto são utilizadas para estimar o esforço requerido.
Nível inicial de projeto: Neste nível, os requisitos do sistema são concluídos e estimativas realizadas com base em pontos de função.
Nível pós-arquitetura: Após a conclusão da arquitetura do projeto, é realizada uma estimativa do tamanho total do software.
4.1.4 Pontos de Caso de Uso - UCP
A UCP (User Case Points) é uma técnica de estimativa usada para determinar o tamanho de um projeto de software orientado a objetos baseada no conceito de casos de uso. (FREIRE, 2008).
Segundo Pressman (2006), os casos de uso têm a função de descrever as características visíveis do usuário que são requisitos básicos para um sistema. O caso de uso
