_pontos de Casos de Uso

7/28/2019 _pontos de Casos de Uso

1/182

UNIVERSIDADE FEDERAL DE SO CARLOS

CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA

PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO

DISSERTAO DE MESTRADO

GERAO DE PONTOS DE CASOS DE USO NOAMBIENTE COCAR

MARCOS DANILO CHIODI MARTINS

So CarlosJaneiro/2007


2/182

Ficha catalogrfica elaborada pelo DePT daBiblioteca Comunitria da UFSCar

M386gpMartins, Marcos Danilo Chiodi.

Gerao de pontos de casos de uso no ambiente Cocar /Marcos Danilo Chiodi Martins. -- So Carlos : UFSCar, 2008.

169f.

Dissertao (Mestrado) -- Universidade Federal de So

Carlos, 2007.

1. Mtricas de software. 2. Pontos de casos de uso. 3.Modelo de casos de uso. 4. Software desenvolvimento. I.Ttulo.

CDD: 005.1 (20a)


3/182

Universidade Federal de So CarlosCentro de Cincias Exatas e de TecnologiaPrograma de Ps-Graduao em Cincia da Computao

"Gerao de Pontos de Casos de Uso no AmbienteCOCAR"

MARCOS DANILO CHIODI MARTINS

Dissertao de Mestrado apresentada aoPrograma de Ps-Graduao em Cincia daComputao da. Universidade Federal de SoCarlos, como parte dos requisitos para aobteno do ttulo de Mestre em Cincia daComputao.Membros da Banca:

~!~clProfa. Dra. Sandra Camargo P. Ferraz Fabbri(Orientadora - DCIUFSCar)

P~~Wel~(ICMCIUSP)

~"" ~ 0~~ JtJc);A)i,Prof. Dr. Auri Marcelo Rizzo Vincenzi(UNlSANTOS)

So CarlosJaneiro/2007


4/182

DEDICATRIA

A minha me Marli, irm Mariele, querida noiva Carole padrasto Paulo pelo carinho, incentivo

e pacincia em todos os momentos.Amo muito todos vocs.


5/182

AGRADECIMENTOS

Acima de tudo a Deus por me proporcionar a sabedoria, a sade e a coragem necessrios para

me permitir realizar este trabalho.

A minha orientadora, Prof. Dr. Sandra C.P.F. Fabbri, pela confiana, ensinamentos,

motivao e excelente orientao, alm da grande pacincia e dedicao.

A Prof. Dr Maria da Graa Brasil Rocha pela colaborao com a parte de implementao da

ferramenta.

Em especial minha me Marli e irm Mariele pelo apoio e incentivo, nunca me permitindo

o desnimo e sempre me mostrando o melhor caminho.

minha sempre amorosa e solcita noiva Carol pela colaborao nas revises, pelo apoio,

incentivo, carinho, pacincia e compreenso nos meus momentos de ausncia ocasionados

por este trabalho.

Ao diretor Lcio da empresa AGX Tecnologia LTDA e diretora Magda, da empresa

VoxAge Teleinformtica LTDA, pela compreenso, apoio, incentivo e fornecimento de

informaes fundamentais para a realizao deste trabalho.

Aos companheiros de mestrado e amigos Andr e Bruno e ao amigo de cruz Pedro, pelos

conhecimentos compartilhados e pela enorme amizade que cultivamos. Ao amigo Maurcio

agradeo as contribuies tcnicas para a implementao da ferramenta, sem as quais

certamente este trabalho no teria sido concludo.

secretria da Ps-Graduao, Cristina e Miriam, pelos seus servios sempre bem

prestados e a toda comisso da PPGCC pela compreenso dos contratempos acontecidos

durante este trabalho.

Aos professores membros da banca examinadora por prestigiarem este trabalho com sua

presena, crticas e sugestes de melhoria.


6/182

SUMRIOSUMRIO......................................................................................................................................................4

LISTA DE FIGURAS ............................................................... ............................................................... .....7

LISTA DE TABELAS...................................................................................................................................8

LISTA DE QUADROS ............................................................. ............................................................... .....9

ABSTRACT ............................................................... ........................................................... .......................11

CAPTULO 1 INTRODUO...................................................................................1

1.1 Contexto...........................................................................................................................................4

1.2 Motivao e Objetivos.....................................................................................................................6

1.3 Organizao do Trabalho...............................................................................................................6

CAPTULO 2 - ENGENHARIA DE REQUISITOS....................................................8

2.1 Consideraes Iniciais.....................................................................................................................8

2.2 Engenharia de Requisitos Principais Conceitos ...................................................... ..................9

2.3 Consideraes Finais.....................................................................................................................28

CAPTULO 3 - MODELAGEM DE REQUISITOS COM CASOS DE USO.............30

3.1 Consideraes Iniciais...................................................................................................................30

3.2 Diagramas de Casos de Uso..........................................................................................................31

3.3 Especificao de Casos de Uso ............................................................ .........................................35


CAPTULO 4 - MTRICAS DE TAMANHO DE SOFTWARE................................39

4.1 Consideraes Iniciais...................................................................................................................39

4.2 Pontos de Casos de Uso.................................................................................................................40

4.3 Pontos por Funo.........................................................................................................................45


CAPTULO 5 - TRABALHOS RELACIONADOS...................................................535.1 Consideraes Iniciais...................................................................................................................53


7/182

v

5.2 Trabalhos Tericos........................................................................................................................54

5.3 Ferramentas para Automatizao de Mtricas de Software.....................................................89


CAPTULO 6 - O AMBIENTE COCAR.....................................................................956.1 Consideraes Iniciais...................................................................................................................95

6.2 Funcionalidades do Ambiente COCAR .........................................................................................96 6.3 Aspectos de Implementao do Ambiente COCAR....................................................................100

6.3.1 Processo de Desenvolvimento............... ........................................................... ................................ 1006.3.2 Projeto ....................................................... ................................................................ ....................... 1036.3.3 Implementao ......................................................... ................................................................ ........ 107

6.4 Requisitos Funcionais do Ambiente COCAR Pontos de Caso de Uso....................................1086.4.1 Classificao Automtica da Complexidade dos Casos de Uso ....................................................... 1096.4.2 Clculo da Medida dos Pontos de Caso de Uso ........................................................... .................... 1096.4.3 Transformao da mtrica de PCU em PF ........................................................... ............................ 111

6.5 Consideraes Finais...................................................................................................................111

CAPTULO 7 - EXEMPLO DE USO DO AMBIENTE COCAR ...............................1137.1 Consideraes Iniciais.................................................................................................................113

7.2 Apresentao do Ambiente COCAR............................................................................................115 7.3 Criao de Sistema......................................................................................................................116

7.4 Cadastramento de Requisitos.....................................................................................................117

7.5 Criao do Modelo de Casos de Uso..........................................................................................1217.5.1 - Actor-Goal Reading Technique ...................................................................... ............................... 1217.5.2 - Use Case Reading Technique (UCRT) ............................................................. ............................. 125

7.6 Automatizao da Tcnica PCU e Gerao da mtrica de PF ................................................130

7.7 Avaliao do Ambiente COCAR ..................................................................................................133 7.7.1 Planejamento do Estudo de Caso ............................................................ ......................................... 1337.7.2 Execuo do Estudo de Caso............................................................................... ........................... 1347.7.3 Coleta e Anlise de Dados.................................................................................. ............................ 135

7.8 Consideraes Finais...................................................................................................................138

CAPTULO 8 - CONCLUSO..............................................................................139

8.1 Contribuies e Limitaes deste Trabalho..............................................................................141

8.2 Lies Aprendidas.......................................................................................................................143

8.3 Trabalhos Futuros.......................................................................................................................144

REFERNCIAS BIBLIOGRFICAS.......................................................................146


8/182

vi

APNDICE I............................................................................................................157

APNDICE II...........................................................................................................163


9/182

vii

LISTA DEFIGURAS

Figura 1 Subreas da engenharia de requisitos [SWEBOK, 2004] ........................................10

Figura 2 Representao grfica de um Caso de Uso .............................................................31Figura 3 Atores com relacionamento de generalizao (adaptado de Boock et al., 2000)....33Figura 4 Casos de Uso e seus relacionamentos (adaptado de Boock et al., 2000)...............35Figura 5 Principais caractersticas e diferenas entre APF e PCU........................................51Figura 6 Processo de estimativa de esforo [Carrol, 2005]...................................................64Figura 7 Formulrio de Casos de Uso Preliminares [Belgamo, 2004]. .................................68Figura 8 - Formulrio de Especificao de Casos de Uso........................................................68Figura 9 - Arquitetura da ferramenta U-EST............................................................................84Figura 10 Formato de um Requisitos Funcional [Kawai, 2005]. ..........................................86Figura 11 Diagrama de Classe UML do Padro DAO[Java, 2006] ....................................105Figura 12 - Diagrama de Classe UML do Padro DAO[Java, 2006] .....................................105Figura 13 - Diagrama de Classes UML do Padro Transfer Object [Java, 2006]..................106Figura 14 - Diagrama de Classes e Seqncia UML do Padro Transfer Object [Java, 2006].................................................................................................................................................106Figura 15 - Diagrama de Classes UML da funcionalidade Cadastrar Sistema..............107Figura 16 - Prototipao Evolucionria [Sommerville, 2003] ...............................................107Figura 17 Interface de help do sistema COCAR...................................................................115Figura 18 Escolha de um sistema ou a criao de um novo sistema...................................116Figura 19 Selecionar um sistema j cadastrado como ativo................................................116Figura 20 Cadastramento de um sistema no ambiente COCAR ..........................................117Figura 21 Cadastramento de Requisitos no ambiente COCAR. ...........................................119

Figura 22 Cadastramento de Entradas no ambiente COCAR ...............................................120Figura 23 Cadastramento de Atores (primrio e secundrio)..............................................120Figura 24 Cadastramento de Solicitante de Requisitos .......................................................120Figura 25 Cadastramento de Gerente de Requisito .............................................................121Figura 26 - Processo de marcao de atores, funes e restries. ........................................123Figura 27 Determinao dos atores e objetivos...................................................................124Figura 28 - Exemplo da interface de resoluo de redundncia intra-atores e inter-atores....125Figura 29 - Exemplo do FAO gerado pela aplicao da AGRT no ambiente COCAR..........125Figura 30 Primeira Etapa: Formulrio de Casos de Uso Preliminares................................127Figura 31 Interface para a especificao dos Casos de Uso e Janela com a janela dosrequisitos relacionados e janela de especificao de curso alternativo ..................................129

Figura 32 Classificao de complexidade dos atores..........................................................130Figura 33 Resultado do Clculo do PCU no ajustado .......................................................131Figura 34 Itens de complexidade ambiental e complexidade tcnica julgados pelo usurio................................................................................................................................................132Figura 35 Relatrio de Pontos de Caso de Uso Ajustado....................................................132


10/182

viii

LISTA DETABELAS

Tabela 1 Forma de classificao dos atores com seus respectivos pesos [Karner, 1993]. .....41

Tabela 2 Forma de classificao dos Casos de Uso com seus respectivos pesos [Karner,1993].........................................................................................................................................41Tabela 3 Fatores que contribuem para a complexidade do sistema [Medeiros, 2004; Karner,1993].........................................................................................................................................42Tabela 4 Fatores que contribuem para a eficincia [Medeiros, 2004; Karner, 1993] ............43Tabela 5 Estimativas de especialistas, estimativa por Pontos de Casos de Uso, e Esforo (emhoras) [Anda et al., 2001]. ........................................................................................................55Tabela 6 Resumo dos Pontos de Casos de Usopara projetos incrementais [Mohagheghi etal., 2005]. ..................................................................................................................................59Tabela 7 - Esforo estimado por projetos................................................................................66Tabela 8 - Esforo de desenvolvimento por Caso de Uso........................................................74Tabela 9 - Horas Estimadas X Horas Gastas dos projetos das quatro empresas......................74Tabela 10 Regras para o clculo da Profundidade das Alteraes de um Caso de Uso........76Tabela 11 Principais funcionalidades da ferramenta Construx Estimate [Construx, 2005]..90Tabela 12 Principais funcionalidades da ferramenta Cost Xpert [Costxpert, 2005]. ............91Tabela 13 Principais funcionalidades da ferramenta COSMOS [Cosmos, 2005]. ................91Tabela 14 Principais funcionalidades da ferramenta EEUC [EEUC, 2005]. ........................92Tabela 15 Resumo das funcionalidades das ferramentas analisadas.....................................92Tabela 16 Dados coletados do Estudo de Caso ....................................................................136


11/182

ix

LISTA DEQUADROS

Quadro 1 Formulrio de Especificao de Casos de Uso [Belgamo, 2004]..........................37

Quadro 2 Complexidade funcional [IFPUG, 1999]. .............................................................46Quadro 3 Complexidade de EE (IFPUG, 1999). ...................................................................48Quadro 4 Complexidade de SE [IFPUG, 1999]. ...................................................................48Quadro 5 Exemplo de clculo dos Pontos por Funo No Ajustados [IFPUG, 1999]........49Quadro 6 - Caractersticas gerais do sistema [Andrade, 2004]. ...............................................49Quadro 7 -Passos para a determinao do VFA [IFPUG, 1999]. ..........................................50


12/182


13/182

ABSTRACT

The objective of this paper was to implement an initial version of a development supportenvironment named COCAR based on the Use Case Model. Even though the conception and

some features of this environment are the outcome of several other master papers, this work

emphasises the relevance of the Use Case Point metric (PCU). This metric strengthens the

usage of estimates which are of fundamental importance for the calculation of a system

development time. Furthermore, such a metric is associated to one of the main drivers of a

software product quality, which is the ability to meet delivery time. With the advent of the

object oriented development paradigm, the Use Case Point metric based on the Use Case

Model has been highlighted. However, given the lack of formality and standardization,

specifying and building these models a PCU metric may be jeopardized. In the scope of this

work, there have been relevant contributions to building such an environment implementing

a technique called TUCCA which helps with the model standardization, a functionality that

supports the insertion of system requirements in the environment and the generation of PCU

as in the model generated by TUCCA application. In the assessment process of the COCAR

environment an informal case study, in which a specification of actual software from a

development company, has been carried out, producing Use Case Models, PCUs and effort

estimates, both compared against the industry benchmarks. The results of this research

showed that for this particular situation the output from the COCAR environment were very

close to those defined by the industry.


14/182

Captulo 1 Introduo 1___________________________________________________________________________

Captulo 1 IntroduoIntroduo

Segundo MCT (2003), o setor de produo de software no Brasil tem crescidovertiginosamente nas ltimas dcadas. O Brasil tem o stimo maior mercado mundial de

software com vendas de US$ 7,7 bilhes em 2001, importa o equivalente a US$ 1 bilho e

exporta em torno de US$ 100 milhes. O mercado brasileiro apresentou um crescimento

anual mdio de 11% entre 1995 e 2002, cerca de cinco vezes maior do que a expanso do

PIB no perodo. o segmento que mais cresce dentro da indstria brasileira de Tecnologia da

Informao (hardware, servios e software).

Com tanta concorrncia no mercado nacional, no mercado internacional o cenrio no

diferente, as empresas esto em busca constante da melhoria de qualidade no

desenvolvimento de produtos de software e prestao de servios.

Como prova disso tem-se o aumento de empresas de software certificadas em Capability

Maturity Model(CMM), que um modelo de qualidade de processo de software, saltando de

uma empresa certificada em 1997 para 30 certificaes em 2003 [MCT, 2005].

Dentro deste contexto, saber o tamanho, a complexidade, custos efetivos, tempo e esforo

despendidos na construo de seus produtos pode representar para as empresas de tecnologia

de informao um diferencial competitivo muito grande, tanto para aumentar o nvel de

qualidade do seu processo de desenvolvimento, sempre se certificando de que o cliente ir

receber o produto no prazo correto, quanto na melhora em matrias administrativas como

contratao de recursos humanos, medidas de produtividade, decises de projetos, anlise de

risco, relacionamento cliente fornecedor, entre outros [Andrade, 2004 apud Hazan, 1999;

Garmus & Herron, 2000; Longstreet, 2002].


15/182


Entre as mtricas citadas, a de tamanho de um produto de software , talvez, uma das mais

importantes, pois por meio dela que se faz possvel estimar o cronograma, custos, esforos

e tempo de desenvolvimento do software [Andrade, 2004 ; Karner, 1993 ; Chen et al., 2004],

informaes estas imprescindveis para a construo do plano de desenvolvimento de

software [Caldieira et al., 1998].

Contudo, pelos motivos apresentados anteriormente, necessrio ento que a medida de

tamanho de software seja feita logo nas fases iniciais do processo de desenvolvimento, e que

seja atualizada no decorrer do projeto, com todas as informaes sobre o software que

estiverem disponveis.

Sendo assim, vrias mtricas vm sendo estudadas ao longo dos anos com o intuito de se

desenvolver novas tecnologias que garantam medidas de tamanho de software mais precisas,

para um melhor gerenciamento do processo de desenvolvimento do software, entre elas

pode-se citar: Linhas de Cdigo Fonte, Pontos por Funo,Bang,Feature Points, Pontos de

Caso de Uso,Internet Points,Domino Points,entre outros [Chen et al., 2004 & McPhee, 1999

& Costxpert, 2005].

Pressman (2006) faz uma diviso entre mtricas orientadas a tamanho (como a Linhas deCdigo Fonte) e mtricas orientadas a funo (como Pontos por Funo e Pontos de Caso de

Uso). Contudo, ele afirma tambm que mtricas orientadas a funo, ao final do seu clculo,

so usadas de forma anloga s mtricas orientadas a tamanho. Ainda, Albrecht (1979)

afirma que Pontos por Funo medem o tamanho de um software de acordo com as

funcionalidades identificadas nos requisitos dos usurios. Portanto, neste trabalho, assim

como em Andrade (2004), as mtricas orientadas a funo sero consideradas como uma

forma de medir o tamanho do software e por isso sero tratadas como mtricas de tamanho[Medeiros, 2004], mesmo porque j sabido da literatura que h vrios mtodos de

transformao de mtricas orientadas a funo para mtricas orientadas a tamanho

[Sommerville, 2003; Anda et al., 2001; Smith, 1999, Fetcke et al., 1998].

Desde a dcada de 1970 h duas mtricas de tamanho de software que predominaram na

indstria nacional e internacional de desenvolvimento: SLOC (Source Lines of Code) e

Pontos por Funo. No Brasil, em 2001, de 30% das empresas pesquisadas que usavam

algum tipo de mtrica de tamanho de software, 10,3% utilizavam o SLOC e 18,2%

utilizavam Pontos por Funo [MCT, 2002].


16/182


No entanto, segundo Chen et. al (2004), h algumas desvantagens em usar as mtricas de

SLOC e Pontos por Funo. Chen et al. (2004) diz que a contagem exata do SLOC s

acontece depois que a construo do software j foi finalizada quando, na verdade, o

interessante seria que essa contagem fosse a mais acurada possvel j no incio do

desenvolvimento do software. J a mtrica de Pontos por Funo no apoiada por nenhuma

ferramenta que faa a contagem automaticamente, sendo que esta uma operao manual e

totalmente dependente da experincia do profissional que est fazendo a contagem, tornando

a mtrica totalmente subjetiva e dependente do ponto de vista desse profissional.

Alm disso, a mtrica Pontos por Funo baseada no paradigma procedimental, o qual

separa dados de funo, deixando esse tipo de mtrica pouco adequada para os novosdesenvolvimentos baseados no paradigma de orientao a objetos, o qual trabalha com dados

e funcionalidades de forma combinada [Carbone & Santucci, 2002].

Por ltimo, de acordo com Andrade (2004), a tcnica Pontos por Funo, apesar de medir o

tamanho do software sob o ponto de vista do usurio, usa como base as informaes geradas

durante todo o processo de desenvolvimento do produto, principalmente as da fase de

projeto. Sendo assim, a medida vai ficando mais acurada somente na fase do projeto, o que,

embora seja muito mais vantajoso do que o oferecido pelo SLOC, ainda no to satisfatrio

quanto a indstria de desenvolvimento de software necessita.

Com o aumento do uso do paradigma de desenvolvimento orientado a objeto, o Modelo de

Caso de Uso tem sido amplamente utilizado para a modelagem de requisitos. No entanto,

apesar dele ter surgido junto com o modelo de desenvolvimento de software orientado a

objeto, o Objectory [Jacobson et al., 1992], o Modelo de Casos de Uso pode ser usado

independentemente deste paradigma, dando suporte para outras fases do desenvolvimento[Belgamo, 2004].

O Modelo de Casos de Uso se prope a capturar e descrever os requisitos funcionais do

software, se configurando como uma atividade que poder ser executada normalmente

durante a fase de elicitao e anlise de requisitos para a representao com preciso dos

requisitos descritos pelos usurios logo no incio do processo de desenvolvimento do

software.


17/182


Pensando na adaptao da tcnica Anlise de Pontos por Funo para atender o novo

paradigma de desenvolvimento e ainda tentando prover uma medida de tamanho de software

mais precisa logo nas fases iniciais do desenvolvimento do software, Gustav Kerner definiu

uma nova mtrica para medir tamanho de software chamada Pontos de Caso de Uso (PCU)

[Karner, 1993; Damodaran, 2003].

Como o PCU usa um modelo como base para o clculo da mtrica de tamanho, fica vivel a

construo de ferramentas para a realizao do clculo automtico dessa mtrica deixando o

processo mais barato, rpido e manutenvel.

O problema para a construo desse tipo de ferramenta que um Caso de Uso pode ser

especificado de diversas maneiras, a saber: texto estruturado informal, texto estruturado

formal, pseudocdigo, fluxograma, redes de Petri ou linguagens de programao e ainda

podendo fazer uso de diversos graus de detalhamento [Cockburn, 2001; Boock et al., 2000].

Sendo assim, a maneira de especificao do Caso de Uso e o grau de detalhamento usado

podem influenciar muito a contagem dos Pontos de Caso de Uso bem como tornar invivel a

automatizao do processo. No entanto, embora existam vrios trabalhos que discutem e

propem frameworks, templates e protocolos na tentativa de padronizar a escrita deste

modelo [Cockburn, 2001; Ryser & Glinz, 2000; Belgamo 2004], no existe um formato

padro para tanto.

Assim, diferentemente dos Pontos por Funo, que segundo Kusumoto et al. (2004) no

podem ser automatizados, pois os itens envolvidos na contagem so subjetivos e melhor

identificados j na fase de projeto, o Pontos de Caso de Uso podem ser computados logo no

incio do desenvolvimento desde que adote um padro de especificao de Caso de Uso.

1.1 Contexto

Dada a importncia da fase de Engenharia de Requisitos para o ciclo de desenvolvimento de

software, o que sabido da prpria literatura e que ficou caracterizado com alguns dados

apresentados anteriormente, alguns trabalhos relacionados com esse tema tm sido orientados

na mesma linha de pesquisa que este trabalho est inserido.

Um desses trabalhos foi o mestrado de Belgamo [Belgamo, 2004; Belgamo & Fabbri, 2005],

que props uma tcnica de leitura para dar apoio construo de Modelos de Casos de Uso

(Diagrama e Especificao dos Casos de Uso), de tal forma que medida que esses modelos


18/182


so construdos, faz-se tambm uma reviso do Documento de Requisitos, uma vez que este

pode no ter passado por um processo de inspeo ou que, mesmo que tenha passado, nem

todos os defeitos podem ter sido detectados.

Com base nos resultados de alguns estudos experimentais j realizados e publicados por

Belgamo [Belgamo & Fabbri, 2004a; Belgamo & Fabbri, 2004b] pode-se dizer que a tcnica

proposta TUCCA1: Technique for Use Case Construction and Construction-based

Requirements Analysis contribui substancialmente para a construo de Modelos de Casos

de Uso mais padronizados, de tal forma que a experincia e a subjetividade do projetista no

tenham tanta interferncia nessa construo. Os Modelos de Casos de Uso gerados nos

estudos experimentais realizados por Belgamo foram tambm avaliados por uma tcnicaproposta por Anda & Sjoberg (2002) e, de acordo com essa tcnica, os modelos satisfazem os

requisitos de qualidade que um bom modelo deve apresentar [Belgamo et al., 2005].

Como vrios passos da TUCCA so bastante procedimentais, vivel a construo de uma

ferramenta que d apoio aplicao da tcnica. Alm disso, um outro trabalho de mestrado

[Kawai, 2005] definiu um formato para especificao de requisitos de forma que a aplicao

da TUCCA seja facilitada.

Assim, dada a relevncia da fase de engenharia de requisitos; dado que os modelos de casos

de uso so bastante utilizados na prtica; que se tem a tcnica TUCCA que ajuda na

padronizao para gerao desses modelos; que se tm diretrizes para especificao dos

requisitos de um sistema de forma a facilitar a aplicao da TUCCA; e que a determinao

do prazo de entrega de um produto uma das principais caractersticas de qualidade de um

processo de desenvolvimento, decidiu-se, no grupo de pesquisa desenvolver um ambiente de

apoio ao desenvolvimento de software que pudesse dar suporte a vrias atividades, tendocomo foco principal o modelo de casos de uso. Outras funcionalidades que podem compor

esse ambiente e que j esto em desenvolvimento no grupo de pesquisa so o gerenciamento

de requisitos e a gerao de casos de teste a partir de casos de uso.

1 Essa tcnica era referenciada anteriormente por GUCCRA-Guidelines for Use Case Construction andRequirements Analysis.


19/182


1.2 Motivao e Objetivos

Dado o contexto apresentado anteriormente o principal objetivo deste trabalho foi especificar

e automatizar a mtrica PCU no ambiente COCAR. Para tanto, foi preciso que se tivesse o

modelo de casos de uso do sistema para que outras funcionalidades pudessem ser geradas

com base nele. Assim, como a TUCCA [Belgamo, 2004] e as diretrizes para especificao de

requisitos [Kawai, 2005] foram definidas em outros trabalhos de mestrado, e no se

encontravam implementadas, o objetivo deste trabalho foi implementar essas duas

funcionalidades para dar incio construo do ambiente COCAR, de forma que fosse

tambm possvel implementar a mtrica PCU, que foi o principal alvo de estudo. A

implementao da TUCCA e das diretrizes foram compartilhadas com outro mestrando [Di

Tommazo, 2007], que desenvolveu a funcionalidade de gerenciamento de requisitos,

simultaneamente a este trabalho.

1.3 Organizao do Trabalho

O trabalho em questo est dividido em 8 captulos, sendo que neste captulo foi apresentado

o contexto no qual o trabalho est inserido e os objetivos para sua elaborao.

No Captulo 2 apresentam-se os principais conceitos relacionados Engenharia de Requisitos

bem como as dificuldades existentes nessa etapa do desenvolvimento de software, com base

na viso estabelecida no SWEBOK(2004).

No Captulo 3 apresentada a tcnica de modelagem de requisitos denominada Casos de

Uso, juntamente com a citao de alguns trabalhos que abordam aspectos de padronizao da

especificao dos Casos de Uso.

No Captulo 4 so abordadas duas mtricas de tamanho de software, Pontos de Caso de Uso,

que alvo do trabalho em questo, e a Anlise de Pontos por Funo.


20/182


No Captulo 5 descrito o ambiente COCAR, mostrando a sua estrutura e aspectos de

implementao, bem como as funcionalidades deste ambiente implementadas por este

trabalho, alm de um pequeno exemplo que mostra o funcionamento desse ambiente.

No Captulo 6 apresenta-se um exemplo de uso do ambiente COCAR com base em um projeto

de software retirado da indstria de desenvolvimento de software brasileira.

No Captulo 7 so apresentadas as concluses deste trabalho bem como propostas para

trabalhos futuros.

No Apndice I encontram-se partes do Documento de Especificao de Requisitos do

ambiente COCAR que segue as diretrizes para a escrita de documentos de requisitos definidas

por Kawai (2005).

No Apndice II so encontradas partes do Modelo de Casos de Uso projetado por meio da

tcnica TUCCA [Belgamo, 2004] baseando-se no documento de requisitos apresentado no

Apndice I.

Tanto o documento de Especificao de Requisitos quanto o Modelo de Casos de Uso do

ambiente COCAR apresentados nos Apndices I e II ficaram com um volume grande

impossibilitando sua incluso por completo neste trabalho de mestrado.


21/182

Captulo 2 Engenharia de Requisitos 8_________________________________________________________________________

Captulo 2 - Engenharia de RequisitosEngenharia de Requisitos

2.1 Consideraes Iniciais

A Engenharia de Requisitos, segundo [Thayer & Dorfman, 1997], a primeira etapa de todo

o processo da Engenharia de Software, tendo como preocupao principal entender o que os

usurios realmente precisam, traduzindo este entendimento num conjunto de especificaes

de requisitos.

Segundo Sommerville (2003), a definio clssica de qualidade de produto que o produto

desenvolvido deve estar de acordo com as suas especificao. Portanto, entender o que o

usurio quer primordial para o sucesso do software. Dessa forma, segundo o SWEBOK

(2004), quando as prticas de Engenharia de Requisitos so realizadas de forma displicente, o

projeto pode levar ao desenvolvimento de um produto de baixa qualidade que no atende a

aquilo que osstakeholders pediram.

Como a estimativa de tamanho de software esta diretamente relacionada com os requisitos

especificados para o software em questo [Sommerville, 2003] especificar bem o software imprescindvel para o sucesso da estimativa. Portanto, estudar a teoria associada

Engenharia de Requisitos de fundamental importncia para este trabalho.

Assim, o objetivo principal deste captulo apresentar os principais conceitos relacionados

Engenharia de Requisitos, o que est feito nos tpicos na Seo 2.2, segundo a viso do

SWEBOK (2004). Em seguida, na Seo 2.3 apresentam-se as consideraes finais.


22/182


2.2 Engenharia de Requisitos Principais Conceitos

Segundo o SWEBOK (2004) a Engenharia de Requisitos uma das reas chaves da

Engenharia de Software e responsvel por coletar, analisar, especificar e validar requisitos

de software, tendo como principal preocupao traduzir a vontade dos usurios do software

em um conjunto de especificao de requisitos de software.

Para melhor explicar a Engenharia de Requisitos, o SWEBOK (2004) a divide em sete

subreas, a saber:

Fundamentos da Engenharia de Requisitos. Processo de Requisitos Elicitao de Requisitos. Anlise de Requisitos. Especificao de Requisitos. Validao de Requisitos. Consideraes Prticas.

A Figura 1 mostra cada um dessas subreas com seus respectivos tpicos. Cada subrea ser

tratada no decorrer desta seo segundo as definies do prprio SWEBOK (2004).

As duas primeiras subreas, Fundamentos da Engenharia de Requisitos e Processo de

Requisitos, trazem definies necessrias para o entendimento das quatro outras subreas

que as seguem: Elicitao de Requisitos, Anlise de Requisitos, Especificao de

Requisitos e Validao de Requisitos, considerados pelo SWEBOK (2004) como sendo as

subreas de maior interesse para a Engenharia de Requisitos em si. Por ltimo h a subrea

Consideraes Prticas a qual mostra algumas prticas importantes que acompanham o

processo de Engenharia de Requisitos.


23/182


Figura 1 Subreas da engenharia de requisitos [SWEBOK, 2004]

Reviso dosRequisitos

Elicitao deRequisitos

Anlise deRequisitos

Especificaode Requisitos

Validao deRequisitos

Engenharia deRequisitos

Fontes deRequisitos

Tcnicas deElicitao

Classificaodos Requisitos

ModeloConceitual

Arquitetura

Design eAlocao deRequisitos

Negociao deRequisitos

Documento deDefinio doSistema

Especificaodos Requisitosdo Sistema

Especificaodos Requisitosde Software

Prototipao

Validao do

modelo

Teste deaceitao

Fundamentos deEngenharia deRequisitos

Definio deRequisitos de Software

Requisitos Funcionaise No-Funcionais

Propriedades Emergentes

Requisitos de Sistema

e de Software

Requisitos de Produto e

Processo

Requisitos Quantificveis

Processo deRequisitos

Modelo de Processo

Atores do Processo

Melhoria e Qualidade

do Processo

Gerenciamento e Suportedo Processo

ConsideraesPrticas

Gerenciamento deMudan as

Atributos de Requisitos

Medindo Requisitos

Natureza Interativa doProcesso de Engenharua

de Requisitos

Rastreabilidade deRequisitos


24/182


a) Fundamentos da Engenharia de Requisitos

Nesta subrea so tratadas algumas definies necessrias para o entendimento das prximas

subreas da Engenharia de Requisitos. Aqui se detalha a definio de requisitos, suaspropriedades e suas classificaes.

Definio de Requisitos de Software

Um requisito de software uma propriedade que o software deve possuir para resolver um

problema especfico do mundo real. Dessa forma um requisito de software deve expressar a

necessidade e as restries colocadas em um produto de software.

Normalmente este problema do mundo real no simples e o requisito de software para

resolv-lo uma combinao complexa de requisitos conhecidos por diferentes pessoas

atuando em diferentes papis no contexto de onde o software ir operar.

Essas diferentes pessoas, que de alguma forma tem influncia direta ou indireta sobre os

requisitos do software, denominam-sestakeholders [Sommerville, 2005].

Dada a complexidade envolvendo os requisitos de um software uma caracterstica importanteque qualquer conjunto de requisitos de software deve possuir de poderem ser verificados.

Mesmo que isso seja difcil e custoso o engenheiro de software deve sempre assegurar que os

requisitos sejam verificados para que o produto final possa atender s necessidades dos

usurios.

Outras caractersticas importantes relacionadas aos requisitos de softwareso:

Prioridade: usada para determinar a ordem com a qual os requisitos devero serimplementados na fase de construo do software;

Unicamente identificvel: cada requisito tem que estar unicamente identificvel peloseu relacionado a um determinado objetivo sustentado por um determinado

stakeholder ou por um determinado grupo de stakeholders que o software deve

atender. Isto para possibilitar o controle de configurao de cada requisito e permitir o

gerenciamento desse requisito por todo o ciclo de desenvolvimento do software.


25/182


26/182


27/182


Portanto, para evitar essa interpretao errnea do processo de Engenharia de Requisitos, o

SWEBOK (2004) prope a subrea de Processo de Requisitos o qual tratado nesta seo.

Desta forma, neste tpico melhor explicado o funcionamento do Modelo de Processo deEngenharia de Requisitos bem como algumas caractersticas importantes desse modelo.

Modelos de Processo

O processo de engenharia de requisitos no se configura to somente como uma fase inicial

isolada do ciclo de vida do desenvolvimento do software e sim como um processo que se

inicia nas primeiras fases do desenvolvimento e segue sendo refinado conforme o ciclo de

vida do softwareevolui.

Neste contexto, os requisitos do software podem sofrer alteraes ao longo do

desenvolvimento e por isso interessante que o processo de Engenharia de Requisitos esteja

preparado para tratar essas alteraes dando suporte a gerncia de configurao desses

requisitos alterados.

Atores do Processo

Atores do processo de Engenharia de Requisitos so os papis por meio dos quais os

stakeholders atuam no processo. Visto que um software possui vrios stakeholders que

possuem necessidades especficas e participam do processo de Engenharia de Requisitos

assumindo diferentes posturas. Tipicamente se tem os seguintessatakeholders:

Usurios: grupo formado pelas pessoas que iro operar o software. Normalmentebastante heterogneo contendo indivduos com diferentes papis e solicitando

diferentes requisitos;

Clientes: Grupo composto por pessoas que esto patrocinando a implementao dosoftware ou ainda por pessoas que so o mercado alvo para o qual o software esta

sendo construdo;

Analistas de Mercados: softwareimplementado destinado para um mercado de massa(sem um cliente patrocinador especfico) necessita do papel do analista de mercado

para definir o que este mercado esta demandando.

Reguladores: h vrios domnios de aplicao que necessitam de rgos reguladorescomo instituio bancrias e transporte pblico. Desta maneira se faz necessrio que


28/182


o software implementado para estes domnios de aplicao sejam regulamentados

pelas autoridades competentes.

Engenheiros de Software: so as pessoas que tem verdadeiro interesse em gerar lucrocom a implementao do software.

Dado o grande nmero destakeholders normalmente envolvidos no processo de Engenharia

de Requisitos simplesmente impossvel atender todos os requisitos de todos os

stakeholders. Por isso, funo do Engenheiro de Requisitos intermediar os interesses dos

stakeholders, elicitando todos os requisitos, entendendo a natureza da necessidade de cada

requisito de cada stakeholdere negociando esses requisitos com os principais stakeholders,

sempre levando em considerao as restries oramentrias e tcnicas do projeto.

Gerenciamento e Suporte do Processo

O processo de engenharia de requisitos requer alguns recursos gerenciais que sejam capazes

de fazer a ligao entre as atividades deste processo e custos, recursos humanos, treinamento

e ferramentas. Por isso, importante levar em considerao, desde o incio da Engenharia de

Requisitos, as prticas estabelecidas na rea chave de Gerenciamento de Engenharia de

Software abordadas no SWEBOK (2004).

Melhoria e Qualidade do Processo

Alguns dos principais papis desenvolvidos pela Engenharia de Requisitos so: melhorar a

satisfao do cliente em relao ao produto desenvolvido e gerenciar melhor custos e prazos

do projeto. Desta forma muito importante avaliar a qualidade do processo de Engenharia de

Requisitos, analisando a sua eficcia e o quanto este processo esta contribuindo para o papel

acima definido.

Portanto, muito importante que o processo de Engenharia de Requisitos seja regido por

padres de qualidade e melhoria de processo de software e sistemas, principalmente no

quesito qualidade do softwaree estimativas.


29/182


c) Elicitao de Requisitos

Segundo SWEBOK (2004), esta a primeira fase de quatro que compem o processo de

Engenharia de Requisitos de Software, na qual o objetivo o entendimento sobre o propsitodo softwareque est sendo implementado. O principal interesse na elicitao de requisitos

identificar as fontes nas quais os requisitos de software sero elicitados e definir como o

Engenheiro de Software poder fazer o levantamento de requisitos.

Fontes de Requisitos

Requisitos podem vir de vrias fontes e essencial que todas essas fontes sejam identificadas

e os seus impactos sobre os requisitos do software sejam avaliados.

Para ser capaz de identificar e avaliar as fontes de requisitos importante que os engenheiros

de software fiquem atentos aos seguintes itens:

i. Objetivos do Software este item tambm conhecido como fator crtico de sucesso dosoftware e seu propsito dar uma viso superficial sobre o software, ressaltando seus

objetivos gerais e a motivao para a sua construo;

ii. Conhecimento do domnio Os engenheiros de software devem adquirir conhecimentosobre o domnio da aplicao. Isto permite a eles inferir conhecimento intuitivo que os

stakeholders no foram capazes de exteriorizar.

iii. Stakeholders de suma importncia que os engenheiros de software no foquem todaa ateno para apenas um grupo de stakeholders. O engenheiro de software deve

identificar, representar e gerenciar os pontos de vistas de vrios e diferentes tipos de

stakeholders para que o produto de software no seja concebido com uma viso

unilateral das necessidades dosstakeholders.

iv. Ambiente operacional Requisitos tambm sero derivados do ambiente no qual osoftware ser executado e por isso importante que o engenheiro de software conhea

esse ambiente, j que ele pode influenciar bastantes custos e decises no projeto do

software.

v. Ambiente organizacional Software construdo geralmente para dar suporte aprocessos de um determinado negcio e podem estar condicionados a uma estrutura,

cultura e polticas internas de uma organizao. Os engenheiros de software precisamser sensveis a esses aspectos, pois software que iro rodar nesses ambientes no podem


30/182


implicar (pelo menos no sem um planejamento prvio) em mudanas nas regras de

negcio da organizao.

Uma vez que as fontes de requisitos tenham sido identificadas e os seus impactos sobre osrequisitos do software avaliados, o engenheiro de software pode comear a coletar os

requisitos do sistema a partir dessas fontes.

Tcnicas de Elicitao

A coleta dos requisitos do sistema uma atividade muito difcil e o engenheiro de software

deve estar ciente de que os usurios apresentam extrema dificuldade em descrever as tarefas

do software, podendo deixar passar despercebido informaes importantes. Por isso, mesmo

com a cooperao dos stakeholders, os engenheiros de software tm um trabalho difcil na

fase de elicitao dos requisitos.

Segundo Sommerville (2003) esta dificuldade ocorre pois:

i. Normalmente os stakeholders so generalistas na definio do que desejam dosistema;

ii. Para os stakeholders os requisitos do sistema so quase intuitivos pois, na grandemaioria das vezes, expressam conhecimento implcito da prpria rea de atuao dos

envolvidos;

iii. Como os stakeholders so formados por um grupo de pessoas grande emultidisciplinar, freqente acontecer conflitos entre os requisitos;

iv. Fatores polticos dentro de organizao podem afetar diretamente os requisitos dosoftware. Gerentes podem definir certos requisitos apenas para aumentar sua

influncia na organizao;

v. bastante comum que o ambiente de negcios associado ao sistema seja dinmico, oque leva os requisitos a sofrerem alteraes a todo momento;

Exatamente pela elicitao de requisitos ser um processo extremamente complicado, h

vrias tcnicas para contemplar essa fase da Engenharia de Requisitos. As principais tcnicas

sugeridas no SWEBOK (2004) so:


31/182


i. Entrevistas meio tradicional de elicitao de requisitos. importante para oengenheiro de software saber das vantagens e limitaes desse mtodo e como conduzi-

la bem.

ii. Cenrios meio valioso para prover contexto para a elicitao de requisitos juntamentecom o usurio. Esse mtodo capaz de prover para o engenheiro de software em um

conjunto de questes sobre as tarefas do usurio como o que ... se isso? ou ainda

como isto feito ?. O tipo mais comum de cenrio o Casos de Uso.

iii. Prottipos abordagem eficiente para tornar claro os requisitos ainda no entendidos eavaliar o sistema antes dele ser construdo. Essa ferramenta pode atuar de forma similar

aos cenrios, provendo aos usurios um contexto no qual ele pode entender melhor qual

informao ele precisa fornecer, para que o software fique o mais completo possvel deacordo com suas necessidades. H uma gama enorme de tcnicas de prototipao que

vo desde mock-up (tcnica de prototipao que usa grficos, imagens e ilustraes em

papel para descrever telas e interao com o usurio) at verses executveis no

oficiais do software (verso beta para teste) que tambm so usados para a validao dos

requisitos.

iv. Reunies intermediadas o propsito desta tcnica tentar alcanar um efeito sinrgico,partindo do princpio de que um grupo de pessoas pode contribuir mais para a coleta derequisitos do que cada pessoa individualmente contribuiria. Essa tcnica pode trazer

idias por meio de brainstorms (reunio na qual vrias idias so enunciadas pelos

participantes sem nenhuma restrio e depois as melhores so selecionadas para

anlise) que dificilmente seriam descobertas por tcnicas de entrevistas usuais. Quando

funciona bem, essa tcnica pode trazer um conjunto de requisitos mais consistente do

que outras tcnicas.

v.

Observao a importncia do contexto do software dentro do ambiente da organizaotem conduzido adaptaes das tcnicas observacionais para a elicitao de requisitos de

software. Engenheiros de software aprendem sobre as tarefas do usurio por meio de

uma imerso em seu ambiente de trabalho, observando como os usurios interagem com

seus software e entre eles. O grande problema dessa tcnica que os usurios tendem a

se policiar mais em suas atividades quando tem alguma pessoa observando as suas

atividades; sendo assim, o que o engenheiro de software vai observar uma tarefa que

nem sempre executada da forma que est sendo mostrada.


32/182


De posse dos requisitos elicitados por meio dos interessados na construo do sistema, tm-

se artefatos suficientes para se avanar para a prxima fase da engenharia de requisitos, a

anlise dos requisitos elicitados.

d) Anlise de Requisitos

Na elaborao dos requisitos de um software deve-se tentar assegurar que estes sempre sejam

descritos de forma a possibilitar a sua validao, a verificao de sua implementao e a

estimativa de seus custos. Para tanto, modelos conceituais so muito aceitos nesta fase,

contudo deve ser claro que, ao contrrio da viso tradicional, esta fase no deve se resumir a

apenas a elaborao desses modelos conceituais.

Assim, a fase de anlise de requisitos tambm tem por objetivo:

Detectar e resolver conflitos entre os requisitos. Descobrir os limites do software e como ele deve interagir com o seu ambiente. Elaborar requisitos de sistema para derivar requisitos de software.

Desta forma, nesta subrea, alm dos modelos conceituais, sero tratados tambm assuntos

importantes para garantir os objetivos dessa fase.

Classificao de Requisitos

Para melhor entender o domnio do software e suas funcionalidades, de acordo com o

SWEBOK Guide 2004 [SWEBOK, 2004], os requisitos devem ser classificados. Existem

vrias formas para a classificao dos requisitos, por exemplo:

i. Requisito Funcional ou Requisito No Funcional.ii. Requisito Derivado ou Emergente: quando um requisito derivado de um ou mais

outros requisitos de alto nvel, ou uma propriedade emergente ou est sendo imposto

diretamente por umstakeholderou outra fonte de requisitos.

iii. Requisito de Produto ou Requisito de Processo: requisitos de processo podem restringira escolha de um contratado ou o processo de engenharia de software a ser escolhido.

iv. Prioridade do requisito: em geral, quanto mais alta a prioridade do requisito maisessencial o requisito para o software. A prioridade tem sempre que ser balanceada deacordo com o seu custo de desenvolvimento e implementao.


33/182


v. Escopo: refere-se extenso com a qual o requisito afeta o software e seuscomponentes.

vi. Volatilidade e Estabilidade: Alguns requisitos iro mudar durante o ciclo de vida dedesenvolvimento do software. Sendo assim, seria muito interessante classificar os

requisitos de acordo com uma probabilidade de mudana que esses requisitos venham a

ter. Sinalizar requisitos potencialmente volteis pode ajudar ao engenheiro de software a

estabelecer um projeto mais tolerante a mudanas.

Tendo classificado os requisitos e entendido melhor o escopo do problema pode-se seguir

com o desenvolvimento de modelos que considerado como a chave da anlise de requisitos

de software, pois esses modelos podero ser usados para a especificao, validao everificao de requisitos, projeto e teste do software.

Modelo Conceitual

Para efeitos prticos, SWEBOK (2004) define um modelo como sendo uma notao ou um

conjunto de notaes includas em um processo que guia a aplicao dessas notaes.

Modelos conceituais devem representar o domnio do problema do mundo real atravs da

modelagem de suas partes e dos relacionamentos e dependncias entre essas partes. Portanto

o principal objetivo da modelagem no ser o incio do projeto do software, apesar de poder

ser usado para tal, mas sim ajudar a compreender melhor o problema do mundo real a ser

implementado pelo software.

Segundo Pressman (2006), o modelo de anlise deve atingir trs objetivos principais:

descrever o que o cliente exige; estabelecer a base para a criao de um projeto de software;

definir um conjunto de requisitos que possam ser validados quando o software for construdo.

Para tanto SWEBOK (2004) sugere vrios modelos que podem ser construdos nesta fase,

incluindo fluxo de dados, modelos de estado, modelos de rastreamento de eventos, modelos

de interao com usurio, modelos de objeto, modelo de dados entre outros.

Para escolher esses modelos h vrios fatores que devem ser levados em considerao,

podendo-se citar [SEWBOK, 2004]:


34/182


i. A natureza do problema: Alguns tipos de software demandam que certos aspectospossam ser analisados particularmente e rigorosamente. Por exemplo, modelos de estado

e fluxo de controle parecem ser mais importantes para software de tempo real do que

para software de gerenciamento de informaes.

ii. A percia do engenheiro de software: geralmente mais produtivo adotar um modelocom o qual o engenheiro de software tenha experincia.

iii. O processo de engenharia de requisitos do cliente: Clientes podem impor algum mtodoou ainda proibir que algum mtodo seja utilizado. Este fator pode entrar em conflito

com o fator anterior.

iv. A disponibilidade de mtodos e ferramentas: Mtodos para os quais no existemferramentas ou treinamento que o do suporte podem no ser aceitos mesmo que sejammais indicados para tipos particulares de problemas.

Arquitetura Design e Alocao de Requisitos

Segundo SWEBOK (2004), o software implementar os requisitos que esto sendo elicitados

por meio de vrios componentes que sero desenvolvidos.

A arquitetura e modelagem desses componentes so realizadas na fase de Projeto doSoftware, contudo a identificao desses componentes e a alocao dos requisitos para esses

componentes deve ser realizada nesta fase da engenharia de requisitos.

Realizar a alocao de requisitos com componentes significa identificar os componentes do

software necessrios para a implementao de um determinado requisito. Por isso, comum

dizer que esta fase da Engenharia de Requisitos se sobrepe com a fase de Projeto de

Software, fazendo com que o engenheiro de requisitos atue como um arquiteto de software.

SWEBOK(2004) chama a ateno para a importncia da execuo dessa atividade na fase de

engenharia de requisitos, pois com ela possvel realizar mais uma anlise detalhada dos

requisitos de software, j que s desta maneira possvel identificar os componentes e os

relacionamentos entre os componentes necessrios para a sua implementao, ou seja, alocar

componentes para requisitos demanda uma nova rodada detalhada de anlise de cada

requisitos.

Porm, o mapeamento de entidades do mundo real para componentes de software no

sempre bvio e, por isso, o Projeto da Arquitetura considerado como um tpico separado da


35/182


modelagem de requisitos e deve ser continuado em fases posteriores (fase de Projeto de

Software) do ciclo de vida de desenvolvimento do software.

Estando os requisitos classificados, modelados e com o projeto da arquitetura do softwareiniciado, fica mais fcil identificar requisitos conflitantes, perfazendo a atividade de

negociao de requisitos, que tambm comumente chamada de resoluo de conflitos.

Negociao de Requisitos

Essa atividade consiste em resolver problemas com requisitos conflitantes que ocorrem

quando dois stakeholders requerem concomitantemente caractersticas incompatveis entre

requisitos e recursos ou entre requisitos funcionais e no funcionais. Na maioria das

vezes no aconselhvel o engenheiro de software tomar uma deciso unilateral, sendo mais

conveniente consultar osstakeholders para chegar a um consenso. Geralmente, por questes

contratuais, importante que esse tipo de deciso seja levada at o cliente.

Com isso, contemplam-se todas as atividades da fase de anlise de requisitos e parte-se para a

fase de especificao.

e) Especificao dos Requisitos

Segundo SWEBOK (2004), para muitas outras engenharias o termo especificao significa o

ato de se atribuir valores ou limites para os objetivos do projeto que esta sendo desenvolvido.

Contudo, na rea de desenvolvimento de software, tipicamente h um nmero pequeno

desses valores, sendo que a nfase esta na quantificao e no gerenciamento da interao

entre o grande nmero de requisitos existente.

Sendo assim, na engenharia de software, a especificao de requisitos de software geralmente

se refere produo de um documento, ou sua verso eletrnica equivalente, que possa ser

sistematicamente revisto, avaliado e aprovado, buscando um melhor gerenciamento dos

requisitos e suas relaes.

Para sistemas complexos, geralmente, se desenvolvem trs tipos desses documentos, a saber:

Documento de Definio do Sistema. Documento de Requisitos do Sistema.


36/182


Documento de Requisitos de Software.Documento de Definio do Sistema

O documento de definio do sistema, tambm conhecido como documento de requisitos do

usurio, guarda os requisitos do sistema definindo-os em alto nvel segundo uma perspectiva

do domnio da aplicao.

Sendo assim, este documento deve listar os requisitos de acordo com uma viso mais abstrata

do sistema e deve ser escrito tendo como pblico alvo o prprio cliente/usurio do software e

utilizar termos do escopo da aplicao (usando os termos do domnio para o qual a aplicao

ser desenvolvida), tendo como objetivo listar os requisitos do sistema, trazendo informaes

relevantes sobre o ambiente no qual o sistema ir operar, restries da operao do sistema e

ainda requisitos no funcionais.

Este documento tambm pode incluir alguns modelos conceituais do sistema como modelos

de contexto e modelos de cenrios.

Documento de Requisitos do Sistema

Para sistemas que renem uma grande quantidade de componentes de software e

componentes no-software (hardware, por exemplo), costuma-se separar a especificao

dos requisitos do sistema da especificao dos requisitos de software.

Para esse tipo de sistema o documento de especificao do sistema dever ser elaborado.

Contudo, segundo o SWEBOK(2004), especificar sistemas uma atividade estritamente da

rea de engenharia de sistemas e foge do escopo desse trabalho, de qualquer maneira pode-se

encontrar informaes sobre esse tipo de documento e especificao em IEEE std 1233

(IEEE1234-98).

Documento de Requisitos de Software

O documento de especificao de requisitos do software estabelece as bases para um acordo

entre clientes e desenvolvedores definindo o produto de software que ir ser construdo.


37/182


A especificao de requisitos do software permite que seja feito um julgamento rigoroso dos

requisitos antes que a fase de projeto se inicie, reduzindo, desta forma, possveis re-projetos

tardios do software.

Tambm possvel com este documento prover uma base para a realizao de estimativas de

custo, risco e cronograma do produto. Ainda algumas indstrias usam esse documento como

entrada para se planejar a fase de validao e verificao de forma mais produtiva.

O documento de especificao de requisitos de software deve ser escrito usando linguagens

formais ou semi-formais, sendo que a escolha de uma boa notao permite que certos

requisitos ou aspectos da arquitetura do software sejam descritos com mais preciso e

consistncia do que se fossem especificados usando uma linguagem natural. Sendo assim,

como regra geral, adotam-se notaes sempre que se deseje descrever os requisitos da

maneira mais precisa possvel.

Por essa caracterstica formal e tcnica do documento de especificao de requisitos

comum este vir acompanhado com o documento de definio do sistema para que leitores

leigos sejam capazes de compreender melhor o documento.

f) Validao de Requisitos

De acordo com SWEBOK(2004), os documentos de requisitos descritos no tpico e

servem de entrada para esta fase da Engenharia de Requisitos, j que esses documentos sero

aqui avaliados quanto ao grau de entendimento dos requisitos por parte dos engenheiros de

software que iro desenvolver o produto, quanto conformidade com padres estabelecidos,

clareza, consistncia e completeza.

Sendo assim, o objetivo principal dessa atividade de validao analisar os documentos de

requisitos especificados na fase anterior para certificar-se de que o software que ser

construdo o software que o usurio espera ver. Ou seja, nessa fase que se procura validar

se os requisitos especificados realmente definem o sistema que o cliente deseja.

[Sommerville, 2005]

Desta forma, considera-se aqui uma vantagem ter os documentos de requisitos escritos com

uma linguagem formal, pois isto permite que a consistncia e a clareza dos requisitos possam

ser testadas.


38/182


Ainda nessa fase importante que diferentes stakeholders, incluindo representantes dos

clientes e desenvolvedores, revisem o(s) documento(s) de requisitos que ainda servir como

entrada para outras atividades derivadas do ciclo de vida do processo de desenvolvimento do

software, sendo normal que essas revises aconteam mais de uma vez durante o processo de

levantamento de requisitos.

Segundo SWEBOK(2004), para se realizar a validao de requisitos vrias tcnicas podem

ser usadas, como por exemplo:

Reviso de requisitos. Prototipao. Validao de modelo. Planejamento de Testes de aceitao.

Em seguida se explica cada uma delas:

Reviso de Requisitos

Este o meio de validao mais comum e tambm conhecido como inspeo de requisitos.

Nesta tarefa um grupo responsabilizado por rever os documentos de requisitos em busca de

erros, suposies errneas, falta de clareza e desvios de padres estabelecidos.

aconselhvel que o grupo que ir fazer a reviso dos requisitos tenha a presena de um

cliente, para que a reviso seja direcionada sob o ponto de vista do usurio, que um dos

principais interessados.

Prototipao

A prototipao um timo meio para validar a interpretao do engenheiro de software em

relao aos requisitos coletados, alm de configurar-se como uma ferramenta muito poderosa

para se elicitar novos requisitos que ainda no foram descobertos.

Contudo, essa tcnica apresenta algumas desvantagens. Uma delas o fato da possibilidade

do cliente se desviar das principais funcionalidades do sistema e ficar mais atento a

problemas cosmticos ou a problemas de falta de qualidade do prottipo. Por isso, algumas


39/182


pessoas recomendam que a prototipao seja feita sem o uso de um software e sim atravs de

mock-ups desenhados em papel.

Validao de Modelo

H a possibilidade de se validar tambm os modelos conceituais estabelecidos durante a fase

de anlise. Para tanto existem vrias tcnicas de validao que buscam analisar a qualidade

desses modelos. Se uma notao formal de especificao tiver sido usada possvel utilizar

lgica formal para testar certas propriedades dos modelos.

Planejamento de Testes de Aceitao

Uma propriedade fundamental dos requisitos de software que seja possvel validar se o

produto final os implementa. Desta forma, uma importante tarefa planejar como cada

requisito ser verificado aps a sua implementao e, na maioria dos casos, planejar testes de

aceitao uma tima estratgia para isso.

A grande dificuldade em se planejar testes de aceitao para todos os requisitos encontra-se

quando estes so requisitos no funcionais. Sendo assim importante, antes de realizar o

planejamento dos testes de aceitao, ainda na fase de anlise, encontrar uma forma de

quantificar os requisitos no funcionais, possibilitando o planejamento dos testes de aceitao

para esses requisitos.

g) Consideraes Prticas

Este ltimo tpico abordado pelo SWEBOK (2004) concentra-se em mostrar alguns

comportamentos dos requisitos ou do Processo de Engenharia de Requisitos que precisam ser

entendidas na prtica.

Assim nesta subrea da Engenharia de Requisitos sero tratados tpicos como a

interatividade do processo de Engenharia de Requisitos e a Gerncia de Requisitos

A natureza interativa do Processo de Engenharia de Requisitos

praticamente impossvel conceber um processo de Engenharia de Requisitos que seja linear

e determinstico no qual os requisitos so elicitados atravs dosstakeholders uma nica vez e


40/182


depois so armazenados dessa forma durante todo o processo de desenvolvimento do

software.

Um ponto que deve ficar claro na Engenharia de Requisitos que os requisitos de softwaremudam conforme o desenvolvimento do software avana. Essas mudanas podem ser

causadas por alguma falha no momento da elicitao do requisitos, mas frequentemente essas

mudanas so reflexos de uma mudana no ambiente no qual o software ir operar como por

exemplo mudanas no mercado onde este software ser vendido ou ainda mudanas nas

regras de negcio do cliente.

Como essas mudanas nos requisitos so inevitveis muito importante que o processo de

Engenharia de Requisitos no seja considerado como um simples processo que termina assim

que a fase de projeto se inicia. Ao invs disso, o processo de Engenharia de Requisitos deve

se preocupar em gerenciar os requisitos durante todo o processo de desenvolvimento de

software gerenciando as mudanas dos requisitos ocorridas para garantir que cada uma

dessas mudanas seja submetida a um processo de aprovao, tenha o seu histrico de

alteraes armazenado e tenha o seu impacto analisado.

Gerenciamento de Mudanas

Para o SWEBOK (2004), o gerenciamento de mudanas a atividade central para o

gerenciamento de requisitos pois neste tpico que se descrevem todos os procedimentos

necessrios e as anlises que devem ser feitas para controlar as alteraes feitas nos

requisitos.

Contudo, o SWEBOK (2004) prefere tratar esse tpico na rea chave de Gerncia de

Configurao de Software.

Atributos dos Requisitos

Todo requisito deve ser composto no apenas pela descrio da especificao do que

requerido pelo software, mas tambm por informaes complementares que ajudam a

gerenciar e interpretar melhor os requisitos.


41/182


42/182


documento de requisitos do sistema e o Modelo de Casos de Uso o qual ser melhor

explicado no prximo captulo.


43/182

Captulo 3 Modelagem de Requisitos com Casos de Uso 30________________________________________________________________________

Captulo 3 - Modelagem de Requisitos com Casos de Uso

Modelagem de Requisitoscom Casos de Uso

3.1 Consideraes Iniciais

Neste captulo sero apresentados os principais conceitos associados tcnica Casos de Uso,

uma vez que o ambiente COCAR essencialmente baseado no Modelo de Casos de Uso de

um sistema, para o qual se deseja prover algumas informaes, inclusive a funcionalidade de

gerao dos Pontos de Casos de Uso, que foi o principal objeto de estudo deste trabalho.

O conceito de Casos de Uso foi proposto inicialmente por Ivar Jacobson, em 1992, como

parte de seu modelo de processo Objectory [Jacobson et al., 1992]. Embora essa tcnicatenha sido incorporada UML [OMG, 2005], como um dos modelos a ser construdo, ela no

uma tcnica restrita ao paradigma de orientao a objetos, podendo ser utilizada em

qualquer contexto.

Por ser uma tcnica simples e que facilita o entendimento do sistema que est sendo

modelado, ressaltando as funcionalidades e as interaes com os atores (usurios) dessas

funcionalidades, ela tem sido muito utilizada na prtica. Jacobson et al (1992) salientam que

o Modelo de Casos de Uso tambm serve como um modelo central que deve ser utilizado

para todos os demais modelos das prximas fases de Anlise, Projeto, Implementao, Testes

e Manuteno. No entanto, no existem diretrizes associadas tcnica que determinem como

um modelo de casos de uso deva ser construdo, permitindo com que a experincia e

subjetividades tenham grande interferncia nessa atividade. Em decorrncia disso, o trabalho

de Belgamo (2004), desenvolvido anteriormente, props a tcnica de leitura TUCCA, cujo

objetivo principal a construo desses modelos e corresponde funcionalidade bsica do

ambiente COCAR, pois, com base nesses modelos que outras funcionalidades so

oferecidas.


44/182


O captulo est organizado da seguinte forma: na Seo 3.2 apresentam-se os conceitos

relacionados com o Diagrama de Casos de Uso, na Seo 3.3 comenta-se sobre a

Especificao dos Casos de Uso e na Seo 3.4 apresentam-se as Consideraes Finais.

3.2 Diagramas de Casos de Uso

Os Modelos de Caso de Uso so representaes pictricas do documento de requisitos, que

tm como objetivo mostrar a funcionalidade do sistema, bem como a interao dos usurios

com o mesmo [Belgamo, 2004]. Esses modelos so compostos pelo Diagrama de Casos deUso e pelas Especificaes dos Casos de Uso e so considerados uma tcnica para capturar

os requisitos funcionais de um sistema, descrevendo as interaes tpicas entre os usurios

desse sistema e o prprio sistema, alm de fornecer uma narrativa de como o sistema

utilizado [Fowler, 2005].

Conceitualmente, de acordo com Booch et al. (2000), um Caso de Uso uma descrio de

um conjunto de seqncias de aes, incluindo tambm as variantes dessas aes, que um

sistema executa para produzir um resultado de valor observvel por um ator. Graficamente, o

Caso de Uso representado como uma elipse.

Sendo assim, um Caso de Uso um tipo de classificador que representa: uma unidade

coerente de funcionalidade provida por sistema ou por um sub-sistema; uma ou mais

interaes desta unidade com componentes externos (representado pelos atores); aes

realizadas pelo prprio sistema [UML 2003].

Todo Caso de Uso deve ter um nome nico (uma seqncia de caracteres textuais) que seja

capaz de diferenci-lo dos demais Casos de Uso.

A Figura 2 mostra a representao de um Caso de Uso com o seu nome.

Figura 2Representao grfica de um Caso de Uso

Validarusurio


45/182


Para mostrar a interao entre o Caso de Uso com entidades externas a ele existe a figura do

ator.

Um ator representa um conjunto coerente de papis que os usurios dos Casos de Usodesempenham quando interagem com esses Casos de Uso. O ator no precisa

necessariamente desempenhar apenas o papel de algum usurio humano; ele tambm pode

desempenhar o papel de um dispositivo de hardware ou at de um outro sistema que interage

com o sistema em questo. Por isso Fowler (2005) afirma que papel seria o termo mais

correto para o que hoje a comunidade de Engenharia de Software chama de ator.

Portanto, pode-se concluir que os Casos de Usos modelam aquilo que o sistema deve fazer

enquanto os atores definem a interao de alguma coisa de fora com o sistema [Jacobson et

al., 1992].

Schneider & Winters (2001) propem algumas questes bsicas para auxilio identificao

de atores no sistema, a saber:

Quem usa o sistema?

Quem instala o sistema? Quem inicia o sistema? Quem mantm o sistema? Quem finaliza o sistema? Quais outros sistemas fazem uso deste sistema? Quem recebe informaes do sistema? Quem envia informaes para o sistema? Alguma coisa acontece automaticamente em um determinado tempo?

A representao de um ator acontece por meio de figuras estilizadas que lembram um ser

humano caricato. Esse tipo de representao o bastante para o ator, pois como ele

representa alguma coisa externa ao sistema, no necessrio descrev-lo em detalhes

[Jacobson et al., 1992].

Existe a possibilidade de se definirem grupos gerais de atores que depois podero ser

especializados, como por exemplo, pode-se definir um ator pessoa, que generaliza um grupo


46/182


de pessoas qualquer, e depois especializar outros atores como funcionrio, professor e aluno,

usando o relacionamento de generalizao, como mostrado na Figura 3.

Figura 3Atores com relacionamento de generalizao (adaptado de Boock et al., 2000)

O relacionamento de generalizao um relacionamento da UML que relaciona itens gerais

em tipos mais especficos desses itens, ou seja, h a necessidade das partes que esto se

relacionando serem de um mesmo tipo.

Cockburn (2001) inseriu uma forma de se classificar atores, a saber:

Atores Primrios: so aqueles que esto em constante contato com o sistema e porisso iro executar as principais tarefas do sistema. Este ator freqentemente aquele

que aciona o Caso de Uso

Atores Secundrios: so aqueles que fazem o sistema funcionar atravs dofornecimento de um servio para o mesmo. Sendo assim no esto em contato

constante com o sistema e no costumam realizar as tarefas principais deixando issopara o ator principal. importante identificar esses atores, pois a partir deles se

identificam as interfaces externas que o sistema usar e os protocolos que cruzam esta

interface.

A conexo entre os Casos de Uso e os atores acontece por meio de um relacionamento de

associao. Este tipo de relacionamento usado na UML como um relacionamento estrutural

que especifica a conexo de objetos de um item com objetos de outro item. Quando usado

para relacionar o Caso de Uso com o ator, essa associao indica que existe uma

Pessoa

Funcionrio

Professor

Aluno


47/182


comunicao entre esses itens, tendo cada parte a possibilidade de envio e recebimento de

mensagens.

Os Casos de Uso podem ser relacionados entre si atravs de generalizaes, incluses ouextenses [Boock et al., 2000].

Em uma generalizao de Casos de Uso o que acontece que um Caso de Uso filho ir

herdar o comportamento e significado do Caso de Uso pai e poder acrescentar ou

sobrescrever algum comportamento.

Para evitar a escrita de um mesmo fluxo de eventos vrias vezes, existe a possibilidade da

incluso de Casos de Uso. Dessa forma, um Caso de Uso (que ser chamado de Caso de Uso

base), poder incluir, em algum momento do seu fluxo de eventos, um outro Caso de Uso.

Esse Caso de Uso includo nunca poder aparecer isoladamente sendo que no momento da

incluso o seu comportamento explicitamente incorporado pelo Caso de Uso base que o

est incluindo.

Um relacionamento de incluso pode ser representado como uma dependncia estereotipada

com include. Dependncia um relacionamento de utilizao definido pela UML. Exemplos

de incluso podem ser vistos na Figura 4.

Contudo, se o comportamento a ser includo em um Caso de Uso no for obrigatrio, ou seja,

h um fluxo de evento no Caso de Uso base que no passa pelo Caso de Uso que esta sendo

includo, o que acontece ento uma extenso de um Caso de Uso. Sendo assim, o Caso de

Uso base poder aparecer isolado e, sob certas condies, seu comportamento poder ser

estendido pelo comportamento de um outro Caso de Uso. O relacionamento estendido

representado como uma dependncia estereotipada como extend. Exemplos de extenso

podem ser vistos na Figura 4.

Apenas o nome e a interao do Caso de Uso com atores no so suficientes para se

descrever o comportamento desse Caso de Uso. preciso algo que deixe claro o

comportamento dos Casos de Uso para qualquer pessoa que precise entender o modelo. Para

isso, elaboram-se as Especificaes dos Casos de Uso. Na Especificao dos Casos de Uso,

existe o que se chama de fluxo de eventos no qual se pode incluir como e quando o Caso de

Uso inicia e termina, quando o Caso de Uso interage com os atores, quais objetos so


48/182


transferidos e o fluxo bsico e alternativo do comportamento, tambm conhecidos como

curso normal e curso alternativo.

Figura 4 Casos de Uso e seus relacionamentos (adaptado de Boock et al., 2000)

O fluxo de eventos de um Caso de Uso pode ser especificado de diversas formas: por meio

de um texto estruturado informal, texto estruturado formal (com pr e ps condies),

pseudocdigo, fluxograma, redes de Petri ou linguagens de programao [Sommerville,2005].

3.3 Especificao de Casos de Uso

Segundo Fowler (2005), apesar da UML adotar os Casos de Uso como um de seus

diagramas, ela apresenta uma definio bastante superficial da tcnica, se limitando apenas a

formalizar o Diagrama de Caso de Uso, sem preocupao em padronizar a Especificao dos

mesmos.

Essa falta de padronizao sobre a forma de escrita do fluxo de eventos de um Caso de Uso

dificulta a determinao de mtricas a partir desse modelo [Damodaran, 2003], apesar de

vrias tcnicas usadas atualmente considerarem os Casos de Uso como sendo um indicador

de tamanho e complexidade de um sistema [Vinsen et al, 2004].


49/182


Por outro lado, Belgamo (2004) mostra que existem alguns autores que sugerem a utilizao

de templates na Especificao de Casos de Uso, como por exemplo, [Kulak & Guiney, 2000;

Ryser & Glinz, 2000; Cockburn, 2001, Schneider & Winters, 2001].

No trabalho de Schneider & Winters (2001) so sugeridas algumas questes que auxiliam na

identificao dos atores do Modelo de Casos de Uso, bem como algumas diretrizes para a

criao de Casos de Uso.

Kulak & Guiney (2000), sugerem um mtodo com quatro interaes pr-estabelecidas, com

base no qual o Modelo de Casos de Uso evolui gradativamente.

Ryser & Glinz, (1999) desenvolveram um mtodo denominado SCENT (SCENarios-Based

Validation and Test of Software) no qual a partir do Modelo de Casos de Uso so elaborados

Statecharts que sero utilizados na criao de Casos de Teste. Embora o principal objetivo do

trabalho seja o desenvolvimento de Casos de Testes um formulrio de especificao de Casos

de Uso apresentado neste trabalho.

J Cockburn (2001) trabalha com o conceito de objetivos para transform-los em Casos de

Uso. Desta forma, os objetivos de um determinado sistema so classificados em trs

possveis nveis: usurio (so objetivos que mostram as necessidades que o ator tem em

relao ao sistema), resumo (so os que mostram as necessidades que contexto no qual o

sistema esta inserido tem) e sub-funes (so os objetivos necessrios para que os objetivos

do usurio possam ser executados).

Dos trabalhos acima analisados nenhuma proposta rene todas as necessidades que a

especificao de Casos de Uso exige em um s template. Por isso, analisando essas

propostas, Belgamo (2004) definiu o template de Especificao de Casos de Uso apresentado

no Quadro 1, o qual utilizado no ambiente COCAR, como resultado da aplicao da TUCCA.

Assim, com base na maneira em que as informaes relacionadas ao Caso de Uso so

armazenadas nesse template, podem-se calcular os Pontos de Casos de Uso, que o principal

objetivo deste trabalho.


50/182


51/182


uma representao do sistema que d apoio a vrias outra

_pontos de Casos de Uso

Documents

Transcript of _pontos de Casos de Uso