Embed Size (px)
Citation preview
_
ADÃO VOLMIR ACOSTA CARACIOLO
AVALIAÇÃO DA INFLUÊNCIA DOS CASOS DE USO DO TIPO EXTEND E INCLUDE NO MÉTODO PONTOS POR CASO DE USO
CANOAS, 2009
1
ADÃO VOLMIR ACOSTA CARACIOLO
AVALIAÇÃO DA INFLUÊNCIA DOS CASOS DE USO DO TIPO EXTEND E INCLUDE NO MÉTODO PONTOS POR CASO DE USO
Trabalho de conclusão apresentado à banca examinadora do curso de Ciência da Computação do Centro Universitário La Salle – Unilasalle, como exigência parcial para obtenção do grau de Bacharel em Ciência da Computação, sob orientação do Prof. Ms. Abraham Lincoln Rabelo de Sousa.
CANOAS, 2009
2
TERMO DE APROVAÇÃO
ADÃO VOLMIR ACOSTA CARACIOLO
AVALIAÇÃO DA INFLUÊNCIA DOS CASOS DE USO DO TIPO EXTEND E INCLUDE NO MÉTODO PONTOS POR CASO DE USO
Trabalho de conclusão aprovado como requisito parcial para a obtenção do grau de
Bacharel do Curso de Graduação em Ciência da Computação do Centro Universitário La Salle – Unilasalle, pela seguinte banca examinadora:
Prof. Ms. Abraham Lincoln Rabelo de Souza UFRGS
Prof. Ms. Marcos Ennes Barreto UFRGS
Prof. Ms. Roberto Petry UFRGS
Canoas, 8 de junho de 2009.
3
RESUMO
Determinar o esforço no desenvolvimento de software é um grande desafio enfrentado pela gerência de projetos. O uso das métricas disponibilizadas pela Engenharia de Software propõe auxiliar nesse desafio. Com o advento da Orientação Objeto, surgiu o método Pontos por Caso de Uso (PCU), no entanto, as empresas enfrentam dificuldades para aplicá-lo devido à falta de padrão dos casos de uso. Este trabalho propõe avaliar o impacto nos resultados apresentados pelo PCU, considerando as propostas de contar ou não os casos de uso do tipo extend e include. Palavras-chave: Estimativa. Casos de uso. PCU. Estendido. Incluído.
ABSTRACT
Determining the effort in software development is a huge challenge faced by project management. The use of metrics provided by Software Engineering should assist in this challenge. Since the creation of the Object-Orientation it was created the Use Case Points method (UCP), however, the companies find difficulties to apply it due to a lack of a standard in use cases. The objective of this work is to evaluate the impact in the results presented by UCP, considered the fact of counting (or not) the use cases of extend and include kind. Key words: Estimation. Use cases. UCP. Extend. Include.
4
SUMÁRIO
1 INTRODUÇÃO .........................................................................................................5
2 MÉTRICAS PARA ESTIMAR TAMANHO DE SOFTWARE....................................7
2.1 Métricas no processo de desenvolvimento de software .................................9
2.2 Pontos por Caso de Uso...................................................................................11
2.3 Padrões para aplicação da PCU.......................................................................14
2.4 Considerações finais sobre o capítulo............................................................18
3 CARACTERIZAÇÃO DO ESTUDO .......................................................................20
3.1 Modelo aplicado ................................................................................................21
4 AVALIAÇÃO DO TRABALHO...............................................................................24
4.1 Avaliação do trabalho realizado.......................................................................24
4.2 Critérios aplicados no modelo anterior...........................................................27
4.3 Avaliação do trabalho sem considerar fatores externos ...............................28
4.4 Avaliação dos resultados apresentados .........................................................31
5 CONCLUSÃO ........................................................................................................35
5.1 Trabalhos futuros ..............................................................................................36
REFERÊNCIAS.........................................................................................................38
5
1 INTRODUÇÃO
Diante do cenário mundial cada vez mais competitivo e dinâmico, as empresas
que desenvolvem software devem estar em constante evolução na busca da
excelência dos seus produtos e serviços, proporcionando o desenvolvimento de
novos negócios e sua afirmação no mercado. Para atingir suas metas as empresas
dependem de projetos bem gerenciados.
Um projeto bem gerenciado reflete na entrega do produto dentro do orçamento,
no prazo contratado e com a qualidade desejada pelo cliente. Para atingir esses
objetivos, as empresas devem estar em constante aperfeiçoamento dos seus
processos de desenvolvimento de software, controle dos projetos e a utilização de
novas tecnologias de desenvolvimento.
Dentro do processo de desenvolvimento de software, surgem as métricas que
são essenciais como elementos de gestão (CARVALHO, 2004), já que, segundo
DeMarco (1982), “não se consegue controlar aquilo que não se consegue medir”.
O grande desafio das empresas que desenvolvem software é conseguir
mensurar e estimar de forma precisa seus projetos, evitando divergências nas
estimativas de tamanho, tempo e custo. Essas divergências têm sido a causa de
constantes atritos entre as áreas de negócios e áreas de Tecnologia da Informação
(TI), pois, na maioria das vezes, o orçamento e a previsão de entrega do produto
não condizem com a realidade. As consequências disso são, segundo Calazans,
Oliveira e Dias (2004), insatisfação do cliente, perda da qualidade, perdas
financeiras e desgastes entre os profissionais envolvidos no processo.
No decorrer do tempo dentro da engenharia de software, diversas métricas
foram criadas para auxiliar nesse desafio de estimar. Dentre as métricas
disponibilizadas, está o método Pontos por Caso de Uso (PCU), que trata de estimar
o tamanho de um sistema de acordo com a visão do usuário final, utilizando como
base os artefatos de caso de uso (ANDRADE, 2004). O PCU surgiu com o advento
6
da orientação objeto, no entanto, as empresas enfrentam dificuldades na utilização
do método devido à falta de padrão de refinamento dos casos de uso, afetando
diretamente as estimativas de tamanho, tempo e custo (FREIRE, 2003).
Essa falta de padrão de refinamento dos casos de uso também decorre por ser
uma métrica nova perante as outras que já estão consolidadas como, por exemplo, a
Análise de Pontos de Função (APF), que apresenta resultados reais, já
demonstrados por diversos estudos, como em Andrade (2004). A aceitação e
aplicação da técnica APF pelo mercado se deu graças ao trabalho dos
pesquisadores no sentido da busca de soluções e padronização para resolução de
problemas em estimativa, o que também deve ser feito para o método PCU.
Nesse contexto, existem diversos trabalhos relacionados a padrões para
aplicação do PCU. Entre os assuntos abordados nessas pesquisas – entre elas
Anda et al. (2001) e Ribu (2001) –, é proposta a contagem dos casos de uso
estendidos e incluídos separadamente, uma única vez, e não como uma transação
de cada caso de uso que o utiliza. No entanto, Karner o criador do PCU (1993), não
recomenda a contagem dos casos de uso estendidos e incluídos.
Entretanto, apesar dos pesquisadores Anda e Ribu discordarem de Karner em
relação à contagem dos casos de uso, não foi localizado nenhum trabalho que
demonstre qual é o impacto de considerar ou não os casos de uso do tipo extend e
include no resultado das estimativas produzidas pelo PCU.
Assim, este estudo tem o seguinte objetivo: avaliar qual a influência do uso ou
não de casos de uso do tipo extend e include no resultado das estimativas
produzidas pelo PCU. A motivação para este trabalho está em avaliar se o impacto
da contagem desses casos de uso é relevante ou não nas estimativas e o quanto
isso afeta o resultado produzido pelo PCU.
Este trabalho está organizado em seis seções. A seção 2 é composta pela
fundamentação teórica e trabalhos relacionados, nos quais são apresentadas as
métricas, suas aplicações no processo de desenvolvimento de software, bem como
os padrões já propostos por pesquisadores. A seção 3 descreve a caracterização do
estudo, identificando qual é o problema e como será resolvido. Na seção 4, é
apresentado o resultado obtido através da avaliação do trabalho realizado. A seção
5 apresenta a conclusão e possíveis trabalhos futuros e, na seção 6, encontram-se
relacionadas às referências bibliográficas utilizadas no trabalho..................................
7
2 MÉTRICAS PARA ESTIMAR TAMANHO DE SOFTWARE
A partir da década de 90, as empresas passaram a se preocupar em melhorar
o processo de desenvolvimento de software, seguindo normas e modelos para medi-
lo. Até então, as empresas não julgavam necessário o planejamento e controle de
projetos. No entanto, para o sucesso da implantação de um projeto, o mesmo deve
ser implantado com planejamento, programação e controle. Nesse contexto, as
métricas de software são essenciais no auxílio do controle no gerenciamento de
projetos (MENESES, 2001).
Segundo Calazans, Oliveira e Dias (2004), uma medida é referente a um valor
de uma métrica, o qual fornece uma indicação de quantidade, capacidade, dimensão
ou tamanho de algum produto de software ou de um processo.
Ultimamente, as métricas têm evoluído no sentido de resolver problemas que
afetam as estimativas, ou seja, problemas que geram divergências entre os valores
estimados e os valores realizados. Essa evolução ocorreu graças ao trabalho dos
pesquisadores no sentido da busca de soluções e padronização para os diversos
problemas e desafios em estimar tamanho de software (MENESES, 2001).
Entre os estudos já realizados (CALAZANS; OLIVEIRA; DIAS, 2004 e
MENESES, 2001), foi identificado que tais divergências muitas vezes decorrem de
alguns fatos, tais como:
a) aumento de escopo;
b) requisitos não bem definidos;
c) requisitos não bem conhecidos por todos;
d) maior detalhamento dos requisitos na fase do planejamento;
e) surgimento de requisitos secundários;
f) software é um produto de alto grau de abstração;
g) os analistas utilizam muito mais a intuição do que o embasamento;
h) pressões por interesses;
8
i) pressões políticas.
Conforme concluiu Meneses (2001), isso pode acarretar problemas como:
a) sobrecarga de trabalho sobre a equipe;
b) desgastes com o cliente pelo atraso;
c) redução de escopo;
d) má estimativa de custos;
e) prejuízos financeiros;
f) perda da qualidade;
g) até mesmo a interrupção do desenvolvimento do projeto. Segundo Meneses (2001) e Peñalvo, Escudero e García (2001), uma métrica
para ser útil e de qualidade deve ser:
a) simples - a definição deve ser simples e o uso da métrica deve ser prático;
b) objetiva - deve indicar claramente, para que diferentes pessoas possam
encontrar valores aproximados, idênticos; devem ter consistência para
evitar interpretações individuais;
c) robusta - a métrica deve ser insensível a mudanças irrelevantes, para
permitir comparações com dados mais úteis;
d) válida - a métrica deve medir o que se pode medir, pois isso dá
confiabilidade à medida.
No decorrer do tempo, diversas métricas foram criadas para auxiliar no desafio
de estimar o tamanho de software. Entre as métricas existentes, podemos citar: LOC
(Linhas de Código); COCOMO (Constructive Cost Model); COCOMO II; APF
(Análise de Pontos de Função) e a PCU (Ponto por Caso de Uso).
A métrica LOC (Lines of Code) objetiva indicar o tamanho de um sistema
basicamente contando o número de linhas de código existente. Provavelmente essa
seja a métrica mais básica dentro do universo de desenvolvimento de software.
Outra métrica é a COCOMO (Constructive Cost Model) e sua evolução
COCOMO II. Este método objetiva medir esforço, prazo, tamanho da equipe e custo
necessário para o desenvolvimento de software, desde que se tenha uma dimensão
do tamanho do mesmo, por meio de um modelo de estimativa. O COCOMO (oriundo
de 1981) teve a sua versão atualizada em 2000, sendo substituído pelo COCOMO II,
que estima o custo e tempo baseado em pessoas/mês e meses. O modelo ainda
prevê um coeficiente de risco de 20% adicional ao tempo computado, como margem
de erro.
9
A APF (Function Point Analysis) foi desenvolvida em 1979 por Allan Albrecht e
refinada posteriormente pelo IFPUG (International Function Point Users Group),
objetiva medir a complexidade de produto pela quantificação de funcionalidade
expressa através da visão do usuário. Pode ser utilizada independente da tecnologia
usada no desenvolvimento de software e mede uma aplicação a partir das funções
desempenhadas por solicitação do usuário final.
O processo de contagem da APF é realizado em sete passos, sendo que a
métrica efetua o cálculo através dos pontos de função, que são os dados ou
transações do sistema, aplicando à complexidade de cada função como: Baixa,
Média ou Alta. A métrica APF é a mais utilizada pelo mercado, porém, só prevê
estimativas mais precisas à medida que obtém maiores informações no decorrer do
desenvolvimento do projeto.
Maiores detalhes sobre a APF poderão ser encontrados em Vazquez, Simões
e Albert (2005).
O PCU (Ponto por Caso de Uso) é um método criado por Gustav Karner, em
1993, com o propósito de poder estimar o tamanho de um projeto de software
orientado a objeto ainda na fase de levantamento dos casos de uso.
O PCU é baseado na Análise por Pontos de Função, para estimar tamanho de um sistema de acordo com o modo que os usuários finais o utilizarão e a complexidade de ações requeridas por cada tipo de usuário final (FREIRE, 2003).
Sobre o PCU, será abordado com mais detalhe na seção 2.2.
2.1 Métricas no processo de desenvolvimento de software
As métricas no processo de desenvolvimento de software devem ser aplicadas
independentemente do modelo de ciclo de vida (por exemplo: cascata, espiral,
prototipação, RUP). No entanto, as métricas utilizam artefatos disponibilizados pela
Engenharia de Software (PEÑALVO; ESCUDERO; GARCÍA, 2001).
A medição pode ser aplicada durante uma ou mais etapas do ciclo de
desenvolvimento de software: especificação de requisitos, análise de requisitos,
modelagem, implementação, depuração, manutenção e documentação (CHÁVEZ,
2005 e PEÑALVO; ESCUDERO; GARCÍA, 2001); porém, cada métrica tem que
10
focar objetivos específicos e bem definidos. Dessa forma, uma métrica aplicada para
estimar o tamanho de código não pode ser utilizada com finalidade de medir a
qualidade do software.
O estudo publicado em Abreu (1996) sugere adotar alguns critérios na
aplicação de métricas, sendo que as mesmas devem ser: bem definidas;
dimensionáveis ou expressas em alguma unidade; obtidas o mais cedo possível no
ciclo de vida do sistema; facilmente calculadas; estar em uma escala que aumente a
precisão; vistas como probabilidade, de forma que permita a aplicação de teorias
estatísticas sobre as mesmas.
Dentro do desenvolvimento de software, as métricas podem ser aplicadas:
a) no planejamento - as informações dos projetos anteriores poderão ser
utilizadas nas estimativas do novo projeto de software;
b) durante o desenvolvimento - medições são coletadas e analisadas em
relação às estimativas propostas inicialmente;
c) ao término do desenvolvimento - as medições são coletadas e analisadas
em relação às estimativas propostas inicialmente.
A Figura 1 apresenta a aplicação das métricas no processo de
desenvolvimento de software.
Figura 1 - Aplicação das métricas dentro do processo de desenvolvimento de software Fonte: Autoria própria, 2007.
O método PCU foi criado para estimar projetos com base no modelo de casos
de uso gerado no início do projeto. Dessa forma, a métrica pode ser aplicada ainda
11
na fase de planejamento, na etapa de levantamento de requisitos, tão logo sejam
produzidos os casos de uso. Diferente do PCU, a métrica APF depende de mais
informações a respeito da complexidade de cada função (dados ou transações),
essas informações somente são identificadas ao longo do processo de
desenvolvimento de software. A principal vantagem do PCU em relação à APF é a
possibilidade de gerar estimativas mais cedo no ciclo de vida do processo de
desenvolvimento de software. Por esse motivo que este trabalho optou em explorar
a potencialidade da aplicação da PCU, buscando sua maior assertividade nas
estimativas de tamanho, geradas ainda no início do processo de desenvolvimento de
software. A APF somente tem melhores resultados à medida que obtém mais
informações de análise e do projeto de sistemas (ANDRADE, 2004).
2.2 Pontos por Caso de Uso
Proposto por Karner, em 1993, Pontos por Caso de Uso é um método com o
propósito de poder estimar o tamanho de um projeto de software ainda na fase de
requisitos. O método estima projetos de acordo com o modo que os usuários finais
utilizarão, com base nos atores, caso de uso e complexidade técnica e de ações
requeridas por cada tipo de usuário final, bem como na complexidade de ambiente,
por exemplo, equipe (FREIRE, 2003).
Após serem levantados os principais casos de uso, já é possível aplicar o PCU
para estimar o tamanho de um software. No entanto, como a análise de medição dos
casos de uso é feita a nível de sistema – o que possibilita diferenciar transações de
interações com o usuário –, o nível de detalhamento dos casos de uso influencia
diretamente nas estimativas. Sendo assim, casos de uso de nível muito alto (busines
modelling do sistema, descrevendo apenas as regras de modelagem do negócio) ou
casos de uso de nível muito baixo (caso de uso atômicos, descrevendo o sistema a
nível de interações do usuário com a interface) são inadequados para medição
(MONTEIRO; PIRES; BELCHIOR, 2004 e FREIRE, 2003).
Ultimamente, o que se tem discutido é sobre qual o nível ideal de
decomposição dos casos de uso para aplicação do PCU, “sendo essa a principal
falha da técnica” (HERVAL, 2003). O PCU apresenta seis etapas para aplicação do
método, no entanto, o grande desafio já começa nas duas primeiras, nas quais os
atores e os casos de uso, bem como suas complexidades, são identificados. Após
12
essa identificação, são aplicados os pesos para o cálculo dos Unajusted Use Case
Points (UUCP)1 (TANAKA; BARROS; NUNES, 2005). Essas duas primeiras etapas
já influenciam diretamente na potencialidade de sucesso ou insucesso da aplicação
do método, conforme apresentam as Tabelas 1 e 2.
Tabela 1 - Classificação de Ator
Tabela da complexidade dos Atores
Complexidade Descrição Peso
Simples Muito poucas entidades de Banco de Dados envolvidas e sem nenhuma regra de negócio complexa / Outro sistema acessado pela API de programação
1
Médio Poucas entidades de Banco de Dados envolvidas e com algumas regras de negócios complexas / Outro sistema interage através de protocolo de comunicação TCP/IP
2
Complexo Muitas entidades de Banco de Dados envolvidas e regas de negócio complexas / Usuário interage com interface gráfica (web)
3
Fonte: Adaptado de Andrade (2004) e Ribu (2001).
Depois de identificados e classificados os Atores, é calculado o Unajusted
Actor Weight (UAW).
Tabela 2 - Classificação do caso de uso
Tabela da complexidade dos casos de uso
Tipo Descrição Peso
Simples Até 3 transações com menos de 5 classes de análise 5
Médio De 4 a 7 transações com 5 a 10 classes de análise 10
Complexo De 7 transações com pelo menos 10 classes de análise 15
Fonte: Adaptado de Andrade (2004) e Ribu (2001).
1 Tradução: Pontos de Caso de Uso Não Ajustados (PCUNA).
13
Após identificados e classificados os casos de uso, é calculado o Unajusted
Use Case Weight (UUCW).
A soma do valor da quantidade de Atores multiplicado pela sua complexidade,
mais a soma do valor da quantidade de casos de uso multiplicado pela sua
complexidade, resulta no valor do Unajusted Use Case Points (UUCP).
UUCP = UAW + UUCW
UAW = (Quantidade de Atores x Complexidade) e,
UUCW = (Quantidade de Casos de Uso x Complexidade)
Maiores detalhes sobre o PCU poderão ser encontrados em Karner (1993) e
Tanaka, Barros e Nunes (2005).
A aplicação do PCU ocorre ainda na fase de planejamento, conforme
apresenta a Figura 2.
Figura 2 - Aplicação do método PCU durante o levantamento de requisitos Fonte: Autoria própria, 2007.
Dessa forma, pode-se entender a necessidade da busca de padrões no
momento de considerar o número de atores e os casos de uso com as suas
respectivas complexidades, pois no momento em que se considerar atores ou
transações inadequadas, estar-se-á afetando diretamente o resultado apresentado
pelo método Pontos por Caso de Uso (MONTEIRO; PIRES; BELCHIOR, 2004).
Destaca-se que o PCU também leva em consideração Fatores Técnicos
(relacionados às dificuldades de construir o sistema) e Fatores Ambientais
14
(relacionados à experiência, motivação da equipe) (ANDA; MOHAGHEGHI;
CONRADI, 2005).
2.3 Padrões para aplicação da PCU
Conforme apresentado nas seções anteriores, a aplicação do PCU baseia-se
no artefato caso de uso, sendo assim, os casos de uso devem ser construídos de
forma que venham a garantir a confiabilidade para aplicação do PCU. No entanto, o
desafio é a inexistência de um padrão do nível ideal de decomposição dos casos de
uso para aplicação do método, algo que está presente nas discussões atuais, sendo
essa a principal falha do método segundo (MONTEIRO; PIRES; BELCHIOR, 2004 e
FREIRE, 2003).
Pode-se dizer que, além desse desafio na utilização da PCU, as contagens
podem variar: entre as organizações e indivíduos; devido aos diferentes casos de
uso; um estilo comum para especificação dos casos de uso pode levar ao sucesso
ou fracasso; não existem padrões para construção de casos de uso; não há como
garantir que a PCU está medindo a mesma coisa, se os critérios para a construção
de casos de uso são diferentes.
Diversos pesquisadores têm trabalhado para propor soluções a esses
problemas, sugerindo algumas diretrizes para elaboração dos casos de uso que
possam trazer uma maior padronização na construção dos mesmos, para aplicação
do método PCU com um maior potencial de assertividade. Para resolver o problema
do nível ideal de decomposição dos casos de uso que influenciam diretamente na
aplicação do PCU, os pesquisadores têm discutido principalmente a identificação
das transações e a generalização dos atores (ANDRADE, 2004).
Alguns pesquisadores (BELGAMO, 2004 e BELGAMO; FABBRI, 2004) têm
proposto a utilização de técnicas de leitura como a GUCCRA como forma de
contribuir fornecendo diretrizes para a construção dos modelos de casos de uso. No
entanto, há um consenso geral sobre o nível de detalhamento dos casos de uso,
sendo que o nível não pode ser nem muito alto, nem muito baixo, ou seja, não pode
se referir à modelagem de negócio do sistema nem à decomposição funcional dos
casos de uso.
Dentre os trabalhos relacionados, podemos destacar dois pesquisadores que
se aprofundaram no assunto, Anda e Ribu, que participaram juntos em 2002 do
15
trabalho que aplicou o método Pontos por Caso de Uso numa empresa de
desenvolvimento de software.
O trabalho realizado por Anda, Angelvik e Ribu (2002) foi aplicar o método de
Karner em três projetos, concluindo que a estrutura dos casos de uso pode gerar
impacto nas estimativas, tais como: uso da generalização entre os atores; contagem
dos casos de uso estendido e incluído; nível de detalhes da descrição dos casos de
uso; entre outras dificuldades, a atribuição de valor para os fatores técnicos e
ambientais e taxa de produtividade por PCU. Já Karner, criador do método PCU, não
recomenda a contagem dos casos de uso estendidos e incluídos.
O trabalho publicado por Ribu (2001) também aplicou o método de Karner,
porém, considerando e não considerando os fatores de ajustes técnicos em projetos
de estudantes e da indústria.
Anda (2002) aplicou o método PCU como parte de três cursos de modelagem
de casos de uso de uma companhia internacional de TI. O objetivo desse trabalho
foi comparar as estimativas realizadas pelos especialistas com as estimativas
geradas pelo método PCU. Os resultados mostram que as estimativas geradas pelo
método foram mais próximas do que as estimativas geradas pelos especialistas. Ao
final do trabalho, o pesquisador concluiu que o método Pontos por Caso de Uso
pode ser utilizado com sucesso para estimar o tamanho de esforço no
desenvolvimento de software.
Destacam-se, entre os estudos realizados pelos pesquisadores Anda e Ribu,
as seguintes propostas:
a) contar os casos de uso estendido e incluído separadamente, uma única
vez, e não como uma transação de cada caso de uso que o utiliza;
b) generalizar os atores em um super ator, quando as descrições de dois ou
mais atores têm muito em comum;
c) utilizar formulário padrão para descrição dos casos de uso;
d) contar uma única vez uma transação quando a mesma ocorrer em diversos
casos de uso, pois uma vez implementada, a mesma será chamada por
outros casos de uso através de reuso;
e) utilizar regras para atribuição de valores aos fatores ambientais;
f) analisar a complexidade do caso de uso através do diagrama de
sequência;
g) analisar a complexidade do caso de uso através das classes que os
16
implementam quando não houver descrição dos mesmos;
h) identificar as classes de análise, não as de projeto, que implementam as
funções do caso de uso para auxiliar na determinação da complexidade do
caso de uso;
i) descartar os fatores de ajustes técnicos;
j) manter os fatores de ajustes ambientais;
k) comparar as transações descritas nos casos de uso com as transações do
diagrama de sequência e com o número de classes de análise utilizadas
para implementar o caso de uso, para verificar se a complexidade do caso
foi definida corretamente;
l) quando a documentação não apresentar casos de uso, deverá ser utilizado
o diagrama de sequência para contar as transações, levando-se em
consideração apenas as transações que indicam o que fazer e não como
fazer, ou classes que implementam o caso de uso.
Já sobre horas por Ponto de Caso de Uso, Karner sugere 20 horas; no entanto,
Schneider e Winters (2001) sugerem uma revisão da técnica e propõe o número
entre 20 a 36 horas. Da mesma forma, o trabalho publicado por Carroll (2005)
concorda com a proposta de Schneider e Winters, pois o mesmo acredita que nem
todos os projetos são iguais.
Em 2005, um novo trabalho publicado por Anda utilizou o PCU para estimar
projetos de grande escala no processo incremental de desenvolvimento de software.
A diferença desse estudo para os anteriores é a aplicação do PCU no processo
incremental, que em cada nova liberação deve ser estimado o projeto a ser entregue
e muitas vezes são apenas exigências não-funcionais como, por exemplo,
desempenho e segurança, que alteram apenas os requisitos não-funcionais2. É
importante observar que os casos de uso essencialmente descrevem os requisitos
funcionais3.
2 Os requisitos não-funcionais são aqueles que expressam como deve ser feito. São as propriedades ou qualidades do produto. Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc. Neles também são apresentadas as restrições e especificações de uso para os requisitos funcionais. 3 Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema, o que o produto deve fazer, as funcionalidades de que o sistema deve dispor.
17
Tabela 3 - Abordagem dos trabalhos relacionados
Autor Assunto abordado
Karner 1993
Anda 2001-2005
Ribu 2001
Freire 2003
Schneider 2001
Carroll 2005
PCU na OO X X X X X X
Horas por PCU X X X
Caso de Uso Nível de Sistema
X
Contagem Caso de Uso Estendido
N S S
Contagem Caso de Uso Incluído
N S S
PCU baixa variação com o real
X X X
Formulário padrão para Caso de Uso
X X
Descartar fatores de ajustes técnicos
X
Super atores X
Diagrama de sequência
X
Regra para fatores ambientais
X
Desenvolvimento incremental
X
Influência dos requisitos não funcionais
X
Coeficiente de risco X
Estimar relatórios diferenciados
X
Fonte: Autoria própria, 2007.
Na Tabela 3, X indica que o assunto foi abordado, S indica que o autor
concorda e N indica que o autor não concorda.
18
Pode ser observada, nessa mesma tabela, a preocupação de medir os casos
de uso em nível de sistema, no qual, como foi dito anteriormente, é possível
diferenciar transações e interações com o usuário. Outro ponto discutido é a
contagem ou não dos casos de uso do tipo extend e include.
Entre as perguntas respondidas no estudo de Anda, Mohagheghi e Conradi
(2005), uma era se a PCU poderia ser aplicada às mudanças incrementais em caso
de uso. Foi concluído que é possível aplicar. Outra pergunta era qual o seu resultado
nesse cenário de desenvolvimento em grande escala. Concluiu-se que os resultados
são satisfatórios, porém, foram sugeridas algumas adequações aos valores,
principalmente quando as mudanças não afetam os casos de uso, ou seja, são
apenas requisitos não-funcionais.
Ao final de seu trabalho, Carroll (2005) propõe, entre outras coisas, a aplicação
de coeficiente de risco a ser adicionado no PCU, bem como estimar os relatórios de
forma específica para o seu desenvolvimento, levando em conta os dados históricos
para determinar o tempo de desenvolvimento dos mesmos.
O trabalho realizado por Freire (2003) reforça a preocupação de somente medir
os casos de uso em nível de sistema, no qual é possível diferenciar as transações e
interações com o usuário.
Estimar cada vez mais cedo no ciclo de vida do desenvolvimento de software é
um desafio. No entanto, a exatidão das estimativas através da aplicação do método
PCU já conseguiu alcançar percentuais consideráveis como, por exemplo, um desvio
de menos de 9% em relação ao real estimado em 95% dos projetos. É o que
demonstra o estudo apresentado por Carroll (2005), que reuniu mais de 450
coordenadores e mais de 200 projetos num período de 5 anos.
2.4 Considerações finais sobre o capítulo
O capítulo apresentou a evolução das métricas no decorrer do tempo, como
forma de apoiar no desafio de estimar projetos que possam gerar estimativas mais
precisas. As métricas são importantes ferramentas no processo de desenvolvimento
de software; com essa finalidade, foram criadas diversas métricas, entre outras,
podemos citar o Pontos por Caso de Uso (PCU).
Este capítulo também abordou as dificuldades enfrentadas e os trabalhos
realizados nesse contexto, bem como os pontos a desenvolver propostos pelos
19
pesquisadores. Entre as dificuldades apresentadas em relação ao método Pontos
por Caso de Uso, destaca-se a preocupação do nível ideal de decomposição dos
casos de uso. Por isso que é importante avaliarmos qual é o impacto que isso pode
gerar nas estimativas apresentadas pelo PCU, sendo que entre os pontos mais
relevantes aqui citados, pode-se destacar: considerar ou não a contagem separada
dos casos de uso do tipo extend e include no método PCU.
No próximo capítulo, será apresentado o estudo e o modelo que será aplicado
para responder qual a influência da contagem separada ou não dos casos de uso do
tipo extend e include no resultado das estimativas produzidas pelo método PCU.
20
3 CARACTERIZAÇÃO DO ESTUDO
Analisando os trabalhos relacionados, percebe-se que apesar da preocupação
dos pesquisadores em considerar a contagem separada dos estereótipos tipo extend
e include, não foram localizados estudos que revelam qual o impacto do uso ou não
desses casos de uso no resultado das estimativas produzidas pelo PCU.
Os casos de uso secundários simplificam o comportamento dos casos de uso
primários por meio de mecanismos de extensão e inclusão (extend e include).
Assim, muitas vezes os casos de uso secundário podem estar contidos dentro do
caso de uso primário na forma de transações.
Dependendo do nível de detalhamento dos casos de uso, um determinado
comportamento pode ser considerado como uma transação ou pode ser separado
como um caso de uso do tipo extend ou include. É nesse ponto que surge o
problema, quando um determinado comportamento deve ser considerado como uma
transação do caso de uso primário ou deve ser separado como um caso de uso
secundário, em um estereótipo do tipo extend e include. E qual o impacto que essa
decisão pode causar nos resultados produzidos pelo PCU? Este trabalho visa avaliar
qual a influência do uso ou não de casos de uso do tipo extend e include no
resultado das estimativas produzidas pelo PCU.
O caso de uso extend é útil para um comportamento não-padrão ou incomum,
enquanto o caso de uso include permite fatorar um comportamento comum a vários
casos de uso, conforme demonstram a Figura 3 (Diagrama de caso de uso primário)
e a Figura 4 (Diagrama de caso de uso secundário).
21
Figura 3 - Diagrama de caso de uso primário Fonte: Autoria própria, 2007.
Figura 4 - Diagrama de caso de uso secundário, incluindo os estereótipos extend e include Fonte: Autoria própria, 2007.
O risco de não contar como um caso de uso separado é de subestimar o
tamanho do projeto. Por outro lado, a contagem como transação dos casos de uso
que o utilizam pode compensar essa provável subestimação. Este é o problema que
ainda não foi esclarecido: Essa contagem ou não dos casos de uso extend e include
realmente impacta nos resultados gerados pelo PCU? E se impacta, o quanto
impacta?
3.1 Modelo aplicado
Para responder à questão de qual a influência do uso ou não de casos de uso
do tipo extend e include no resultado das estimativas produzidas pelo PCU, este
estudo apresenta um trabalho retrospectivo, no qual é aplicado o método PCU
baseado nos requisitos dos casos de uso de uma base de projetos. O método PCU
foi aplicado de duas formas:
a) considerando a contagem separada dos casos de uso do tipo extend e
include;
b) não considerando a contagem separada os casos de uso do tipo extend e
include.
As informações para a realização deste trabalho foram fornecidas a partir de
uma base de projetos reais, desenvolvidos em uma fábrica de software. Foram
selecionados seis projetos e foi aplicado o método pontos por caso de uso
considerando de duas formas:
22
a) aplicar o método PCU (Estimativa CCS), para estimar o esforço do projeto
através do método PCU com base no diagrama de casos de uso S (casos
de uso primários e secundários), considerando a contagem separada dos
casos de uso do tipo extend e include;
b) aplicar o método PCU (Estimativa NCS), para estimar o esforço do projeto
através do método PCU com base somente no diagrama de casos de uso
P (casos de uso primários), não considerando a contagem separada dos
casos de uso do tipo extend e include;
Depois de aplicado o método, os resultados são comparados com as
informações do total de horas realizadas até a conclusão do projeto. Os resultados
gerados pela aplicação deste modelo serão apresentados na seção seguinte.
Foram avaliados os valores estimados (Estimativa CCS e Estimativa NCS) em
relação ao valor realizado até a conclusão do projeto. A Figura 5 apresenta o modelo
aplicado.
Figura 5 - Modelo aplicado no trabalho Fonte: Autoria própria, 2007.
É importante destacar que o objetivo deste trabalho é avaliar qual a influência
do uso ou não de casos de uso do tipo extend e include no resultado das estimativas
produzidas pelo PCU. Dessa forma, não está sendo abordado qual o nível de
detalhamento dos casos de uso é o melhor para aplicação do PCU, mas sim qual é o
impacto que a contagem separada dos casos de uso extend e include podem gerar
nos resultados apresentados pelo método. Da mesma forma que o nível de
23
detalhamento dos casos de uso não está sendo considerado, outros fatores também
não estão sendo observados, exceto os fatores que influenciam a tabela de
complexidade de Atores e tabela de complexidade de casos de uso.
O escopo deste trabalho limita-se aos fatores que provocam a influência na
complexidade da tabela de classificação do caso de uso. Não são considerados
outros fatores como: Fator de Complexidade Técnica e Fator de Complexidade
Ambiental.
24
4 AVALIAÇÃO DO TRABALHO
A contagem separada dos casos de uso do tipo extend e include influenciam
nos resultados gerados pelo método Pontos por Caso de Uso, porém o impacto
depende do tamanho do projeto e da sua complexidade. Ou seja, depende do
número e da complexidade dos casos de uso que compõem o projeto a ser
desenvolvido.
4.1 Avaliação do trabalho realizado
Com o objetivo de avaliar a influência da contagem separada ou não dos casos
de uso do tipo extend e include no método Pontos por Caso de Uso, foi aplicado o
modelo apresentado na seção 3.1, gerando o seguinte resultado:
Figura 6 - Resultado apresentado na aplicação do modelo Fonte: Autoria própria, 2009.
25
O resultado gerado por este trabalho demonstra que realmente a contagem
separada dos casos de uso do tipo extend e include influencia no resultado da
estimativa gerado pelo método PCU. A Figura 6 demonstra os resultados do
percentual de desvio após aplicado o modelo.
Na Figura 6, %N_C_S indica o percentual de desvio entre o valor do tempo
gasto para a realização do projeto (tempo realizado) em relação ao valor do tempo
estimado pela PCU (valor estimado NCS), não considerando a contagem separada
dos casos de uso do tipo extend e include. Porém, o %C_C_S indica o percentual de
desvio entre o valor do tempo gasto para a realização do projeto (tempo realizado)
em relação ao tempo estimado pelo PCU (valor estimado CCS), considerando a
contagem separada dos estereótipos extend e include.
Também, na Figura 6, os projetos foram dispostos de acordo com o seu
tamanho e complexidade, sendo os menores e menos complexos representados
pelo identificador A e B e os maiores e mais complexos sendo representados pelo
identificador E e F, respectivamente nessa ordem. Dessa forma, C e D representam
os projetos intermediários.
Os resultados apresentados no gráfico da Figura 6 mostram que, conforme
aumentam o tamanho e a complexidade dos projetos, aumenta também o percentual
de desvio entre os valores estimados pelo método Pontos por Caso de Uso em
relação ao tempo efetivo de realização do projeto. Porém, observa-se também que
os percentuais de desvio entre o tempo estimado %N_C_S (não consideração a
contagem separada dos casos de uso do tipo extend e include) e %C_C_S
(consideração a contagem separada dos casos de uso do tipo extend e include) se
aproximam. Dessa forma, o gráfico demonstra que o grau descolamento entre os
valores estimados pelo PCU considerando e não considerando a contagem
separada os casos de uso do tipo extend e include não aumentam conforme
aumenta o tamanho e o grau de complexidade dos projetos.
Com esses números apresentados, pode ser observado que a contagem
separada dos casos de uso do tipo extend e include influenciam nos resultados
estimados pelo método Pontos por Caso de Uso, porém, não determinam o que gera
essa influência.
Outra análise importante a ser observada é que, conforme o grau de
complexidade e tamanho do projeto aumenta, também aumenta o percentual de
desvio entre os valores estimados em relação aos valores reais dos projetos. No
26
entanto, apenas essa análise inicial pode ser precipitada, uma vez que os projetos
podem ser influenciados por outros fatores que eventualmente interferem no
andamento dos mesmos, gerando, dessa forma, distorções na análise. Os fatores
que podem influenciar no andamento de um projeto muitas vezes são fatores
externos que devem ser observados, gerenciados e desconsiderados nesse tipo de
trabalho, para não invalidar os resultados gerados pelas estimativas da PCU. Tais
fatores já foram abordados na seção 2, por exemplo: pressões políticas e falta de
motivação da equipe.
Na seção 4.1, destacam-se, entre outros pontos importantes, as seguintes
conclusões:
a) a contagem separada ou não dos casos de uso extend e include
influenciam nos resultados de estimativas gerados pela PCU;
b) à medida que o tamanho e a complexidade dos projetos aumentam, a
diferença dos percentuais de desvio entre os valores estimados pela PCU e
o valor realizado também aumenta;
c) à medida que o tamanho e a complexidade dos projetos aumentam, a
diferença entre os percentuais %N_C_S (não considerando a contagem
separada) e %C_C_S (considerando a contagem separada dos casos de
uso do tipo extend e include) diminui;
d) os valores do percentual de desvio entre %N_C_S e %C_CS não
aumentam conforme aumentam o tamanho e o grau de complexidade dos
projetos.
Com esses resultados, apenas tem-se uma percepção do que gera a influência
nos resultados apresentados pela PCU, na contagem separada ou não dos casos de
uso extend e include.
Com base nos resultados apresentados nesta seção, e como forma de avaliar
este trabalho que objetiva demonstrar qual a influência do uso ou não de casos de
uso do tipo extend e include no resultado das estimativas produzidas pelo PCU, foi
aplicado um novo modelo avaliando o impacto gerado pela contagem separada ou
não desses casos de uso, porém, sem considerar o fator tempo de realização do
projeto. Foram aplicadas simulações de projeto no método Pontos por casos de uso.
O resultado dessa avaliação será apresentado na seção 4.3.
27
4.2 Critérios aplicados no modelo anterior
O resultado obtido por meio da aplicação do modelo apresentado na Figura 5
está composto por seis projetos:
Tabela 4 - Projetos utilizados no modelo aplicado
Fonte: Autoria própria, 2009.
Na Tabela 4, Horas N_C_S significa a quantidade de horas estimadas pelo
método PCU não considerando a contagem separada dos casos de uso do tipo
extend e include; enquanto isso, Horas C_C_S significa a quantidade de horas
estimadas pelo método PCU considerando a contagem separada dos estereótipos
extend e include, e o Peso Total = UUCW (Quantidade de Casos de Uso x
Complexidade). Horas Realizadas corresponde à quantidade de horas efetivamente
realizadas para concluir o projeto.
A fórmula para aplicar o percentual de desvio entre os valores estimados e o
realizado foi definida da seguinte forma:
% desvio = (valor estimado / valor realizado) – 100
Como o objetivo deste trabalho é apenas avaliar a influência da contagem
separada ou não dos estereótipos extend e inlcude, e como forma de viabilizar o
trabalho, os fatores de complexidade técnica e fatores ambientais foram
considerados de forma padrão para não influenciar os resultados. Ou seja, não
foram considerados os fatores de complexidade técnicas e ambientais, pois essa
informação somente seria obtida no momento em que as equipes estavam
desenvolvendo os projetos. Esses fatores podem ter influenciado no percentual de
desvio entre os valores estimados em relação aos valores realizados.
28
4.3 Avaliação do trabalho sem considerar fatores externos
Como forma de avaliar os resultados apresentados a partir do modelo aplicado
na seção 4.1, foi realizada uma nova avaliação deste trabalho, por meio da
aplicação de simulação de projetos.
Como o objetivo deste trabalho é avaliar a influência dos casos de uso do tipo
extend e include no método Pontos por Caso de Uso, ou seja, realmente saber se a
contagem separada ou não desses estereótipos impacta nos resultados gerados
pelo PCU, foram considerados os seguintes critérios:
a) avaliar somente a influência da contagem separada ou não dos casos de
uso do tipo extend e include, sem considerar as horas efetivamente
realizadas;
b) desconsiderar os fatores de complexidade técnica e fatores ambientais,
pois ambos dependem da equipe e do ambiente onde está inserida, algo
que pode ter influenciado no percentual de desvio entre os valores
estimados e realizados apresentados na seção 4.1, conforme já
apresentado pelos trabalhos de Anda et al. (2001), Ribu (2001), Anda,
Mohagheghi e Conradi (2005), nos quais já foram propostos alguns ajustes
nestes fatores;
c) neste trabalho de avaliação sem considerar a influência de fatores
externos, os valores apenas serão influenciados pela contagem separada
ou não dos casos de uso extend e include, pois os demais parâmetros
foram mantidos iguais para não influenciar as comparações dos resultados.
Outra observação importante neste trabalho de avaliação é que foram apenas
considerados os resultados apresentados das estimativas, sem considerar o valor
das horas realizadas, pois este pode ser influenciado por uma série de fatores
externos que independe do método PCU. A Figura 7 demonstra o modelo aplicado
para avaliar o trabalho sem considerar os fatores de influência externa.
29
Figura 7 - Modelo aplicado para avaliar o trabalho sem influência externa Fonte: Autoria própria, 2009.
Com o objetivo de avaliar o trabalho realizado, que propõe demonstrar qual a
influência da contagem separada ou não dos casos de uso do tipo extend e include
no método Pontos por Caso de Uso, foi aplicado o modelo demonstrado na Figura 7,
gerando o seguinte resultado:
Figura 8 - Resultado apresentado na aplicação do modelo sem influência externa Fonte: Autoria própria, 2009.
30
Esse gráfico demonstra que conforme a evolução do tamanho e complexidade
do projeto (os projetos estão dispostos na ordem de A...Z, respectivamente na
sequência do menor ao maior em relação ao tamanho e à complexidade dos
projetos), o percentual de desvio das estimativas se mantém na média 5% para mais
ou para menos, mantendo esse mesmo nível após o projeto D. Dessa forma, o
comportamento do gráfico está em conformidade com o mesmo comportamento
apresentado na seção 4.1, ou seja, a contagem separada dos estereótipos do tipo
extend e include influenciam nos resultados gerados pelo método PCU, dependendo
do tamanho e complexidade dos casos de uso do projeto.
Na Figura 8, %N_C_S indica o percentual de desvio entre o valor estimado
pela PCU, não considerando a contagem separada dos casos de uso do tipo extend
e include; em relação a %C_C_S, indica o percentual do valor estimado pela PCU,
considerando a contagem separada dos estereótipos extend e include.
Com objetivo de entender o que influencia esse percentual de desvio,
apresentam-se as informações que geraram o resultado apresentado na Figura 8.
Tabela 5 - Resultado dos projetos simulados sem a influência externa
Fonte: Autoria própria, 2009.
31
Essas informações disponibilizadas na Tabela 5 demonstram que a influência
da contagem separada ou não dos casos de uso do tipo extend e include somente
recai sobre o resultado se o peso da complexidade dos casos de uso for alterado.
Em algumas situações, existe uma compensação de peso na aplicação da contagem
separada e na contagem não separada dos casos de uso.
Na Tabela 5, N_C_S significa: não considerando a contagem separada dos
casos de uso do tipo extend e include; enquanto isso, C_C_S significa: considerando
a contagem separada dos estereótipos extend e include, e o Peso Total = UUCW
(Quantidade de Casos de Uso x Complexidade).
É importante destacar que os projetos apresentados na Tabela 5, são
diferentes dos projetos demonstrados na Tabela 4 da seção 4.2.
4.4 Avaliação dos resultados apresentados
Os resultados gerados pelos dois modelos aplicados e apresentados nas
seções 4.1 e 4.3 demonstram que realmente a contagem separada ou não dos
casos de uso dos estereótipos tipo extend e include influenciam no resultado gerado
pelo método Pontos por Caso de Uso. Os resultados apresentados demonstram:
a) o impacto da contagem separada nos projetos com UUCW <= 40 é maior
do que a influência apresentada nos demais projetos com UUCW > 40;
b) o percentual da influência nos resultados apresentados na contagem
separada nos projetos com UUCW <= 40 é entre 6% - 9% para mais ou
para menos;
c) o percentual da influência nos resultados apresentados na contagem
separada nos projetos com UUCW > 40 é < 5%, ou seja, menor que os
projetos com UUCW <= 40;
d) à medida que o UUCW aumenta o seu valor, o percentual de influência
tende a diminuir, porém, depende da complexidade e do número de casos
de uso que utilizam os estereótipos do tipo extend e include;
e) dependendo do número de casos de uso que utilizam os estereótipos
extend e include, uma contagem compensa a outra, refletindo num
percentual de influência nula, igual a zero.
As evidências de que projetos de porte menor e complexidade maior são mais
influenciados pela contagem se concretizam: à medida que o impacto do percentual
32
é maior na proporção da quantidade horas ser menor, matematicamente o
percentual é maior. Por outro lado, há evidências de que projeto de porte maior e
complexidade menor terá percentual de influência menor: na medida em que a
proporção de horas aumenta, o percentual diminui. O grande impacto que influencia
nos resultados apresentados pelo PCU é a complexidade dos casos de uso que
gera o valor apresentado como UUCW, que compõe uma parte do cálculo da UUCP,
e esse impacto depende do número de casos de uso que terão a sua complexidade
alterada na aplicação da contagem separada dos casos de uso. É importante
ressaltar que UUCW mede somente a complexidade dos casos de uso.
Quando é aplicado o método PCU sem considerar a contagem separada dos
casos de uso, as transações dos casos de uso secundário são consideradas em
cada caso de uso primário que utilizam. Dessa forma, muitos casos de uso primários
que deveriam ser considerados de complexidade média, acabam elevando o grau
para complexo.
No entanto, quando é realizada a contagem separada dos casos de uso tipo
extend e include, as transações desses casos de uso não são consideradas em
cada caso de uso que utilizam, mas são contadas uma única vez. Dessa forma,
algumas vezes ocorre a compensação de complexidade, onde o caso de uso que
anteriormente era complexo acaba transformando em complexidade média. Algumas
vezes existe uma simples compensação de complexidade, gerando o mesmo
resultado de ambos os modelos (considerando e não considerando a contagem
separada). Porém, também existe a possibilidade da contagem separada gerar um
peso de UUCW menor que a contagem não separada.
Tabela 6 - Tabela da complexidade dos casos de uso
Fonte: Autoria própria, 2009.
33
Esse impacto decorre de um ponto a ser desenvolvido no método, pois
atualmente pode representar uma limitação. Os pesos atribuídos através da tabela
da complexidade dos casos de uso são distintos e não existe uma proporção para
cada transação, mas a um conjunto de transações.
A Tabela 6 demonstra a tabela da complexidade dos casos de uso atual,
aplicando pesos consideráveis e distintos (Simples = peso 5, Médio = peso 10 e
Complexo = peso 15). Isso influencia diretamente no resultado apresentado pela
contagem separada dos casos de uso do tipo extend e include.
Muitas vezes, ocorre da complexidade do caso de uso ficar em uma zona de
fronteira entre uma complexidade e outra, conforme demonstra a Tabela 6, sendo
sensível a qualquer movimento de alteração, impactando diretamente no resultado
gerado pelo método PCU.
Este ponto a ser desenvolvido no método pode ser resolvido ao aplicar uma
tabela menos sensível, utilizando valores proporcionais às transações e não a um
conjunto de transações, dessa forma, estaria cumprindo ao critério de uma métrica
insensível, conforme demonstra a Tabela 7.
Tabela 7 - Tabela da complexidade dos casos de uso – Menos sensível
Fonte: Autoria própria, 2009.
Aplicando a proposta da Tabela 7, provavelmente será reduzido o impacto dos
valores gerados pelo método PCU, pelo motivo da tabela aplicar pesos menos
distintos.
Entretanto, os resultados iniciais demonstram que a redução da influência dos
resultados entre a contagem separada e não separada dos casos de uso do tipo
extend e include não é simplesmente inverso ao porte e complexidade dos projetos.
34
Nesse contexto, não pode ser analisado somente o tamanho ou complexidade dos
projetos, mas sim o comportamento da classificação da complexidade dos casos de
uso em número de transações.
Os resultados iniciais apresentam que, na contagem separada dos casos de
uso extend e include através do método Pontos por Caso de Uso, deve ser
considerada a complexidade dos casos de uso e o número de casos de uso primário
que utilizam os casos de uso secundário. Desta forma, os resultados trarão uma
maior assertividade nas estimativas geradas pelo método PCU.
O estudo apresentado por Carroll (2005) demonstra que conseguiu alcançar
percentuais consideráveis como, por exemplo, um desvio de menos de 9% entre o
valor real e o valor estimado. Ao final desse trabalho, Carroll propõe, entre outras
coisas, a aplicação de coeficiente de risco a ser adicionado no PCU. O
comportamento dos resultados iniciais deste trabalho apresenta um percentual de
desvio menor que 9%, desta forma realmente pode ser aplicado um coeficiente de
risco. Porém a proposta deve ser baseada em critérios técnicos e não de forma
empírica.
Um coeficiente de risco a ser adicionado pode ser o coeficiente de risco de
utilização dos casos de uso do tipo extend e include. O estudo de um novo
coeficiente de risco a ser aplicado no PCU deve levar em consideração a relação do
valor da UUCW e o número de usabilidade dos casos de uso do tipo extend e
include.
35
5 CONCLUSÃO
Estimar não é uma tarefa fácil, no entanto, as métricas disponibilizadas pela
Engenharia de Software apresentam o propósito de auxiliar os profissionais
envolvidos no processo de desenvolvimento de software. Porém, as empresas que
desenvolvem software encontram dificuldades para aplicação do método Pontos por
Caso de Uso, que foi criado para estimar projetos ainda na fase de requisitos. Tais
dificuldades ocorrem pela falta de padrão dos casos de uso, sendo que o principal
artefato para aplicação do método PCU são os casos de uso.
Este trabalho visa contribuir para uma maior assertividade nas estimativas
geradas pelo método Pontos por Caso de Uso. Dessa forma, analisando os
resultados gerados e avaliados por este trabalho, pode-se concluir que a contagem
separada dos casos de uso do tipo extend e include influencia nas estimativas
geradas pelo PCU, porém, depende do tamanho, da complexidade do projeto a ser
desenvolvido e do número de casos de uso que utilizam outros casos de uso de
inclusão (include) e extensão (extend).
Projetos de porte menor são mais influenciados, dependendo da complexidade
do projeto; porém, conforme evolui o porte e a complexidade dos projetos, o
percentual de influência tende a diminuir. No entanto, não deve ser apenas
considerado o porte e complexidade do projeto: outro fator determinante é o grau de
usabilidade dos casos de uso em relação aos estereótipos do tipo extend e include.
Uma das vantagens da contagem separada dos casos de uso do tipo extend e
include são a maior precisão nos resultados das estimativas geradas pelo PCU.
Porém o impacto da influência média dos projetos ficou em torno de 5%, devendo as
empresas avaliarem se este percentual realmente deve ser considerado relevante ou
não em suas estimativas.
Uma das desvantagens da contagem separada dos casos de uso do tipo
extend e include no método PCU são os pesos atribuídos a partir da tabela da
36
complexidade dos casos de uso, pois não existe valor proporcional a cada
transação, mas a um conjunto de transações, sendo que para o cálculo do método
PCU é aplicada a tabela da complexidade dos casos de uso, com pesos distintos e
valores consideráveis. Isso influencia diretamente no resultado apresentado pela
contagem separada dos casos de uso do tipo extend e include.
A tarefa de estimar um projeto não é fácil, mas isso desafia os profissionais e
as empresa de TI diariamente. O mundo científico deve aplicar novos estudos para
contribuir com propostas para uma melhor distribuição dos pesos aplicados na
tabela de complexidade dos casos de uso e a possibilidade de aplicar um coeficiente
de risco ao método, sendo esses os pontos a serem desenvolvidos na busca da sua
maior assertividade nas estimativas geradas através do método Pontos por Caso de
Uso (PCU).
5.1 Trabalhos futuros
Este estudo gera conhecimento e recomenda a aplicação de outros trabalhos a
partir dos dados dispostos neste trabalho e das informações aqui apresentadas.
Entre os trabalhos futuros recomendados a partir deste, destacam-se:
a) realizar um trabalho aplicado em estimativas de software, num ambiente
próprio de uma fábrica de desenvolvimento, adicionando ao método Pontos
por Caso de Uso um coeficiente de risco de usabilidade de inclusão e
extensão. Esse coeficiente deverá ser definido no trabalho futuro a ser
realizado, aplicando o valor do coeficiente proporcional aos valores
apresentados neste trabalho. Os dados que servirão de base para definir o
valor do coeficiente estão dispostos na Tabela 5 através dos valores
apresentados nas colunas: Peso Total (não considera a contagem
separada), Peso Total (considera a contagem separada), Diferença de
Peso, % N_C_S e % C_C_S. Também se recomenda que o trabalho futuro
efetue o dimensionamento dos valores ideais de mínimos e máximos para
cada classe de valor a ser aplicado um percentual distinto no coeficiente de
risco;
b) realizar um trabalho aplicado em estimativas de software, também dentro
de um ambiente próprio de uma fábrica de desenvolvimento, utilizando uma
proposta diferente da atual classificação da complexidade dos casos de
37
uso, deve ser observado a proporcionalidade além de Simples, Média e
Complexa. Como recomendação para o trabalho futuro, sugere-se verificar
a possibilidade de utilizar a estratégia de dimensionar o valor do peso da
tabela da complexidade dos casos de uso proporcional a cada transação e
não mais a um conjunto de transações, dessa forma reduzindo o impacto
atual gerado através da aplicação de pesos muito distintos entre uma
classificação de complexidade para a outra. A Tabela 2, que apresenta os
critérios atuais para classificação da complexidade dos casos de uso, deve
ser observada a Tabela 7 para definir novos valores e regras de
proporcionalidade.
Recomenda-se que novos trabalhos sejam realizados com o objetivo de buscar
um maior aprimoramento da técnica, para que aplicação do método Pontos por Caso
de Uso gere estimativas ainda mais assertivas, cumprindo, dessa forma, o seu papel
de importante ferramenta para o apoio gestão no processo de desenvolvimento de
software.
38
REFERÊNCIAS
ABREU, Fernando Brito e. Metrics for object-oriented desing on software quality. In: PROCEEDINGS OF THE 3 RD INTERNATIONAL SOFTWARE METRICS SYMPOSIUM, 3., 1996, Berlim, Germany. Artigo. Disponível em: <http:// eprints.kfupm.edu.sa/38200/>. Acesso em: 24 maio 2009.
ANDA, Bente et al. Estimating software development effort based on use cases - experiences from industry. In: INTERNATIONAL CONFERENCE ON THE UNIFIED MODELING LANGUAGE, 4., 2001, Toronto. Artigo. Toronto, Canadá: Martin Gogolla and Cris Kobryn (editors), LNCS 2185, Springer Verlag, p. 487-502. Disponível em: <http://www.idi.ntnu.no/emner/tdt4290/docs/faglig/uml2001-anda.pdf>. Acesso em: 20 maio 2009.
ANDA, Bente; ANGELVIK, Endre; RIBU, Kirsten. Improving estimation practices by applying use case models. In: INTERNATIONAL CONFERENCE ON PRODUCT FOCUSED SOFTWARE PROCESS IMPROVEMENT, 4., 2002. Artigo. Disponível em: <http://portal.acm.org/citation.cfm?id=713661>. Acesso em: 24 maio 2009.
ANDA, Bente; MOHAGHEGHI, Parastoo; CONRADI, Reidar. Effort estimation of use cases for incremental large-scale software development. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 27., 2005, St. Louis, MO, USA. Artigo. Disponível em: <http://portal.acm.org/citation.cfm?id=1062455.1062516>. Acesso em: 24 maio 2009.
ANDRADE, Edméia Pereira de. Pontos de Caso de Uso e Pontos de Função na gestão de estimativa de tamanho de projetos de software orientados a objetos. 2004. 132 f. Dissertação (mestrado) - Universidade Católica de Brasília, Curso de Pós-Graduação stricto sensu em Gestão do Conhecimento e Tecnologia da Informação. Disponível em: <http://www.bfpug.com.br/Artigos/UCP/ Tese%20Edmeia.zip>. Acesso em: 20 maio 2009.
BELGAMO, Anderson. CUCCRA: técnicas de leitura para construção de modelos de casos de uso e análise do documento de requisitos. 2004. 157 f. Dissertação (mestrado) - Universidade Federal de São Carlos, Curso de Pós-Graduação em Ciência da Computação. Disponível em: <http://www.bdtd.ufscar.br/tde_busca/ arquivo.php?codArquivo=801>. Acesso em 4 abr. 2007.
BELGAMO, Anderson; FABBRI, Sandra. Um estudo sobre a influência da sistematização da construção de modelos de casos de uso na contagem dos pontos de casos de uso. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 3., 2004, Brasília. Artigo. Disponível em: <http://ftp.mct.gov.br/Temas/info/Dsi/PBQP/ IIISBQS/ST7_2.pdf>. Acesso em: 3 abr. 2007.
39
CALAZANS, Angélica; OLIVEIRA, Marcelo de; DIAS, Zeno. Avaliação do processo de estimativas de tamanho, custo e duração para construção do produto software. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, São Paulo. Artigo. Disponível em: <http://www.simpros. com.br/simpros2004/Apresentacoes_PDF/Artigos/Art_02_Simpros2004.pdf>. Acesso em: 20 maio 2009.
CARROLL, Edward. Estimating software based on use case points. In: CONFERENCE ON OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND APPLICATIONS, 20., 2005, San Diego, CA, USA. Artigo. Disponível em: <http://portal.acm.org/citation.cfm?id=1094855.1094960>. Acesso em: 24 maio 2009.
CARVALHO, Gonçalo Lages de. Métricas de modelação de software. 2004. Disponível em: <http://berlin.inescid.pt/cadeiras/pfsi/PFSI2003/SEMINARIO/ pdfs/metricas-goncalo-carvalho.pdf>. Acesso em: 20 maio 2009.
CHÁVEZ, Michelet. Estimativas de esforço de projetos de software utilizando pontos de caso de uso e redes neurais artificiais. 2005. 53 f. Trabalho de Conclusão de Curso (graduação) - Curso de Ciência da Computação - Universidade Federal de Lavras, Minas Gerais, 2005. Disponível em: <http://cc.msnscache.com/ cache.aspx?q=%22estimativas+de+esforco+de+projetos+de+software+utilizando+pontos+de+caso+de+uso+e+redes+neurais+artificiais%22&d=75828820837495&mkt=pt-BR&setlang=pt-BR&w=4e6b5756,deb0c3c4>. Acesso em: 23 maio 2009.
DEMARCO, Tom. Controlling Software Projects: management, measurement & estimation. Englewood Cliffs, NJ: Prentice Hall, 1982.
FREIRE, Herval. Calculando estimativas: o Método de Pontos de Caso de Uso. Developer’s Magazine, n. 78, fev. 2003. Disponível em: <http://www.cnnt.com.br/ files/usecasepoints.pdf>. Acesso em: 20 maio 2009.
KARNER, Gustav. Resource estimation for objectory projects. Objective Systems SF AB. 1993. Disponível em: <http://www.bfpug.com.br/Artigos/UCP/Karner%20-%20Resource%20Estimation%20for%20Objectory%20Projects.doc>. Acesso em: 20 maio 2009.
MENESES, Javé de. Inspector: um processo de avaliação de progresso para projetos de software. 2001. 189 f. Dissertação (mestrado) - Universidade Federal de Pernambuco, Curso de Pós-Graduação em Ciência da Computação. Disponível em: <http://www.cin.ufpe.br/~gmp/docs/papers/dissertacao-inspector-final.pdf>. Acesso em: 23 maio 2009.
MONTEIRO, Tatiana; PIRES, Carlo Giovano S.; BELCHIOR, Arnaldo Dias. Estimativas por tipo de produto de trabalho: uma extensão da técnica PCU para CMMI-SW Nível 2. In: CONFERÊNCIA LATINO-AMERICANA DE INFORMÁTICA,
40
30., 2004, Peru. Artigo. Disponível em: <http://www.clei.cl/nuevaweb/cleiversion/ 2004/es/Wc4d46f6de9cee.htm>. Acesso em: 24 maio 2009.
PEÑALVO, Francisco José García; ESCUDERO, Pedro Jesús Vázquez; GARCÍA, María N. Moreno. Métricas orientadas a objetos. Departamento de Informática y Automática, Universidad de Salamanca, 2001. Disponível em: <http://diaweb.usal.es/ diaweb20/archivos/10001122DPTOIA_IT_2001_002.pdf>. Acesso em: 23 maio 2009.
RIBU, Kirsten. Estimating object-oriented software projects with use cases. 2001. 133 f. Master of Science Thesis - Departament of Informatic, University of Oslo, Oslo, Norway. Disponível em: <http://heim.ifi.uio.no/%7Ekribu/oppgave.pdf>. Acesso em: 20 maio 2009.
SCHNEIDER, Geri; WINTERS, Jason. Applying use cases: a practical guide. 2. ed. [S.l.]: Addison Wesley, 2001.
TANAKA, Sergio A.; BARROS R. M.; NUNES, R. L. Aplicação de métricas utilizando casos de uso. In: SEMANA DE COMPUTAÇÃO DA UNIVERSIDADE ESTADUAL DE LONDRINA, 2., 2005, Londrina. Artigo. Disponível em: <http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4705668H9>. Disponível em: 5 abr. 2007. VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de pontos de função: medição, estimativas e gerenciamento de projetos de software. 3. ed. São Paulo: Érica, 2005.
