ads:
UNIVERSIDADE PAULISTA – UNIP
PROGRAMA DE MESTRADO EM ENGENHARIA DE PRODUÇÃO
PROPOSTA DE UM MÉTODO DE ESTIMATIVA PARA
PROJETOS DE MANUTENÇÃO DE SOFTWARE
BASEADO EM PONTOS POR CASO DE USO
Dissertação apresentada ao Programa de
Mestrado em Engenharia de Produção da
Universidade Paulista – UNIP, para a
obtenção do título de mestre em Engenharia
de Produção.
WILSON VENDRAMEL
São Paulo
2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE PAULISTA – UNIP
PROGRAMA DE MESTRADO EM ENGENHARIA DE PRODUÇÃO
PROPOSTA DE UM MÉTODO DE ESTIMATIVA PARA
PROJETOS DE MANUTENÇÃO DE SOFTWARE
BASEADO EM PONTOS POR CASO DE USO
Orientador: Prof. Dr. Mauro de Mesquita
Spínola
Área de Concentração: Gestão da Informação
Dissertação apresentada ao Programa de
Mestrado em Engenharia de Produção da
Universidade Paulista – UNIP, para a
obtenção do título de mestre em Engenharia
de Produção.
WILSON VENDRAMEL
São Paulo
2008
ads:
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
III
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Dedicatória
Aos meus pais, Clotilde Sita Vendramel e
Élcio Vendramel, por todo o apoio e
estrutura familiar que têm me dado ao
longo de todos estes anos.
Aos meus professores, alunos e amigos,
que foram fontes de estímulo para a
realização deste trabalho.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
IV
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Agradecimentos
A Deus, em todos os momentos, por ter me dado as condições necessárias para traçar
e percorrer mais uma trajetória.
Ao professor e orientador Dr. Mauro de Mesquita Spínola, pela sabedoria e
colaboração na elaboração desta pesquisa.
Ao professor Dr. Ivanir Costa, pois tomei conhecimento do curso por intermédio e
incentivo desse professor.
A todos os professores do curso de pós-graduação em Engenharia de Produção, que
transmitiram muitas informações sobre a área de produção de software, utilizadas
para o desenvolvimento deste trabalho.
Ao engenheiro Luiz Geraldo Vieira Ferreira Jr e ao Dr. José Benedito de Almeida,
por passarem as informações pertinentes sobre o sistema UniLIMS, além de cederem
espaço na empresa que foi alvo da pesquisa.
Aos meus colegas Anderson Pinheiro Balbo, José Anselmo Pereira da Silva e Márcio
Magno Chaves, que colaboraram com a aplicação da pesquisa na empresa
UNICORP.
Aos meus gerentes e companheiros de trabalho, Bernard Soihet e Ana Akiko, pelo
apoio e autorização da minha licença de trabalho, possibilitando a realização do
curso de mestrado.
À professora Msc. Rosangela Kronig, e ao meu amigo de trabalho Tiago Fazio, que
assumiram alguns compromissos de minha responsabilidade enquanto cursava o
mestrado.
A todos os autores das referências utilizadas que deram base teórica à elaboração
desta dissertação.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
V
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Epígrafe
“Não são as espécies mais fortes que
sobrevivem, nem as mais inteligentes, mas
aquelas mais sensíveis às mudanças”.
C. DARWIN
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
VI
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Resumo................................................................................................. VIII
Abstract ...................................................................................................IX
Lista de Abreviaturas e Siglas.................................................................. X
Lista de Figuras.......................................................................................XI
Lista de Quadros ....................................................................................XII
Lista de Anexos.................................................................................... XIII
Lista de Apêndices ............................................................................... XIV
1 Introdução ........................................................................................... 15
1.1 Apresentação do Assunto..................................................................................... 15
1.2 Justificativas e Questões de Pesquisa................................................................... 17
1.3 Objetivos .............................................................................................................. 20
1.3.1 Objetivo Geral................................................................................................... 20
1.3.2 Objetivos Específicos........................................................................................ 20
1.4 Contribuição......................................................................................................... 20
1.5 Metodologia de Pesquisa ..................................................................................... 21
1.6 Estrutura do Trabalho........................................................................................... 22
2 Fundamentação Teórica ...................................................................... 23
2.1 Processo de Software ........................................................................................... 23
2.1.1 Especificação do Software................................................................................ 24
2.1.2 Projeto e Implementação do Software .............................................................. 25
2.1.3 Verificação e Validação de Software................................................................ 25
2.1.4 Evolução de Software ....................................................................................... 26
2.1.5 O Processo de Manutenção de Software da Norma ISO/IEC 12207.................27
2.2 Medidas de Software............................................................................................ 30
2.2.1 Estimativa de Tamanho..................................................................................... 32
2.2.2 Pontos por Caso de Uso .................................................................................... 33
3 MEMPCU: um método de estimativa para manutenção de software
com base em pontos por caso de uso ...................................................... 36
3.1 Etapas do MEMPCU............................................................................................ 37
3.1.1 Alinhamento do Nível de Objetivo do Caso de Uso......................................... 39
3.1.2 Contagem dos Casos de Uso Afetados ............................................................. 40
3.1.3 Contagem dos Atores Afetados......................................................................... 45
3.1.4 Cálculo dos Pontos por Caso de Uso não Ajustados......................................... 47
3.1.5 Cálculo do Fator de Complexidade Técnica..................................................... 47
3.1.6 Cálculo do Fator Ambiental.............................................................................. 48
3.1.7 Cálculo do Tamanho da Manutenção................................................................ 50
3.1.8 Cálculo do Esforço da Manutenção .................................................................. 50
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
VII
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4 Pesquisa-Ação...................................................................................... 53
4.1 Iniciação da Pesquisa-Ação.................................................................................. 53
4.1.1 O Objetivo da Pesquisa..................................................................................... 53
4.1.2 As Questões da Pesquisa................................................................................... 53
4.1.3 As Proposições do Estudo................................................................................. 53
4.1.4 Seleção e Caracterização da Unidade de Análise: Unidade de Negócio .......... 54
4.1.5 Seleção e Caracterização da Unidade de Análise: Produto............................... 56
4.2 Planejamento da Pesquisa-Ação .......................................................................... 63
4.2.1 Definição da Equipe da Pesquisa...................................................................... 63
4.2.2 Comprometimento da Equipe ........................................................................... 63
4.2.3 Planejamento dos Ciclos da Pesquisa-Ação...................................................... 64
4.3 Execução e Acompanhamento da Pesquisa-Ação Primeiro Ciclo....................... 66
4.3.1 Reunião de Iniciação do Primeiro Ciclo ........................................................... 66
4.3.2 Seleção do Projeto A de Manutenção ............................................................... 66
4.3.3 Aplicação do Método MEMPCU no Projeto A ................................................ 67
4.3.4 Avaliação dos Resultados do Projeto A............................................................ 73
4.3.5 Análise e Encerramento do Primeiro Ciclo....................................................... 74
4.4 Execução e Acompanhamento da Pesquisa-Ação 2 Segundo Ciclo.................... 76
4.4.1 Reunião de Iniciação do Segundo Ciclo ........................................................... 76
4.4.2 Seleção do Projeto B de Manutenção................................................................ 77
4.4.3 Aplicação do Método MEMPCU no Projeto B................................................. 77
4.4.4 Avaliação dos Resultados do Projeto B ............................................................ 83
4.4.5 Análise e Encerramento do Segundo Ciclo....................................................... 84
4.5 Encerramento da Pesquisa-Ação.......................................................................... 87
5 Conclusão............................................................................................ 89
5.1 Discussão sobre as Questões de Pesquisa............................................................ 89
5.2 Discussão sobre a Metodologia de Pesquisa Utilizada ........................................ 90
5.3 Limitações da Pesquisa ........................................................................................ 91
5.4 Pesquisas Futuras ................................................................................................. 92
Referências.............................................................................................. 93
Anexos..................................................................................................... 96
Apêndices.............................................................................................. 105
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
VIII
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Resumo
VENDRAMEL, Wilson. Proposta de um método de estimativa para projetos de
manutenção de software baseado em Pontos por Caso de Uso.
Dissertação (Mestrado em Engenharia de Produção) - Universidade Paulista, São
Paulo, 2008.
Ao longo do ciclo de vida de um produto de software, os requisitos originalmente
definidos sofrem mudanças para atender às exigências do negócio. As mudanças
podem envolver melhorias, adaptações ou correções de componentes do sistema. É
importante ter um método de apoio ao processo de manutenção capaz de realizar uma
estimativa de esforço baseada no tamanho da manutenção requerida dentro do custo
e prazo acordado. O objetivo desta pesquisa é adaptar e desenvolver um método de
estimativas aplicável em projetos de manutenção, utilizando como base a técnica de
Pontos por Caso de Uso (PCU). O método está fundamentado em pesquisa
bibliográfica e na metodologia de pesquisa-ação. Os resultados obtidos por meio dos
ciclos da pesquisa-ação são analisados para a avaliação e refinamento do método
proposto.
Palavras-chave: Manutenção de Software; Requisito; Estimativa, Pontos por
Caso de Uso; Projeto de Manutenção.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
IX
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Abstract
VENDRAMEL, Wilson. Proposal of a method of estimate for software
maintenance projects based on Use Case Points. Dissertação (Mestrado em
Engenharia de Produção) - Universidade Paulista, São Paulo, 2008.
Throughout the life cycle of a software product, requirements originally defined
suffer changes to achieve business requirements. The changes can involve
improvements, adaptations or corrections of the systems components. It is important
to have a method of support the maintenance process capable to carry through a
estimate of effort inside based on the required maintenance size and the agreeded
cost and period. The objective of this research is to adapt and to develop a method of
estimates applicable in maintenance projects, being used as a base the technique Use
Case Points (UCP). The research methodology is based on a bibliographical
research and an action research. The results gotten through the cycles of the action
research are analyzed for the evaluation and refinement of the considered method.
Key-words: Software Maintenance, Requirement, Estimate, Use Case Points,
Maintenance Project.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
X
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Lista de Abreviaturas e Siglas
CMMI - Capability Maturity Model Integration
CoCoMo - Constructive Cost Model
EF - Environmental Factor
FP - Function Point
FProd – Fator de Produtividade
IEC - International Electrotechnical Commision
IFPUG - International Function Point User Group
ISO - International Organization for Standardization
LOC - Lines of Code
NCU – Novo Caso de Uso
MCU – Mudanças em Caso de Uso
MEMPCU – Método de Estimativa de Manutenção com base em Pontos por Caso de
Uso
PCU – Pontos por Caso de Uso
PM – Profundidade de Mudança
TCF - Technical Complexity Factor
TA – Transações Alteradas
TE – Transações Excluídas
TEx – Transações Existentes
TI – Transações Incluídas
TMan – Tamanho da Manutenção
TTI – Total de Transações Identificadas
UAW - Unadjusted Actor Weight
UCP - Use Case Point
UML - Unified Modeling Language
UUCP - Unadjusted Use Case Point
UUCW - Unadjusted Use Case Weight
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
XI
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Lista de Figuras
Figura 1 – Processo de Manutenção baseado na ISO 12207 ..................................... 37
Figura 2 – Alinhamento do Nível de Objetivo de um Caso de Uso........................... 40
Figura 3 – Planilha para Contagem dos Novos Casos de Uso................................... 41
Figura 4 – Planilha para Registro do Total de Transações Existentes....................... 41
Figura 5 – Planilha para Contagem dos Casos de Uso Afetados............................... 43
Figura 6 – Definição da Complexidade e Cálculo da Profundidade de Mudança ..... 45
Figura 7 – Planilha para Contagem dos Atores Afetados .......................................... 46
Figura 8 – Cálculo do UUCP ..................................................................................... 47
Figura 9 – Fatores de Complexidade Técnica............................................................ 48
Figura 10 – Fatores de Complexidade Ambiental...................................................... 50
Figura 11 – Planilha para Cálculo do Tamanho e Esforço da Manutenção............... 51
Figura 12 – Modelo de Processo de Laboratório de Análise ..................................... 55
Figura 13 – Pacotes do Módulo UniMaster ............................................................... 59
Figura 14 – Diagrama de Casos de Uso - Pacote de Análise do UniMaster.............. 60
Figura 15 – Diagrama de Casos de Uso - Pacote de Coleta do UniMaster................ 60
Figura 16 – Diagrama de Casos de Uso - Pacote de Laboratório do UniMaster ....... 61
Figura 17 – Diagrama de Casos de Uso - Pacote de Regulamentações..................... 61
Figura 18 – Diagrama de Casos de Uso – Pacote Supervisão do UniMaster ............ 62
Figura 19 – Diagrama de Casos de Uso – Pacote Pontos de Coleta do UniMaster... 62
Figura 20 – Cronograma da Pesquisa-Ação............................................................... 65
Figura 21 – Transações Existentes nos Casos de Uso Afetados no Projeto A........... 67
Figura 22 – Total de Transações Identificadas no Projeto A..................................... 68
Figura 23 – Complexidade e Profundidade de Mudança no Projeto A...................... 69
Figura 24 – Cálculo do UUCW no Projeto A ............................................................ 69
Figura 25 – Atores Afetados pelas Mudanças no Projeto A...................................... 70
Figura 26 – Cálculo do UUCP no Projeto A.............................................................. 70
Figura 27 – Cálculo do TCF para o Projeto A ........................................................... 71
Figura 28 – Cálculo do EF para o Projeto A.............................................................. 72
Figura 29 – Cálculo do Tamanho da Manutenção para o Projeto A.......................... 72
Figura 30 – Cálculo do Esforço da Manutenção para o Projeto A............................. 73
Figura 31 - Transações Existentes nos Casos de Uso Afetados no Projeto B............ 78
Figura 32 – Total de Transações Identificadas no Projeto B ..................................... 79
Figura 33 – Complexidade e Profundidade de Mudança no Projeto B...................... 79
Figura 34 – Cálculo do UUCW no Projeto B ............................................................ 80
Figura 35 – Atores Afetados pelas Mudanças no Projeto B ...................................... 80
Figura 36 – Cálculo do UUCP no Projeto B.............................................................. 81
Figura 37 – Cálculo do TCF para o Projeto B ........................................................... 81
Figura 38 – Cálculo do EF para o Projeto B.............................................................. 82
Figura 39 – Cálculo do Tamanho da Manutenção para o Projeto B.......................... 82
Figura 40 – Cálculo do Esforço da Manutenção para o Projeto B............................. 83
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
XII
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Lista de Quadros
Quadro 1 – Atividades do processo Manutenção de Software e Sistema – ISO/IEC
12207.......................................................................................................................... 28
Quadro 2 – Critérios para Definição dos Pesos dos Casos de Uso ............................ 44
Quadro 3 – Critérios para Definição dos Pesos dos Atores ....................................... 46
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
XIII
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Lista de Anexos
Anexo I – Questionário de Fatores de Complexidade Técnica e de Fatores
Ambientais ................................................................................................................. 96
Anexo II – Documento de Descrição Funcional de Melhorias................................ 103
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
XIV
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Lista de Apêndices
Apêndice A – Modelo de Especificação de Caso de Uso........................................ 105
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
15
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
1 – Introdução
1.1 Apresentação do Assunto
As empresas que concorrem no mercado de software buscam constantemente
aperfeiçoar a qualidade dos serviços prestados, a fim de se obter diferencial
competitivo e fidelidade do cliente. Segundo o Standish Group apud HAZAN e
STAA (2004), uma das maiores preocupações dessa indústria tem sido a estimativa
de projetos, pois apenas 34% dos projetos de software atingem seus objetivos dentro
do cronograma e orçamento planejados.
Decisões tomadas com bases empíricas costumam estimar o projeto com
esforço, prazo e custo inconsistentes. O Standish Group apud HAZAN e STAA
(2004) destaca que 43% dos erros localizados em um projeto estão relacionados ao
fator custo. Vale ressaltar que os erros envolvendo custo podem ser conseqüentes de
estimativas incorretas sobre o tamanho do software.
A ausência de um bom planejamento de estimativas pode trazer a falta de
controle adequado no que se refere ao esforço, custo e prazo no ciclo de
desenvolvimento de software, não somente no desenvolvimento de projetos novos,
mas também durante a evolução de software.
Mesmo após a implantação do sistema, este deve sofrer mudanças para
permanecer útil; afinal, novos requisitos surgem e os já existentes mudam. As
mudanças na pós-implantação não estão associadas simplesmente a reparos de
defeitos no software, pois a maioria das mudanças deriva de novos requisitos gerados
em resposta às mudanças de negócio ou necessidades da comunidade usuária, sendo
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
16
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
que a maior parte do orçamento nas grandes empresas está relacionada à manutenção
dos sistemas existentes, que fazem parte dos ativos do negócio. Erlikh apud
Sommerville (2007) ressalta que 90% dos custos de software estão na sua evolução.
Para Webster et al. apud Freire (2007), a manutenção de software tem
chegado a 70% dos custos, tornando-se um dos grandes desafios da engenharia de
software. O fato evidencia a importância de pesquisas na evolução de sistemas de
software, em que processos são adaptados e métodos de estimativas são elaborados,
como é o caso da estimativa de tamanho de um projeto de manutenção.
Diante dos motivos expostos, é desejável que a empresa possua conhecimento
sobre métodos de estimativa aplicáveis nos projetos de manutenção. Assim como é
importante haver uma base de dados a respeito de projetos anteriores e que
possibilite o seu aproveitamento, pois dessa forma o gerente de projetos pode estar
capacitado a planejar o esforço necessário para evoluir um software, baseando-se em
dados mais concisos e realistas.
As estimativas de tamanho dependem de informações que nem sempre estão
disponíveis no início dos projetos. De qualquer forma, a presença dessas estimativas
é importante para negociar com o cliente e/ou usuário a viabilidade do projeto de
manutenção em termos de custo versus benefício. A obtenção de estimativas mais
precisas no início do projeto e também o seu controle, tendem a reduzir problemas de
gestão, como altos custos, atrasos de entrega, insatisfação do cliente e dificuldades de
medição dos projetos (MURTHI apud ANDRADE, 2004).
Por causa do interesse de se ter uma estimativa de tamanho mais realista
desde o início do projeto, a técnica de Pontos por Caso de Uso (PCU) tornou-se uma
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
17
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
alternativa para medição, especialmente em projetos de software orientado a objetos,
sendo possível também ser aplicada na evolução da aplicação já existente.
1.2 Justificativas e Questões de Pesquisa
Há mais de três décadas, a manutenção de software foi comparada a um
iceberg, pois somente uma parte dele é visível, e uma grande parte de possíveis
problemas e questões de custo está abaixo da superfície. A manutenção de software
chega a ser responsável por mais de 60% de todo o esforço gasto por uma empresa
de software, e porcentagem aumenta à medida que o produto de software cresce.
Esse número não está ligado somente ao reparo de defeitos na aplicação
desenvolvida. Cerca de 20% de todo o trabalho envolvem a correção de defeitos; os
80% restantes são despendidos com melhorias do produto de software (PRESSMAN,
2006).
Como a manutenção do software é inevitável, sugere-se que a empresa tenha
condições de estimar o tamanho da modificação capaz de atender às exigências dos
clientes dentro de custo e prazo acordados entre as partes envolvidas. Medidas mais
realistas costumam favorecer a estimativa e controle da manutenção.
As questões a serem respondidas nesta pesquisa são:
• O método PCU é aplicável em projetos de manutenção de software?
• O tamanho dos casos de uso na aplicação existente influencia as
estimativas de manutenção?
• Como adaptar e aplicar o método PCU em uma pequena empresa
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
18
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
mantenedora de software?
A pesquisa bibliográfica, com o intuito de buscar respostas às questões
levantadas, direcionou os estudos para o método de Pontos por Caso de Uso (PCU)
aplicado em projetos de manutenção de software.
Em 1993, Gustav Karner desenvolveu em seu mestrado a técnica de Pontos
por Caso de Uso, do inglês Use Case Points (UCP), como uma adaptação aos pontos
de função, supervisionado por Ivar Jacobson. Contudo, não houve grande
repercussão do método nessa época, e mesmo a ida de Karner para a Rational
Software não foi suficiente para disseminar o PCU, de acordo com Drach (2005).
As empresas que utilizam os casos de uso como forma de explicitar ou
mapear os requisitos do cliente definem as ações que o sistema deve realizar no
início do projeto, assim como no decorrer do desenvolvimento do sistema. Segundo
Monteiro (2005), o PCU permite que as estimativas sejam realizadas já na etapa de
requisitos.
Estimativas geradas no início do projeto possibilitam ao gerente de projeto o
levantamento de dados imediatos para calcular o custo do produto. A técnica de
estimativa CoCoMo é dependente da tecnologia aplicada, pois gera as medidas a
partir de linhas de código. A técnica de Análise de Pontos por Função facilita a
medição independente da linguagem de programação utilizada. Mas deve ter as
funcionalidades do sistema definidas, para os cálculos serem implementados. O
PCU, por outro lado, contabiliza as realizações do sistema no diagrama de casos de
uso e nas especificações destes.
Os clientes costumam ter interesse nos casos de uso, pois representam as
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
19
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
funcionalidades do sistema e descrevem como será operacionalizado. A participação
do cliente durante a modelagem e especificação dos casos de uso é muito importante
para o sucesso do projeto (TONSIG, 2003).
O PCU já foi aplicado em muitos projetos novos de produtos de software,
mas espera-se que o método seja também aplicado na manutenção do sistema, seja
em sistemas construídos por meio de métodos empíricos, como principalmente
aqueles desenvolvidos com base em PCU.
Ao longo do ciclo de vida de um software, os requisitos originalmente
definidos sofrem mudanças para atender às exigências do negócio e aos requisitos
dos clientes e/ou comunidade usuária. As mudanças envolvem melhorias, adaptações
ou correções de componentes do sistema. É importante que o processo de
manutenção seja apoiado por um método de estimativa capaz de estimar o tamanho e
esforço do projeto da modificação, procurando cobrir as mudanças solicitadas dentro
do custo e prazo acordados.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
20
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
1.3 Objetivos
1.3.1 Objetivo Geral
O objetivo desta pesquisa é desenvolver um método de estimativa aplicável
em projetos de manutenção, utilizando como base a técnica de Pontos por Caso de
Uso (PCU).
1.3.2 Objetivos Específicos
São objetivos específicos desta pesquisa:
• Estudar os conceitos e aplicações da técnica de estimativa baseada em
Pontos por Caso de Uso (PCU);
• Propor um método de estimativa na etapa de manutenção de software;
• Planejar, estruturar e executar uma pesquisa-ação com o intuito de
aplicar, avaliar e aperfeiçoar o método proposto.
1.4 Contribuição
Este trabalho pretende contribuir com as áreas:
• Acadêmica – contribuição como referência para estudos relacionados
a estimativas de tamanho e esforço de manutenção de software em
empresas de desenvolvimento.
• Empresarial – contribuição ao método de estimativas aplicável na
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
21
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
manutenção de sistemas para empresas de software que precisam de
uma estimativa mais precisa de tamanho, esforço, custo e prazo em
sua evolução.
1.5 Metodologia de Pesquisa
Para se realizar uma pesquisa qualitativa, foi escolhida a metodologia da
pesquisa-ação. A escolha é justificada pela natureza das questões investigadas e pela
proposta em fornecer ao pesquisador e ao grupo de participantes os meios de se
tornarem capazes de responder com maior eficiência aos problemas da situação em
que vivem, sob a forma de diretrizes de ação transformadora (THIOLLENT, 2004).
A metodologia deste trabalho inicia-se com o estudo bibliográfico para se se
entender a teoria sobre manutenção de software, técnicas de estimativa de software e
Pontos por Caso de Uso. O resultado desta pesquisa bibliográfica foi a proposta de
um método de estimativa voltada para projetos de manutenção de software. Foi
elaborado também o planejamento de uma pesquisa-ação.
Para Asato (2007), o planejamento organiza a execução das etapas de uma
pesquisa-ação. As etapas são flexíveis e possibilitam a execução de ciclos
seqüenciais das mesmas em função das características da equipe de pesquisa em
relação à situação investigada. A quantidade de ciclos a ser executada foi definida no
planejamento.
A partir do detalhamento do planejamento, executou-se a seqüência das
etapas. Os resultados obtidos e as avaliações permitiram o refinamento do método
proposto. O planejamento da nova seqüência se baseia nos resultados coletados na
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
22
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
execução da seqüência anterior.
Ao final da execução dos ciclos é obtida a proposta aprimorada do método de
estimativa, objeto desta dissertação.
1.6 Estrutura do Trabalho
O presente capítulo apresenta o assunto, justificativas e questões de pesquisa,
objetivos e metodologia adotada na pesquisa.
No Capítulo Dois há a fundamentação teórica para entender os conceitos de
manutenção de software e medidas de software, com enfoque em PCU.
No Capitulo Três, a proposta do método de estimativa baseado em PCU,
denominado Método de Estimativa de Manutenção com base em Pontos por Caso de
Uso (MEMPCU).
O Capítulo Quatro detalha o planejamento e a execução da pesquisa-ação,
incluindo os resultados obtidos em cada ciclo de execução da pesquisa.
Finalmente, no Capítulo Cinco estão a conclusão, a discussão sobre as
questões de pesquisa e a metodologia utilizada, além de possíveis pesquisas futuras.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
23
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
2 Fundamentação Teórica
Neste capítulo estão elencados os conceitos básicos da dissertação. Os
conceitos têm como objetivo entender a teoria sobre manutenção de sistemas em um
processo de desenvolvimento e técnicas de estimativa aplicáveis em projetos de
software. A norma ISO 12207 também foi apresentada para dar visão geral sobre as
atividades de manutenção de software e sistema em um processo de manutenção,
apoiado por um método de estimativa.
2.1 Processo de Software
O processo de software é como um arcabouço para as tarefas necessárias à
construção de softwares de alta qualidade. O processo de software é, muitas vezes,
confundido com a própria Engenharia de Software. O primeiro define a abordagem
adotada na construção de um produto de software. O segundo também inclui o uso de
tecnologias que constituem um processo, ou seja, métodos técnicos e ferramentas
automatizadas (PRESSMAN, 2006).
De acordo com Bezerra (2007), um processo de desenvolvimento de software
compreende as atividades necessárias para definir, desenvolver, testar e manter um
produto de software.
No desenvolvimento de software, o passo inicial é a escolha de um modelo
de processo (PAULA FILHO, 2005).
Sommerville (2007) afirma que os modelos de processo de software variam
de uma empresa para outra; entretanto, há quatro atividades fundamentais:
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
24
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Especificação, Projeto e Implementação, Verificação e Validação, e Evolução. Essas
atividades são ampliadas ou reduzidas, de acordo o modelo adotado.
2.1.1 Especificação do Software
Quando se pretende desenvolver um produto, a primeira etapa a ser
considerada é sobre o que será construído, descrito na forma de requisitos.
Um requisito é uma característica do produto de software ou a descrição de
algo que o sistema é capaz de realizar para atingir os seus objetivos (PFLEEGER,
2004).
Os requisitos formam o conjunto de necessidades estabelecidas pelos
envolvidos, que definem a estrutura e o comportamento do produto de software que
será desenvolvido. Os requisitos determinam a funcionalidade essencial para que um
usuário resolva os problemas inerentes ao negócio da empresa e que as necessidades
e restrições da organização ou dos outros componentes do sistema sejam atendidas
(TONSIG, 2003).
Tonsig (2003) ainda classifica os requisitos como funcionais ou não-
funcionais. Os requisitos funcionais definem a funcionalidade desejada do sistema,
ou seja, as funções que podem ser realizadas por meio de comandos dos usuários ou
pela ocorrência de eventos internos ou externos ao sistema. Já os requisitos não-
funcionais referem-se às qualidades globais de um sistema de software, como a fácil
manutenção, segurança, facilidade de uso e desempenho.
Para Paula Filho (2005), a documentação da especificação dos requisitos
facilita a comunicação da equipe no processo de desenvolvimento do sistema. Além
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
25
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
disso, os requisitos, obtidos na sua totalidade e corretamente documentados, evitam
maior custo para o fornecedor e consumidor. Os requisitos que caracterizam o
software são analisados, e apenas as características relevantes são mantidas na
documentação. Em caso de falha na especificação, a mesma deve ser reportada ao
cliente, para ser corrigida antes da implementação do software.
2.1.2 Projeto e Implementação do Software
Essa atividade do processo compõe a conversão dos requisitos documentados
em produto de trabalho. Nessa etapa é permitido o aperfeiçoamento da especificação
do software. Contudo, considera-se que os requisitos já estejam formalizados de
acordo com as necessidades do cliente e a viabilidade da empresa fornecedora do
produto; caso contrário, recomenda-se que seja retomada a etapa da especificação de
requisitos. Ao obter a documentação técnica do software ou componente deste, o
programador, a partir de uma análise apurada da especificação do sistema, verifica a
forma de iniciar o processo de codificação (SOMMERVILLE, 2007).
Para Bezerra (2007), na etapa de implementação o sistema é codificado
mediante o uso de uma linguagem de programação.
2.1.3 Verificação e Validação de Software
As atividades de Verificação e Validação (V&V) asseguram que o software
funcione de acordo com o que foi especificado e atenda aos requisitos dos
envolvidos. Essas atividades podem ser iniciadas com as revisões dos requisitos,
passando pelas revisões da análise e do projeto e as inspeções do código até chegar
aos testes (KOSCIANSKI e SOARES, 2006).
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
26
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Para Bartié (2002), as atividades de verificação e validação são
complementares e não devem ser vistas como atividades redundantes.
A verificação investiga defeitos no software que impedem a correta execução
das suas tarefas, enquanto a validação constata se o produto está de acordo com a
especificação do cliente (SOMMERVILLE, 2007).
2.1.4 Evolução de software
Quando um software conclui as etapas de testes com sucesso e é entregue ao
cliente, passa a executar as funcionalidades delineadas inicialmente. A partir daí, o
sistema é constantemente adaptado às necessidades de negócio. Além disso, os
sistemas evoluem com o tempo, e essa evolução deve ser acompanhada por
modificações do software que atendam aos novos requisitos (SOMMERVILLE,
2007).
“A falta de habilidade em mudar um software rapidamente, e de maneira
confiável, pode causar a perda de oportunidades de negócio” (BENNETT e
RAJLICH, 2000 apud PADUELLI, 2007, p.36).
Após ser concluído e colocado em uso, um produto de software
inevitavelmente sofrerá modificações, sejam para corrigir defeitos encontrados na
operação, melhorar o desempenho do sistema ou adicionar e adaptar novas
funcionalidades, de forma a atender às exigências dos clientes diante das mudanças e
constante evolução do ambiente em que o sistema está inserido (FREIRE e
BELCHIOR, 2007).
A atividade de evolução de software pode ser definida como o processo geral
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
27
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
de modificação de um produto de software depois de colocado em uso, para a
correção de eventuais defeitos, melhora em seu desempenho, ou qualquer outro
atributo, ou ainda para adaptação desse produto a um ambiente modificado (IEEE,
1998 apud PADUELLI, 2007; SOMMERVILLE, 2007).
Segundo Lientz e Swanson (1980) apud Paduelli (2007), as ações ligadas à
manutenção de software foram classificadas, de acordo com sua natureza, em três
diferentes categorias: corretivas, adaptativas e perfectivas, definidas da seguinte
forma:
a) Manutenção corretiva: visa corrigir defeitos de funcionalidade, o que inclui
acertos emergenciais de um programa;
b) Manutenção adaptativa: refere-se a adequar o software ao seu ambiente
externo;
c) Manutenção perfectiva: tem o objetivo de acrescentar novos recursos de
funcionalidade ao software, normalmente em razão de solicitações dos usuários.
2.1.5 O Processo de Manutenção de Software da Norma ISO/IEC
12207
Criada em 1995 com o objetivo de criar um framework adaptável para
auxiliar a gerência e a construção de software, a norma ISO/IEC 12207 - Information
technology -- Software life cycle processes (Tecnologia da Informação – Processos
do ciclo de vida de software) provê “um conjunto de processos de engenharia que
uma organização deve utilizar para adquirir, fornecer, desenvolver, ou manter
software”, documentando os processos do ciclo de vida de um software em um
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
28
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
modelo de referência de processos. A norma está atualmente na versão 2008
(ISO/IEC 12207:2008), e seu nome foi alterado para Systems and software
engineering - Software life cycle processes (Engenharia de sistemas e de software -
Processos do ciclo de vida de software) (PADUELLI, 2007).
Segundo Machado (2006), a norma descreve a arquitetura dos processos de
ciclo de vida de software, mas não especifica os detalhes de como implementar ou
executar as atividade e tarefas incluídas nos processos, nem prescreve um modelo de
ciclo de vida ou método de desenvolvimento de software específico. Os envolvidos
são responsáveis pela adaptação dos processos, atividades e tarefas da norma para
atender ao modelo de ciclo de vida para o projeto de software. Os envolvidos são
também os responsáveis pela seleção e aplicação dos métodos de desenvolvimento
de software.
Machado (2006) ainda diz que a norma é dividida em três classes de
processos: Processos fundamentais, Processos organizacionais e Processos de apoio.
O processo de Manutenção de Software e Sistema pertence à classe dos Processos
Fundamentais, e possui seis atividades, conforme mostra o quadro 1:
Quadro 1: Atividades do processo Manutenção de Software e Sistema – ISO/IEC 12207
Fonte: Adaptado de Paduelli (2007)
Atividade Descrição
Implantação do processo Inclui tarefas para o desenvolvimento de planos e
procedimentos para manutenção de software, criando
procedimentos para receber, gravar e monitorar pedidos
de manutenção, e estabelecer uma interface
organizacional com o processo de gerenciamento de
configuração. Inclui ainda definir o escopo de
manutenção e a identificação e análise de alternativas.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
29
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Atividade Descrição
Análise do problema e da
modificação
Tem por objetivo analisar a requisição de manutenção
para classificá-la, podendo então determinar o escopo
em termos de tamanho, custos e tempo necessário,
destacando ainda sua prioridade. As demais tarefas
focam o desenvolvimento e a documentação de
alternativas para mudança de implementação e
aprovação das opções adotadas.
Implantação da
modificação
Engloba a identificação dos itens que precisam ser
modificados e os processos de desenvolvimento que
precisarão ser implementados. Outros requisitos da
modificação incluem teste e validação de que as
modificações estão corretamente implementadas, e que
os itens não modificados não foram afetados.
Revisão/aceitação da
modificação
Tarefas dedicadas à confirmação da integridade do
software modificado e à conclusão dos negócios com o
cliente, quando este concorda e aprova satisfatoriamente
a conclusão da requisição de manutenção.
Migração Ocorre quando o software é transferido de um ambiente
de operação para outro. Requer o desenvolvimento de
planos de migração e comunicação aos usuários dos
requisitos, dos motivos do antigo ambiente não ser mais
suportado e uma descrição do novo ambiente e data de
disponibilidade.
Descontinuação do
software
Consiste em descontinuar o software por meio da
formalização, junto ao cliente, de um plano de
descontinuação.
O processo Manutenção de Software e Sistema da ISO/IEC 12207 serve
como base para a organização criar o seu processo de manutenção de software, pois
Paduelli (2007) salienta que a norma não é um modelo fixo ao qual a organização
que a adota se submete, mas antes um modelo de apoio que a organização pode
adaptar de acordo com suas necessidades.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
30
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
2.2 Medidas de Software
Fernandes e Teixeira (2004) apresentam o conceito da medição de software
como o fator crucial para concretizar a gestão das melhorias de processo, pois é a
base para se manter o controle do mesmo, além de ser tratado como indicador de
desempenho de software.
As medições que tratam de tamanho associado ao custo, prazo e esforço em
processo de desenvolvimento de software são consideradas fatores primordiais de
sucesso em gerenciamento de projetos.
“As estimativas documentadas constituem a base para a
elaboração de um plano do projeto de software. As estimativas de
tamanho de projetos de software devem ser utilizadas para a
derivação das estimativas de custo, esforço e cronograma,
conforme as diretrizes do CMMI” (HAZAN e STAA, 2004, p.33).
Quando se fala a respeito de medições, é importante distinguir esse termo de
medida e métrica, embora ambos estejam intimamente ligados ao primeiro. Chiossi e
Germano (2005) caracterizam a medida em engenharia de software como um
indicador quantitativo de um atributo, enquanto a medição é o ato de determinar a
medida, e a métrica é a quantidade de medidas individuais de um atributo ou
processo de desenvolvimento.
Com isso, entende-se que a medida de software mensura extensão,
capacidade ou qualquer outro fator quantitativo relacionado a uma característica ou
propriedade envolvida. Pela medição, são descritas as medidas básicas para se obter
os valores e resultados.
O conjunto de medidas obtido possibilita a extração de dados que, aliados a
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
31
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
um indicador, facilitam a análise conjunta do universo de pesquisa. Segundo Chiossi
e Germano (2005), o indicador é o valor ou o agrupamento de valores de referência
que, quando comparado com as medidas, analisa se estas estão ou não ajustadas ao
valor esperado.
Roche apud Pressman (2006) divide o processo de medição em formulação,
coleta, análise, interpretação e realimentação. A atividade de formulação abstrai as
medidas e métricas adequadas do projeto, considerando apenas aquelas viáveis para a
análise. A coleta acumula os dados abstraídos do projeto, que darão suporte à análise.
A atividade de análise calcula as medidas. A interpretação analisa as medidas
calculadas em busca da representatividade das informações. A atividade de
realimentação leva à equipe as orientações para o ajuste do processo, de acordo com
as informações interpretadas.
Para uma medida ser viável em um projeto, ela deve ter atributos mensuráveis
e não sofrer influência dos envolvidos no projeto; a coleta de dados também não
deve prejudicar o processo de desenvolvimento. Além disso, as medidas devem ser
analisadas sob o ponto de vista de pessoas, processo e produto, de acordo com
Chiossi e Germano (2005).
A partir da obtenção das medidas de esforço e tempo em projetos anteriores,
são formados indicadores que podem ser usados com as atuais medições do projeto,
gerando estimativas que auxiliam as decisões do gerente. Segundo Pressman (2006),
essas decisões têm como objetivo reduzir o prazo do projeto por meio de correções
de atrasos e problemas, e aperfeiçoar a qualidade do produto durante o seu ciclo de
vida, assim como a redução de defeitos.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
32
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
2.2.1 Estimativa de Tamanho
A evolução tecnológica trouxe aos ambientes de desenvolvimento de software
a oportunidade de trabalhar com novos paradigmas de medição no projeto, pois para
cada abordagem de linguagem de programação utilizada, novos ajustes ou métodos
para obtenção das medidas são adotados.
Segundo Pressman (2006), nenhum método de estimativa é adequado a todos
os processos de desenvolvimento, pois para cada um existe uma amostra limitada do
projeto, passível de ajustes para ser utilizado.
Ao se utilizar os métodos de estimativa, é possível justificar a solicitação de
recursos monetários, de tempo e pessoas; avaliar a necessidade de treinamento e
recrutamento de pessoas; gerar compensações de produtividade, custo e qualidade;
avaliar e mitigar o impacto das mudanças; negociar o orçamento de acordo com as
novas exigências de desenvolvimento. Segundo Peters e Pedrycz (2001), essas razões
para estimar o custo de software explicam o uso dos métodos.
As linhas de código, ou Lines of Code (LOC), são medidas que levam em
consideração a quantidade de linhas produzidas essenciais para a execução de um
programa ou componente (CHIOSSI e GERMANO, 2005).
A medida de pontos de função, ou Function Points (FP), foi desenvolvida
como forma de medir um software considerando as funcionalidades criadas. A
medida FP é independente da tecnologia utilizada no desenvolvimento e é aplicada
logo após a definição da arquitetura, permitindo estimar o esforço de implementação
de um projeto (KOSCIANSKI e SOARES, 2006).
Dados estatísticos obtidos por Drach (2005) confirmam que em 2001 apenas
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
33
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
30% das empresas mediam a produtividade dos processos de software, sendo que
18,2% aplicavam a técnica de pontos de função, e 10,3% baseavam-se em linhas de
código.
Por fim, a medida de pontos por caso de uso foi definida para estimar projetos
orientados a objetos com base no modelo de casos de uso (ANDRADE, 2004).
2.2.2 Pontos por Caso de Uso
O método Pontos por Caso de Uso (PCU) foi proposto por Gustav Karner, em
1993, também conhecido como Use Case Points (UCP). O método permite estimar o
tamanho de um projeto com base em casos de uso, considerando a complexidade das
ações e uma análise de alto nível dos passos executados em cada tarefa (LIMA,
2007).
As empresas que passaram a utilizar os casos de uso para mapear os
requisitos do cliente tendem a definir as ações que o sistema deve realizar no início
do projeto, assim como no decorrer do desenvolvimento do sistema. Segundo
Monteiro (2005), o PCU permite que as estimativas sejam realizadas já na etapa de
requisitos.
Situações em que há modificações na especificação são previstas para essa
medição, pois os requisitos, desde que previamente acordados entre fornecedor e
cliente, são passíveis de adaptação. De acordo com Anda et al. (2001), há quatro
razões principais no projeto que levam os requisitos a serem readaptados:
• Mudanças funcionais nos requisitos que não foram especificadas nos
casos de uso: as exigências do cliente/usuário evoluem, refletindo no
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
34
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
sistema em desenvolvimento. Essas modificações devem, antes de
tudo, estar documentadas nos casos de uso, impedindo que haja
desvios das medidas com o projeto;
• A evolução dos requisitos não-funcionais também deve aparecer na
diagramação dos casos de uso, evitando que elementos importantes do
desempenho do sistema deixem de constar para as estimativas;
• Os sistemas são suscetíveis a mudanças corretivas, caso apresentem
alguma alteração com o que foi especificado nos requisitos; desse
modo os defeitos localizados devem estar documentados no diagrama
de casos de uso;
• Algumas alterações não são solicitadas pelo cliente; contudo, o
gerente de projetos pode solicitar à sua equipe alterações quanto ao
produto em desenvolvimento, a fim de evitar futuros problemas de
incompatibilidade do software ou mesmo para adequá-lo às exigências
do mercado.
De acordo com Damodaram e Washington (2002), é crescente a utilização do
modelo de casos de uso para descrever os requisitos funcionais de um sistema, e isso
favorece a aplicação cada vez maior do método PCU. Apesar de ainda não ser um
método tão consolidado quanto a Análise de Pontos por Função, vários autores
(ANDA et al., 2001; DAMODARAM e WASHINGTON, 2002; ANDRADE, 2004)
acreditam que o método tem grande potencial para se tornar cada vez mais aceito no
mercado.
Estudo realizado por Anda et al. (2001) demonstrou a utilização prática do
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
35
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
método PCU para se estimar o esforço necessário para o desenvolvimento de três
projetos, fazendo comparação entre as estimativas obtidas com o método PCU e as
estimativas feitas por especialistas no domínio dos sistemas desenvolvidos e da
tecnologia utilizada. O resultado demonstrou que as estimativas de esforço obtidas
utilizando método PCU ficaram muito próximas às estimativas de especialistas e
também do esforço real.
Anda et al. (2001) ressaltam ainda que os resultados foram obtidos sem
nenhuma alteração do método como foi originalmente proposto por Karner,
indicando que o método pode ser aperfeiçoado para obter resultados ainda mais
precisos e consistentes.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
36
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
3 MEMPCU: um método de estimativa para
manutenção de software com base em pontos por
caso de uso
Este capítulo descreve as etapas utilizadas para o desenvolvimento e
aplicação da proposta de um método de estimativas a ser utilizada na etapa de
manutenção de um produto de software, denominado Método de Estimativa de
Manutenção com base em Pontos por Caso de Uso (MEMPCU). O método consiste
no uso da técnica de estimativa de Pontos por Caso de Uso, também conhecida como
Use Case Points (UCP). O método MEMPCU também foi baseado na norma ISO
12207, principalmente na atividade de análise do problema e da modificação.
O intuito de se desenvolver uma proposta de estimativas para projetos de
manutenção é permitir que a empresa desenvolvedora e mantenedora tenha
condições para estimar o tamanho do projeto de evolução de um sistema de software,
a partir da melhoria solicitada pelo cliente.
O MEMPCU é apoiado por uma planilha eletrônica contendo as informações
básicas para a definição das estimativas. Da mesma forma que esse método foi
customizado a partir de técnica já existente, existe a possibilidade dele ser adaptado
para um uso mais propício numa determinada empresa de software.
A figura 1 representa um processo genérico de manutenção de software com
base na norma ISO 12207. No processo, uma das atividades é fazer a Análise do
Problema e da Modificação, prevista na norma 12207. A atividade é apoiada pela
subatividade de Estimativa de Manutenção com o uso método MEMPCU.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
37
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 1: Processo de Manutenção baseado na ISO 12207
Fonte: elaborado pelo autor
3.1 Etapas do MEMPCU
Como precondição, deve-se ressaltar que as funcionalidades dos sistemas ou
módulos devem estar especificados no formato de caso de uso, preferencialmente em
um documento padrão utilizado pela organização. A especificação precisa conter os
passos dos fluxos de eventos reconhecidos como transações.
Muitos modelos (também chamados de templates) para especificação de
casos de uso são propostos e utilizados pelas organizações. Para Fowler apud
Monteiro (2005), ainda não existe um modelo padrão largamente aceito para a
especificação de casos de uso, especialmente por esta ser de natureza subjetiva e de
depender do grau de detalhamento e do conhecimento das informações disponíveis.
Para este pesquisa, foi elaborado e proposto o Modelo de Especificação de
Casos de Uso adaptado de Bezerra (2007), e que está disponível no Apêndice A.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
38
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Como esse modelo é um dos subsídios para o cálculo do PCU, a especificação
precisa ser padronizada pela empresa para que todos os envolvidos realizem e
compreendam a contagem do UUCW.
Outra precondição é a utilização de documento de solicitação de mudanças,
em que as mudanças requeridas devem ser identificadas. Apesar da relevância desse
documento, o MEMPCU permite que a empresa de software utilize o seu documento
padrão para o pedido das modificações. De qualquer forma, é importante salientar
que a especificação apresente os casos de uso afetados.
Tendo os casos de uso do sistema atual especificados de forma padronizada e
um documento de solicitação de mudanças estabelecido, o método já pode ser
utilizado.
O MEMPCU propõe, em linhas gerais, oito etapas para ser aplicado:
• Alinhamento do Nível de Objetivo do Caso de Uso;
• Contagem dos Casos de Uso Afetados;
• Contagem dos Atores Afetados;
• Cálculo dos Pontos de Caso de Uso não Ajustados;
• Cálculo do Fator de Complexidade Técnica;
• Cálculo do Fator de Complexidade Ambiental;
• Cálculo do Tamanho da Manutenção;
• Cálculo do Esforço da Manutenção.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
39
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
3.1.1 Alinhamento do Nível de Objetivo do Caso de Uso
Um dos problemas a serem enfrentados pelo PCU é a atenção ao nível de
detalhamento dos casos de uso. A especificação do caso de uso varia de estilo e
forma, de empresa para empresa, e ainda não há padrões universais para a construção
de casos de uso (LIMA, 2007).
O método utiliza a especificação dos casos de uso para identificar as
transações dos novos casos de uso e dos existentes no sistema atual. Um número
muito elevado de passos pode dificultar a etapa de entendimento e contagem das
transações. Para ocorrer um bom entendimento dos casos de uso, é importante que
eles estejam descritos em níveis de abstração mais próximos.
Os objetivos e interações de um caso de uso são desdobrados em objetivos e
interações mais refinados e mais granulados. Como os passos de um caso de uso
descrevem como um processo é realizado, o nome do caso de uso indica o porquê do
interesse do processo. Aqui, o relacionamento como/por que pode ser utilizado para
encontrar o nível de objetivo apropriado para ser usado em um passo. Para elevar o
nível de objetivo de um caso de uso, a pergunta sobre por que o ator está fazendo
aquele processo é feita, resultando numa resposta de um nível mais alto; em
contrapartida, a pergunta sobre como o processo está sendo feito resulta numa
resposta mais especializada do caso de uso (COCKBURN, 2005).
Cockburn (2005) ainda afirma que uma maneira para avaliar níveis de
objetivo é avaliar o comprimento do caso de uso, eliminando passos que incluem
detalhes de interface do usuário ou passos de ações num nível muito baixo.
A figura 2, proposta por Costa (2008), apresenta o alinhamento do nível de
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
40
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
objetivo de um caso de uso com as perguntas por quê? / como?, tendo o propósito de
elevar e especializar um caso de uso, respectivamente.
Figura 2: Alinhamento do Nível de Objetivo de um Caso de Uso
Fonte: adaptado de Costa (2008)
3.1.2 Contagem dos Casos de Uso Afetados
A manutenção precisa estar adequada à arquitetura do sistema atual, as
alterações devem funcionar corretamente com as funcionalidades existentes,
incluindo as inúmeras dependências que existem entre elas. O projeto de manutenção
está relacionado a novas funcionalidades, a mudanças das funções existentes ou até
mesmo em ambos. Uma nova funcionalidade é identificada, como a criação de novos
casos de uso a serem adicionados no sistema em uso. Uma mudança é identificada
como modificação nos casos de uso existentes no sistema atual (DIEV, 2006).
O MEMPCU permite que o gerente de projetos registre a contagem dos novos
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
41
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
casos de uso derivados da mudança, conforme visto na figura 3. Para um novo caso
de uso (NCU), o total de transações será identificado, descobrindo-se assim a sua
complexidade.
Figura 3: Planilha para Contagem dos Novos Casos de Uso
Fonte: elaborada pelo autor
Para um caso de uso atual afetado por uma modificação, denominado no
trabalho como Mudança em Caso de Uso (MCU), deve-se saber a quantidade de
transações existentes afetadas por uma mudança, tendo como base a documentação
dos casos de uso atuais do sistema. O Total de Transações Existentes (TEx) dos
casos de uso é fundamental para a aplicação do método. Na figura 4, é apresentada a
planilha para registrar o TEx.
Figura 4: Planilha para Registro do Total de Transações Existentes
Fonte: elaborada pelo autor
Segundo Freire e Belchior (2007), as novas transações identificadas podem
ser Transações Incluídas (TI), Transações Alteradas (TA) ou Transações Excluídas
(TE).
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
42
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
As transações reconhecidas devem ser somadas no Total de Transações
Identificadas (TTI).
Somente os passos modificados e identificados como transações devem ser
contados para efeito de estimativa de manutenção.
Apesar de o PCU permitir definir o peso para cada caso de uso de acordo com
três opções de classificação - transações, número de classes de objetos e classificação
simples da lógica de processamento -, de acordo com Karner (1993), o MEMPCU
apenas baseia-se na quantidade de transações identificadas.
É necessário haver um padrão na definição do que deve ser considerado como
uma transação para identificar as transações nos casos de uso e evitar distorções no
processo de estimativa. Anda et al. (2001, p.3) definem que uma transação é “um
evento que ocorre entre um ator e o sistema, sendo esse evento executado
completamente ou não”. Mas essa definição é um pouco vaga. Monteiro (2005) lista
alguns eventos que ocorrem nos passos dos fluxos básicos e alternativos de um caso
de uso e que são considerados como uma transação:
• Passos que contenham campos de entrada possuindo valores passíveis
de escolha originados de leitura de dados (listas de opções, combos e
grids), por exemplo: “A aplicação exibe os nomes dos assinantes de
uma companhia telefônica”;
• Passos que apresentem retorno de consultas com filtros preenchidos
por buscas em bancos de dados, por exemplo: “A aplicação exibe uma
lista contendo os nomes da rua de acordo com o CEP selecionado”;
• Passos que proporcionem validações complexas de negócio
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
43
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
(relacionamentos com outras entidades, verificações de existência,
etc.);
• Passos que contenham uma geração de relatório são considerados
como transação, e cada filtro das consultas apresentado no relatório
será considerado outra transação; assim, a quantidade de filtros será a
quantidade de transações;
• Passos nos quais é essencial a transformação de extensões entre
arquivos. Por exemplo: passar um arquivo HTML para XML;
• Passos do fluxo de eventos do caso de uso que apresentem
funcionalidades de consultas auxiliares como casos de uso à parte
(extensão); por exemplo, telas pop-up.
O MEMPCU considera como transações a relação de eventos apresentados
por Monteiro (2005). A figura 5 apresenta a planilha para contagem dos casos de uso
afetados pela mudança.
Figura 5: Planilha para Contagem dos Casos de Uso Afetados
Fonte: elaborada pelo autor
Os critérios estabelecidos por Karner (1993) para se considerar a
complexidade dos casos de uso foram adaptados e classificados de acordo com o
Total de Transações Identificadas (TTI), e são mostrados no quadro 2.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
44
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Quadro 2: Critérios para Definição dos Pesos dos Casos de Uso
Fonte: adaptado de Karner (1993); Diev (2006)
COMPLEXIDADE DEFINIÇÃO PESO
Simples Um caso de uso é simples se ele possui o TTI
>=1 e <=3
5
Médio Um caso de uso é médio se ele possui o TTI
>=4 e <=7
10
Complexo Um caso de uso é complexo se ele possui o
TTI >=8
15
Para Diev (2006), quando se trata de modificação em um caso de uso
existente, é preciso verificar o impacto da mudança com base nos casos de uso
afetados pela modificação. Esse impacto é denominado no método de Profundidade
de Mudança (PM), em que o total de novas transações identificadas e que podem ser
do tipo incluído, alterado ou excluído, seja dividido pelo total de transações
existentes no caso de uso, sendo calculado da seguinte forma:
PM = TTI / TEx, sendo que TEx é o total de transações do caso de uso antes
das modificações, e TTI é o total de transações incluídas, alteradas ou excluídas no
caso de uso.
A figura 6 mostra que a planilha para a contagem dos casos de uso afetados
também permite registrar a complexidade do caso de uso e o cálculo da profundidade
de mudança.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
45
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 6: Definição da Complexidade e Cálculo da Profundidade de Mudança
Fonte: elaborada pelo autor
Para se calcular o UUCW (Unadjusted Use Case Weight), é preciso:
• Calcular o tamanho da mudança envolvendo as novas funcionalidades
=> (Tamanho(NCU)) = 5x ∑(Caso de uso simples) + 10 x ∑(Caso de
uso médio) + 15 x ∑(Caso de uso complexo)
• Calcular o tamanho da mudança nos casos de uso existentes =>
(Tamanho(MCU)) =5x ∑(PM de Caso de uso simples) + 10 x ∑(PM
de Caso de uso médio) + 15 x ∑(PM de Caso de uso complexo)
• Somar os resultados obtidos => UUCW = NCU + MCU
3.1.3 Contagem dos Atores Afetados
Os atores afetados pela mudança também devem ser contabilizados. O
MEMPCU permite registrar os atores afetados pela mudança, conforme visto na
figura 7.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
46
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 7: Planilha para Contagem dos Atores Afetados
Fonte: elaborada pelo autor
Os critérios para determinar a complexidade dos atores foram adaptados de
Karner (1993) e são mostrados no quadro 3:
Quadro 3: Critérios para Definição dos Pesos dos Atores
Fonte: adaptado de Karner (1993)
COMPLEXIDADE DEFINIÇÃO PESO
Simples O ator afetado pela mudança representa um sistema
externo que é acessado por meio de uma API
(Application Programming Interface) ou outro
acesso direto.
1
Médio O ator afetado pela mudança representa um sistema
externo que interage por meio de um protocolo de
comunicação, por exemplo, TCP/IP, ou uma
interação humana por meio de um terminal de linha
de comando.
2
Complexo O ator afetado pela mudança representa um usuário
que interage com o sistema, por meio de uma
interface gráfica cliente-servidor ou WEB.
3
Conforme Andrade (2004), para se efetuar a contagem dos atores deve-se
multiplicar o total de atores de acordo com o tipo de complexidade pelo respectivo
peso e somar os produtos para obter o total de atores não ajustados ou UAW
(Unadjusted Actor Weight). O cálculo do peso dos atores é feito da seguinte forma:
UAW = 1 x ∑(Ator
simples
) + 2 x ∑(Ator
médio
) + 3 x ∑(Ator
complexo
)
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
47
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
3.1.4 Cálculo dos Pontos por Caso de Uso não Ajustados
O cálculo dos Pontos por Caso de Uso Não Ajustados, ou UUCP (Unadjusted
Use Case Points), é feito pelo somatório dos pesos dos atores afetados (UAW) e dos
pesos dos casos de uso afetados (UUCW), de acordo com a figura 8.
Figura 8: Cálculo do UUCP
Fonte: elaborado pelo autor
3.1.5 Cálculo do Fator de Complexidade Técnica
O modelo de casos de uso não leva em consideração a tecnologia utilizada
para desenvolver o sistema, e por isso o método PCU é independente da tecnologia a
ser aplicada. No entanto, quando há uma série de requisitos funcionais que afetam
tecnicamente a realização de um projeto, estes devem ser levados em consideração
para que as estimativas sejam coerentes com as condições técnicas da empresa.
De acordo com Andrade (2004), o método PCU considera 13 fatores de
complexidade técnica, mostrados na figura 9, que variam numa escala de pontuação
de 0 a 5, sendo que o valor 0 indica que o fator possui baixa complexidade e é pouco
crítico, considerado irrelevante para o projeto, e o valor 5 indica alta complexidade e
muito crítico, sendo essencial para o projeto.
Os 13 fatores técnicos também são considerados pelo método de manutenção
MEMPCU.
Após determinar o valor para cada um dos fatores deve-se multiplicar esse
valor pelo respectivo peso e depois somar os produtos. O somatório dos produtos é
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
48
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
denominado Tfactor, utilizado para calcular o Fator de Complexidade Técnica (TCF
- Technical Complexity Factor) por meio da seguinte fórmula:
TCF = 0,6 + (0,01 x Tfactor)
Figura 9: Fatores de Complexidade Técnica
Fonte: adaptada de Karner (1993) e Andrade (2004)
3.1.6 Cálculo do Fator Ambiental
De acordo com Karner (1993), o Fator Ambiental (EF - Environmental
Factor) foi adicionado ao cálculo do PCU visando estimar quão eficiente é o projeto.
São oito os fatores ambientais definidos no método PCU, e eles devem ser
computados com base na experiência das pessoas que trabalham no projeto
(CHIOSSI e GERMANO, 2005). O critério de pontuação é o mesmo utilizado nos
fatores de complexidade técnica, sendo que para os fatores ambientais o valor 0
indica pouca experiência e o valor 5 indica alta experiência para os fatores de F1 a
F4.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
49
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Para o fator F5 - Motivação –, o valor 0 significa que não há motivação para a
realização do projeto, e o valor 5 significa que a equipe possui alta motivação. Para o
valor F6 - Requisitos estáveis –, o valor 0 significa que os requisitos são altamente
instáveis e o valor 5 que são estáveis. Para o fator F7 – Trabalhadores em tempo
parcial –, o valor 0 significa poucos ou nenhum funcionário que não trabalhe em
período integral, e o valor 5 significa que todos os profissionais trabalham em
período parcial. Para o fator F8 - Dificuldade da linguagem de programação –, o
valor 0 indica uma linguagem de pouca complexidade ou que a equipe do projeto
tem domínio completo sobre ela (ANDRADE, 2004).
Os oito fatores ambientais também são considerados pelo método de
manutenção MEMPCU.
O valor do Fator Ambiental é calculado de forma semelhante ao TCF,
conforme visto na figura 10, determinando o valor para cada um dos fatores e
multiplicando esse valor pelo respectivo peso, depois somando os produtos. O
somatório dos produtos, denominado Efactor, é utilizado para calcular o Fator
Ambiental (EF) por meio da seguinte fórmula:
EF = 1,4 + (-0,03 x Efactor)
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
50
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 10: Fatores de Complexidade Ambiental
Fonte: adaptada de Karner (1993) e Andrade (2004)
3.1.7 Cálculo do Tamanho da Manutenção
Segundo Monteiro (2005), para calcular o tamanho do projeto de
manutenção, os fatores EF devem ser desmembrados do cálculo do tamanho, pois o
tamanho é grandeza física e não deve ter seu valor alterado em função de fatores
ambientais.
O valor do tamanho da manutenção (TMan) é obtido pela seguinte fórmula:
TMan = UUCP x TCF
3.1.8 Cálculo do Esforço da Manutenção
Segundo Monteiro (2005), o fator de produtividade está diretamente
vinculado com a estabilidade dos requisitos e experiência da equipe. Karner (1993)
apresentou originalmente a taxa de produtividade de 20 Homens-Hora (HH) por
ponto por caso de uso para projetos com requisitos estáveis e com equipe experiente,
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
51
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
e 28HH para cada ponto por caso de uso, para projetos com requisitos não estáveis e
equipe não experiente.
Anda et al. (2001) apresentam que o esforço pode variar de 15HH por caso
de uso para projetos com requisitos estáveis e com equipe experiente, e 30HH por
caso de uso para projetos com requisitos não estáveis e com equipe não experiente.
O cálculo da produtividade utilizada pelo MEMPCU apóia-se na proposta de
Freire e Belchior (2007), em que a produtividade varia de 15HH a 30HH.
O Fator de Produtividade (FProd) é calculado por meio da seguinte fórmula:
FProf = b – [(b – a) / 32,5] * EFactor
A variável “a” representa a produtividade mais alta (30HH), e a variável “b”
representa a produtividade mais baixa (15HH). O valor 32,5 corresponde à somatória
dos produtos dos fatores F1 a F6, multiplicados pelo maior fator equivalente a 5,
representando assim uma equipe experiente e com requisitos estáveis. O EFactor é
encontrado a partir da tabela de Fatores Ambientais (EF).
A figura 11 apresenta a planilha para o cálculo do tamanho e do esforço da
manutenção.
Figura 11: Planilha para Cálculo do Tamanho e Esforço da Manutenção
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
52
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Para projetos de manutenção, o método sugere que 40% do esforço sejam
destinados às etapas de Análise e Projeto, e 60% do esforço destinados às etapas de
Implementação e Testes.
É importante observar que o FProd a ser adotado deve ser calibrado de acordo
com cada organização, sempre atentando para os dados dos projetos já concluídos,
para ser possível definir a produtividade da equipe responsável pelo desenvolvimento
da manutenção do produto de software.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
53
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4 Pesquisa-Ação
Neste capítulo é apresentada a pesquisa de campo voltada para aplicar, avaliar
e aperfeiçoar o método MEMPCU desenvolvido para apoiar estimativas de projetos
de manutenção. A pesquisa de campo foi baseada na metodologia da pesquisa-ação.
4.1 Iniciação da Pesquisa-Ação
A iniciação da pesquisa-ação gerou os seguintes itens descritivos:
4.1.1 O Objetivo da Pesquisa
O objetivo desta pesquisa é verificar a aplicabilidade do método MEMPCU
em projetos de manutenção de software em empresa desenvolvedora e mantenedora
de software.
4.1.2 As Questões da Pesquisa
A principal questão de pesquisa do presente trabalho é “como aplicar uma
estimativa de tamanho e esforço apoiado pelo método MEMPCU em projetos de
manutenção de software?”.
As questões da pesquisa foram mencionadas no item 1.2 deste trabalho.
4.1.3 As Proposições do Estudo
A seguinte proposição foi formulada visando responder às questões da
pesquisa:
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
54
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
A aplicação do método MEMPCU em projetos de manutenção permite
melhor estimativa do tamanho e esforço para definir o custo e tempo das atividades
de desenvolvimento.
4.1.4 Seleção e Caracterização da Unidade de Análise: Unidade de
Negócio
Ao selecionar a unidade de negócio apropriada para esta pesquisa, foram
levados em consideração os critérios para a aplicação da proposta MEMPCU e as
características da organização.
A unidade de negócio escolhida foi a UNICORP – Informática Industrial,
empresa de software com mais de 15 anos de tradição na área de automação de
laboratórios. Seus sistemas atendem às empresas das áreas de saneamento básico,
siderurgia, energia elétrica, meio ambiente, têxtil e gás.
O principal produto da empresa é o sistema corporativo para automação e
gestão de laboratórios, chamado UniLIMS (Laboratory Information and
Management System - LIMS), sistema de Automação e Gestão de Laboratórios
Físico-químicos e Microbiológicos de Controle de Qualidade desenvolvido pela
própria organização, que faz também a manutenção do sistema. O sistema UniLIMS
foi desenvolvido com base em modelos utilizados em diversos países nos quais há o
controle de qualidade de água (ALMEIDA, 2000). O Modelo de Processos de
Laboratório de Análise (MPLA) é o modelo que identifica os processos laboratoriais,
conforme mostra a figura 12.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
55
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 12: Modelo de Processo de Laboratório de Análise
Fonte: Almeida (2000)
Por meio do UniLIMS, a empresa atende a empresas de diversas áreas, como
saneamento básico, siderurgia, energia elétrica, meio ambiente, têxtil e gás,
destacando-se grandes empresas, como Sabesp (Companhia de Saneamento Básico
do Estado de São Paulo), CST, Embasa e Sanepar.
A UNICORP participa com freqüência de licitações para fornecimento de
serviços, e conforme relatado pelo diretor da empresa, o tempo costuma ser muito
pequeno para se elaborar uma proposta, e geralmente não possui muitas informações
disponíveis além dos requisitos funcionais.
Em 2007, foi proposta para a empresa a utilização do método PCU para
estimar o esforço de novos sistemas, mas a maior demanda de trabalho da empresa é
com a manutenção das aplicações existentes, sejam elas corretiva, adaptativa ou, na
maior parte dos casos, a criação e modificação de funcionalidades.
Para procurar atender à necessidade da organização de possuir estimativas
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
56
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
mais realistas do tamanho da modificação, foi analisada a possibilidade de aplicar o
método MEMPCU para estimar o esforço necessário em projetos de manutenção. A
proposta pareceu inicialmente ser viável, pois se trata de método de simples
utilização com pequena quantidade de regras, que permite a obtenção de estimativas
de forma rápida já no início do projeto de manutenção.
4.1.5 Seleção e Caracterização da Unidade de Análise: Produto
O sistema UniLIMS permite a automatização da programação de coleta das
amostras, coleta automática dos resultados das análises e gerenciamento de todas as
atividades de um laboratório. O controle da amostra é feito por meio do uso de
código de barras, data e hora, instrumento, metodologia utilizada e o responsável
pelas análises. Outra função é viabilizar a análise da qualidade da matéria-prima e
dos produtos finais, além de permitir o rastreamento do processo.
Esse sistema possui diversos módulos, que podem ser adquiridos
opcionalmente pelos clientes, com exceção dos módulos UniMaster e UniLab, que
juntos possuem as funcionalidades básicas para a automação e gestão laboratorial. Os
módulos existentes atualmente são UniMaster, UniLab, UniPAC, UniMan, UniStock
e PocketLab.
Por ser um sistema de tamanho e complexidade elevados, e a empresa não
possuir atualmente as funcionalidades documentadas na especificação de casos de
uso, foi selecionado como unidade de análise o produto UniMaster para a realização
das estimativas. O sistema tem seus parâmetros ajustados para atender a diversos
tipos de laboratórios e empresas. Para esse estudo, o foco para a especificação dos
casos de uso foi o domínio de laboratórios de análises de qualidade da água.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
57
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
O módulo UniMaster oferece os recursos essenciais para a completa gestão de
todos os laboratórios da empresa, bem como os atendimentos às exigências dos
órgãos de regulamentação, incluindo a emissão de relatórios gerenciais. O controle
das amostras coletadas e suas respectivas análises para atendimento das exigências
dos órgãos de regulamentação são muito importantes para as empresas atenderem à
legislação vigente, evitando multas e prejuízos financeiros. Esse controle também é
utilizado para atender a exigências internas de qualidade.
O sistema permite a gestão efetiva dos laboratórios, acompanhando as
análises, as fórmulas e métodos adotados para obtenção dos resultados e um controle
estatístico de processo para verificar tendências de desvio e problemas nas análises.
Por meio do módulo UniMaster, também são identificados os postos de
trabalho e respectivos equipamentos usados em cada um deles, além das vidrarias e
produtos químicos utilizados pelos laboratórios.
O sistema também permite definir as diretrizes básicas para as coletas das
amostras, determinando as combinações dos frascos e métodos de preservação
utilizados para cada tipo de análise que será feita com a amostra, e designando o
pessoal operacional para efetuar a coleta.
Conforme descrito no capítulo 3, a proposta MEMPCU requer que o produto
de análise, no caso o módulo UniMaster, tenha as funcionalidades existentes
documentadas por meio do modelo de casos de uso.
A documentação resultou num total de 27 casos de uso. Para facilitar a
organização dos casos de uso e também a posterior manutenção desses diagramas, os
casos de uso foram agrupados em pacotes que reúnem características comuns.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
58
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Esse agrupamento em pacotes colabora na manutenção do sistema. Quando
solicitada modificação de uma funcionalidade, os casos de uso estarão categorizados,
e a procura será feita diretamente no pacote específico. Também ajuda quando for
exigida a inclusão de novas funcionalidades, pois permite que os envolvidos
verifiquem se a nova funcionalidade se enquadra em um dos pacotes existentes e
costuma afetar os demais casos de uso que o sistema possui.
Os atores identificados para o sistema foram: “Supervisor”, responsável pela
maior parte dos cadastros e definições que devem ser feitas para a correta utilização
do sistema; “Analista Biólogo” e “Analista Químico”, que utilizam algumas
funcionalidades do sistema, de acordo com a permissão de acesso de cada um deles.
Como efetuam muitas interações semelhantes com o sistema, mas também possuem
interações específicas a cada um deles, foi criado um ator base chamado “Analista” e
aplicada a generalização de atores; e “Cliente”, que normalmente acessa o sistema
para obtenção de relatórios e visualização de dados para conferir e fiscalizar o
andamento dos trabalhos feitos nos laboratórios.
A figura 13 mostra os pacotes do módulo UniMaster.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
59
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 13: Pacotes do Módulo UniMaster
Fonte: elaborada pelo autor
As figuras 14,15,16,17,18 e 19 mostram os diagramas de casos de uso de cada
um dos pacotes do UniMaster: Análise, Coleta, Laboratório, Regulamentações,
Supervisão e Pontos de Coleta, respectivamente.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
60
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 14: Diagrama de Casos de Uso - Pacote de Análise do UniMaster
Fonte: elaborada pelo autor
Figura 15: Diagrama de Casos de Uso - Pacote de Coleta do UniMaster
Fonte: Elaborado pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
61
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 16: Diagrama de Casos de Uso - Pacote de Laboratório do UniMaster
Fonte: elaborada pelo autor
Figura 17: Diagrama de Casos de Uso - Pacote de Regulamentações
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
62
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 18: Diagrama de Casos de Uso – Pacote Supervisão do UniMaster
Fonte: elaborada pelo autor
Figura 19: Diagrama de Casos de Uso – Pacote Pontos de Coleta do UniMaster
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
63
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4.2 Planejamento da Pesquisa-Ação
O planejamento da pesquisa-ação gerou as seguintes partes:
4.2.1 Definição da Equipe da Pesquisa
A equipe definida para a condução e execução desta pesquisa foi composta
por:
• 01 Pesquisador;
• 02 Pesquisadores Colaboradores;
• 01 Gerente de Projetos;
• 01 Diretor;
• 02 Desenvolvedores.
A participação do autor como pesquisador foi possível por causa da relação
do mesmo com a empresa. A atuação teve início no planejamento preliminar da
pesquisa até a finalização deste trabalho.
4.2.2 Comprometimento da Equipe
Com o objetivo de obter o comprometimento da equipe de pesquisa, foram
planejadas as seguintes atividades:
• Reunião de iniciação da pesquisa;
• Determinar os objetivos, a estratégia e metas da pesquisa;
• Apresentar o método de estimativa para a equipe;
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
64
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
• Atribuir as responsabilidades a cada um dos envolvidos;
• Definir o plano de comunicação para a divulgação dos resultados.
4.2.3 Planejamento dos Ciclos da Pesquisa-Ação
Atualmente, o método de estimativa utilizado para definir o tamanho e
esforço da manutenção baseia-se na experiência que a equipe obteve em projetos
anteriores. O propósito do MEMPCU é estimar de forma mais realista o projeto de
manutenção já na etapa de avaliação da solicitação de melhoria vinda do cliente, com
base nos casos de uso afetados.
Para a pesquisa, a estratégia adotada foi a de ciclos de pesquisa-ação visando
à aplicabilidade e adaptação do MEMPCU e à avaliação da proposta neste trabalho
(ASATO, 2007).
No planejamento, foram definidos dois ciclos da pesquisa-ação:
1- Ciclo de aplicação do método MEMPCU no projeto A de manutenção,
com foco na Análise da Aplicabilidade e Adaptação do método de estimativa;
2- Ciclo de aplicação do método MEMPCU no projeto B de manutenção,
com foco na Análise da Aplicabilidade e Adaptação do método de estimativa, com
base nos resultados obtidos no primeiro ciclo.
Cada ciclo de pesquisa-ação possui as seguintes etapas:
• Reunião de iniciação para estabelecer como o método MEMPCU será
executado durante a etapa de manutenção, definir o papel de cada
integrante durante a execução, relatar as atividades executadas e os
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
65
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
resultados obtidos, e revisar o método proposto;
• Seleção do projeto de manutenção considerado viável por parte da
equipe para ser estimado com o MEMPCU;
• Estimativa da manutenção com o método proposto e execução da
manutenção;
• Avaliação dos resultados obtidos após a execução do projeto de
manutenção estimado;
• Análise e Encerramento do Ciclo com sugestões para adaptação do
método para os próximos ciclos.
A figura 20 apresenta o cronograma com as atividades de cada ciclo da
pesquisa-ação.
Figura 20: Cronograma da Pesquisa-Ação
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
66
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4.3 Execução e Acompanhamento da Pesquisa-Ação
Primeiro Ciclo
O primeiro ciclo da pesquisa-ação para aplicação do MEMPCU em projetos
de manutenção de software foi realizado a partir da execução das seguintes etapas:
4.3.1 Reunião de Iniciação do Primeiro Ciclo
Nesta etapa foram apresentados, para a equipe, os objetivos, a estratégia e
metas da pesquisa, o método proposto para estimar o tamanho da manutenção de um
produto de software e as responsabilidades de cada um dos integrantes da equipe. O
procedimento de como se aplicar estimativa com MEMPCU foi explicado para os
envolvidos, incluindo o uso da planilha que acompanha o método, para registrar,
comparar e divulgar os resultados da pesquisa.
Também foi apresentado o propósito da pesquisa-ação, e acordado com a
equipe que a seleção e a execução dos projetos de manutenção teriam como condição
o tempo indispensável para atingir os objetivos da pesquisa.
4.3.2 Seleção do Projeto A de Manutenção
A organização possui uma planilha de novas funcionalidades e modificações,
chamadas de NF. Essas funcionalidades baseiam-se no documento de Descrição
Funcional de Melhorias utilizado pela organização, disponível no Anexo 2.
O projeto A de manutenção selecionado corresponde à nova funcionalidade
número 57 (NF-57), que se refere à Gestão do Laboratório.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
67
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4.3.3 Aplicação do Método MEMPCU no Projeto A
Com a participação do gerente de projetos, o documento de Descrição
Funcional de Melhorias referente à NF-57 foi analisado juntamente com os
documentos dos casos de uso afetados com a mudança. Na análise foram verificados
dois casos de uso envolvidos com a mudança, o “Manter Laboratórios”, pertencente
ao pacote “Laboratório”, e o “Inspecionar Recebimentos”, do pacote “Supervisão”. O
ator Supervisor também foi afetado com a mudança.
Seguem abaixo as etapas da aplicação do MEMPCU no projeto A. Os
conceitos e fórmulas do método foram explicados no capítulo 3.
1 - Alinhamento do Nível de Objetivo do Caso de Uso
Os casos de uso afetados foram alinhados de acordo com o seu nível de
objetivo para apoiar o entendimento e contagem das transações existentes. Após o
alinhamento, a quantidade de transações existentes (TEx) dos casos de uso afetados
pela mudança foi contabilizada, conforme mostra a figura 20.
Figura 21: Transações Existentes nos Casos de Uso Afetados no Projeto A
Fonte: elaborada pelo autor
Essa etapa contou com a participação dos pesquisadores colaboradores, que
ajudaram na especificação dos casos de uso do sistema atual e na identificação das
transações existentes.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
68
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
2- Contagem dos Casos de Uso Afetados
Para o caso de uso “Manter Laboratórios”, foram identificadas duas novas
transações incluídas (TI), e o caso de uso “Inspecionar Recebimentos” ficou com
quatro novas transações incluídas (TI).
Figura 22: Total de Transações Identificadas no Projeto A
Fonte: elaborada pelo autor
Pela quantidade de transações identificadas, a complexidade foi definida
como simples para o caso de uso “Manter Laboratórios”, pois o TTI foi igual a 2, e
como média para o caso de uso “Inspecionar Recebimentos”, pois o TTI foi igual a 4.
A definição da complexidade do caso de uso afetado seguiu os critérios de definição
dos pesos dos casos de uso.
A profundidade de mudança (PM) foi obtida a partir da divisão do TTI pela
TEx. A figura 23 mostra a complexidade e a profundidade de mudança para os dois
casos de uso afetados.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
69
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 23: Complexidade e Profundidade de Mudança no Projeto A
Fonte: elaborada pelo autor
A NF-57 não resultou em novos casos de uso, portanto, o NCU ficou com o
valor zero e o resultado do MCU foi obtido da seguinte forma:
MCU = 5 x (0,50) + 10 x (1,33) + 15 x (0)
A figura 24 apresenta o resultado do UUCW.
Figura 24: Cálculo do UUCW no Projeto A
Fonte: elaborada pelo autor
3- Contagem dos Atores Afetados
O único ator afetado pela mudança nos casos de uso foi o “Supervisor”.
Como o ator representa um usuário que interage com o sistema é considerado
complexo. Conforme explicado, o peso de um ator complexo é 3. O resultado do
UAW foi obtido da seguinte forma:
UAW = 1 x (0) + 2 x (0) + 3 x (1)
A figura 25 mostra os atores afetados pelas mudanças nos casos de uso.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
70
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 25: Atores Afetados pelas Mudanças no Projeto A
Fonte: elaborada pelo autor
4 - Cálculo dos Pontos por Caso de Uso não Ajustados
O cálculo do UUCP foi feito a partir do somatório do UAW e UUCW,
conforme apresenta a figura 26.
Figura 26: Cálculo do UUCP no Projeto A
Fonte: elaborada pelo autor
5- Cálculo do Fator de Complexidade Técnica
O próximo passo foi obter o TCF. O gerente de projetos respondeu ao
questionário para identificar o nível de influência dos fatores de complexidade
técnica disponível no Anexo I.
A figura 27 apresenta as respostas do gerente de projetos na coluna Fator e o
cálculo do TCF para o projeto.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
71
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 27: Cálculo do TCF para o Projeto A
Fonte: elaborada pelo autor
6- Cálculo do Fator Ambiental
No mesmo questionário disponível no Anexo I, o gerente de projetos
respondeu às questões referentes aos fatores de complexidade ambiental para o valor
de EF ser obtido.
A figura 28 apresenta as respostas do gerente de projetos na coluna Fator e o
cálculo do EF para o projeto.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
72
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 28: Cálculo do EF para o Projeto A
Fonte: elaborada pelo autor
7- Cálculo do Tamanho da Manutenção
Com base nos resultados do UUCP e TCF, o valor do tamanho da
manutenção (TMan) para o projeto A foi obtido conforme mostrado na figura 29.
Figura 29: Cálculo do Tamanho da Manutenção para o Projeto A
Fonte: elaborada pelo autor
8- Cálculo do Esforço da Manutenção
O esforço estimado para executar o projeto de manutenção selecionado para
aplicação do MEMPCU foi obtido a partir dos resultados do TMan, FProd e EF.
Com base nos valores atribuídos para os fatores de complexidade ambiental e no
cálculo de produtividade proposto para este trabalho, o FProd resultou em 19HH. A
figura 30 mostra o cálculo do esforço para o projeto A de manutenção escolhido.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
73
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 30: Cálculo do Esforço da Manutenção para o Projeto A
Fonte: elaborada pelo autor
O esforço obtido em HH foi arredondado para 249 horas, sendo 99 horas
destinadas às etapas de Análise e Projeto e 150 horas para as etapas de
Implementação e Testes.
4.3.4 Avaliação dos Resultados do Projeto A
A avaliação dos resultados do Projeto A foi feita pelos participantes da
pesquisa, resultando as seguintes observações:
• O esforço real para a execução do projeto foi de 224 horas, sendo 34
horas utilizadas pelo gerente de projetos, nas etapas de Análise e
Projeto, e 189 horas utilizadas pelos dois desenvolvedores nas etapas
de Desenvolvimento e Testes. A diferença para a estimativa obtida
com a aplicação do método MEMPCU foi de 25 horas;
• Os fatores de complexidade ambiental podem ter influenciado o valor
da estimativa, pois o valor EF é utilizado para calcular o FProd;
• A estimativa de 40% destinada às etapas de Análise e Projeto proposto
pelo método foi considerada alta para projetos de Manutenção;
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
74
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
• A estimativa inicial não foi ajustada durante a execução do projeto.
4.3.5 Análise e Encerramento do Primeiro Ciclo
Os resultados obtidos foram analisados e os seguintes pontos observados em
relação à execução e acompanhamento do primeiro ciclo:
• Houve o envolvimento de todos os integrantes da equipe que fizeram
parte da pesquisa, propiciando aprendizado para todos, desde o autor
do método até as pessoas que executaram as atividades de manutenção
previstas no ciclo planejado anteriormente;
• O gerente de projetos acompanhou a execução do ciclo desde o seu
início, registrando os resultados de cada etapa;
• O pesquisador participou parcialmente da execução e
acompanhamento do ciclo, pois o mesmo não é profissional fixo da
unidade de negócio;
• As etapas previstas no planejamento do ciclo foram mantidas. Durante
o acompanhamento, os participantes da pesquisa não observaram
modificações relevantes que devessem ser efetuadas durante a
execução do ciclo;
• Os resultados obtidos foram analisados e comparados pelo
pesquisador e pelo gerente de projetos;
• A utilização de uma planilha eletrônica formatada facilitou a aplicação
do método e a avaliação dos resultados;
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
75
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
• A aplicação do MEMPCU para estimativas de tamanho da
manutenção de um produto de software foi avaliada de modo geral
pelos participantes como um passo inicial de muita importância para
que os projetos apresentem estimativas mais realistas no início da
etapa de manutenção;
• O diretor da unidade de negócio selecionada para a pesquisa aprovou
a aplicabilidade do método proposto e a forma de como a pesquisa foi
feita;
• A etapa de alinhamento do nível de objetivo do caso de uso foi
considerada morosa, de forma geral, pela equipe de pesquisa, que
prefere contabilizar as transações do documento de especificação, sem
a necessidade dessa etapa;
• Os conceitos e forma de aplicação do MEMPCU precisam ser
reforçados para a equipe estimar as etapas do método da forma mais
correta possível;
• A análise dos resultados obtidos estimulou a equipe de pesquisa a
tomar algumas medidas visando ao refinamento do método proposto
para a aplicação e execução do próximo ciclo da pesquisa-ação. As
medidas são citadas no início da execução do segundo ciclo;
• Tendo em vista os pontos observados acima, o primeiro ciclo da
pesquisa foi considerado concluído.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
76
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4.4 Execução e Acompanhamento da Pesquisa-Ação
Segundo Ciclo
Para o segundo ciclo da pesquisa-ação, algumas considerações foram feitas
com base na experiência e conhecimento adquiridos na execução do primeiro ciclo,
com o intuito de aprimorar o método proposto. As seguintes medidas foram tomadas
pela equipe:
• Um novo treinamento do MEMPCU para os envolvidos foi agendado
para a reunião de iniciação do próximo ciclo da pesquisa;
• Os mesmos participantes do primeiro ciclo foram mantidos para o
segundo ciclo;
• Mesmo não havendo aceitação muito intensa em relação à primeira
etapa do MEMPCU, sendo essa correspondente ao alinhamento do
nível de objetivo do caso de uso, a mesma foi mantida;
• Os outros pontos do método e da própria pesquisa-ação não citados
acima foram mantidos.
Baseando-se nas considerações oriundas do ciclo anterior, o segundo ciclo
objetivou nova aplicação da proposta MEMPCU em projetos de manutenção de
software, feito por meio da execução das etapas a seguir.
4.4.1 Reunião de Iniciação do Segundo Ciclo
Nessa etapa foram reforçados os conceitos e etapas da aplicação do
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
77
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
MEMPCU para a equipe, sendo também conscientizada sobre a importância das
estimativas em projetos de produto de software, inclusive na etapa de manutenção.
Os resultados e análise do primeiro ciclo da pesquisa-ação foram
apresentados para a equipe de pesquisa, para todos entenderem melhor os números
estimados com a aplicação do método versus os resultados obtidos na realidade.
4.4.2 Seleção do Projeto B de Manutenção
O segundo projeto de manutenção selecionado foi a nova funcionalidade
número 58 (NF-58), que também se refere à Gestão do Laboratório. Como
mencionado, a NF é descrita no documento utilizado pela unidade de negócio
denominado Descrição Funcional de Melhorias, encontrado no Anexo 2.
4.4.3 Aplicação do Método MEMPCU no Projeto B
Também com a participação do gerente de projetos, novo documento de
Descrição Funcional de Melhorias foi analisado, agora referente à NF-58. Os
documentos dos casos de uso afetados com a mudança foram estudados. Na análise
verificaram-se dois casos de uso envolvidos com a mudança, o “Manter Análises”,
pertencente ao pacote “Análise”, e o “Gerar Relatórios”, do pacote “Supervisão”. Os
atores “Supervisor”, “Analista Biológico”, “Analista Químico” e “Cliente” foram
afetados com a mudança.
Para o projeto B, algumas considerações foram feitas para a aplicação do
método, de acordo com os resultados obtidos e avaliados no projeto A.
• Os fatores de complexidade ambiental foram revistos com os
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
78
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
membros da unidade de negócio;
• O método proposto passou a destinar 30% do esforço para as etapas
de Análise e Projeto, enquanto as etapas de Implementação e Testes
ficaram com o restante.
Seguem abaixo as etapas da aplicação do MEMPCU no projeto B. Os
conceitos e fórmulas do método foram explicados no capítulo 3.
1 - Alinhamento do Nível de Objetivo do Caso de Uso
Para o projeto B, utilizou-se como base o mesmo alinhamento de nível de
objetivo dos casos de uso realizado no projeto A. A quantidade de transações
existentes (TEx) dos casos de uso afetados pela mudança no projeto B foi
contabilizada, conforme mostra a figura 31.
Figura 31: Transações Existentes nos Casos de Uso Afetados no Projeto B
Fonte: elaborada pelo autor
Essa etapa teve a participação dos pesquisadores colaboradores, que ajudaram
na especificação dos casos de uso do sistema atual e na identificação das transações
existentes.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
79
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
2- Contagem dos Casos de Uso Afetados
Para o caso de uso “Manter Análises”, identificou-se nova transação incluída
(TI), e o caso de uso “Gerar Relatórios” ficou com duas novas transações alteradas
(TA), conforme apresentado na figura 32.
Figura 32: Total de Transações Identificadas no Projeto B
Fonte: elaborada pelo autor
Pela quantidade de transações identificadas, definiu-se a complexidade como
simples para o caso de uso “Manter Análises”, pois o TTI foi igual a 1, e como
simples também para o caso de uso “Gerar Relatórios”, pois o TTI foi igual a 2. A
definição da complexidade do caso de uso afetado seguiu os critérios de definição
dos pesos dos casos de uso.
A profundidade de mudança (PM) foi obtida a partir da divisão do TTI pela
TEx. A figura 33 mostra a complexidade e a profundidade de mudança para os dois
casos de uso afetados.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
80
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Figura 33: Complexidade e Profundidade de Mudança no Projeto B
Fonte: elaborada pelo autor
A NF-58 não resultou em novos casos de uso, portanto o NCU ficou com o
valor zero e o resultado do MCU foi obtido da seguinte forma:
MCU = 5 x (0,65) + 10 x (0) + 15 x (0)
A figura 34 apresenta o resultado do UUCW.
Figura 34: Cálculo do UUCW no Projeto B
Fonte: elaborada pelo autor
3- Contagem dos Atores Afetados
Os atores afetados pela mudança nos casos de uso são apresentados na figura
35. Todos os atores representam um usuário que interage com o sistema, sendo
considerados complexos. Conforme explicado, o peso de um ator complexo é 3. O
resultado do UAW foi obtido da seguinte forma:
UAW = 1 x (0) + 2 x (0) + 3 x (4)
Figura 35: Atores Afetados pela Mudança no Projeto B
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
81
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
4- Cálculo dos Pontos por Caso de Uso não Ajustados
Calculou-se o UUCP a partir do somatório do UAW e UUCW, conforme
apresenta a figura 36.
Figura 36: Cálculo do UUCP no Projeto B
Fonte: elaborada pelo autor
5- Cálculo do Fator de Complexidade Técnica
O próximo passo foi obter o TCF. O gerente de projetos respondeu ao
questionário para identificar o nível de influência dos fatores de complexidade
técnica disponível no Anexo I.
A figura 37 apresenta as respostas do gerente de projetos na coluna Fator e o
cálculo do TCF para o projeto.
Figura 37: Cálculo do TCF para o Projeto B
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
82
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
6- Cálculo do Fator de Complexidade Ambiental
No mesmo questionário disponível no Anexo I, o gerente de projetos
respondeu às questões referentes aos fatores de complexidade ambiental para o valor
de EF ser obtido. Vale ressaltar que algumas mudanças foram consideradas
necessárias em alguns fatores ambientais em relação ao ciclo anterior.
A figura 38 apresenta as respostas do gerente de projetos na coluna Fator e o
cálculo do EF para o projeto, inclusive com fatores respondidos diferentemente dos
fatores do projeto A.
Figura 38: Cálculo do EF para o Projeto B
Fonte: elaborada pelo autor
7- Cálculo do Tamanho da Manutenção
Com base nos resultados do UUCP e TCF, o valor do tamanho da
manutenção (TMan) para o projeto B foi obtido, conforme mostrado na figura 39.
TMan (UUCP x CF)
16,17
Figura 39: Cálculo do Tamanho da Manutenção para o Projeto B
Fonte: elaborada pelo autor
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
83
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
8- Cálculo do Esforço da Manutenção
O esforço estimado para executar o projeto de manutenção selecionado para
aplicação do MEMPCU foi obtido a partir dos resultados do TMan, FProd e EF.
Com base nos valores atribuídos para os fatores de complexidade ambiental e no
cálculo de produtividade proposto para este trabalho, o FProd resultou em 17HH. A
figura 40 mostra o cálculo do esforço para o projeto B de manutenção escolhido.
Figura 40: Cálculo do Esforço da Manutenção para o Projeto B
Fonte: elaborada pelo autor
O valor esforço obtido em HH foi arredondado para 159 horas, sendo 48
horas destinadas para as etapas de Análise e Projeto, e 111 horas para as etapas de
Implementação e Testes. Conforme mencionado no início do segundo ciclo, foram
considerados 30% do esforço destinado às etapas de Análise e Projeto, e 70% às
etapas de Implementação e Testes.
4.4.4 Avaliação dos Resultados do Projeto B
A avaliação dos resultados obtidos no projeto B foi feita pelos participantes
da pesquisa. A avaliação permitiu as seguintes observações:
• O esforço real para a execução do projeto foi de 139 horas, sendo 46
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
84
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
horas utilizadas pelo gerente de projetos, nas etapas de Análise e
Projeto, e 93 horas utilizadas pelos dois desenvolvedores nas etapas de
Desenvolvimento e Testes. A diferença para a estimativa obtida com a
aplicação do método MEMPCU foi de 20 horas;
• As mudanças no EF, e posteriormente no FProd, diminuíram a
diferença entre o estimado e o realizado, comparado ao projeto A
executado no primeiro ciclo;
• A redução para 30% de estimativa de esforço usado nas etapas de
Análise e Projeto também se aproximou dos números derivados do
realizado;
• A estimativa inicial também não foi ajustada durante a execução do
projeto no segundo ciclo.
4.4.5 Análise e Encerramento do Segundo Ciclo
Os resultados obtidos foram analisados e os seguintes pontos observados em
relação à execução e acompanhamento do segundo ciclo:
• Houve novamente o envolvimento de todos os integrantes da equipe
de pesquisa, aumentando ainda mais o aprendizado, principalmente do
gerente de projetos, que fez a estimativa e acompanhava os resultados
posteriormente. Esse novo ciclo permitiu maior maturidade para os
envolvidos;
• O gerente de projetos acompanhou novamente a execução do ciclo
desde o seu início, registrando os resultados de cada etapa;
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
85
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
• O pesquisador continuou participando parcialmente da execução e
acompanhamento do ciclo, pois não se concentra na unidade de
negócio diariamente;
• As etapas previstas no planejamento do segundo ciclo também foram
mantidas;
• Os resultados obtidos foram analisados e comparados pelo
pesquisador e pelo gerente de projetos;
• A utilização de uma planilha eletrônica formatada facilitou a aplicação
do método e a avaliação dos resultados;
• A etapa de alinhamento do nível de objetivo do caso de uso continuou
sendo considerada morosa pelos participantes da pesquisa;
• A equipe considerou de extrema importância que o método de
estimativa seja aplicado em novos projetos de manutenção, e que os
resultados sejam analisados, visando aos ajustes necessários e
conseqüentemente, ao refinamento do método;
• O diretor aprovou o MEMPCU como método de estimativa a ser
utilizado na etapa de manutenção do processo de desenvolvimento da
organização. Mesmo com a avaliação positiva em relação ao método,
o mesmo somente poderá ser liberado para uso por todos os
profissionais da área de desenvolvimento após o seu aprimoramento e
capacitação dos funcionários da unidade de negócio.
• A análise dos resultados gerados possibilitou à equipe de pesquisa
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
86
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
tomar algumas decisões objetivando o aprimoramento do método
proposto. As decisões são descritas a seguir:
o Planejar, executar, acompanhar e avaliar novos projetos de
manutenção, que foram estimados com o MEMPCU;
o Propiciar o treinamento referente ao método aos outros
integrantes da equipe de desenvolvimento e manutenção,
visando também conscientizar os membros da unidade de
negócio sobre a importância do uso de estimativas em projetos
de software;
o Manter base de dados com o histórico dos projetos estimados
com o método, registrando inclusive os resultados obtidos a
partir do executado. Ao manter um histórico do esforço
utilizado para as atividades de manutenção em horas, pode-se
identificar um fator de produtividade médio, permitindo
produzir estimativas de esforço cada vez mais confiáveis por
meio do MEMPCU;
o Rever com freqüência os fatores de complexidade técnica e
ambiental, pois foi constatada a influência destes na geração
da estimativa de tamanho e esforço da manutenção;
o Manter o uso da planilha eletrônica adotada nos dois ciclos da
pesquisa;
o Controlar as versões dos documentos de especificação dos
casos de uso, pois sofrerão alterações ao longo do ciclo de vida
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
87
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
do produto de software;
o Criar uma matriz de rastreabilidade entre os casos de uso,
possibilitando aumento na eficácia na etapa de contabilização
dos casos de uso afetados pelas mudanças;
o Manter a etapa de alinhamento do nível do objetivo dos casos
de uso, mas somente para alguns projetos de manutenção,
principalmente aqueles que afetam casos de uso ainda não
alinhados. Para projetos de manutenção que atingem casos de
uso já alinhados, essa etapa não será considerada obrigatória
na aplicação do MEMPCU.
• Tendo em vista os pontos observados acima, o segundo ciclo da
pesquisa foi considerado concluído.
4.5 Encerramento da Pesquisa-Ação
Após o planejamento, execução, acompanhamento e avaliação dos resultados
dos dois ciclos, e aprimoramento do método proposto para este trabalho, a pesquisa-
ação foi considerada encerrada.
A proposição do início da pesquisa-ação, que o método MEMPCU aplicado
em projetos de manutenção permite melhor estimativa do tamanho e esforço para
definir o custo e tempo das atividades de desenvolvimento, foi confirmada durante a
pesquisa.
A execução da pesquisa utilizou três dias adicionais em relação ao
cronograma apresentado no planejamento da pesquisa.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
88
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
A metodologia de pesquisa escolhida neste trabalho, com o objetivo de
aplicar, avaliar e aperfeiçoar o método proposto, foi aprovado pela equipe de
pesquisa, pois gerou conhecimento para todos os envolvidos. Os participantes
aprenderam ainda mais sobre o MEMPCU com as etapas propostas na pesquisa-ação
adotada neste trabalho.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
89
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
5 – Conclusão
Este trabalho objetivou o desenvolvimento de um mecanismo de estimativa
para medir o tamanho de projetos de manutenção de produtos de software. Para
atingir o objetivo, elaborou-se um método de estimativa com base em Pontos por
Caso de Uso capaz de mensurar o tamanho e esforço de um projeto de manutenção a
partir da solicitação de mudança.
O trabalho aplicou a metodologia da pesquisa-ação visando à aplicabilidade e
refinamento do método. De acordo com os resultados, o método foi avaliado como
mecanismo de medição aplicável e eficaz para projetos de manutenção, podendo ser
aplicado nos processos de manutenção de outras organizações de software.
5.1 - Discussão sobre as Questões de Pesquisa
Os seguintes resultados foram observados para as questões de pesquisa
formuladas:
Questão 1: “O método PCU é aplicável em projetos de manutenção de
software?”
Resultado: Os resultados da pesquisa-ação mostraram a aplicabilidade do
método em estimativas de tamanho e esforço de projetos de manutenção. Os dois
ciclos da pesquisa, que foram executados e acompanhados pela equipe, apresentaram
uma diferença de horas relativamente pequena entre o valor estimado e o valor
obtido a partir do realizado. O método recebeu ajustes para que fosse aplicado de
acordo com os objetivos de negócio da organização.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
90
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Questão 2: “O tamanho dos casos de uso na aplicação existente pode
influenciar as estimativas de manutenção?”
Resultado: Sim. Foi verificada a importância de se conhecer o tamanho atual
dos casos de uso atingidos com a solicitação de uma manutenção, inclusive para
calcular a profundidade da mudança, que requer o número de transações existentes
dos casos de uso do sistema alvo de manutenção.
Questão 3: “Como adaptar e aplicar o método PCU em uma pequena empresa
mantenedora de software?”
Resultado: A partir da proposta original, o PCU pode ser adaptado e também
aplicado para estimativa de projetos de manutenção, considerando as novas
transações identificadas nos casos de uso existentes. O método de estimativa de
manutenção com base em pontos por caso de uso, isto é, o MEMPCU, foi uma
adaptação de outras propostas de estimativas de manutenção existentes, e que se
basearam no próprio PCU. A empresa de software precisa ter as funcionalidades
especificadas como requisitos e documentadas no formato de casos de uso. Uma
matriz de rastreabilidade entre as funcionalidades ou entre os casos de uso é
recomendada como apoio para localizar todos os casos de uso afetados pelo projeto
de manutenção.
5.2 Discussão sobre a Metodologia de Pesquisa Utilizada
Os principais pontos observados em relação à metodologia de pesquisa
adotada neste trabalho foram:
• O planejamento e envolvimento dos integrantes da equipe de pesquisa
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
91
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
foram extremamente importantes para as atividades;
• O envolvimento dos participantes com a pesquisa diminuiu a
resistência geralmente encontrada em atividades de mudanças em
processos organizacionais;
• Os participantes adaptaram o processo de acordo com as necessidades
da empresa;
• A metodologia de pesquisa possibilitou a geração do conhecimento
em ação, tanto para o pesquisador como para os demais envolvidos;
• Nesta pesquisa em particular, o método proposto antes dos ciclos não
sofreu mudanças significativas durante a pesquisa-ação, mas permitiu
que todas as pessoas vivenciassem e conhecessem melhor o processo;
• A metodologia também permitiu desenvolver uma análise crítica
sobre ela mesma por parte de todos os integrantes da pesquisa.
5.3 Limitações da Pesquisa
Alguns critérios foram considerados para a pesquisa. Foram escolhidos
apenas uma unidade de negócio e um produto de software como alvo da pesquisa.
Existe a intenção de expandir a aplicação do método na manutenção de outros
produtos de software da mesma unidade de negócio.
A pesquisa aplicou o método somente em dois projetos de manutenção,
ambos com mais de 100 horas de desenvolvimento. Para os projetos selecionados, os
resultados foram considerados satisfatórios pelos membros da equipe de pesquisa. De
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
92
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
qualquer forma, é importante aplicar o MEMPCU em novos projetos, para o
histórico confirmar a eficácia do método proposto.
Outro ponto é que a pesquisa utilizou o método de estimativa somente em
projetos cujas funcionalidades do sistema existente estavam especificadas no modelo
de casos de uso. Caso os requisitos estejam documentados de outra forma, deve-se
mapeá-los para casos de uso.
Os participantes envolvidos com a pesquisa mostraram interesse em continuar
aplicando o método em novos projetos de manutenção e adotá-lo como atividade
padrão da etapa de manutenção do processo de software seguido pela organização.
5.4 Pesquisas Futuras
O método proposto neste trabalho considerou o número de transações para
definir o peso de um caso de uso afetado pela mudança.
Karner (1993), em sua proposta original, ressalta que o PCU utiliza outras
formas de classificação para determinar o peso de um caso de uso, entre elas a
quantidade de classes de objetos.
Existe a possibilidade de uma pesquisa futura para adaptar o método
proposto, dando ênfase na quantidade de classes de objetos, isto é, nas classes de
negócio derivadas dos casos de uso, ao invés de se basear somente na forma de
contabilização das transações identificadas, adotada no trabalho em questão.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
93
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Referências
ALMEIDA, J.B. Automação dos Processos de Controle de Qualidade da Água e
Esgoto de Laboratórios de Controle Sanitário. 2000. 162f. Tese (Doutorado em
Sistemas de Automação). EPUSP - Escola Politécnica da Universidade de São Paulo,
São Paulo, 2000.
ANDA, B. et al. Estimating Software Development Effort Based on Use Cases -
Experiences from Industry. Universidade de Oslo: 2001. Disponível em <
http://www.bfpug.com.br/Artigos/UCP/Anda-
Estimating_SW_Dev_Effort_Based_on_ Use_Cases.pdf>. Acesso em 14.abr.2008.
ANDRADE, E.L.P. Pontos de Casos de Uso e Pontos de Função na Gestão de
Estimativa de Tamanho de Projetos de Software Orientados a Objetos. 2004.
143f. Dissertação (Mestrado em Gestão do Conhecimento e Tecnologia da
Informação) – Universidade Católica de Brasília, Brasília. Disponível em <http://
www.bfpug.com.br/Artigos/UCP/Tese%20Edmeia.zip>. Acesso em 09.mai.2008.
ASATO, R.Y. Alinhamento entre a Estratégia de Negócios e a Melhoria de
Processos de Software: um roteiro de implementação. 2007. 138f. Dissertação
(Mestrado em Engenharia de Produção) – Universidade Paulista, São Paulo, SP,
2007.
BANERJEE, G. Use Case Estimation Framework. In: Annual IPML Conference.
Birlasoft Limited. Noida, India: 2004. Disponível em <http:// www.qaiasia.com/
Conferences/presentations/gautam_birlasoft_pre.pdf>. Acesso em 17.mai.2008.
BARTIE, A. Garantia da Qualidade de Software. Rio de Janeiro: Campus, 2002.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Rio de
Janeiro: Campus, 2007.
CARROLL, E. Estimating Software Via Use Cases. [s.l]: 2005. Disponível em <
http://www.ironspeed.com/articles/Estimating%20Software%20via%20Use%20Case
s/article.aspx>. Acesso em 25.mai.2008.
CHIOSSI, T.C. dos S.; GERMANO, F.S.R. Gerenciamento de Projetos de
Software. Campinas: Unicamp, 2005.
COCKBURN, A. Escrevendo Casos de Uso Eficazes. Porto Alegre: Bookman,
2005.
COSTA, I. Métricas de Estimativa de Software: Qualidade de Casos de Uso.
Notas de Aula, 2008.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
94
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
DAMODARAN, M.; WASHINGTON, A.N.E. Estimation Using Use Case Points.
[s.l]: 2004. Disponível em <http://www.bfpug.com.br/Artigos/UCP/Damodaran-
Estimation_Using_Use_Case_Points.pdf>. Acesso em 17.mar.2008.
DIEV, S. Software Estimation in the Maintenance Context. In: ACM SIGSOFT
Software Engineering Notes. v.31,n.2 Mar, 2006.
DRACH, M.D. Aplicabilidade de Métricas por Pontos de Função em Sistemas
Baseados em Web. São Paulo: UNICAMP - Universidade de Campinas, 2005.
Disponível em <http://libdigi.unicamp.br/document/?code=vtls000359854>. Acesso
em 10 mar. 2008.
FERNANDES, A.A.; TEIXEIRA, D.S. Fábrica de Software: implantação e gestão
de operações. São Paulo: Atlas, 2004.
FREIRE, Y.M.A; BELCHIOR, A.D. Pontos de Caso de Uso Técnicos para
Manutenção de Software. In: XXI Simpósio Brasileiro de Engenharia de Software.
Fortaleza: 2007.
HAZAN, C.; STAA, A. Análise e Melhoria de um Processo de Estimativas de
Tamanho de Projetos de Sofware. In: VI Simpósio Internacional de Melhoria de
Processos de Software. São Paulo: 2004.
IEEE. The Institute of Electrical and Electronics Engineers Computer Society. Guide
to the Software Engineering Body of Knowledge. [s.l]: [s.n], 2004.
IFPUG. The International Function Point Users Group. Manual de Práticas de
Contagem de Pontos de Função. Versão 4.2.1. [s.l]: [s.n], 2005.
KARNER, K. Resource Estimation for Objectory Projects. Kista: [s.n], 1993.
Disponível em <http://www.bfpug.com.br/Artigos/UCP/Karner%20-
%20Resource%20 Estimation%20for%20Objectory%20Projects.doc>. Acessado em:
10.abr.2008.
KOSCIANSKI, A.; SOARES, M.S. Qualidade de Software. São Paulo: Novatec,
2006.
LIMA, A.S. UML 2.0: do requisito à solução. São Paulo: Érica, 2007.
MACHADO, C.A.F. Definindo Processos do Ciclo de Vida de Software usando a
Norma ISO/IEC 12207 e suas Ementas 1 e 2. Lavras: UFLA/FAEPE, 2006.
MONTEIRO, T.C. Pontos de Caso de Uso Técnicos (TUCP): Uma Extensão da
UCP. 2005. 213f. Dissertação (Mestrado em Informática Aplicada) - Universidade
de Fortaleza, Fortaleza. Disponível em <https://uol01.unifor.br/oul/ObraBdtd
SiteTrazer.do?method=trazer&obraCodigo=69800&programaCodigo=83>.
Acessado em: 15.mar.2008.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
95
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
PADUELLI, M.M. Manutenção de Software: problemas típicos e diretrizes para
uma disciplina específica. 2007. 144f. Dissertação (Mestrado em Ciências de
Computação e Matemática Computacional) – Instituto de Ciências Matemáticas e de
Computação da Universidade de São Paulo, São Carlos, SP, 2007. Disponível em <
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-21062007-154606/>. Acesso
em 04.mai.2008.
PAULA FILHO, W.P. Engenharia de Software: Fundamentos, Métodos e
Padrões. 2. ed. Rio de Janeiro: LTC, 2005.
PETERS, J.F.; PEDRYCZ, W. Engenharia de Software: teoria e prática. Rio de
Janeiro: Campus, 2001.
PFLEEGER, S.L. Engenharia de Software: teoria e prática. 2.ed. São Paulo:
Prentice-Hall, 2004.
PRESSMAN, R.S. Engenharia de Software. 6.ed. Rio de Janeiro: McGraw-Hill,
2006.
SOMMERVILLE, I. Engenharia de Software. 8.ed. São Paulo: Pearson Addison
Wesley, 2007.
THIOLLENT, M. Metodologia da pesquisa-ação. 13. ed. São Paulo: Cortês, 2004.
TONSIG, S.L. Engenharia de Software: análise e projeto de sistemas. São Paulo:
Futura, 2003.
VAVASSORI, F.B. Metodologia para o Gerenciamento Distribuído de Projetos e
Métrica de Software. 2002. 211f. Tese (Doutorado em Engenharia de Produção) –
Universidade Federal de Santa Catarina, Florianópolis. Disponível em <
http://teses.eps.ufsc.br/defesa/pdf/4193.pdf>. Acesso em 07.abr.2008.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
96
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Anexo I
Questionário de Fatores de Complexidade Técnica e
de Fatores Ambientais
O questionário a seguir identifica o nível de influência dos fatores de complexidade técnica,
de acordo com IFPUG (2003) e KARNER (1993), e ambiental, propostos por KARNER (1993) para
desenvolvimento de projetos de software OO.
Questionário para identificar o nível de influência dos fatores de
complexidade técnica e ambiental da métrica UCP
Instruções:
Assinale o grau de influência de cada fator abaixo do projeto ou sistema de acordo com a
escala de 0 a 5. Após determinar o valor de cada fator, multiplique pelo seu peso e some o
total dos valores para obter os fatores de complexidade técnica e ambiental, conforme
seção 3.3.3.
Fatores de Complexidade Técnica
1. Sistemas distribuídos: descreve o nível em que a aplicação transfere dados entre os
componentes do sistema.
0 ( ) A aplicação não participa da transferência de dados ou processamento de funções
entre os componentes do sistema.
1 ( ) A aplicação prepara dados para processamento pelo usuário final em outro
componente do sistema, como planilhas eletrônicas ou banco de dados.
2 ( ) Dados são preparados para transferência, então são processados em outro
componente do sistema (não para processamento pelo usuário final).
3 ( ) Processamento distribuído e transferência de dados on-line apenas e em uma
direção.
4 ( ) Processamento distribuído e transferência de dados on-line e em ambas as
direções.
5 ( ) O processamento de funções é executado dinamicamente no componente mais
apropriado do sistema.
2. Desempenho da aplicação: identifica os objetivos de performance da aplicação, em
termos de tempo de resposta ou taxa de transações, estabelecidos ou aprovados pelo
usuário.
0 ( ) O usuário não estabeleceu nenhum requisito especial sobre performance.
1 ( ) Requisitos de performance e projeto foram estabelecidos e revisados, mas
nenhuma ação especial foi tomada.
2 ( ) Tempo de resposta ou taxa de transações são críticos durante as horas de pico.
Não é necessário nenhum projeto especial para a utilização de CPU. O limite para
o processamento é o dia seguinte.
3 ( ) Tempo de resposta ou taxa de transações são críticos durante todas as horas de
trabalho. Não foi necessário nenhum projeto especial para a utilização de CPU. O
limite de processamento é crítico.
4 ( ) Adicionalmente, requisitos especificados pelo usuário são exigentes o bastante
para que tarefas de análise de performance sejam necessárias na fase de projeto.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
97
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
5 ( ) Adicionalmente, ferramentas de análise de performance devem ser utilizadas nas
fases de projeto, desenvolvimento e/ou implementação, para que os requisitos de
performance do usuário sejam atendidos.
3. Eficiência do usuário final (on-line): descreve em que nível considerações sobre
fatores humanos e facilidade de uso pelo usuário final influenciam o desenvolvimento da
aplicação. O projeto inclui:
¾ Auxílio para navegação, como teclas de função, saltos, menus gerados
dinamicamente;
¾ Menus;
¾ Ajuda on-line e documentação;
¾ Movimentação automática do cursor;
¾ Paginação;
¾ Impressão remota por meio de transações on-line;
¾ Teclas de função predefinidas;
¾ Tarefas em lote submetidas a transações on-line;
¾ Seleção feita por posicionamento de cursor em tela de dados;
¾ Uso intenso de vídeo reverso, brilho, cores e outros indicadores;
¾ Documentação impressa das transações;
¾ Interface de mouse;
¾ Janelas pop-up;
¾ Utilização de número mínimo de telas para executar uma função do negócio;
¾ Suporte a dois idiomas (conte como quatro itens);
¾ Suporte a mais de dois idiomas (conte como seis itens);
0 ( ) Nenhum dos itens anteriores.
1 ( ) De um a três dos itens anteriores.
2 ( ) De quatro a cinco dos itens anteriores.
3 ( ) Seis ou mais dos itens anteriores, mas não existem requisitos específicos do
usuário associados à eficiência.
4 ( ) Seis ou mais dos itens anteriores e requisitos explícitos sobre a eficiência para o
usuário final são fortes o bastante para necessitarem de tarefas de projeto que
incluam fatores humanos, como minimizar o número de toques no teclado,
maximizar padrões de campo e uso de modelos.
5 ( ) Seis ou mais dos itens anteriores e requisitos explícitos sobre a eficiência para o
usuário final são fortes o bastante para necessitarem do uso de ferramentas e
processos especiais para demonstrar que os objetivos foram alcançados.
4. Processamento Interno Complexo: descreve em que nível o processamento lógico ou
matemático influencia o desenvolvimento da aplicação. Os seguintes componentes estão
presentes:
¾ Controle sensível e/ou processamento específico de segurança da aplicação.
Exemplo: processamento especial de auditoria.
¾ Processamento lógico extensivo. Exemplo: sistema de gestão de crédito.
¾ Processamento matemático extensivo. Exemplo: sistema de otimização de corte de
tecidos.
¾ Muito processamento de exceção resultando em transações incompletas que devem
ser processadas novamente. Exemplo: transações incompletas em ATM em função de
problemas de teleprocessamento, falta de dados ou de edição.
¾ Processamento complexo para manipular múltiplas possibilidades de entrada e saída.
Exemplo: sistema de extrato de conta corrente que emite via terminal de retaguarda,
auto-atendimento, web, e-mail, telefone celular.
0 ( ) Nenhum dos itens anteriores.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
98
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
1 ( ) Qualquer um dos itens anteriores.
2 ( ) Quaisquer dois dos itens anteriores.
3 ( ) Quaisquer três dos itens anteriores.
4 ( ) Quaisquer quatro dos itens anteriores.
5 ( ) Todos os cinco itens anteriores.
5. Reusabilidade do código em outras aplicações: a aplicação e seu código foram
especificamente projetados, desenvolvidos e suportados para serem reutilizados em outras
aplicações.
0 ( ) Não há código reutilizável.
1 ( ) Código reutilizável é utilizado na aplicação.
2 ( ) Menos de 10% da aplicação levou em consideração as necessidades de mais de
um usuário.
3 ( ) 10% ou mais da aplicação levaram em consideração as necessidades de mais de
um usuário.
4. ( ) A aplicação foi especificamente empacotada e/ou documentada para fácil
reutilização. Ela é customizada pelo usuário por meio de manutenção de
parâmetros.
5. ( ) A aplicação foi projetada e documentada para facilitar a reutilização de código, e a
aplicação é customizada para uso por meio de parâmetros que podem ser
atualizados pelo usuário.
6. Facilidade de Instalação: descreve em que nível a conversão de ambientes
preexistentes influencia o desenvolvimento da aplicação.
0 ( ) O usuário não definiu considerações especiais, assim como não é requerido
nenhum setup para a instalação.
1 ( ) O usuário não definiu considerações especiais, mas é necessário setup para a
instalação.
2 ( ) Requisitos de instalação e conversão foram definidos pelo usuário, e guias de
conversão e instalação foram fornecidas e testadas. Não é considerado importante
o impacto da conversão.
3 ( ) Requisitos de instalação e conversão foram definidos pelo usuário, e guias de
conversão e instalação foram fornecidas e testadas. É considerado importante o
impacto da conversão.
4 ( ) Além do item 2, ferramentas de instalação e conversão automáticas foram
fornecidas e testadas.
5 ( ) Além do item 3, ferramentas de instalação e conversão automáticas foram
fornecidas e testadas.
7. Usabilidade (facilidade operacional): descreve em que nível a aplicação atende a
alguns aspectos operacionais, como inicialização, segurança e recuperação. A aplicação
minimiza a necessidade de atividades manuais, como montagem de fitas, manipulação de
papel e intervenção manual pelo operador.
0 ( ) Não foi estabelecida pelo usuário outra consideração que não os procedimentos
normais de segurança.
1 - 4 ( ) Um, alguns ou todos os seguintes itens são válidos para a aplicação. Selecione
todos aqueles que sejam válidos. Cada item tem um valor de um ponto, a exceção
de onde seja citado o contrário.
¾ Procedimentos de inicialização, salvamento e recuperação foram fornecidos,
mas é necessária a intervenção do operador.
¾ Procedimentos de inicialização, salvamento e recuperação foram fornecidos, e
não é necessária a intervenção do operador (conte como dois itens).
¾ A aplicação minimiza a necessidade de montagem de fitas.
¾ A aplicação minimiza a necessidade de manipulação de papel.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
99
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
5 ( ) Aplicação projetada para operação não-assistida. Isto é, não é necessária
nenhuma intervenção do operador para operar o sistema, que não seja a
inicialização e término da aplicação. A recuperação automática de erros é uma
característica da aplicação.
8. Portabilidade: a aplicação foi especificamente projetada, desenvolvida e suportada
para instalação em múltiplos locais para múltiplas organizações.
0 ( ) Os requisitos do usuário não consideram a necessidade de mais de um
usuário/local de instalação.
1 ( ) Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi
projetada para operar apenas nos mesmos ambientes de hardware e de software
similares.
2 ( ) Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi
projetada para operar em apenas ambientes de hardware e de software similares.
3 ( ) Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi
projetada para operar em ambientes diferentes de hardware e de software.
4 ( ) Adicionalmente aos itens 1 ou 2, plano de suporte e documentação são fornecidos
e testados para suportar a aplicação em múltiplos locais.
5 ( ) Adicionalmente ao item 3, plano de suporte e documentação são fornecidos e
testados para suportar a aplicação em múltiplos locais.
9. Facilidade de Manutenção: descreve em que nível a aplicação foi especificamente
desenvolvida para facilitar a mudança de sua lógica de processamento ou estrutura de
dados. As seguintes características podem ser válidas para a aplicação:
¾ São fornecidos mecanismos de consulta flexível, que permitem a manipulação de
pedidos simples; por exemplo, lógica de e/ou aplicada a apenas um arquivo lógico
(conte como um item).
¾ São fornecidos mecanismos de consulta flexível, que permitem a manipulação de
pedidos de média complexidade; por exemplo, lógica de e/ou aplicada a mais de um
arquivo lógico (conte como dois itens).
¾ São fornecidos mecanismos de consulta flexível, que permitem a manipulação de
pedidos complexos; por exemplo, lógica de e/ou combinadas em um ou mais arquivos
lógicos (conte como três itens).
¾ Dados de controle do negócio são mantidos pelo usuário por meio de processos
interativos, mas as alterações só têm efeito no próximo dia útil.
¾ Dados de controle do negócio são mantidos pelo usuário por meio de processos
interativos, e as alterações têm efeito imediato (conte como dois itens).
0 ( ) Nenhum dos itens anteriores.
1 ( ) Qualquer um dos itens anteriores.
2 ( ) Quaisquer dois dos itens anteriores.
3 ( ) Quaisquer três dos itens anteriores.
4 ( ) Quaisquer quatro dos itens anteriores.
5 ( ) Todos os cinco itens anteriores.
10. Concorrência: descreve em que nível o alto volume de transações influencia o projeto,
desenvolvimento, instalação e suporte da aplicação.
0 ( ) Não é antecipado nenhum período de pico de transações.
1 ( ) São antecipados períodos de pico de processamento (por exemplo, mensal,
quinzenal, periódico, anual).
2 ( ) Picos de transação semanais são previstos.
3 ( ) Picos de transação diários são previstos.
4 ( ) Altas taxas de transação definidas pelo usuário nos requisitos ou os níveis de
serviços acordados são altos o bastante para requererem tarefas de análise de
performance na fase de projeto.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
100
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
5 ( ) Adicionalmente, existem requisitos de ferramentas de análise de performance nas
fases de projeto, desenvolvimento e/ou instalação.
11. Características especiais de segurança: descreve o nível de segurança exigido pela
aplicação.
0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de controle de
segurança da aplicação.
1 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do
sistema.
2 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do
sistema, e a aplicação foi projetada para ser acessada somente por usuários
autorizados.
3 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do
sistema, e a aplicação foi projetada para ser acessada somente por usuários
autorizados. O acesso será controlado e auditado.
4 ( ) Um plano de segurança foi elaborado e testado para suportar o controle de acesso
à aplicação.
5 ( ) Um plano de segurança foi elaborado e testado para suportar o controle de acesso
à aplicação e à auditoria.
12. Acessível por terceiros: descreve o nível de acesso de terceiros (usuários,
organizações externas, proprietário) na aplicação. O acesso à aplicação pode incluir as
seguintes características:
¾ A aplicação está disponível ao público da Internet em geral.
¾ A aplicação mantém e controla a integração de terceiros.
¾ A aplicação consome serviços de terceiros (contar um item para cada terceira parte
envolvida).
¾ A aplicação publica e documenta uma API (Application Programming Interface).
¾ A aplicação deve acessar o software de terceiros sem tornar a aplicação pública
(contar como dois itens).
0 ( ) Nenhum dos itens anteriores.
1 ( ) Qualquer um dos itens anteriores.
2 ( ) Quaisquer dois dos itens anteriores.
3 ( ) Quaisquer três dos itens anteriores.
4 ( ) Quaisquer quatro dos itens anteriores.
5 ( ) Todos os cinco itens anteriores.
13. Facilidades especiais de treinamento: descreve o nível de facilidade de treinamento
de usuários.
0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de treinamento
especial.
1 ( ) Necessidade de treinamento especial foi levada em consideração no projeto do
sistema.
2 ( ) Necessidade de treinamento foi levada em consideração no projeto do sistema, e a
aplicação foi projetada para ser acessada com facilidade pelos usuários.
3 ( ) Necessidade de treinamento especial foi levada em consideração no projeto do
sistema, e a aplicação foi projetada para ser utilizada por usuários de diversos
níveis.
4 - 5 ( ) Um plano de treinamento foi elaborado e testado para facilitar o uso da aplicação.
Fatores de Complexidade Ambiental
1. Familiaridade com o processo formal de desenvolvimento: descreve a experiência
da equipe com o processo (método) utilizado no desenvolvimento do projeto.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
101
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
0 ( ) A equipe não é familiar com o processo de desenvolvimento de software.
1 ( ) A equipe tem conhecimento teórico do processo de desenvolvimento de software.
2 - 3 ( ) Um ou mais membros utilizaram o processo uma ou poucas vezes.
3 - 4 ( ) Pelo menos a metade dos membros da equipe tem experiência no uso do
processo em diferentes projetos.
5. ( ) Toda a equipe tem experiência no uso do processo em vários projetos diferentes.
2. Trabalhadores com dedicação parcial: mede a estabilidade da equipe e a influência
do trabalho parcial na produtividade.
0 ( ) Não tem membro com dedicação parcial.
1 - 2 ( ) Poucos membros (20%) trabalham em período parcial.
3 - 4 ( ) A metade dos membros da equipe trabalha em período parcial.
5 ( ) Todos os membros da equipe trabalham em período parcial.
3. Capacidade do líder do projeto: descreve a experiência do líder do projeto na análise
de requisitos e modelagem.
0 ( ) O líder do projeto é novato.
1 - 2 ( ) Possui experiência de poucos projetos.
3 - 4 ( ) Pelo menos dois anos de experiência com vários projetos.
5 ( ) Pelo menos três anos de experiência com vários projetos.
4. Experiência com a aplicação de desenvolvimento: descreve a experiência com
diferentes tipos de aplicação ou com o tipo de aplicação que está sendo desenvolvida.
0 ( ) Todos os membros da equipe são novatos.
1 - 2 ( ) Poucos membros da equipe possuem alguma experiência (de 1 a 1 ½ ano). Os
outros são novatos.
3 ( ) Todos os membros têm mais de 1 ½ ano de experiência.
4 ( ) A maioria da equipe tem dois anos de experiência.
5 ( ) Todos os membros são experientes.
5. Experiência em orientação a objetos: descreve a experiência da equipe com análise e
projeto OO, modelagem de casos de uso, classes e componentes.
0 ( ) A equipe não é familiar à análise e projeto OO.
1 ( ) Todos os membros têm menos de 1 ano de experiência.
2 - 3 ( ) Todos os membros têm de 1 a 1 ½ ano de experiência.
4 ( ) A maioria da equipe tem mais de dois anos de experiência.
5. ( ) Todos os membros são experientes (mais de dois anos).
6. Motivação: descreve a motivação da equipe.
0 ( ) Não motivada.
1 - 2 ( ) Pouco motivada.
3 - 4 ( ) Motivada.
5. ( ) Bastante motivada.
7. Dificuldade na linguagem de programação: descreve a experiência com ferramentas
primárias de desenvolvimento e com a linguagem de programação escolhida.
0 ( ) Todos os membros da equipe são programadores experientes.
1 ( ) A maioria dos membros da equipe possui mais de dois anos de experiência.
2 ( ) Todos os membros têm mais de 1 ½ ano de experiência.
3 ( ) A maioria da equipe tem mais de um ano de experiência.
4 ( ) Poucos membros da equipe têm alguma experiência (um ano). Os outros são
novatos.
5 ( ) Todos os membros da equipe são novatos.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
102
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
8. Requisitos Estáveis: mede o grau de mudança de requisitos e inseguranças sobre o
significado dos requisitos.
0 ( ) Requisitos muitos instáveis com mudanças freqüentes.
1 - 2 ( ) Requisitos instáveis. Clientes demandam algumas mudanças em diversos
intervalos.
3 - 4 ( ) Estabilidade global. Pequenas mudanças são realizadas.
5 ( ) Requisitos estáveis ao longo do desenvolvimento.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
103
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Anexo 2
Documento de Descrição Funcional de Melhorias
UNICORP Informática Industrial Ltda
CONTRATO XXX
Implantação do Sistema XYZ
DESCRIÇÃO FUNCIONAL DAS
MELHORIAS – Etapa-X –VX
Total de páginas:
Elaborado por:
LOCAL - DATA
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
104
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
OBJETIVO
Este documento apresenta a Especificação Funcional das Melhorias (NF – Novas
Funcionalidades) do Projeto de Implantação do Sistema NetControl Corporativo na
Sabesp, como resultado dos trabalhos de Levantamento e Dados e detalhamento do
Termo de Referência do contrato. O objetivo principal é o detalhamento das Novas
Funcionalidades, descrevendo, de forma mais clara, as especificações das funções
que foram solicitadas como melhorias. Desta forma, esta Descrição Funcional deverá
detalhar o funcionamento das melhorias do TR, sendo este o seu principal objetivo.
METODOLOGIA UTILIZADA
Os trabalhos estão sendo executados por meio da leitura, comentário e discussão
sobre as definições existentes no TR do Contrato. Algumas definições estão sendo
melhoradas e as Novas Funcionalidades previstas terão as suas soluções (telas e
modelo de BD) detalhadas neste documento (que deverá ser aprovado pela
Sabesp), que será utilizada com base na Especificação Funcional.
REGRAS ADOTADAS NESTE DOCUMENTO
Os trabalhos estão sendo executados com base no documento EspFuncional-
Melhorias-NetCCorp-Etapa-1-2, em que cada Nova Funcionalidade será detalhada
com o seguinte conteúdo:
a) Descrição
b) Solução adotada
c) Módulos Afetados
d) Analista responsável
e) Modelo da BD
f) Protótipo da Tela
g) Aprovação do Cliente
h) Ação corretiva (apenas quando a NF não for aprovada)
DESCRIÇÃO FUNCIONAL POR GRUPO DE FUNÇÕES
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
105
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Apêndice A
Modelo de Especificação de Caso de Uso
O Modelo abaixo foi adaptado de Bezerra (2007) e elaborado para a Especificação dos Casos de Uso
do módulo UniMaster. O exemplo especificado refere-se a um dos casos de uso abordados neste
trabalho.
Módulo: UniMaster
Caso de Uso: Manter Análises
ESPECIFICAÇÃO
UNICORP
O conteúdo deste documento destina-se exclusivamente ao Cliente, não devendo ser revelado fora da fábrica de
software e da corporação contratante. Não deve ser duplicado, usado ou publicado, no total ou em sua parte,
para qualquer outro propósito que não de avaliação deste Relatório técnico ou para acompanhamento do
serviço contratado.
© UNICORP – Todos os direitos reservados.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
106
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
Histórico de Revisão
Data Versão Descrição Autor
05/05/08 1.0 Documentação do Caso de Uso Equipe
Pesquisa
MANTER ANÁLISES
SUMÁRIO: o objetivo deste caso de uso é manter o cadastro das análises realizadas
pelos laboratórios.
ATORES: supervisor.
PRECONDIÇÕES:
• O usuário deverá estar identificado no sistema;
• O usuário deverá ter acesso à funcionalidade “Cadastro Geral” e a demais
subitens.
FLUXO PRINCIPAL
1. O usuário escolhe a opção “Análises” dentre as opções fornecidas pelo
sistema UniLIMS;
2. O sistema exibe uma lista com as análises já cadastradas;
3. O usuário insere o nome e a abreviação do nome da análise que deseja
cadastrar;
4. O usuário escolhe a opção “Gravar Análise”;
5. O sistema cria a análise de acordo com as informações fornecidas pelo
usuário;
6. O caso de uso é finalizado.
Proposta de um método de estimativa para projetos de manutenção de software
baseado em Pontos por Caso de Uso
107
UNIP - Universidade Paulista
Programa de Pós-Graduação em Engenharia de Produção (Mestrado)
FLUXOS ALTERNATIVOS
Passo 3a (Alterar):
• O usuário escolhe a análise e efetua as alterações desejadas;
• O usuário confirma as alterações efetuadas;
• O sistema grava as alterações efetuadas pelo usuário, e o caso de uso é
finalizado.
Passo 3b (Excluir):
• O usuário escolhe a análise que deseja remover e escolhe a opção “Excluir”;
• O sistema remove a análise escolhida pelo usuário, e o caso de uso é
finalizado.
a) Passo 3c (Consultar):
• O usuário insere o nome da análise no respectivo campo de pesquisa e
escolhe a opção “Pesquisar”;
• O sistema retorna uma lista de acordo com os critérios fornecidos pelo
usuário;
• O caso de uso é finalizado.
PÓS-CONDIÇÕES: Uma análise foi alterada, excluída ou seus detalhes foram
exibidos.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
