Cristina Bona

AVALIAO DE PROCESSOS DE SOFTWARE:

UM ESTUDO DE CASO EM XP E ICONIX

Dissertao apresentada ao
Programa de Ps-Graduao em
Engenharia de Produo da
Universidade Federal de Santa Catarina
como requisito parcial para obteno
do grau de Mestre em
Engenharia de Produo

Orientador: Prof. Marcello Thiry Comicholi da Costa, Dr.

Florianpolis
2002
 Cristina Bona

AVALIAO DE PROCESSOS DE SOFTWARE:

UM ESTUDO DE CASO EM XP E ICONIX

Esta dissertao foi julgada e aprovada para a

obteno do grau de Mestre em Engenharia de
Produo no Programa de Ps-Graduao em
Engenharia de Produo da
Universidade Federal de Santa Catarina

Florianpolis, 25 de outubro de 2002.

Prof. Edson Pacheco Paladini, Dr.

Coordenador do Programa

BANCA EXAMINADORA

_______________________________
Prof. Marcello Thiry C. da Costa, Dr.
Universidade do Vale do Itaja
Orientador

________________________________ ________________________________
Prof. Alejandro Martins Rodriguez, Dr. Prof. Vincius Medina Kern, Dr.
Universidade Federal de Santa Catarina Universidade Federal de Santa Catarina
 Aos meus pais, Fedele e Luiza
pelo carinho constante.
Aos meus irmos Ione, Marcos e Daiane.
 Agradecimentos

Agradeo primeiramente quela luz maior,

por me conduzir e me dar foras para alcanar meus objetivos.
Universidade Federal de Santa Catarina.
Ao orientador Prof. Marcello Thiry, pela dedicao incondicional,
apoio, pacincia e tambm por ter acreditado em mim.
Aos meus pais Fedele e Luiza, pelo carinho, educao e lio de vida.
Vocs me ensinaram a confiar e sonhar.
Ao meu marido Marcello, pelo seu amor, carinho, compreenso
e constante ajuda nesta caminhada.
Decka, pela amizade e momentos de descontrao.
CEFET/SC e Secretaria Municipal da Sade,
pela disponibilizao das informaes.
todos que direta ou indiretamente
contriburam para a realizao
desta pesquisa.
Quando os ventos da mudana sopram,
alguns constroem abrigos,
outros, moinhos.
Clauss Mller
 Sumrio

Lista de Figuras ......................................................................................9

Lista de Tabelas....................................................................................11

Resumo..................................................................................................12

Abstract .................................................................................................13

1 INTRODUO....................................................................................14

1.1 Contextualizao ...........................................................................14

1.2 Objetivos do Trabalho...................................................................15

1.2.1 Objetivo geral ...................................................................................................15
1.2.2 Objetivos especficos .......................................................................................15
1.3 Justificativa do Trabalho ..............................................................16

1.4 Estrutura do Trabalho ...................................................................17

2 PROCESSO DE SOFTWARE ............................................................18

2.1 Introduo ......................................................................................18

2.2 Fases do Processo de Software....................................................19

2.3 Atividades do Processo de Software............................................21

2.4 Modelos de Ciclo de Vida ..............................................................22

2.4.1 Modelo cascata ................................................................................................23
2.4.2 Modelo espiral ..................................................................................................24
2.4.3 Modelo de prototipao ....................................................................................26
2.4.4 Modelo iterativo e incremental..........................................................................27
2.5 Metodologias geis........................................................................31
2.5.1 Extreme Programming (XP) .............................................................................31
2.5.2 SCRUM ............................................................................................................32
2.5.3 Crystal/Clear.....................................................................................................34
2.6 Consideraes Finais ...................................................................35

3 EXTREME PROGRAMMING (XP) .....................................................37

3.1 Introduo .......................................................................................37

3.2 Os Quatro Valores do XP ...............................................................38

3.3 As Doze Prticas do XP .................................................................40

3.3.1 Jogo de planejamento ......................................................................................42
3.3.2 Pequenas verses............................................................................................43
3.3.3 Metfora ...........................................................................................................44
3.3.4 Projeto simples.................................................................................................45
3.3.5 Teste ................................................................................................................45
3.3.6 Refactoring .......................................................................................................46
3.3.7 Programao em pares ....................................................................................47
3.3.8 Propriedade coletiva.........................................................................................49
3.3.9 Integrao contnua..........................................................................................49
3.3.10 Semana de 40-horas ......................................................................................50
3.3.11 Cliente dedicado.............................................................................................50
3.3.12 Cdigo padro................................................................................................51
3.4 Ciclo de Vida e as Fases do Processo XP....................................51
3.4.1 Explorao .......................................................................................................52
3.4.2 Planejamento ...................................................................................................53
3.4.3 Iterao para primeira verso...........................................................................55
3.4.4 Produo ..........................................................................................................55
3.4.5 Manuteno......................................................................................................56
3.4.6 Fim do Projeto ..................................................................................................57
3.5 Papis do Time ...............................................................................57

3.6 Consideraes Finais.....................................................................59

4 ICONIX................................................................................................60

4.1 Introduo .......................................................................................60

4.2 Tarefas e Marcos do ICONIX..........................................................62

4.2.1 Anlise de requisitos ........................................................................................62
4.2.2 Anlise e projeto preliminar ..............................................................................63
4.2.3 Projeto ..............................................................................................................64
4.2.4 Implementao.................................................................................................64
4.3 Alertas do ICONIX...........................................................................65

4.4 Modelo de Domnio.........................................................................66

4.5 Modelo de Caso de Uso .................................................................67

4.6 Anlise de Robustez.......................................................................71

4.7 Modelo de Interao .......................................................................74

4.8 Endereando Requisitos................................................................77

4.9 Consideraes Finais.....................................................................80

5 PROCEDIMENTOS METODOLGICOS ...........................................81

5.1 Ambiente da Aplicao e Escalonamento dos Processos .........81

5.1.1 Infra-estrutura e tecnologia de desenvolvimento..............................................81
5.1.2 Escalonamento dos processos X sistemas ......................................................82
5.2 Aplicao do XP..............................................................................83
5.2.1 Composio e tarefas do time..........................................................................83
5.2.2 Descrio do sistema .......................................................................................83
5.2.3 Metfora ...........................................................................................................85
5.2.4 Histrias do usurio..........................................................................................85
5.2.5 Estimativa, priorizao e planejamento ............................................................87
5.2.6 Teste de aceitao ...........................................................................................88
5.2.7 Desenvolvimento orientado por teste ...............................................................88
5.2.8 Entrega da verso para produo ....................................................................89
5.3 Aplicao do ICONIX ......................................................................90
5.3.1 Descrio do sistema .......................................................................................90
5.3.2 Atores (utilizadores) .........................................................................................91
5.3.3 Anlise de requisitos ........................................................................................92
5.3.4 Projeto preliminar .............................................................................................95
5.3.5 Projeto detalhado .............................................................................................97
5.3.6 Implementao.................................................................................................99
5.3.7 Entrega da verso para produo ..................................................................100
6 ANLISE DOS RESULTADOS........................................................102

6.1 Pontos Positivos do XP ...............................................................102

6.2 Pontos Negativos e Problemas com XP .....................................103

6.3 Pontos Positivos do ICONIX........................................................106

6.4 Pontos Negativos e Problemas com ICONIX .............................107

6.5 Comparao do XP e do ICONIX .................................................108

6.6 Questionrio..................................................................................109

6.7 Consideraes Finais...................................................................114

7 CONCLUSO ...................................................................................115

7.1 Trabalhos Futuros ........................................................................116

REFERNCIAS BIBLIOGRFICAS ....................................................118

 Lista de Figuras

Figura 1: Diagrama simplificado do modelo cascata .................................................24

Figura 2: Diagrama simplificado do modelo espiral...................................................25
Figura 3: Diagrama simplificado do modelo de prototipao.....................................27
Figura 4: Modelo Iterativo..........................................................................................28
Figura 5: Distribuio das atividades nas fases do modelo iterativo .........................29
Figura 6: Metodologia SCRUM (adaptado de SCHWABER, 1997)...........................33
Figura 7: Diagrama de planejamento e feedback (WELLS, 2001) ............................39
Figura 8: Colaborao entre as prticas (adaptado de BECK, 2000)........................41
Figura 9: Modelo de carto de histria (adaptado de BECK, 2000) ..........................42
Figura 10: Modelo de carto de tarefa (adaptado de BECK, 2000)...........................43
Figura 11: Comparao: tempo de programao (adaptado de WILLIAMS, 2000)...48
Figura 12: Jogo de Planejamento: Release (adaptado de WAKE, 2002)..................54
Figura 13: Jogo de Planejamento: Iterao (adaptado de WAKE, 2002) ..................54
Figura 14: Processo ICONIX, mostrando a contribuio dos trs amigos ..............60
Figura 15: ICONIX - Atividades da anlise de requisitos...........................................62
Figura 16: ICONIX - Atividades da anlise e projeto preliminar ................................63
Figura 17: ICONIX - Atividades do projeto ................................................................64
Figura 18: Exemplo textual de caso de uso de alto nvel ..........................................68
Figura 19: Exemplo textual de caso de uso...............................................................69
Figura 20: Diagrama de caso de uso ........................................................................70
Figura 21: Smbolos do diagrama de robustez..........................................................71
Figura 22: Regras do diagrama de robustez .............................................................73
Figura 23: Elementos do diagrama de seqncia .....................................................75
Figura 24: Diagrama de atividades da GID ...............................................................84
Figura 25: Planilha para coleta e simulao da GID .................................................85
Figura 26: Carto de histria e tarefas ......................................................................86
Figura 27: Carto de histria e tarefas resumido ......................................................86
Figura 28: Tela de entrada dos dados mensais da GID ............................................90
Figura 29: Diagrama de domnio do InfoSade.........................................................92
Figura 30: Diagrama de casos de uso da recepcionista e coordenador....................93
Figura 31: Diagrama de casos de uso do corpo clnico.............................................94
Figura 32: Lista de requisitos funcionais ...................................................................95
Figura 33: Modelo textual de caso de uso do InfoSade ..........................................96
Figura 34: Diagrama de robustez do caso de uso Configura Agenda.....................97
Figura 35: Diagrama de seqncia do caso de uso Configura Agenda ..................98
Figura 36: Diagrama de classe, parcial, do InfoSade..............................................99
Figura 37: Tela de configurao da agenda do InfoSade......................................101
Figura 38: Tela de agendamento de consultas do InfoSade .................................101
Figura 39: Gosta de programao em pares...........................................................110
Figura 40: Velocidade de programao ..................................................................110
Figura 41: Dificuldade de escrever histrias............................................................111
Figura 42: Necessidade de documentao .............................................................111
Figura 43: Aplicao de refactoring.........................................................................112
Figura 44: Aplicao da integrao contnua ..........................................................112
Figura 45: Preferncia dos clientes entre o XP e o ICONIX....................................113
 Lista de Tabelas

Tabela 1: Dados dos cartes de histria ...................................................................87

Tabela 2: Diviso das histrias em tarefas................................................................88
Tabela 3: Comparao dos processos....................................................................108
 Resumo

BONA, Cristina. Avaliao de Processos de Software: Um estudo de caso em

XP e ICONIX. Florianpolis, 2002. 122f. Dissertao (Mestrado em Engenharia
de Produo) Programa de Ps-Graduao em Engenharia de produo,
UFSC, 2002.

O presente trabalho busca fornecer, atravs de exemplos prticos e

representaes grficas, uma estrutura capaz de orientar as organizaes na
escolha da metodologia mais apropriada para seus projetos de software. Um dos
principais esforos dos pesquisadores envolvidos com a Engenharia de Software
tem sido apresentar e abstrair modelos que descrevem processos de software. Estes
modelos permitem que se compreenda o processo de desenvolvimento dentro de
um paradigma conhecido. A existncia de um modelo apontada como um dos
primeiros passos em direo ao gerenciamento e melhoria do processo de
software. Na ltima dcada, um novo segmento da comunidade de Engenharia de
Software vem defendendo processos simplificados, tambm conhecidos como
processos geis, focados nas pessoas que compem o processo e, principalmente,
no programador. O trabalho apresenta a aplicao e avaliao de dois processos. O
primeiro a ser discutido o Extreme Programming (XP), o qual est entre os
processos geis e que vai contra uma srie de premissas adotadas por mtodos
mais tradicionais de desenvolvimento. O segundo processo o ICONIX, o qual
definido como sendo um processo prtico que utiliza a notao UML. Como produto
final, alm da aplicao de cada processo, so discutidos os seus pontos positivos e
negativos. Um estudo comparativo entre os modelos tambm elaborado, onde so
examinados simultaneamente os recursos de ambos os processos, para desta
forma, determinar quais caractersticas devem ser inerentes a um processo de
software que garanta a produtividade e qualidade.

Palavras-chave: Processo de Software, Extreme Programming, ICONIX, UML.

 Abstract

BONA, Cristina. Avaliao de Processos de Software: Um estudo de caso em

XP e ICONIX. Florianpolis, 2002. 122f. Dissertao (Mestrado em Engenharia
de Produo) Programa de Ps-Graduao em Engenharia de produo,
UFSC, 2002.

This work intends to offer, by means of practical examples and graphic notations,
a document guide to lead the choice in organizations of the proper methodology for
its software projects. One of the main researchers' efforts involved with the Software
Engineering has been to present and to abstract models that describe software
processes. These models allow the understanding about the development process
inside a well-known paradigm. The existence of a model is pointed as one of the first
steps in direction to the management and to the improvement of the software
process. In the last few years, a new faction of the Software Engineering community
is defending the necessity of simpler processes, also known as agile processes,
which focus on the people that compose the process and, mostly, on the
programmer. This work introduces the application and evaluation of two processes.
The first one to be discussed is the Extreme Programming (XP), one of the more
known among the agile processes. XP goes against a set of premises adopted by
more traditional development methods. The second process to be presented and to
be discussed is ICONIX, which is defined as a practical process that uses the UML
notation. After the presentation of the two processes, it is presented a practical
application of each process where their positive and negative aspects are pointed
out. A comparative study between the two models is also elaborated, where are
examined the resources from both processes. In this way, the work concludes how to
determine which aspects should be inherent to a software process that guarantees
productivity and quality.

Keywords: Software Process, Extreme Programming, ICONIX, UML.

 14

1 INTRODUO

1.1 Contextualizao

O impacto e a rpida evoluo ao longo dos ltimos 40 anos das tecnologias

relacionadas com os sistemas de informao tm colocado sucessivos desafios s
empresas. A dependncia e demanda crescentes da sociedade em relao
Informtica e, em particular, a software, tem ressaltado uma srie de problemas
relacionados ao processo de desenvolvimento de software: alto custo, alta
complexidade, dificuldade de manuteno, e uma disparidade entre as necessidades
dos usurios e o produto desenvolvido.

Empresas de software em todo o mundo empregam perto de 7 milhes de

tcnicos e geram anualmente uma receita de mais de 600 bilhes de dlares, com
taxa de crescimento anual de mais de 25% nos ltimos trs anos. A indstria de
software vista atualmente como um dos segmentos mais promissores, com um
enorme potencial futuro (CORDEIRO, 2000). Desta forma, desenvolver projetos de
software eficientes de fundamental importncia para a indstria de software como
um todo.

A necessidade de se encontrar mtodos que pudessem ajudar na evoluo do

processo de construo de software, culminaram com o desenvolvimento da
Engenharia de Software. Essa nova abordagem ao processo de construo de
software trouxe consigo mtodos e tcnicas que ajudaram na administrao da
complexidade inerente do software. Conforme Silva & Videira (2001), a comunidade
de Engenharia de software, desde os finais da dcada de 60, estuda e implementa
prticas de desenvolvimento de software bem organizadas e documentadas.

Os processos usados para desenvolver um projeto de software tm a maior

importncia na qualidade do software produzido e na produtividade alcanada pelo
projeto. No entanto, no existe um modelo uniforme que possa descrever com
preciso o que de fato acontece durante todas as fases da produo de um
software; os processos implementados so muito variados, e as necessidades de
cada organizao diferem substancialmente (SILVA & VIDEIRA, 2001).
 15

Alm disso, na ltima dcada, um segmento crescente da comunidade de

Engenharia de Software vem defendendo a existncia de problemas fundamentais
da aplicao sistemtica e institucionalizada de processos de software
convencionais (HIGHSMITH, 2002), (BECK, 2000), (FOWLER, 2001) e
(SCHWABER, 1997). Estes proponentes advogam processos simplificados, focados
nas pessoas que compem o processo, e principalmente no programador.

O processo Extreme Programming (XP) est entre os denominados processos

geis (HIGHSMITH, 2002), que vai contra uma srie de premissas adotadas por
mtodos mais tradicionais de desenvolvimento. XP consiste numa srie de prticas e
regras que permitem aos programadores desenvolver software de uma forma
dinmica e gil, com mnimo de documentao.

Neste contexto, o processo ICONIX define-se como um processo de

desenvolvimento de software prtico. O ICONIX est entre a complexidade e
abrangncia do RUP (Rational Unified Processes) e a simplicidade e o pragmatismo
do XP, mas sem eliminar as tarefas de anlise e de desenho que o XP no
contempla.

1.2 Objetivos do Trabalho

1.2.1 Objetivo geral

O objetivo principal deste trabalho realizar um estudo comparativo entre os

modelos de desenvolvimento de sistemas o XP e o ICONIX, buscando fornecer uma
estrutura capaz de orientar as organizaes na escolha da metodologia mais
apropriada para seus projetos de software.

1.2.2 Objetivos especficos

Estudar os principais processos de desenvolvimento de software;

Estudar, atravs da reviso bibliogrfica, o modelo Extreme Programming ;

Estudar, atravs da reviso bibliogrfica, o modelo ICONIX;

Especificar a estrutura para aplicao dos modelos;

 16

Descrever os pontos positivos e negativos dos dois processos avaliados;

Apresentar um esquema comparativo dos modelos;

Validar a aplicao;

Anlise dos resultados.

1.3 Justificativa do Trabalho

A Engenharia de Software foi sempre muito mais aplicada no ambiente

acadmico que no mercado de desenvolvimento. Entretanto, a competitividade e a
necessidade crescente por um desenvolvimento de qualidade em prazos apertados
tem feito com que as empresas mudem sua forma de trabalhar e procurem solues
para a organizao do processo de desenvolvimento de software. No Brasil, cerca
de 87% das empresas de desenvolvimento de software so de pequeno e mdio
porte (SEMEGHINI, 2001). Sendo assim, existem limitaes de recursos para serem
aplicados em treinamento e consultorias voltadas implantao de qualidade de
software e de um processo que garanta resultados adequados.

Atualmente, a prtica tem mostrado resultados que estimulam a reviso dos

procedimentos tradicionais de engenharia de requisitos. O trabalho em grupo outra
importante ferramenta para aumentar o conhecimento sobre um determinado
assunto. O processo de discusso faz com que novas idias sejam consideradas e
oferece diversas vises sobre o mesmo problema. Estas novas tendncias de
trabalho so interessantes na rea de desenvolvimento de software, uma vez que a
caracterstica de resolver problemas colaborativamente (em grupo) uma realidade
(BECK, 2001), (COCKBURN, 2000).

A diversidade de processos de desenvolvimento de software (FOWLER, 2000),

(SUTHERLAND, 2000), (EVANS, 2001), (ROSENBERG & SCOTT, 1999) tambm
faz com que seja importante um bom entendimento sobre como desenvolver
software de qualidade e encontrar qual o processo mais adequado para o tipo de
software que ser desenvolvido.
 17

1.4 Estrutura do Trabalho

O trabalho est estruturado da seguinte forma:

Captulo 1: Neste captulo apresentada a contextualizao da pesquisa deste

trabalho, enfatizando os objetivos propostos e a justificativa.

Captulo 2: Aborda uma reviso sobre processo de software. Apresentando uma

separao em fases do processo, atividades do processo, modelos
de clico de vida e metodologias geis.

Captulo 3: Este captulo descreve o modelo de processo XP. Enfatizando os

quatro valores e apresentando detalhes das doze prticas do
processo. Apresenta tambm o clico de vida do XP e, destaca
alguns pontos positivos e negativos.

Captulo 4: Este captulo apresenta o modelo de processo ICONIX. Mostra as

principais tarefas e marcos do processo, destacando os alertas do
mesmo. Aborda tambm os modelos utilizados exemplificando-os.

Captulo 5: Identifica os procedimentos metodolgicos utilizados para a

realizao do trabalho. Apresenta o ambiente da aplicao e como
foi realizada a coleta das informaes atravs da aplicao do XP e
da aplicao do ICONIX.

Captulo 6: Este captulo apresenta a anlise dos resultados. Destaca os pontos

positivos e negativos do XP e do ICONIX. Alm de exibir uma tabela
comparativa entre ambos os processos. Adicionalmente, realizado
um questionrio e o resultado representado graficamente.

Captulo 7: Apresenta as concluses alcanadas no desenvolvimento desta

pesquisa, e as recomendaes e trabalhos futuros.
 18

2 PROCESSO DE SOFTWARE

2.1 Introduo

Muito do que ser investigado neste trabalho diz respeito ao Processo de

Software, e para defini-lo, cabe alguma discusso. Existe alguma sobreposio em
relao aos termos Processo, Modelo, Mtodo e Metodologia, gerando confuso em
algumas circunstncias. Embora no sejam sinnimos, comum observar na
literatura o uso de um termo em lugar do outro. Assim, necessrio buscar
definies para fundamentar o objetivo deste trabalho, que envolve o entendimento
de um processo para software.

O Processo de Software definido por Sommerville (1995) como:

O processo um conjunto de atividades e resultados associados que produzem

um produto de software.

Pressman (1997), oferece a seguinte definio:

...definimos um processo de software como um framework para as tarefas que

so necessrias para a construo de software de alta qualidade.

De acordo com Thiry (2001), o processo de software tem a seguinte definio:

O processo define quem ir fazer o que e como ser atingido o objetivo. O

objetivo construir um software ou melhorar um existente".

Estas definies oferecem uma idia mais clara do que considerado um

processo. Diretamente delas, pode-se retirar os seguintes pontos:

O processo rene um conjunto de atividades. Como existem atividades que

englobam outras atividades, pode-se usar o termo fase para descrever
atividades de nvel mais alto;

A definio contempla na prtica: procedimentos e mtodos, ferramentas e

equipamentos, comunicao e pessoas;

O processo tem como objetivo desenvolver um produto de software.

Pressman (1997) restringe o termo a processos que geram produtos de alta
 19

qualidade, mas se esta restrio for ignorada, pode-se aplicar o termo a

qualquer conjunto de atividades que aplicada com o objetivo de desenvolver
software;

O processo direciona as tarefas individuais e do time como um todo.

O nvel de detalhamento de cada processo depende da equipe envolvida no

desenvolvimento do software. Rezende (2002) usa a metfora da receita de bolo
para representar o processo. Quem segue uma receita tem a liberdade de adicionar
ou suprir partes, assim tambm pode ocorrer com o processo, estabelecendo um
dinamismo na execuo.

No h processo correto ou incorreto; dependendo da sua aplicao, ambiente e

objetivo, o uso de um processo especfico pode ser vantajoso ou no. Um ponto
importante a ressaltar que, cada autor e organizao colocam e classificam
processos e atividades de forma diferente, tornando difcil uma uniformidade
completa. As sees seguintes discutem vises alternativas, e se baseiam em
caractersticas comuns encontradas na literatura para classificar fases, atividades e
modelos de processo.

2.2 Fases do Processo de Software

Pela definio, podemos entender o que o processo; no entanto, torna-se

importante conhecer quais as fases que o compe.

Em meados dos anos 70, Schwartz (1975) j apontava como fases principais do
processo de produo de um sistema de software:

Especificao de Requisitos: traduo da necessidade ou requisito

operacional para uma descrio da funcionalidade a ser executada;

Projeto de Sistema: traduo destes requisitos em uma descrio de todos

os componentes necessrios para codificar o sistema;

Programao (codificao): produo do cdigo que controla o sistema e

realiza a computao e lgica envolvida;

Verificao e Integrao (checkout): verificao da satisfao dos requisitos

iniciais pelo produto produzido.
 20

A definio moderna oferecida por Sommerville (1995) similar; define as fases

como Especificao, Desenvolvimento, Validao e Evoluo. Este ltimo ponto no
descrito diretamente por Schwartz (1975):

Evoluo (manuteno): alterao do software para atender a novas

necessidades do usurio.

interessante observar que destacada a questo da longevidade do software

no item Evoluo. Neste sentido, pode-se perceber que a definio de Schwartz
(1975) omite uma particularidade importante: o software continua sendo
desenvolvido mesmo depois de entregue. Pressman (1997) oferece uma viso
compatvel com esta, ainda que simplificada: as fases descritas so definio,
desenvolvimento e manuteno.

Neste contexto, Leach (2000) destaca o processo de desenvolvimento de

software usado na Microsoft. Onde a maior parte dos novos softwares desenvolvidos
tem trs fases: o planejamento, o desenvolvimento e a estabilizao. A ltima fase
compreende os testes realizados dentro da Microsoft e os testes realizados por
usurios externos a partir de uma verso beta. A estabilizao acontece quando as
mudanas so visveis e o nmero de erros est bem reduzido, em um nvel
aceitvel. Este nvel baseado no conhecimento do time em saber se o software
seguro. A evoluo est presente nas constantes melhorias que a empresa realiza
em seus produtos.

importante ressaltar que no existe uma seqncia nem um nmero obrigatrio

de fases. Rezende (2002) ressalta que mesmo considerando a ISO 9000-3, no
existe um padro universalmente aceito, podendo esta diviso ter mais ou menos
fases.

Alm da questo de seqencialidade, existem autores que defendem que o

processo de software muito mais iterativo e cclico do que a idia de fases simples
pode sugerir. Em particular, Microsoft (1996), Leach (2000), Beck (2000) e o
prprio Rational Unified Process (RUP) sugerem processos onde existem ciclos
contnuos e repetidos, onde alguma forma de produto desenvolvida a cada ciclo. A
extenso de cada ciclo, no entanto, no um consenso.
 21

2.3 Atividades do Processo de Software

Para cada fase do processo de desenvolvimento de software existe uma srie de

atividades que so executadas. Segundo Pressman (1997) as atividades constituem
um conjunto mnimo para se obter um produto de software. Observando as fases
individuais e suas atividades associadas, combinando classificaes de Schwartz
(1975), Pressman (1997) e Sommerville (1995), possvel identificar as seguintes
atividades:

Especificao

Engenharia de Sistema: estabelecimento de uma soluo geral para o

problema, envolvendo questes de tecnologia e equipamento;

Anlise de Requisitos: levantamento das necessidades do software a ser

implementado. A Anlise tem como objetivo produzir uma especificao de
requisitos, que convencionalmente um documento;

Especificao de Sistema: descrio funcional do sistema. Pode incluir um

plano de testes para verificar adequao.

Projeto

Projeto Arquitetural: onde desenvolvido um modelo conceitual para o

sistema, composto de mdulos mais ou menos independentes;

Projeto de Interface: onde cada mdulo tem sua interface de comunicao

estudada e definida. Pode resultar em um prottipo;

Projeto Detalhado: onde os mdulos em si so definidos, e possivelmente

traduzidos para pseudocdigo1.

Implementao

Codificao: a implementao em si do sistema em uma linguagem de

computador, de programao.

1
Instrues do computador escritas pelo programador em linguagem simblica.
 22

Validao

Teste de Unidade e Mdulo: a realizao de testes para verificar a presena

de erros e comportamento adequado relacionado s funes e mdulos
bsicos do sistema;

Integrao: a reunio dos diferentes mdulos em um produto de software

homogneo, e a verificao da interao entre estes quando operando em
conjunto.

Evoluo e Manuteno

Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas
as fases anteriores.

O Processo de Software pode ser visto como um gerador de produtos, sendo que
o produto final, ou principal, o Software em si. importante perceber que existem
subprodutos que so gerados para cada fase. Como exemplo, ao final da fase de
Especificao, comum ter sido desenvolvido e entregue um ou mais documentos
que detalham os requisitos do sistema. Estes subprodutos tambm so chamados
na literatura de deliverables ou artefatos.

Todo modelo de software deve levar em considerao as fases descritas; no

entanto, cada um organiza estas fases de acordo com sua filosofia de organizao.
Na prxima seo, so analisados alguns modelos mencionados na literatura.

2.4 Modelos de Ciclo de Vida

O ciclo de vida a base para a gerncia e controle o projeto, o corao do

processo, pois define as fases e atividades a serem seguidas. Entretanto, um ciclo
de vida no define notao nem se preocupa em estabelecer claramente os
artefatos a serem produzidos.

Thiry (2001) considera que ...modelo uma coleo de artefatos, cada um

expressando uma viso do sistema. ....artefato qualquer informao produzida por
um participante (modelo, documentos). Um artefato pode ter ainda, suas verses
controladas.
 23

Existem alguns modelos tericos desenvolvidos que buscam descrever a forma

com que as fases seguem e interagem. Nesta seo esto descritos alguns dos
modelos de clico de vida mais conhecidos, como: modelo cascata, modelo espiral,
modelo prottipo e modelo iterativo e incremental (ICONIX, RUP). Existe alguma
flexibilidade no que diz respeito definio do termo modelo, neste trabalho so
considerados, dentre os modelos descritos na literatura, os que tm um carter
estratgico, e no especfico. Em outras palavras, um modelo uma filosofia do
andamento das fases ciclo de vida, e no uma descrio de como cada atividade
deve ser executada.

A seo 2.5, por sua vez, descreve algumas metodologias, que so formas
prticas de organizar o processo de desenvolvimento. Uma metodologia traz
conceitos bastante especficos em relao ao desenvolvimento, como exemplifica
Beck (2000) em sua descrio da metodologia Extreme Programming (XP):
programao em pares, ciclos pequenos e equipes com at 10 programadores.

2.4.1 Modelo cascata

O modelo mais comum de processo de desenvolvimento de software chamado

de modelo cascata (LEACH, 2000). Este modelo foi idealizado em 1970 por Royce
(THIRY, 2001), e tem como caracterstica principal seqencialidade das atividades:
sugere um tratamento ordenado e sistemtico ao desenvolvimento do software.
Cada fase transcorre completamente e seus produtos so vistos como entrada para
a nova fase. O software desenvolvido em um longo processo e entregue ao final
deste. O modelo sugere laos de feedback, que permitem realimentar fases
anteriores do processo, mas em geral o modelo cascata considerado um modelo
linear (LEACH, 2000). A figura 1 fornece uma descrio visual do modelo.

A maior relevncia deste modelo est na reunio de diversos conceitos que so

adotados at hoje. Alm disso, ele estabeleceu a necessidade de definir uma
sistemtica para o desenvolvimento de software. Entretanto, possvel observar que
a rigidez da sistemtica proposta inicialmente resulta na inadequao deste modelo
para processos reais. Geralmente, h muito intercmbio de informaes entre as
fases, e este modelo no permite flexibilidade de retorno nas sequncias, tornando o
desenvolvimento do software altamente engessado (REZENDE, 2002). A
 24

manuteno ainda considerada uma fase por si s, enquanto a forma moderna de

desenvolvimento estabelece que a manuteno deve ser feita atravs da
reaplicao do processo sob as novas demandas. Alm disso, o modelo cascata no
leva em considerao questes modernas importantes ao desenvolvimento:
prototipao, aquisio de software e alteraes constantes nos requisitos, por
exemplo s apresentadas por Beck (2000) e Cockburn (2000).

Especificao

Projeto

Codificao

Teste e integrao

Manuteno

Figura 1: Diagrama simplificado do modelo cascata

Apesar das suas limitaes, o modelo em cascata foi base para o surgimento
de diferentes modelos de ciclo de vida.

2.4.2 Modelo espiral

O modelo espiral uma forma elaborada do modelo cascata, introduzido por

Barry Boehm em um artigo publicado na IEEE Computer em Maio de 1988. Boehm
sugeriu um modelo evolucionrio para o desenvolvimento de software, baseado em
uma seqncia de fases que culminam em verses incrementais do software
(CANTOR, 1998). Esta caracterstica incremental confirmada no conceito do
modelo de prototipao rpida (LEACH, 2000), e em metodologias de processo mais
modernas, como RUP, ICONIX e Extreme Programming descrita por Beck (2000).

O modelo espiral define quatro importantes atividades representadas em quatro

quadrantes conforme representado na figura 2:

Determinao dos objetivos: definio que ser desenvolvido, restries

impostas aplicao, tais como desempenho, funcionalidade, capacidade de
acomodar mudanas, meios alternativos de implementao;
 25

Anlise de risco: anlise das alternativas e identificao/resoluo dos riscos.

Uma vez avaliados os riscos, pode-se construir prottipos para verificar se
estes so realmente robustos para servir de base para a evoluo futura do
sistema;

Desenvolvimento: detalhe do projeto, codificao, integrao;

Planejamento e prxima iterao: avaliao dos resultados pelo cliente,

entrega ao cliente.

Segundo Schneider (1999), um aspecto bastante intrigante do modelo espiral

torna-se aparente quando passa a se considerar a sua dimenso radial. Cada
iterao ao redor da espiral (comeando pelo centro e crescendo para fora), indica
que uma meta do projeto foi executada. Durante o primeiro ciclo ao redor de uma
espiral, objetivos, alternativas e restries so definidas, riscos so identificados e
analisados. Se a anlise de risco indicar que h dvidas nos requisitos, a
prototipao pode ser usada no quadrante de desenvolvimento para assegurar o
projeto. Entretanto, em muitos casos, o fluxo ao redor da espiral continua, onde cada
rotao indica uma evoluo significativa do projeto, at a sua completa concluso.
Cada circuito ao redor da espiral, envolve desenvolvimento que pode ser alcanado
com o modelo cascata ou prototipao.

Determinar Anlise de
objetivos risco

Desenvolvimento
Planejamento
do produto
prxima iterao

Figura 2: Diagrama simplificado do modelo espiral

 26

Geralmente, modelos incrementais tm o objetivo de lidar melhor com um

conjunto de requisitos incertos ou sujeitos a alteraes. O modelo espiral parece
mais bem adequado a projetos reais que o modelo cascata.

Entretanto, Cantor (1998) faz algumas recomendaes sobre a forma que o

modelo apresentado, que pode ser muito detalhado para atender as necessidades
de um projeto. O modelo espiral assume a existncia de alguma seqncia entre as
fases: no h suporte para fases que ocorrem simultaneamente, ou que necessitam
de intercomunicao contnua para operarem.

2.4.3 Modelo de prototipao

Segundo Leach (2000), o modelo de prototipao iterativo e requer a criao de

um ou mais prottipos como parte de um processo de desenvolvimento de software.

O modelo de prototipao se baseia na utilizao de um prottipo do sistema

real, para auxiliar na determinao de requisitos. Um prottipo deve ter custo
reduzido e rpida obteno, para que possa ser avaliado. Para isto, uma parte do
sistema desenvolvida com o mnimo de investimento mas sem perder as
caractersticas bsicas, para ser analisada juntamente com o usurio (ver figura 3).

De acordo com Pascoal (2001), a prototipao um processo que habilita o

desenvolvedor a criar um modelo do software que deve ser construdo. O modelo
pode ter diferentes formas, como:

uma no papel ou em um modelo baseado em computador, no qual a interao

homem-mquina desenhada para permitir ao usurio entender como tal
interao ir ocorrer;

uma verso funcional que contm apenas um subconjunto das

funcionalidades requeridas no software desejado;

um prottipo em execuo, o qual executa parte ou todas a funes

desejadas, mas tem outras caractersticas que sero melhoradas no
desenvolvimento.

Por sua vez, o prottipo pode servir como um "primeiro sistema". Neste sentido,
Pascoal (2001) destaca que alguns problemas podem surgir quando o cliente
 27

visualiza o que parece ser uma verso do software, sem perceber que na realidade,
no foram considerados aspectos de qualidade e de manuteno. Quando
informado de que o produto deve ser reconstrudo, o cliente "implora" para que no
mude. Outro problema, o desenvolvedor assumir um compromisso de
implementao para obter um prottipo funcional rapidamente. Ento, um sistema
operacional ou linguagem de programao inadequados podem ser usados
simplesmente porque esto disponveis e so conhecidos.

Incio

Coleta e
Fim refinamento
dos requisitos

Engenharia Projeto
do produto rpido

Refinamento Construo
do prottipo do prottipo

Avaliao do
prottipo
pelo cliente

Figura 3: Diagrama simplificado do modelo de prototipao

2.4.4 Modelo iterativo e incremental

Larman (2000) apresenta que Um ciclo de vida iterativo se baseia no aumento e

no refinamento sucessivo de um sistema atravs de mltiplos ciclos de
desenvolvimento de anlise, de projeto, de implementao e de teste (ver figura 4).

O modelo iterativo corresponde idia de melhorar pouco-a-pouco, ou seja,

refinar o sistema. A essncia do sistema no alterada, mas o seu detalhe vai
aumentando em iteraes sucessivas. Por sua vez, o modelo incremental
corresponde idia de aumentar pouco-a-pouco a esfera do sistema, ou seja,
alargar o sistema em sucessivos incrementos (SILVA & VIDEIRA, 2001).
 28

Anlise
Planejamento Requisitos
Inicial
Projeto

Iterao (N) Implementao

Planejamento

Avaliao Entrega
Teste

Figura 4: Modelo Iterativo

Desta forma, Silva & Videira (2001) definem que O princpio subjacente ao
modelo iterativo e incremental que a equipe envolvida possa refinar e alargar
pouco-a-pouco a qualidade, detalhe e mbito do sistema envolvido.

Neste sentido, a equipe seleciona o que deve ser feito em cada iterao baseada
em dois fatores. Primeiro, a iterao deve trabalhar com um grupo de casos de uso
que juntos estendam a usabilidade do produto em desenvolvimento. Segundo, a
iterao deve tratar os riscos mais importantes (MARTINS, 1999).

Cantor (1998) apresenta as atividades do modelo iterativo e incremental

distribudas em quatro fases: concepo, elaborao, construo e transio (ver
figura 5). Estas fases so organizadas em uma srie de atividades. Entretanto, o
trmino de cada fase no determinado pela execuo completa de suas
atividades. Desta forma, o projeto pode avanar mesmo quando ainda houver
alguma pendncia. Estas pendncias vo sendo resolvidas ao longo das demais
fases. Cada fase tem como propsito o seguinte:

Concepo: entendimento inicial e concordncia da definio do produto, isto

, o que ser entregue. A principal atividade a reviso do escopo do projeto,
atravs de uma modelagem de negcio e reviso dos requisitos do sistema. O
principal artefato desta fase um documento com a viso geral do sistema
em desenvolvimento;

Elaborao: entendimento inicial e concordncia do projeto detalhado, isto ,

como ser construdo. O objetivo desta fase preparar a documentao
 29

necessria para que a codificao do sistema possa acontecer de forma

organizada, reduzindo a distncia entre os requisitos e os resultados. As
principais atividades so a reviso do empacotamento dos requisitos,
detalhamento dos requisitos, definio das entidades (inclusive, as
persistentes), montagem inicial do plano de testes, organizao da arquitetura
do sistema, orientao para a codificao e definio da interface;

Construo: criao do primeiro build2 totalmente funcional. Durante o

processo so desenvolvidos builds incrementais. Esta fase est associada
principalmente com a codificao do sistema. Entretanto, possui tambm
atividades relacionadas com anlise e projeto. necessrio realizar uma
reviso dos modelos gerados pela fase de elaborao. Alm disso, testes
sero feitos com base nos componentes desenvolvidos;

Transio: entrega do produto de acordo com os requisitos iniciais. A fase de

transio est relacionada com a implantao e estabilizao final do sistema.
Alm disso, so aplicados os testes de aceite e os ajustes finais.

WorkFlow Concepo Elaborao Construo Transio

Modelagem
de negcios

Requisitos

Anlise e
Projeto

Implementao

Teste

Iteraes Iter. Iter. Iter. Iter. Iter. Iter.

Iteraes preliminares #1 #2 #n #n+1 #n+2 #m

Figura 5: Distribuio das atividades nas fases do modelo iterativo

2
Um build uma pr-verso do sistema que atende um conjunto de requisitos funcionais.
 30

H vrios benefcios em se adotar um processo iterativo e incremental , entre os

quais pode-se destacar (MARTINS, 1999):

Reduo dos riscos envolvendo custos a um nico incremento. Se a equipe

precisar repetir a iterao, perde-se somente o esforo mal direcionado de
uma iterao, no o valor de um produto inteiro;

Reduo do risco de lanar o produto no mercado fora do cronograma

previsto. Identificando os riscos na fase inicial do projeto o tempo gasto para
gerenci-los ocorre cedo, quando as pessoas esto sob menos presso do
que numa fase final de projeto;

Acelerao do tempo de desenvolvimento do projeto como um todo, porque

os desenvolvedores trabalham de maneira mais eficiente quando buscam
resultados de escopo pequeno e claro;

Reconhecimento de uma realidade freqentemente ignorada: as

necessidades dos usurios e os requisitos correspondentes no podem ser
totalmente definidos no incio do processo. Eles so tipicamente refinados em
sucessivas iteraes. Este modelo de operao facilita a adaptao a
mudanas de requisitos.

O modelo iterativo e incremental um modelo emergente. Seu enfoque

interessante no sentido de que usa a flexibilidade e modularidade do
desenvolvimento orientado a objeto. Assim, prov um ciclo de vida que combina
ambas a preocupao com como as pessoas trabalham e concede o controle de
gerenciamento (CANTOR, 1999). Estas caractersticas esto presentes em grande
parte das metodologias atuais, que focam os aspectos prticos do desenvolvimento,
e no em questes filosficas profundas. Na prxima seo so analisadas algumas
metodologias de desenvolvimento, tambm chamadas de processos leves
(lightweight processes) ou processos geis (BECK, 2000), (FOWLER, 2001).
 31

2.5 Metodologias geis

Fowler (2001) coloca que as metodologias modernas de desenvolvimento, como

Extreme Programming (XP) e SCRUM, so uma reao a modelos extremamente
conceituais e a metodologias monumentais. Nas suas palavras:

Estas metodologias monumentais existem h muito tempo. Elas no so

conhecidas por serem particularmente de sucesso [...] A crtica mais
freqente a estas metodologias que so burocrticas. Existe tanto material
h ser produzido para seguir a metodologia, que a velocidade de
desenvolvimento diminui [...] Como uma reao a estas metodologias, um
grupo novo de metodologias apareceu nos ltimos anos [...] Estes novos
mtodos tentam estabelecer um compromisso til entre nenhum processo e
processo demasiado, provendo apenas processo suficiente para fornecer
uma vantagem razovel.

Segundo Evans (2001), por dcadas o processo de desenvolvimento de software

tem sido um tpico interessante. Mas nos ltimos anos, o debate retornou de forma
intensa. Pois uma nova abordagem os processos geis ou leves vem de encontro
abordagem dos processos pesados como a tradicional abordagem cascata,
comentada na seo anterior, e o RUP, processo introduzido em 1990, para prover
produtos baseados em UML (Unified Modeling Language) (OMG, 2001).

Nesta seo esto descritas metodologias geis para o desenvolvimento, que

so formas especficas de organizar o processo de software para obter vantagens de
qualidade e produtividade. A metodologia tem por objetivo especificar tarefas
aplicando um conceito especfico (refactoring e programao em pares no XP, por
exemplo) a cada fase do desenvolvimento, e propor solues prticas para
problemas comuns. Posteriormente, sero detalhas em seo independente, a
metodologia ICONIX considerada uma metodologia intermediria e a
metodologia XP, que so as metodologias analisadas neste trabalho, com enfoque
maior na anlise de requisitos.

2.5.1 Extreme Programming (XP)

O trabalho de Beck (2000) descreve um processo minimalista onde existe muito

pouca burocracia envolvida no desenvolvimento. Equipes pequenas, de at 10
 32

desenvolvedores, trabalham em iteraes curtas, produzindo software de modo

incremental, e analisando requisitos medida que estes so descritos pelo cliente.

O XP se apia em um contnuo refinamento do projeto e da implementao deste

no cdigo. Para realizar este refinamento, aplica alguns princpios bsicos como:
propriedade coletiva, programao em pares, histrias do usurio, refactoring e
testes de unidade. A metodologia XP ser detalha posteriormente no captulo 3.

O interesse que XP tem gerado entre a comunidade de desenvolvimento - desde

o ano de 2000 realizada anualmente a Extreme Programming Conference - pode
ter relao com sua atitude de menor esforo em face de problemas complexos do
desenvolvimento (XP2002, 2000). Por exemplo, a documentao do sistema deve
ser mantida junto com o prprio cdigo fonte e deve ser mnima, forando o
desenvolvedor a escrever cdigo auto-explicativo e a evitar complexidade.

2.5.2 SCRUM

Uma outra metodologia de desenvolvimento que classificada como gil o

SCRUM3 (SUTHERLAND, 2000). Esta metodologia foi criada na Easel, e
posteriormente desenvolvida por duas empresas em conjunto: Advanced
Development Methods e VMARK. Seu objetivo fornecer um processo conveniente
para projeto e desenvolvimento orientado a objeto (SUTHERLAND, 2000).

A metodologia baseada em princpios semelhantes aos do XP: equipes

pequenas, requisitos pouco estveis ou desconhecidos, e iteraes curtas para
promover visibilidade para o desenvolvimento. No entanto, as dimenses em
SCRUM diferem do XP.

SCRUM divide o desenvolvimento em iteraes (chamadas de sprints) de 30

dias. Equipes pequenas, de at 07 (sete) pessoas, so formadas por projetistas,
programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em
cima de funcionalidade (os requisitos, em outras palavras) definidas no incio de
cada sprint. A equipe responsvel pelo desenvolvimento desta funcionalidade.

3
A palavra Scrum vem do nome de uma ttica utilizada em rugby, onde um grupo de jogadores
precisa trabalhar em equipe para recuperar uma bola perdida.
 33

Neste sentido, Fowler (2001) destaca que o ponto estabilizar os requisitos durante
o sprint.

Ainda de acordo com Fowler (2001), todo dia, feita uma reunio de 15 minutos
onde o time expe gerncia o que ser feito no prximo dia, e nestas reunies os
gerentes podem levantar os fatores de impedimento (bottlenecks), alm de avaliar o
progresso geral do desenvolvimento. SCRUM interessante porque fornece um
mecanismo de informao de status que atualizado continuamente, e porque
utiliza a diviso de tarefas dentro da equipe de forma explcita.

Schwaber (1997) ressalta que a anlise, o projeto, e os processos de

desenvolvimento na fase de sprint so inconstantes. Entretanto, um mecanismo de
controle usado para administrar a imprevisibilidade e controlar o risco. O resultado
flexibilidade, receptividade e confiabilidade (ver figura 6).

Desenvolver

Planejamento e Fechamento
Ajustar Rever
Arquitetura do
Sistema
Sprints

Figura 6: Metodologia SCRUM (adaptado de SCHWABER, 1997)

Segundo Schwaber (1997), as caractersticas da metodologia SCRUM so:

A primeira fase e a ltima fase (planejamento e fechamento) consistem em

definir processos. Todos os processos de entrada e de sada so bem
definidos e a forma de como executar o processo explicito. O fluxo linear,
com algumas iteraes na fase de planejamento;

A fase de sprint um processo emprico, ou seja, baseado somente na

experincia do time. Alguns processos na fase de sprint no so identificados
ou controlados. Ento, so tratados como controles de requisitos externos.
 34

Estes controles, incluindo os riscos de gerenciamento, so colocados em

cada iterao da fase de sprint para evitar o caos enquanto maximizam
flexibilidade;

Sprints so flexveis e no-lineares. Se disponvel, o conhecimento explcito

do processo usado. Caso contrrio, o conhecimento tcito, tentativa, e erro
so usados para construir o conhecimento do processo. Os sprints servem
para evoluir no produto final;

O projeto permanece aberto ao ambiente at a fase de fechamento. O produto

a ser entregue pode ser mudado a qualquer momento durante o planejamento
e as fases de sprint do projeto. O projeto permanece aberto complexidade
do ambiente, inclusive competitividade, tempo, qualidade, e presses
financeiras, ao longo destas fases;

O produto a ser entregue determinado durante o projeto, baseado no

ambiente.

Nos ltimos anos, o mtodo de desenvolvimento SCRUM tem rapidamente

ganhado reconhecimento como uma ferramenta eficaz para desenvolvimento
produtivo de software. Mesmo quando, padres de SCRUM so combinados com
outros padres organizacionais existentes, eles so altamente adaptveis, ainda que
em organizaes de desenvolvimento de software bem estruturadas
(SUTHERLAND, 2000).

2.5.3 Crystal/Clear

Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado por

Cockburn (2000). As premissas apresentadas para a existncia deste conjunto so:

todo projeto tem necessidades, convenes e uma metodologia diferente;

o funcionamento do projeto influenciado por fatores humanos e h melhora

neste quando os indivduos produzem melhor;

uma comunicao melhor e lanamentos freqentes reduzem a necessidade

de construir produtos intermedirios do processo.
 35

Crystal/Clear uma metodologia direcionada a projetos pequenos, com equipes

de at 6 (seis) desenvolvedores. Assim como com o SCRUM, os membros da
equipe tm especialidades distintas. Existe uma forte nfase na comunicao entre
os membros do grupo, e a organizao do espao de trabalho deve permitir este tipo
de colaborao. O enfoque do Crystal/Clear est em alcanar o sucesso do projeto
por realar o trabalho das pessoas envolvidas.

Toda a especificao e projeto so feitos informalmente, utilizando quadros

publicamente visveis. Os requisitos so elaborados utilizando casos de uso - use
case em UML (OMG, 2001), um conceito similar aos cartes de histrias em XP,
onde so enunciados os requisitos como tarefas e um processo para sua execuo.
A liberao das verses de software so feitos em incrementos regulares de um
ms, e existem alguns subprodutos do processo que so responsabilidade de
membros especficos do projeto.

Grande parte da metodologia pouco definida e, segundo o autor, isto

proposital; a idia do Crystal/Clear permitir que cada organizao implemente as
atividades que lhe parecem adequadas, fornecendo um mnimo de suporte til do
ponto de vista de comunicao e documentos.

Fowler (2001) enfatiza que Crystal compartilha uma orientao humana com XP,
mas no segue um processo disciplinado. Embora Crystal seja menos produtivo que
XP, mais pessoas podero seguir esta metodologia.

Ainda de acordo com Fowler (2001), em fevereiro de 2001 Alistair Cockburn

anunciou que ele e Jim Highsmith - autor da metodologia de Desenvolvimento de
Software Adaptvel (ASD) - esto unindo suas metodologias. Ambos, contribuem e
continuam a fundir suas percepes sobre princpios e prticas para executar um
projeto to rpido e to eficazmente quanto permitem de circunstncias.

2.6 Consideraes Finais

Grande parte das pesquisas feitas na rea de Engenharia de Software, e em

particular no desenvolvimento de Processos de Software, continuam sendo
desenvolvidas e contribuindo para melhorias na construo de produtos de software.
No entanto, existe uma tendncia atual para a simplificao e pragmatizao do
 36

processo para acomodar novas necessidades de desenvolvimento, os requisitos e

demandas por novos sistemas so muito diferente dos conhecidos e estabelecidos
nos anos 70 e 80 (EVANS, 2001).

Neste contexto, vem tona o destaque da literatura nos requisitos, sejam eles
documentados em cartes de histrias (segundo a abordagem do XP) ou
documentados atravs da anlise de requisitos diretamente associada aos casos de
uso (segundo a abordagem ICONIX). Na seo seguinte abordado o processo XP
e na seo subseqente o processo ICONIX.
 37

3 EXTREME PROGRAMMING (XP)

3.1 Introduo

Extreme Programming (XP) uma metodologia leve, eficiente, flexvel e de baixo

risco para times pequenos e mdios, que desenvolvem software com requisitos
dinmicos ou em constante mudana (BECK, 2000).

A metodologia XP foi criada por Kent Beck, que no incio dos anos 1990 pensava
sobre caminhos melhores para desenvolver software. Em maro de 1996 Kent
comeou um projeto na Daimler Chrysler usando novos conceitos em
desenvolvimento de software. O resultado era a metodologia XP (WEELS, 2002).

De acordo com Beck (2000), XP se distingue de outras metodologias por:

apresentar feedback (retornos) contnuos e concretos em ciclos curtos;

abordar planejamento incremental, apresentando rapidamente um plano

global, que evolui durante o ciclo de vida do projeto;

ter habilidade flexvel de programar implementao de funcionalidade,

respondendo as mudanas das regras de negcio;

confiar nos testes automatizados escritos pelos programadores e clientes,

para monitorar o progresso do desenvolvimento, permitindo a evoluo do
sistema e detectando antecipadamente os problemas;

acreditar na comunicao oral, na colaborao ntima dos programadores,

nos testes e no cdigo fonte, definindo a estrutura do sistema e os objetivos;

confiar no processo de evoluo do projeto, que dura tanto quanto o sistema;

acreditar nas prticas que trabalham tanto com as aptides, a curto prazo, dos
programadores, quanto os interesses, a longo prazo, do projeto.

XP uma disciplina de desenvolvimento de software baseado em valores de

simplicidade, comunicao, feedback e coragem. XP envolve o time inteiro para um
trabalho de equipe com prticas simples, com feedback suficiente para capacitar o
 38

time a ver onde eles esto e a convergir para prticas em uma soluo nica
(JEFFRIES, 2001).

No XP, cada contribuinte do projeto um integrante do time inteiro. O time

trabalha com um representante de negcio chamado de o Cliente, que participa
ativamente com o time diariamente.

Os times usam uma forma simples de planejamento e acompanhamento para

decidir qual a prxima tarefa a ser realizada e predizer quando o projeto ser feito.
Definidas as regras de negcio, o time produz o software em uma srie de pequenas
verses, que passam por todos os testes que o cliente definiu.

Ainda de acordo com Jeffries (2001), os programadores trabalham em pares e

em grupo, com projeto simples e cdigo obsessivamente testado, melhorando o
projeto continuamente para manter sempre as necessidades correntes e o sistema
integrado. Os programadores escrevem todo cdigo de produo em pares, e todos
trabalham junto o tempo todo. Eles codificam de forma consistente para que todos
possam entender e melhorar o cdigo quando necessrio.

3.2 Os Quatro Valores do XP

importante ressaltar que, o XP segue um conjunto de valores, princpios e

regras bsicas que visam alcanar eficincia e efetividade no processo de
desenvolvimento de software (BECK, 2000). Os valores so quatro: comunicao,
simplicidade, feedback e coragem. Nestes valores, esto fundamentados alguns
princpios bsicos: feedback rpido, simplicidade assumida, mudanas incrementais,
compreenso s mudanas e qualidade do trabalho. A partir destes princpios,
foram definidas as doze prticas bsicas que so adotadas pelo XP.

Os quatro valores do XP so:

Comunicao: o primeiro valor do XP. Deve-se preferir sala de discusso

(chat) a correio (e-mail), telefonemas a chat, conversar pessoalmente a
telefonemas, trabalhar na mesma sala a ter salas isoladas, trabalhar em
conjunto a revisar o resultado final (WUESTEFELD, 2001). Jeffries (2001)
enfatiza que deve existir comunicao em todos os sentidos. O time deve
escrever o cdigo usando as mesmas convenes de formatao, nomeando
 39

convenes, e definindo os padres de codificao. Desta forma,

independente que quem escreveu o mtodo familiar e fcil de entender. A
comunicao deve ser facilitada para todo o time do XP;

Simplicidade: o segundo valor do XP. O objetivo simplificar

continuamente o software. isso que sustenta a premissa de extremo, pois a
simplicidade no fcil. O processo em si tambm adaptado, a cada dia, se
houver como torn-lo mais simples. Simplicidade e comunicao esto
diretamente relacionadas. Pois quando mais comunicao existe no time,
mais claro fica de se ver o que realmente precisa ser feito e, mais seguro de
ver o que no precisa ser feito. Assim, se faz o software mais simples quando
possvel de se trabalhar;

Feedback: o terceiro valor do XP. Todo problema evidenciado o mais

cedo possvel para que possa ser corrigido o mais rpido possvel. Toda
oportunidade descoberta o mais cedo possvel para que possa ser
aproveitada o mais rpido possvel (WUESTEFELD, 2001) (ver figura 7);

Coragem: Este valor somente tem peso se estiver combinado com os trs
primeiros valores (BECK, 2000). preciso coragem para apontar um
problema no projeto, pedir ajuda quando necessrio, simplificar cdigo que
est funcionando, expor para o cliente que o prazo estimado para
implementar determinado requisito no suficiente, fazer alteraes no
processo de desenvolvimento. Ou seja, fazer a coisa certa mesmo que no
parea o mais correto naquele momento.

Figura 7: Diagrama de planejamento e feedback (WELLS, 2001)

 40

3.3 As Doze Prticas do XP

1. Jogo de Planejamento (Planning Game): Rapidamente determina o escopo

das prximas verses combinando a prioridades do negcio e estimativas
tcnicas. Como prtica, estrutura o plano e atualiza o plano.

2. Pequenas verses (Small releases): O time XP coloca rapidamente um

sistema simples em produo, e o atualiza freqentemente em ciclos bastante
curtos.

3. Metforas: Guiam todo o desenvolvimento e a comunicao com o cliente

utilizando um sistema de nomes e uma descrio do sistema.

4. Projeto simples (Simple design): O sistema precisar ser projetado o mais

simples possvel satisfazendo os requisitos atuais.

5. Teste: Os times XP focalizam a validao do software durante todo o

processo. Os programadores escrevem primeiro os testes, e s ento
continuam o desenvolvimento que deve atender os requisitos destes testes.
Os clientes escrevem testes para validar se os requisitos esto sendo
atendidos.

6. Refactoring: Os times procuram aperfeioar o projeto do sistema durante

todo o desenvolvimento, mantendo a clareza do software: sem ambigidade,
com alta comunicao, simples, porm completo.

7. Programao em pares (Pair Programming): Todo cdigo produzido feito

em duplas, ou seja, dois programadores trabalhando juntos na mesma
mquina.

8. Propriedade coletiva (Colletive ownership): Todo o cdigo pertence a todo o

time. Ento, qualquer um pode alterar qualquer cdigo em qualquer tempo.

9. Integrao contnua (Continnuous integration): Integra e constri o sistema

de software vrias vezes por dia. A todo o momento, uma tarefa
completada.

10. Semana de 40-horas (40-hour week): Como regra, no se deve trabalhar

mais que 40 (quarenta) horas na semana. Programadores exaustos cometem
mais erros.
 41

11. Cliente dedicado (On-site customer): Os times XP tem o cliente real,

disponvel todo o tempo, que determina os requisitos, atribui as prioridades, e
reponde as dvidas.

12. Cdigo padro (Coding standards): Todos os programadores escrevem o

cdigo da mesma forma, de acordo com regras que asseguram a clareza e a
comunicao atravs do cdigo.

A maioria das regras XP causa polmica primeira vista e muitas no fazem

sentido se aplicadas isoladamente. a sinergia de seu conjunto que sustenta o
processo XP, encabeando uma verdadeira revoluo de metodologias geis.

Nas prximas sees, cada prtica ser delineada e, examinada a conexo entre
elas, que permite que as fraquezas de uma prtica sejam superadas pelas foras de
outras prticas (BECK, 2000).

A figura 8 um diagrama que representa a colaborao entre as prticas. Cada

prtica uma parte simples. A riqueza est na interao das partes. A linha de
ligao entre duas prticas significa que elas do suporte uma a outra.

Figura 8: Colaborao entre as prticas (adaptado de BECK, 2000)

 42

3.3.1 Jogo de planejamento

Conforme Beck (2000), o jogo de planejamento suportado tanto pelas regras de

negcio quanto pelas consideraes tcnicas. As regras de negcio so estimadas
pelo cliente de negcio, que decide sobre: escopo, prioridade, composio das
verses e datas das verses. As consideraes tcnicas so estimadas pelos
tcnicos, que decidem sobre: tempo, riscos tcnicos e processo.

Planejamento no XP responde duas perguntas chaves em desenvolvimento de

software: predizer o que ser realizado at determinada data, e determinar qual a
prxima tarefa a ser realizada. A nfase est em guiar o projeto, em lugar de
especificar exatamente o que ser necessrio e quanto tempo levar, o que j
bastante difcil (JEFFRIES, 2001). Existem dois passos chave em planejamento XP,
abordando estas duas perguntas:

Verso de Planejamento (Release Planning) o passo onde o cliente apresenta

as caractersticas desejadas aos programadores, e os programadores estimam sua
dificuldade. A figura 9 mostra a estrutura de um carto de histria. XP preconiza
verses freqentes e pequenas a cada dois ou trs meses. Com as estimativas das
dificuldades, e com conhecimento da importncia das caractersticas, o cliente atinge
um plano para o projeto. Inicialmente, as verses dos planos so imprecisas. Uma
vez que, as prioridades e as estimativas no so verdadeiramente slidas, at que o
time comece a trabalhar. Ento, pode-se saber o quo rpidos eles iro executar o
trabalho.

Carto de Histria e Tarefa

Data: ___/___/______ Tipo de Atividade: Nova:____ Dificuldade: _____ Valor: _____
Nmero da Histria: __________ Prioridade: Usurio: _____ Tcnico: _____
Referncia Anterior: __________ Risco: _____________ Estimativa do Tcnico: _______________
Descrio da Tarefa:
Notas:
Acompanhamento da Tarefa:
Data Estado Para Realizar Comentrio

Figura 9: Modelo de carto de histria (adaptado de BECK, 2000)

 43

Iterao de Planejamento (Iteration Planning) o passo em que o time recebe

orientao atravs de cartes de tarefas (BECK, 2001). A figura 10 um modelo de
carto de tarefa. Os times XP constroem software em "iteraes" de duas a trs
semanas, entregando um software executvel e til no fim de cada iterao. Durante
a Iterao de Planejamento, o cliente apresenta as caractersticas desejadas para as
prximas duas semanas. Os programadores quebram as caractersticas em tarefas,
e estimam o tempo (em um nvel mais detalhado que na Verso de Planejamento).
O time baseado no volume de trabalho realizado na iterao prvia, estima o tempo
que ser empreendido na iterao corrente.

Nesta proposta, a cada duas semanas, a quantia de progresso completamente

visvel. No existe "noventa por cento feitos" em XP: um conjunto de caractersticas
totalmente completado, ou no . Este enfoque pode resultar em um bom e
pequeno paradoxo: por um lado, com tanta visibilidade, o cliente est em uma
posio para cancelar o projeto se o progresso no for suficiente. Por outro lado, o
progresso to visvel, e a habilidade de decidir o que ser feito na prxima iterao
to completa, que projetos XP tendem a entregar mais do que necessrio, com
menos presso e tenso (JEFFRIES, 2001).

Carto de Tarefa
Data: ___/___/______
Nmero da Histria: __________ Autor do Software: _________ Estimativa da Tarefa: ________
Descrio da Tarefa:
Notas do Autor do Software:
Acompanhamento da Tarefa:
Data Realizado Para Realizar Comentrio

Figura 10: Modelo de carto de tarefa (adaptado de BECK, 2000)

3.3.2 Pequenas verses

Segundo Jeffries (2001), os times XP trabalham com pequenas verses em dois

modos importantes:
 44

Primeiro, o time disponibiliza uma verso executvel, considerando que o

software est testado, com as caractersticas escolhidas pelo cliente naquela
iterao. O cliente pode usar este software para qualquer propsito, tanto para
avaliao, quanto para liberar aos usurios finais (altamente recomendado). O
aspecto mais importante que o software visvel, e dado ao cliente no final de
cada iterao. Assim, mantm o projeto aberto e tangvel.

Segundo, o time XP freqentemente disponibiliza para seus usurios finais uma

verso. Nos projetos XP Web, com durao mensal ou menor, so disponibilizadas
verses dirias, quando possvel.

Jeffries (2001) argumenta que pode parecer impossvel criar boas verses nesta
freqncia, mas times XP por toda parte esto fazendo isso. Pode-se ver mais
adiante em Integrao Contnua, que verses freqentes so mantidas confiveis
com teste obsessivos do XP, como descrito na seo Teste.

Todas as verses devem ser to pequenas quanto possveis, e devem conter os

requisitos mais importantes (BECK, 2000).

3.3.3 Metfora

O projeto de software em XP guiado por uma metfora simples (BECK, 2000).

A metfora ajuda a manter todos os desenvolvedores em sintonia com o projeto e
auxilia a definir nomes a objetos ou classes. bastante importante como uma
prtica para manter o cdigo padro.

Jeffries (2001) comenta que, s vezes uma metfora suficientemente potica no

surge. Entretanto, com ou sem uma imagem explcita, os times XP usam um sistema
comum de nomes para que todos entendam como o sistema trabalha. Assim, pode-
se localizar a funcionalidade que se est procurando, ou saber o lugar certo para pr
a funcionalidade que se quer adicionar.

Por exemplo, um cliente necessita de um sistema de HelpDesk com

caractersticas similares ao Microsoft Outlook. Ento, o Outlook pode ser a
metfora (ULIANA, 2001).
 45

3.3.4 Projeto simples

Os times XP constroem o software de acordo com um projeto simples. Desta

forma, o time XP mantm o projeto exatamente delineado com a funcionalidade
corrente do sistema. Sendo assim, no existe nenhum movimento perdido, e o
software est sempre pronto para a prxima iterao (JEFFRIES, 2001).

Beck (2000) enfatiza que o projeto certo para um software em qualquer tempo
aquele que:

executa todos os testes;

no tem lgica duplicada (deve-se ter cuidado com hierarquia de classes

paralelas);

expe claramente cada inteno para os programadores;

tem o menor nmero possvel de classes e mtodos.

Projeto em XP no algo que possa ser realizado uma nica vez. necessrio
ser feito o tempo todo. Pois, existem passos do projeto feitos na verso de
planejamento e na iterao de planejamento, e cada vez mais, o time toma parte
nestas sesses e na reviso rpida do projeto por refactoring. Em processos
incrementais e iterativos, como Extreme Programming, um bom projeto
indispensvel. por isso que existe tanto enfoque em projeto ao longo do curso de
todo o desenvolvimento (JEFFRIES, 2001).

Wells (2002) aborda tambm que um projeto simples sempre requer menos
tempo para terminar que um complexo. Desta forma, o objetivo fazer um projeto
mais simples, mas suficiente para se trabalhar. Isto parece coerente uma vez que
mais rpido e mais barato substituir um cdigo complexo durante o desenvolvimento
do que desperdiar muito mais tempo no futuro.

3.3.5 Teste

Os programadores primeiramente escrevem os testes de unidade e o cliente

escreve os testes funcionais, de forma que a confiana na funcionalidade possa se
tornar parte do programa desenvolvido (BECK, 2000).
 46

Fowler & Foemmel (2000) destacam que os testes de unidade escritos pelos
programadores tm por finalidade testar uma classe individual ou um grupo de
classes. J os testes funcionais (tambm chamados de testes de aceitao) escritos
pelo cliente tm por finalidade testar o sistema de ponta-a-ponta. importante
ressaltar que os testes so escritos antes do cdigo ser construdo.

Criar testes de unidade ajuda o desenvolvedor a considerar o que realmente tem

que ser feito. Os requisitos so reforados pelos testes. No pode haver erros de
interpretao em uma especificao escrita na forma de cdigo executvel.

Nesta proposta, Oshiro (2001) destaca que as atividades de teste so realizadas

durante todo o processo de desenvolvimento, e o cdigo construdo com a
finalidade de satisfazer os resultados esperados. E medida que um novo cdigo
adicionado, novos testes devem ser executados e assim garantir que no ocorram
impactos negativos.

Testes de Unidade so considerados elementos chaves em XP (WELLS, 2002),

pois so criados antes do cdigo e armazenados em um repositrio junto ao cdigo
que ser testado. Um fator importante para a utilizao dos testes de unidade,
sobretudo se for automatizado, a economia de custo que podem proporcionar ao
identificar erros. Desta forma, um conjunto completo de testes de unidade deve
estar disponvel no incio do projeto, e no no final.

Testes Funcionais constituem a primeira indicao que as histrias dos clientes

so vlidas, mostram que cada histria pode ser testada (ASTELS,2002).
Normalmente, so escritos pelos clientes ou usurios finais atravs dos cartes de
histria (WELLS, 2002), com suporte de um membro do time responsvel por testar
o sistema. Testes funcionais tambm so usados como testes de validao,
anteriores liberao de uma verso do sistema.

3.3.6 Refactoring

O enfoque do XP est em entregar as regras de negcios a cada iterao. Para

realizar isto no decorrer do projeto inteiro, o software deve estar bem projetado.
Ento, o XP usa um processo contnuo de melhoria de projeto chamado refactoring,
 47

do ttulo do livro de Martin Fowler, Refactoring: Improving the Design of Existing

Code (JEFFRIES, 2001).

Refactoring a tcnica empregada na reestruturao do cdigo, cujo principal

propsito fazer com que um programa fique mais reutilizvel e fcil de entender,
sem que haja mudana de comportamento (FOWLER, 2001).

O objetivo do processo de refactoring remover duplicao (um sinal certo de

projeto pobre) e acrescentar a "coeso" ao cdigo, enquanto baixa o acoplamento.
Alta coeso e baixo acoplamento reconhecida pelo menos nos ltimos 30 (trinta)
anos como marca de cdigo bem projetado. O resultado que os times XP
comeam com uma vantagem, projeto simples, e continuam com essa vantagem
durante todo o processo. Fowler (2001) enfatiza que bom projeto essencial para
manter a velocidade do desenvolvimento do software. Nesta proposta, a tcnica de
refactoring ajuda a desenvolver o cdigo mais rapidamente.

Refactoring o processo de melhorar o projeto de um cdigo que j est

funcionando. Entretanto, fica a questo, afinal qual o melhor projeto para um
software? Wuestefeld (2001) responde que, O melhor projeto para um software
aquele que, por prioridade:

passa 100% nos testes de unidade;

tem performance aceitvel;

o mais claro, o mais fcil de entender.

Ainda de acordo com Wuestefeld (2001), deve-se fazer refactoring onde for
possvel e sempre que possvel. Reescrever o cdigo atual, parte por parte, fazendo
com que ele fique cada vez mais manutenvel. Os testes de unidade oferecem
segurana para o que o que j estava funcionando continue funcionando.

3.3.7 Programao em pares

Segundo Jeffries (2001), Todo software produzido em XP construdo por dois

programadores, sentados lado a lado, na mesma mquina. Esta prtica assegura
que todo cdigo produzido revisado por, pelo menos outro, programador. O
resultado desta prtica um projeto rpido, com testes mais eficazes e um cdigo
 48

melhor. Pode parecer ineficiente ter dois programadores fazendo o trabalho de um,
mas Williams (2001) ressalta que o contrrio verdadeiro. Pesquisas mostram que o
cdigo produzido por dois programadores melhor e a velocidade da produo
quase equivalente ao trabalho realizado por um programador isolado (WILLIAMS,
2000). A figura 11 mostra a comparao do tempo de concluso de projetos
realizados por pares de programadores e por programadores individuais.

Individual Par

100

80

60

40

20

0
Programa 1 Programa 2 Programa 3

Figura 11: Comparao: tempo de programao (adaptado de WILLIAMS, 2000)

importante observar que existem dois papis em cada par. O parceiro que est
com o teclado e o mouse, pensa na melhor forma de implementar o mtodo
corrente. Enquanto que, o outro parceiro pensa mais estrategicamente em: se
aquela abordagem ir funcionar, se existe algum teste que ainda no foi trabalhado
e se existe alguma forma que possa simplificar o sistema corrente para que
problema desaparea (BECK, 2000).

A programao em pares necessita de prtica para ser realizada bem.

necessrio praticar algumas semanas para ver se o resultado satisfatrio. De
acordo com Jeffries (2001), noventa por cento dos programadores que aprende
programao em pares prefere esta programao isolada. Ento, o XP recomenda
a programao em pares para todos os times. Esta tcnica, alm de prover cdigo e
testes melhores, tambm serve para transferir conhecimento a todo o time. Assim,
todos conseguem o benefcio do conhecimento especializado do outro. Os
programadores aprendem, suas habilidades melhoram e se tornam mais valiosos
para o time e para a companhia.
 49

3.3.8 Propriedade coletiva

Em um projeto XP, qualquer par de programadores pode melhorar qualquer

cdigo em qualquer hora. Isto significa que todo cdigo consegue o benefcio de
muita ateno das pessoas, o que acrescenta qualidade ao cdigo e reduz defeitos
(JEFFRIES, 2001).

Segundo Beck (2000) o time XP, como um todo, responsvel por cada
programa de cdigo. No necessrio pedir autorizao para alterar qualquer
programa. Entretanto, isso somente possvel com os testes de unidade bem
elaborados, permitindo segurana aos programadores que trabalham no cdigo.
Alm disso, a propriedade coletiva tambm tende a espalhar conhecimento de todo
o sistema para o time.

Wuestefeld (2001) aborda que a prtica de integrao contnua auxilia a prtica

de propriedade coletiva, pois, faz com que os programadores que trabalham neste
ambiente, nem percebam se o cdigo que eles programaram foi modificado ou
estendido.

3.3.9 Integrao contnua

Os times XP mantm o sistema integrado o tempo todo. O cdigo integrado e

testado depois de algumas horas, no mximo depois de um dia de desenvolvimento.
A forma mais simples para fazer isto, ter uma mquina dedicada para a integrao
(BECK, 2000). Ferramentas de controle de verso podem ser teis neste momento.

De acordo com Wells (2002), a integrao contnua freqentemente evita a

divergir ou a fragmentar os esforos de desenvolvimento. Nesta proposta, os
programadores devem estar em constante comunicao um com os outros, pois
assim, eles sabem o que pode ser reutilizado, ou o que pode ser compartilhado.
Todo o time precisa trabalhar com a verso mais recente, evitando perder tempo
com verso obsoleta. Ento, a integrao deve ser feita vria vezes por dia. Cada
par de programao responsvel por integrar seu prprio cdigo. Isto pode ser
feito quando os testes de unidade tenham sido executados 100% em cada
funcionalidade planejada. A integrao contnua evita ou descobre problemas de
compatibilidade cedo.
 50

3.3.10 Semana de 40-horas

No produtivo fazer horas extras por perodos maiores que uma semana. Como
tambm no produtivo passar a noite acordado e trabalhar no dia seguinte.

Wuestefeld (2001) enfatiza que as pessoas no possuem o mesmo ritmo de

trabalho, por isso no existe um nmero de horas ideal para todas as pessoas.
Algumas sero mais produtivas com 07 (sete) horas e outras com 08 (oito) ou com
09 (nove) horas. Os excessos que esto fora de questo, como trabalhar 01 (uma)
hora por dia ou 20 (vinte) horas por dia.

O time XP trabalha intensamente de modo a maximizar a produtividade. Um

programador quando est cansado, raciocina mais lentamente e fica mais distrado.
Um programador cansado timo para inserir erros (bugs) em um programa, erros
que vo dar trabalho para serem corrigidos e exigir mais horas extras.

De acordo com Beck (2000), a sobrecarga de trabalho sintoma de srios

problemas no projeto. A regra XP simples, no se deve trabalhar uma segunda
semana fazendo horas extras. Uma semana trabalhando horas a mais, para por o
planejamento em ordem, admissvel. Entretanto, se isso se repetir na semana
seguinte, pode indicar que algo est errado.

3.3.11 Cliente dedicado

Um cliente real precisa sentar com o time, deve estar sempre disponvel, no
somente para auxiliar, mas para fazer parte da equipe. Beck (2000) define por
cliente real, aquele cliente que realmente ir utilizar o sistema quando ele estiver
em produo. O objetivo desta regra ter o usurio real do sistema, de preferncia
junto com o desenvolvimento. O cliente muito valioso para o time.

A principal vantagem (WUESTEFELD, 2001) que o cliente poder fornecer

detalhes do sistema quando surgirem dvidas. E surgem muitas dvidas quando os
programadores esto implementando uma funcionalidade. Se o cliente estiver
sempre por perto, significa que toda e qualquer dvida pode ser prontamente
esclarecida e que o cliente tem um controle maior do que est realmente sendo
implementado.
 51

Entretanto, algumas vezes, no possvel que o cliente esteja no mesmo local

de trabalho que os programadores. Ainda assim, possvel trabalhar com XP, desde
que se tenha um canal aberto de comunicao e que o cliente tenha disponibilidade
para:

atender os programadores quando surgirem s dvidas;

produzir valor para o projeto escrevendo testes funcionais;

definir o escopo e definir as prioridades para os programadores.

Nestes casos seria indicado o uso de ambientes colaborativos atravs da

Internet. Por sua vez, se o time no incluir um cliente real, torna-se necessrio
adicionar um risco ao projeto para o futuro, pois os programadores iro codificar sem
saber exatamente que testes eles devem satisfazer e quais eles devem ignorar.

3.3.12 Cdigo padro

Os times XP seguem um padro de codificao comum a todos os membros.

Desta forma, todo cdigo no sistema pode ser visto como se fosse escrito por um
nico programador. As particularidades do padro no so importantes: o que
importante que todo o cdigo deve parecer familiar, em defesa da propriedade
coletiva (JEFFRIES, 2001).

De acordo com Wells (2002) a padronizao do cdigo mantm o mesmo

consistente e fcil para todo o time entender e/ou fazer o refactoring. No importa
qual o padro, desde que haja um. Ele no precisa ser arbitrariamente definido,
podendo emergir naturalmente como resultado da propriedade coletiva
(programao em pares).

3.4 Ciclo de Vida e as Fases do Processo XP

O projeto ideal em XP aquele que inicia por uma curta fase de

desenvolvimento, seguida de anos de produo e refinamentos simultneos e
finalmente encerra quando o projeto no faz mais sentido (BECK, 2000).

O ciclo de vida e as fases do processo XP so abordagens muito discutidas por

diversos autores que adotam essa metodologia. O ciclo de vida XP bastante curto
 52

e, primeira vista, difere dos padres dos modelos de processo convencionais.

Entretanto, esta abordagem faz sentido somente em um ambiente onde as
mudanas de requisitos do sistema so fatores dominantes (OSHIRO, 2001). No
caso extremo, os requisitos podem mudar no meio da verso, para atender
funcionalidades mais importantes do que as definidas no planejamento original.

3.4.1 Explorao

De acordo com Wake (2002), o objetivo da fase de Explorao entender o que

o sistema deve fazer, bem o suficiente para que possa ser estimado. Sendo que, o
cliente escreve e administra histrias (story cards) e o programador estima as
histrias. Encerra quando todas as histrias necessrias para a prxima fase fase
de planejamento - tenham sido estimadas (ver figura 12).

A fase de Explorao deve proporcionar confiana suficiente para o time de

forma que, com as ferramentas que possui consiga iniciar e finalizar o programa. O
time deve acreditar que tem (ou pode aprender) os conhecimentos necessrios para
o projeto. Enfim, o time XP precisar aprender a confiar em todos os membros da
equipe (BECK, 2000).

A fase de Explorao comea com as regras de negcio. O cliente escrevendo

cartes de histria que descrevem o que o sistema precisa fazer. Wake (2002)
considera que, histrias menores tendem a ter risco menor. Ento, se uma histria
for muito grande, o cliente deve quebrar a histria para ficar mais flexvel ou, quebrar
a pedido dos programadores, que podem estar sentindo dificuldades de estimar. Se
os programadores no souberem como estimar alguma coisa, eles podem fazer uma
rpida programao da histria, ou seja, uma pontuao (spike), que pode durar
minutos, horas ou no mximo dois dias (ver figura 5). O resultado de uma pontuao
conhecimento suficiente para tentar uma estimativa.

Em paralelo as histrias dos clientes os programadores esto experimentando

ativamente as diferentes tecnologias e as possveis configuraes, explorando as
possibilidades para a arquitetura do sistema. Leva-se de uma a duas semanas
testando a arquitetura, mas deve-se testar de trs a quatro maneiras, ou seja,
diferentes pares podem testar diferentes tecnologias e comparar ou, dois pares
 53

podem testar a mesma tecnologia e comparar as diferenas emergentes. Se este

perodo no for suficiente para testar a tecnologia, ento a tecnologia deve ser
classificada como um risco para o projeto. Entretanto, durante a fase de explorao
pode-se convidar um especialista na tecnologia escolhida, o qual no ir perder
tempo em pequenos problemas, pois sabe por experincia como resolv-los.

Beck (2000) ressalta que esta pequena explorao na arquitetura, auxilia os

programadores a terem uma idia da implementao quando o usurio apresentar
seus cartes de histria. Pois, os programadores precisam estimar cada tarefa de
programao durante a explorao. Quando uma tarefa feita, eles precisam
repassar para o calendrio o tempo gasto para executar aquela tarefa. A prtica da
estimativa cria confiana no time para quando eles realmente tiverem que estimar o
tempo.

3.4.2 Planejamento

O objetivo da fase de Planejamento definir a menor data e o maior conjunto

histrias que sero realizadas na primeira verso. Esta definio feita de acordo
com estimativas entre cliente e programadores (BECK, 2000).

Assim que as histrias so coletadas, o Jogo de Planejamento conduzido.

Como apresentado anteriormente, o Jogo de Planejamento a melhor maneira de
executar esta fase. O cliente decide quais histrias so vitais e que devem fazer
parte da primeira verso. Desta forma, pode-se elaborar uma lista priorizada das
histrias. Se houver uma boa preparao durante a fase de explorao necessrio
apenas alguns dias para a fase de planejamento.

Wake (2002), apresenta alguns passos, que tambm podem ser visualizados na
figura 12, para auxiliar a fase de release no jogo de planejamento:

o cliente seleciona as histrias por valor: alto, mdio ou baixo;

os programadores qualificam as histrias por risco (opcional): alto, mdio ou

baixo;

os programadores declaram a velocidade: calculada sobre a estimativa

realizada sobre as histrias dos clientes. A velocidade empiricamente
determinada, ou seja, baseada na experincia dos programadores;
 54

clientes escolhem o escopo: escolhem as histrias para a prxima verso.

Figura 12: Jogo de Planejamento: Release (adaptado de WAKE, 2002)

Wake (2002) ressalta que as histrias dos clientes so quebradas em pequenas

tarefas (task cards) e, definidos quais os programadores que iro trabalhar em cada
tarefa. No primeiro dia de cada iterao, o time decide quais as histrias que sero
trabalhadas. Os programadores selecionam as tarefas, estimam (pontuam em dias)
e aceitam as tarefas que iro programar. A figura 13 mostra como funciona a fase de
iterao no Jogo de Planejamento.

Figura 13: Jogo de Planejamento: Iterao (adaptado de WAKE, 2002)

 55

3.4.3 Iterao para primeira verso

Segundo Beck (2000), os compromissos so divididos para serem executados

em iteraes que duram de uma a quatro semanas. Para cada histria executada
naquela iterao produzido um conjunto de testes funcionais.

A primeira iterao, mostra como a arquitetura do sistema ir se comportar.

Ento, as histrias devem ser escolhidas de forma que representem fora para criar
todo o sistema. A pergunta chave para ser trabalhada nesta fase : Qual a coisa de
maior valor para o time para ser trabalhada nesta iterao? (BECK, 2000).

Uma importante caracterstica do XP (WELL, 2001) somente implementar uma

funcionalidade que esteja marcada para a interao corrente. Pois, sempre existir
tempo para implementar uma funcionalidade em uma prxima iterao, ou seja,
quando a histria do cliente for selecionada como a mais importante na verso de
planejamento.

Desta forma, o prazo final de cada interao ser seriamente respeitado.

Consegue-se analisar qual a real velocidade do projeto durante aquela interao.
Ento, o conjunto de histrias que faro parte da nova iterao estar mais bem
estimado.

Conforme Reis (2000), uma seqncia de ciclos iterativos conduzem o

desenvolvimento, que concentra o projeto, a codificao, os testes e as verses do
produto. Normalmente, h alguns ciclos iterativos antes da fase de produo.

No final de cada iterao o cliente ter completado a execuo de todos os testes

funcionais e, no final da ltima iterao, o sistema estar pronto para entrar em
produo.

3.4.4 Produo

A produo do sistema pode iniciar quando o ciclo de feedback encerrado, ou

seja, no final de uma verso, como representado anteriormente na figura 7.

De acordo com Beck (2000), existem alguns processos para avaliar se o software
realmente est pronto para entrar em produo. Pode-se implementar novos testes
 56

para provar se o sistema est estvel o suficiente para entrar em produo. Testes
so freqentemente aplicados nesta fase.

Pode ser necessrio apenas ajustar o desempenho. E o melhor momento para

realizar estes ajustes seria no final da verso. Pois, se tem mais conhecimento do
projeto, assim como existe a possibilidade de realizar estimativas reais de
sobrecarga de produo do sistema. E provavelmente, este teste poder ser
realizado na mquina de produo.

3.4.5 Manuteno

A fase de manuteno o estado normal de um projeto XP. Deve-se

simultaneamente produzir novas funcionalidades, manter o sistema existente
rodando, substituir membros do time que partem e incorporar novos membros ao
time (BECK, 2000).

Nesta fase, pode-se tentar fazer refactorings maiores, os quais, nas verses
anteriores, causaram certo receio. Pode-se testar novas tecnologias que se pretende
incorporar nas prximas verses, ou migrar a tecnologia que est em uso para
verses mais atualizadas. O cliente pode escrever novas histrias que tragam para o
seu negcio grandes conquistas.

Quando o sistema est em produo, provvel que a velocidade de

desenvolvimento mude. Enquanto se est explorando, se pode mensurar o real
efeito que produz o tempo gasto com suporte sobre as atividades de
desenvolvimento. Beck (2000) acredita que h um aumento proporcional em 50%
do tempo requerido antes da produo (de 2 dias requeridos para 3 dias).
Entretanto, no se deve adivinhar, mas estimar.

A estrutura do time provavelmente ser alterada, ou seja, voltada para a

produo. Talvez seja necessrio um help-desk, e j no se tenha a necessidade de
um grande quantidade de programadores. Entretanto, se deve ter cuidado com a
rotao da posio de todos os programadores, pois h coisas que se aprende
dando suporte a produo e que no se aprende de outra forma. O suporte pode ser
to interessante quanto o desenvolvimento. Ento, para diminuir riscos, o time pode
ser mudado gradualmente. Isto importante, tanto para comunicar a estrutura de
 57

todo o projeto, quanto os detalhes de planejamento e implementao, e que

somente pode ser feito atravs do contato dirio entre o time.

3.4.6 Fim do Projeto

Beck (2000) considera que Morrer bem to importante quanto viver bem. Isto
uma verdade para o XP como para as pessoas.

Quando no mais existir novas histrias, o momento de finalizar o projeto. o

momento de escrever algumas pginas (de 5 a 10 pginas) sobre a funcionalidade
do sistema, um documento que auxilie no futuro a saber como realizar alguma
alterao no sistema. Uma boa razo para finalizar o projeto o cliente estar
satisfeito com o sistema e no ter mais nada que consiga prever para o futuro.

Toda a equipe que trabalhou no sistema deve ser reunida para reavaliao.
Aproveite a oportunidade de analisar o que pode ter causado queda no sistema e o
que fez o projeto avanar. Assim, o time saber melhor o que fazer no futuro, o time
executar tarefas de formas diferentes da prxima vez.

3.5 Papis do Time

Certamente, alguns papis so fundamentais e precisam existir em um time XP

como: o programador, o cliente, o treinador e o supervisor (BECK, 2000). Outros
papis podem combinar responsabilidades na mesma pessoa. Um exemplo claro o
caso do gerente e do supervisor (WUESTEFELD, 2001).

O programador o corao do XP, responsvel por:

estimar prazos das histrias do cliente;

definir os cartes de tarefas a partir dos cartes de histrias;

estimar os cartes de tarefa;

implementar testes unitrios. Deve ser feito antes do cdigo;

implementar o cdigo de produo;

trabalhar em par;

fazer refactoring sempre que necessrio;

 58

solicitar ao cliente que esclarea ou divida uma histria quando necessrio.

O cliente outro papel essencial do Extreme Programming. Enquanto o

programador sabe como programar, o cliente sabe o que deve ser programado. O
cliente quem paga pelo desenvolvimento do projeto e tambm precisa estar
disposto a aprender. Pois, no fcil executar funes como:

definir os requisitos do software;

escrever os cartes de histria;

definir as prioridades para os cartes de histria;

validar e definir os testes funcionais sempre que solicitado;

esclarecer dvidas sempre que solicitado.

O testador em XP tem o papel realmente focado no cliente. a pessoa do time

que aplicar os testes. Tem por responsabilidade:

definir com o cliente os testes funcionais do projeto;

escreve os testes funcionais;

executa os testes e publica os resultados para o time.

O supervisor (tracker4) a conscincia do time, sua responsabilidade :

coletar sinais vitais do projeto (mtricas) uma ou 2 vezes por semana;

manter todos informados do que esta acontecendo;

tomar atitudes sempre que as coisas parecerem ir mal.

O treinador responsvel pelo processo como um todo. Notifica as pessoas

quando elas esto se desviando do processo e conduz o time novamente para o
processo. O treinador tem a funo de:

garantir que o projeto permanea extremo;

ajudar com o que for necessrio;

4
A traduo literal seria batedor ou aquele que segue uma trilha, mas no contexto deste trabalho
se optou por usar supervisor.
 59

manter a viso do projeto;

formular e comunicar uma tarefa que um programador pode querer trabalhar.

O gerente a pessoa que precisa transmitir coragem, confiana e saber cobrar o

que de responsabilidade de cada um. O gerente tem vrios tipos de trabalho
como:

gerenciar o time e os problemas do time;

agendar as reunies de planejamento;

garantir que as reunies fluam como planejado;

escrever o que foi definido nas reunies;

manter o supervisor (tracker) informado dos acontecimentos das reunies;

buscar recursos.

3.6 Consideraes Finais

Nesta seo foi apresentado o XP, que um processo orientado por princpios e
prticas que guiam um projeto e sua equipe de desenvolvimento. O projeto deve ser
gil, incremental e aperfeioado com refactoring. Desta forma, o XP defende que
no se deve criar um grande volume de documentos ou diagramas que podem ficar
desatualizados. Uma vez que, o objetivo ganhar tempo para ir mais rpido. Astels
(2002) enfatiza que a natureza cooperativa do XP e a sua orientao a resultados
garantem a longevidade. O prximo captulo apresenta o modelo de processo
ICONIX. Ele procura mostra as principais tarefas e marcos do processo, destacando
os alertas do mesmo. Aborda tambm os modelos utilizados exemplificando-os.
 60

4 ICONIX

4.1 Introduo

O ICONIX um processo simplificado que unifica conjuntos de mtodos de

orientao a objetos em uma abordagem completa, com o objetivo de dar cobertura
ao ciclo de vida. Foi elaborado por Doug Rosenberg e Kendall Scott a partir da
sntese do processo unificado pelos trs amigos - Booch, Rumbaugh, e Jacobson o
qual tem dado suporte e conhecimento a metodologia ICONIX desde 1993
(Rosenberg & Scott, 1999). Ver representao na figura 14.

Silva & Videira (2001), apresentam o ICONIX como uma metodologia prtica,
intermediria entre a complexidade do RUP (Rational Unified Process) e a
simplicidade do XP (Extreme Programming). O ICONIX est adaptado ao padro da
UML (OMG, 2001), dirigido por casos de uso e o seu processo iterativo e
incremental.

Dinmico

Prottipo GUI Jacobson

Modelo caso de uso Diagrama de
seqncia

Jacobson
Diagrama de
robustez
Booch
Esttico

Rumbaugh Cdigo

Modelo de domnio Diagrama de classe

Figura 14: Processo ICONIX, mostrando a contribuio dos trs amigos

 61

De acordo com Rosenberg & Scott (1999), o ICONIX tem como base responder
algumas questes fundamentais sobre o software. Desta forma, utiliza tcnicas da
UML (OMG, 2001) que auxiliam a prover a melhor resposta. As questes e as
tcnicas so:

1. Quem so os usurios do sistema (ou atores), e o que eles esto tentando

fazer? Utilizar casos de uso;

2. O que so, no "mundo real" (chamado domnio de problema), os objetos e as

associaes entre eles? Utilizar diagrama de classe de alto nvel;

3. Que objetos so necessrios para cada caso de uso? Utilizar anlise de

robustez;

4. Como objetos esto colaborando e interagindo dentro de cada caso de uso?

Utilizar diagrama de seqncia e de colaborao;

5. Como ser manipulado em tempo-real aspectos de controle? Utilizar

diagrama de estado;

6. Como realmente ser construdo o sistema em um nvel prtico? Utilizar

diagrama de classe de baixo nvel.

Borillo (2000), destaca trs caractersticas fundamentais no ICONIX:

Iterativo e incremental: vrias iteraes ocorrem entre o desenvolvimento do

modelo de domnio e a identificao dos casos de uso. O modelo esttico
incrementalmente refinado pelo modelo dinmico (ver figura 14);

Rastreabilidade (traceability): cada passo referncia para os requisitos de

alguma forma. Silva e Videira (2001) definem rastreabilidade como sendo a
capacidade de seguir a relao entre os diferentes artefatos produzidos.
Desta forma, pode-se determinar qual o impacto que a alterao de um
requisito tem em todos os artefatos restantes;

Aerodinmica da UML : a metodologia oferece o uso aerodinmico da UML

(OMG, 2001) como: os diagramas de casos de uso, diagramas de seqncia
e colaborao, diagramas de robustez.
 62

4.2 Tarefas e Marcos do ICONIX

Rosenberg & Scott (1999) apresentam as seguintes tarefas principais: anlise de

requisitos, anlise e projeto preliminar, projeto e implementao. Estas tarefas
incluem a abordagem completa da metodologia ICONIX tendo marcos especficos
associados, conforme ser apresentado a seguir.

4.2.1 Anlise de requisitos

A realizao das seguintes atividades compe a tarefa de anlise de requisitos,

representada tambm na figura 15:

Identificar no mundo real os objetos e todas as relaes de agregao de

generalizao entre eles. Utilizar para representar o diagrama de classe de
alto nvel definido como modelo de domnio;

Apresentar, se possvel, uma prototipao rpida de interface do sistema, ou

diagramas de navegao, etc., de forma que o cliente possa compreender
melhor o sistema proposto;

Identificar os casos de uso do sistema mostrando os atores envolvidos.

Utilizar para representar o modelo de caso de uso;

Organizar os casos de uso em grupos, ou seja, utilizar diagrama de pacote;

Associar requisitos funcionais aos casos de uso e aos objetos de domnio.

Primeiro Marco: Reviso dos requisitos

Prottipo Diagrama de Pacote

Modelo de Domnio Modelo Caso de Uso Associao requisitos

Figura 15: ICONIX - Atividades da anlise de requisitos

 63

Um importante aspecto do ICONIX que um requisito se distingue explicitamente

de um caso de uso (SILVA & VIDEIRA, 2001). Neste sentido, um caso de uso
descreve um comportamento; um requisito descreve uma regra para o
comportamento. Alm disso, um caso de uso satisfaz um ou mais requisitos
funcionais; um requisito funcional pode ser satisfeito por um ou mais casos de uso.
Ainda de acordo com os autores Silva & Videira (2001), a relao entre casos de uso
e requisitos um assunto em discusso na comunidade de OO (Orientao a
Objeto), no existindo qualquer consenso at o momento.

4.2.2 Anlise e projeto preliminar

As atividades que fazem parte da tarefa de anlise e projeto preliminar so (ver

figura 16):

Escrever os casos de uso, com fluxo principal das aes, podendo conter o
fluxo alternativo e o fluxo de exceo;

Apresentar a anlise de robustez. Sendo que, para cada caso de uso se

deve identificar um conjunto de objetos (usar os esteretipos de classes) e
atualizar o diagrama de classes do modelo de domnio;

Terminar a atualizao do diagrama de classe.

Segundo Marco: Reviso do projeto preliminar

Anlise de Robustez

Modelo Caso de Uso Diagrama de Classe

Figura 16: ICONIX - Atividades da anlise e projeto preliminar

 64

4.2.3 Projeto

A tarefa de projeto consiste na realizao das seguintes atividades (ver figura

17):

Especificar comportamento atravs do diagrama de seqncia. Para cada

caso de uso, identificar as mensagens entre os diferentes objetos. Se
necessrio utilizar diagrama de colaborao para representar as transaes
chaves entre os objetos. Pode-se complementar utilizando diagrama de
estado para mostrar o comportamento em tempo real;

Terminar o modelo esttico, adicionando detalhes ao projeto no diagrama de

classe;

Verificar com o time se o projeto satisfaz todos os requisitos identificados.

Terceiro Marco: Reviso detalhada/Crtica do projeto

Diagrama de Seqncia Diagrama de Classe

Figura 17: ICONIX - Atividades do projeto

4.2.4 Implementao

As atividades que do suporte a tarefa de implementao so:

Utilizar diagrama de componente, se for necessrio para apoiar a fase de

desenvolvimento;

Escrever/Gerar o cdigo;

Realizar testes de unidade e de integrao;

Realizar testes de aceitao do usurio.

Quarto Marco: Entrega

 65

A metodologia ICONIX apresenta um conjunto de alertas para cada tarefa

realizada (SILVA & VIDEIRA, 2001). A seo seguinte apresenta os alertas do
ICONIX, e nas sees posteriores so detalhadas as tcnicas de modelo de
domnio, modelo de use case, anlise de robustez, modelo de interao (diagrama
de seqncia) e finalmente endereando requisitos.

4.3 Alertas do ICONIX

Silva & Videira (2001) e Borillo (2000) destacam os alertas do ICONIX por
advertirem sobre problemas e dvidas comuns em times de desenvolvimento de
software. Os alertas esto relacionados com cada tcnica, como a seguir:

Alertas do modelo de domnio: (1) no perder muito tempo com verificao

gramatical; (2) no adicionar multiplicidade muito cedo ao projeto; (3)
enderear agregao e composio apenas na fase do projeto detalhado; (4)
no desenhar um diagrama com mais de 7-9 classes;

Alertas do modelo de use case: (1) no tentar escrever casos de uso antes
de saber o que os usurios realmente fazem; (2) no desperdiar tempo
construindo modelos elegantes de casos de uso que no servem para
construir o projeto; (3) no perder tempo discutindo se vai usar includes ou
extends; (4) no usar templates textuais de caso de uso longos ou complexos;

Alertas da anlise de robustez: (1) no tentar fazer um projeto detalhado do

diagrama de robustez; (2) no perder tempo aperfeioando o diagrama de
robustez medida que o projeto evolui;

Alertas do diagrama de seqncia: (1) no tentar alocar comportamento

aos objetos antes de saber realmente o que os objetos so; (2) no iniciar o
diagrama de seqncia antes de completar o diagrama de robustez
associado; (3) no focar a ateno na configurao de mtodos get e set em
vez de focalizar a ateno em mtodos reais.
 66

4.4 Modelo de Domnio

Rosenberg & Scott (1999) definem a modelagem de domnio como sendo a tarefa
de descobrir objetos (classes), que representam coisas e conceitos no mundo real.
Na abordagem do ICONIX, a modelagem de domnio envolve palavras externas dos
requisitos de dados, para construir o modelo esttico.

O modelo de domnio serve como um glossrio de termos, que pode ser utilizado
na primeira fase para escrever os caso de uso, destaca Borillo (2000).

As regras para se conseguir um modelo de domnio so:

substantivos e frases com substantivos se tornam objetos e atributos;

verbos e frases com verbos se tornam operaes e associaes;

frases possessivas indicam que substantivos devem ser atributos em vez de

objetos.

Jim Rumbaugh (apud ROSENBERG & SCOTT, 1999) define uma classe como
uma descrio de um grupo de objetos com propriedades similares, comportamento
comum, relaes comum, e semntica comum. Borillo (2002) apresenta alguns
passos para auxiliar a construir o modelo esttico, ou seja, atravs da abstrao real
do problema de domnio localizar as classes apropriadas, sendo:

o primeiro passo descobrir as classes: as melhores fontes possveis para

descobrir as classes so os requisitos de baixo nvel, declarao do problema
de alto nvel, e conhecimento de perito;

o segundo passo eliminar da lista de classes candidatas os itens que no

so necessrios;

o terceiro passo construir a relao de generalizao: a generalizao a

relao em que uma classe o refinamento de outra classe. Nesta relao
antiga classe chamada de superclasse e a ltima classe chamada de
subclasse;

o quarto passo construir associao entre as classes: a associao uma

relao esttica entre duas classes. Mostra a dependncia entre as classes,
mas no as aes.
 67

Os dez erros de mais freqentes na modelagem de domnio, destacados por

Rosenberg & Scott (1999), so:

1. Atribuir multiplicidade nas associaes logo no incio da modelagem;

2. Fazer anlise de verbo e substantivo exaustivamente;

3. Atribuir operaes para classes sem explorar casos de uso e diagramas de

seqncia;

4. Aperfeioar o cdigo para reusabilidade antes de satisfazer os requisitos;

5. Debater sobre usar agregao (compartilhada) ou composio para cada

parte de associao;

6. Presumir uma estratgia de implementao especfica nesta fase;

7. Usar nomes difceis de entender para as classes;

8. Ir diretamente para construo da implementao;

9. Criar um mapeamento de um-para-um entre as classes do modelo de

domnio e as tabelas do banco de dados;

10. Utilizar padres de projeto de forma prematura.

Desta forma, o objetivo do modelo de domnio realizar um primeiro

levantamento das entidades que fazem parte do problema. Sendo assim, os erros
levantados anteriormente pretendem alertar os desenvolvedores para que eles
evitem uma precipitao na busca de detalhes.

4.5 Modelo de Caso de Uso

Borillo (2000) destaca que o modelo de caso de uso o centro conceitual do

desenvolvimento, porque guia todo o processo do ICONIX. Neste sentido,
Rosenberg & Scott (1999) apresentam alguns elementos chaves, onde os modelos
de casos de uso so desenvolvidos em cooperao com o modelo de domnio; a
anlise de robustez identifica, um conjunto de objetos que satisfazem cada caso de
uso; o diagrama de seqncia traa o fluxo das mensagens entre os objetos
conforme especificao dos casos de uso. Alm disso, o endereamento de
requisitos conecta requisitos de usurio com casos de uso e classes e finalmente, os
 68

casos de uso servem de base para os testes de funcionalidade durante a fase de

implementao.

Um caso de uso uma seqncia de aes que um ator realiza no sistema para
alcanar um objetivo (ROSENBERG & SCOTT, 1999). Um caso de uso descreve e
valida o que o sistema ir fazer, serve de controle entre o usurio, cliente e
desenvolvedores. De acordo com Larman (2000), casos de uso no so exatamente
a especificao de requisitos ou a especificao funcional, mas ilustra e implica em
requisitos nos documentos que descreve. So compostos por atores (entidades
externas) e casos de uso (cenrios, texto).

Ainda de acordo com LARMAN (2000), a estrutura e os cabealhos dos casos de

uso so usualmente descritos como apresentado na figura 18. interessante iniciar
com a construo de um modelo de caso de uso de alto nvel. Nesta viso, os casos
de uso procuram descrever sucintamente um processo. O objetivo obter
rapidamente uma compreenso dos processos principais. Em um segundo
momento, este modelo deve ser expandido para garantir uma compreenso mais
profunda dos requisitos e dos processos.

Caso de uso: Verifica conferncia

Atores: Professor
Tipo: Primrio
Descrio: O professor verifica a existncia de uma conferncia. Valida se esta
pode fazer parte de outra conferncia geral. Especifica tambm o
prazo para submisso de artigos. No trmino, esta conferncia estar
disponvel para edio.

Figura 18: Exemplo textual de caso de uso de alto nvel

importante ressaltar que a UML (OMG, 2001) no especifica uma forma

padronizada para descrever casos de uso. Esta atividade deve ser definida pelo
fluxo de trabalho estabelecido para o processo em uso. Entretanto, comum utilizar
sees como pr-condies (o que precisa ser verdadeiro antes do incio do caso de
uso) e ps-condies (o que passa a ser verdadeiro aps o trmino do caso de uso).
Alm disso, os fluxos de aes so normalmente representados atravs de uma lista
enumerada de passos a serem seguidos (ver figura 19). Este formato adotado no
trabalho de Fowler & Scott (2000), onde a descrio de um cenrio feita atravs de
 69

uma seqncia de passos e de seqncias alternativas (variaes do fluxo

principal).

Verifica conferncia
1. O professor verifica a existncia de uma conferncia
2. Se existir realiza manuteno dos dados
3. Seno inclui dados
4. Valida se esta conferncia composta por outra conferncia principal
5. Se houver deve ser diferente da conferncia em questo.
6. Confirma o sucesso da operao
7. Disponibiliza conferncia para edio

Alternativa: Conferncia principal no existe.

No item 4, no existir a conferncia principal, permitir a incluso desta e retornar ao item 4.

Figura 19: Exemplo textual de caso de uso

Os atores representam o papel de uma entidade externa ao sistema, como um

usurio, o hardware, ou outro sistema que interage com o sistema modelado.
importante ressaltar que, os atores no fazem parte do sistema, mas identificam
seus limites. Fowler & Scott (2000) enfatizam que, quando se falar em atores,
importante pensar nos papis e no nas pessoas ou em cargos. Um nico ator pode
desempenhar vrios casos de uso, e um caso de uso pode reciprocamente ter
muitos atores.

Atores e casos de uso so classes. Um ator est conectado a um ou mais casos

de uso atravs de associaes, e podem possuir relacionamentos de generalizao
que definem um comportamento de herana. Para a visualizao do diagramas de
caso de uso ver a representao da figura 20.

De acordo com Silva & Videira (2001) um pacote (package) em UML (OMG,
2001) um elemento meramente organizacional. Permite agregar diferentes
elementos de um sistema em grupos de forma que semntica ou estruturalmente
faa sentido. Ento, um grupo de casos de uso relacionado definido como pacote
de casos de uso.
 70

Verifica Conferncia

<<include>> Valida Idiom a

<<include>>

Profes s or
<<include>>

<<include>> Valida Local

Edio
Edita de Conferncia
Conferncia

Pes quis ador

Valida As s unto

Figura 20: Diagrama de caso de uso

Pode-se aplicar algumas regras para definir qual associao utilizar entre os
casos de uso:

Usar incluso (<<include>>) quando estiver repetindo o mesmo fluxo em dois

ou mais casos de uso separados e deseja evitar a repetio. Por exemplo,
vrios casos de uso validam usurio (login). Ento, se cria um caso de uso
para validar_usurio, onde, os casos de uso que utilizam esse
procedimento, vo incluir (<<include>>) uma referncia ao caso de uso
validar_usurio (ver figura 20);

Usar generalizao quando estiver descrevendo uma variao semelhante

outra, mas que faz um pouco mais, e deseja descrev-la sem muito controle;

Usar extenso (<<extend>>) quando descrever uma variao em

comportamento normal e deseja utilizar a forma mais controlada, explicando
os pontos de extenso no use-case geral. Por exemplo, matrcula de ps-
graduao regular e especial. O caso de uso realiza_matrcula_especial
uma extenso (<<extend>>) do caso de uso geral realiza_matrcula.

Os dez enganos a serem evitados quando se escreve caso de uso, destacados

por Rosenberg & Scott (1999), so:

1. Escrever requisitos funcionais em vez de texto de cenrio de uso;

2. Descrever atributos ou mtodos no lugar de uso;

3. Escrever os casos de uso de forma muito sucinta;

 71

4. Desvincular completamente da interface com o usurio;

5. Evitar nomes explcitos para os objetos de limite;

6. Escrever usando uma perspectiva diferente do usurio, em voz passiva;

7. Descrever somente interaes de usurio, ignorando respostas de sistema;

8. Omitir texto para fluxos alternativos de ao;

9. Enfocar em algo diferente do que est "dentro de" um caso de uso, como pr-
condies ou ps-condies;

10. Gastar muito tempo decidindo se melhor usar includes ou extends.

Aps a concluso dos casos de uso, pode-se iniciar a sua anlise, por meio dos
diagramas de robustez.

4.6 Anlise de Robustez

O conceito de anlise de robustez foi introduzido por Ivar Jacobson para o mundo
de OO em 1991. Anlise de robustez envolve analisar o texto narrativo de cada caso
de uso e identificar um primeiro conjunto de possveis objetos que participaro do
caso de uso (ROSENBERG & SCOTT, 1999). Estes objetos so classificados em
trs esteretipos (ver figura 21):

Objetos de limite (boundary objects): os atores usam para se comunicar com

o sistema (freqentemente referidos como objetos de interface ou fronteira);

Objetos de entidade (entity objects): so normalmente objetos do modelo de

domnio, geralmente mapeados em tabelas de um banco de dados;

Objetos de controle (control objects): funcionam como integradores entre os

objetos de limite e os objetos de entidade. Geralmente, so convertidos em
mtodos de objetos de entidade ou de objetos de limite.
n

n
re

re
lV

lV
EA

-U
te

te
ia

ia
on
is

is
10
Tr

Tr
eg

eg
si

3.
er
d

d
nr

nr

e
re

re
lV

lV
EA

-U
te

te
ia

ia
on
is

is

Objeto de limite Objeto de controle Objeto de entidade

10
Tr

Tr
eg

eg
si

3.
er
d

d
nr

nr

Figura 21: Smbolos do diagrama de robustez

 72

Borillo (2000) e Silva & Videira (2001) enfatizam que a anlise de robustez o
link entre a anlise (o qu) e o projeto (como), tendo as seguintes regras chaves:

Verificar razoabilidade: ajuda a ter certeza que o texto de caso de uso est
correto e se a especificao do comportamento do sistema est razovel.
Pode-se substituir os substantivos genricos do texto do caso de uso para
nomes adequados dos objetos que aparecem nos diagramas de robustez;

Verificar a perfeio: ajuda a validar se todas as referncias de execuo do

sistema esto descritas no fluxo principal e alternativo dos casos de uso;

Identificar objetos: permite identificar novos objetos que no foram

esquecidos durante a modelagem de domnio. Esta fase ajuda a achar
discrepncias e conflitos entre nomes. Deve-se usar os nomes do modelo de
domnio para os objetos de entidade. Quando se termina a anlise de
robustez, deve-se ter identificado, a maioria das classes de domnio;

Projeto preliminar: os diagramas de robustez so menos complexos e mais

fceis ler que diagramas de seqncia.

Uma importante sugesto do ICONIX desenvolver os diagramas de anlise de

robustez antes, ou em paralelo, com a descrio textual dos casos de uso (SILVA &
VIDEIRA, 2001). Desta forma, pode-se influenciar a identificao dos objetos e a
escolha dos nomes usados. A finalidade substituir os nomes genricos por nomes
dos objetos que aparecem os diagramas de robustez. Ainda de acordo com Silva e
Videira (2001), outra sugesto relevante evitar fazer desenho detalhado nesta fase
e neste tipo de diagrama. Uma vez que, o objetivo fundamental encontrar para
cada caso de uso, os principais objetos e a relao de comunicao entre eles.

O ICONIX apresenta dois princpios para guiar a anlise de robustez que so: (1)
deve-se trabalhar com um nmero pequeno (entre dois e cinco) de controles por
caso de uso. Se existir mais de 10 controles por caso de uso, ento, deve-se dividir
em casos de uso menores; (2) as setas podem seguir uma ou duas direes entre
diferentes tipos de objetos, e indicam associaes lgicas (BORILLO, 2000). A figura
22 mostra o que permitido e o que no permitido ser feito no diagrama de
robustez.
 73

Figura 22: Regras do diagrama de robustez

A essncia do diagrama de robustez pode ser capturada pelas seguintes regras:

atores podem se comunicar somente com objetos de limite;

objetos de limite podem conversar apenas com atores e objetos de controle;

objetos de entidade se comunicam apenas com objetos de controle;

objetos de controle podem conversar somente com objetos de limite e de

controle.

Segundo Rosenberg & Scott (1999), o prximo passo necessrio, antes de

passar para a modelagem de interao (diagrama de seqncia), atualizar o
modelo de domnio (esttico). De fato, muito importante atualizar continuamente o
modelo esttico enquanto se trabalha com os casos de uso e durante a anlise de
robustez.

Os dez benefcios da anlise de robustez, destacados por Rosenberg & Scott

(1999) so:

1. Obriga a escrita dos casos de uso de forma concisa;

2. Fora a escrita dos casos de caso na pessoa correta;

3. Provem mecanismos de checagem dos casos de uso;

 74

4. Ajuda a definir regras de sintaxe do tipo O ator interage somente com objetos
do tipo limite, para os casos de uso;

5. A realizao dos diagramas de robustez mais fcil de entender e mais

rpido de desenhar do que os diagramas de seqncia;

6. Permite o esboo de um framework para GUI-Lgica-Repositrio para

sistemas cliente/servidor;

7. Permite o mapeamento entre o que o sistema faz (casos de uso) e como o

sistema ir funcionar (diagrama de seqncia);

8. Preenche a lacuna semntica entre a anlise (caso de uso) e o projeto

(diagrama de seqncia);

9. Permite que seja feito um repasse para identificao de reutilizao de

estrutura definidas na realizao dos casos de uso;

10. Permite a diviso entre o paradigma de Modelo Viso Controle.

Uma vez terminada a modelagem de domnio e a anlise de robustez, tem-se a

maior parte dos objetos e definidos alguns atributos para os objetos. Ento, pode-se
partir para a especificao de como o software realmente ir trabalhar. Utilizando
para isto o modelo de interao, que ser visto na prxima seo.

4.7 Modelo de Interao

A modelagem de interao a fase na qual se constri as linhas de execuo

que unem os objetos e capacitam visualizar inicialmente, como o novo sistema
apresentar comportamento til (ROSENBERG & SCOTT, 1999).

O comportamento de um caso de uso no modelo de interao detalhado

atravs do diagrama de seqncia. O diagrama de seqncia mostra a colaborao
dinmica entre os vrios objetos do sistema. Um importante aspecto deste diagrama
que, a partir, dele percebe-se a seqncia de mensagens enviadas entre os
objetos, pois mostra a interao entre os mesmos (SILVA & VIDEIRA, 2001). Alm
disso, aloca comportamento nos objetos de controle, que normalmente se
transformam em objetos de limite e/ou objetos de entidade e, ajuda finalizar a
distribuio das operaes nas classes. Ento, pode-se atualizar o modelo esttico e
 75

completar os mtodos utilizando os atributos identificados nas fases anteriores

(BORILLO, 2000).

Rosenberg & Scott (1999) destacam quatro tipos de elementos no diagrama de

seqncia (ver figura 23):

1. Texto do caso de uso (fluxo de ao). Copiar este item para a margem
esquerda do diagrama de seqncia;

2. Objetos dos diagramas de robustez. Eles so representados com o nome do

objeto e (opcionalmente) o nome da classe a que pertence (objeto::classe);

3. Mensagens representadas como setas entre objetos;

4. Mtodos (implementao de operaes) so mostrados como retngulos em

cima das linhas pontilhadas que pertence aos objetos em que se est
atribuindo os mtodos.

ator mtodo mensagem objetos

Fluxo Principal
1. O sistema apresenta
uma tela para informar
o Aluno.
2. O aluno informa o
cdigo e seleciona
Mostrar Notas.
3. O sistema apresenta
uma tela com a lista de
todos os trabalhos e as
respectivas notas.
4. Encerra consulta

Fluxo Alternativo
No item 2, se o cdigo
invlido, apresentar a
mensagem Cdigo
invlido e retorna ao
item 2 (no est
representado).

Figura 23: Elementos do diagrama de seqncia

Decidir que mtodos continuam e que classes so a essncia da modelagem de

interao, no tarefa fcil de realizar e exige muito esforo e experincia
(ROSENBERG & SCOTT, 1999). O ICONIX apresenta algumas sugestes para
realizar esta tarefa, como:
 76

Iniciar convertendo os objetos de controle, dos diagramas de robustez, para

conjuntos de mtodos e mensagens que incluam o comportamento desejado;

Usar o diagrama de robustez como uma lista de checagem, para ter certeza
que todo o comportamento requerido do sistema est no diagrama de
seqncia;

Conseguir responder a questo: Que objetos so responsveis por quais

funes?;

Desenhar mensagens entre objetos equivalente a atribuir mtodos e/ou

operaes para os objetos.

importante ressaltar que, no modelo de interao pode-se usar o diagrama de

colaborao e diagrama de estado da UML (OMG, 2001) em conjunto com o
diagrama de seqncia (so opcionais). Estes diagramas auxiliam a modelar
aspectos adicionais do comportamento dinmico do sistema que se est projetando
(ROSENBERG & SCOTT, 1999). Silva e Videira (2001) consideram que os
diagramas de colaborao ajudam a ilustrar as principais transaes entre objetos,
em particular situaes com padres de desenho. O ICONIX d nfase utilizao
de diagramas de estados associados a casos de uso em vez de, como mais
comum, a objetos e classes.

Os dez pontos mais importantes do modelo de interao, destacados por

Rosenberg & Scott (1999) so:

1. Fazer um diagrama de seqncia atravs dos casos de uso;

2. Combinar o fluxo narrativo do caso de uso associado com o diagrama;

3. Construir um diagrama de seqncia nico para cada caso de uso, inclusive

com os fluxos alternativos;

4. As mensagens entre objetos invocam as operaes nas classes;

5. Ter dificuldades em iniciar a construo do diagrama de seqncia indica que

o caso de uso pode estar escrito de forma incorreta ou a anlise de robustez
no foi completada;
 77

6. Explorando o comportamento dinmico do sistema se identifica atributos e

mtodos dos diagramas de classe;

7. O diagrama de seqncia o veculo primrio para tomar decises de

alocao de comportamento;

8. Adicionar soluo dos objetos de limite (interface) para os objetos de domnio

do problema, como se explora o uso do sistema em um nvel detalhado;

9. Os padres de projeto, nesta atividade, so freqentemente teis;

10. Escrever o texto original, nvel de requisitos, do caso de uso na margem do

diagrama de seqncia prov requisitos visuais de rastreabilidade.

De acordo com Silva & Videira (2001), a ltima atividade para completar o
modelo de interao atualizar o modelo esttico. Para tanto, deve-se adicionar
informaes detalhadas ao diagrama de classe, com base nos diagramas de
seqncia que identificam as operaes que de devero fazer parte das classes
correspondentes. Alm disso, o diagrama de classe dever incluir todos os atributos,
operaes, valores de visibilidade e de navegabilidade.

4.8 Endereando Requisitos

O ICONIX reserva a abordagem da anlise de requisitos por ltimo, por duas

razes principais (BORILLO, 2000):

para evitar a possvel confuso entre requisitos, casos de uso e funes

(operaes). O conceito de casos de uso e funes foi explanado
anteriormente atravs da modelagem de casos de uso e da modelagem de
interao. Desta forma, o ICONIX acredita que mais fcil falar sobre
requisitos e como eles contrastam com esses itens;

o conceito de rastreabilidade se torna mais importante no momento anterior a

codificao. preciso evitar codificar um sistema que no esteja de acordo
com os requisitos reais do cliente.

Um requisito um critrio especificado pelo usurio que o sistema precisa

satisfazer (ROSENBERG & SCOTT, 1999).
 78

Pressman (1997) define requisito como uma condio ou capacidade que o

software deve possuir para atender uma necessidade do usurio, ou para resolver
um problema, ou para atingir um objetivo, ou para atender as restries da
organizao ou dos outros componentes do sistema.

Segundo Rosenberg & Scott (1999), os requisitos so normalmente expressos

em sentenas que incluem as palavras deve ter ou necessrio. Existem vrios
tipos diferentes de requisitos. Borillo (2002) considera os seguintes requisitos como
os mais usados:

os requisitos funcionais: que representam a funcionalidade que o sistema

deve ter. Podem ser especificados, por exemplo, na forma de pr-condio
(estado), ao e ps-condio (resultado);

os requisitos no-funcionais: que representam as qualidades do produto.

Podem incluir requisitos de desempenho, de capacidade, de teste e de
segurana. Geralmente associados a critrios que servem como parmetro
para quantificar o requisito;

as restries: que fixam os limites do projeto e do sistema. Normalmente

associadas a uma razo por que uma restrio est limitando o sistema.

Ainda de acordo com Borillo (2000), o modo que o ICONIX aborda os requisitos
em relao aos casos de uso e funes a seguinte: um caso de uso descreve uma
unidade de comportamento para um sistema; os requisitos descrevem as leis que
governam o comportamento; as funes so as aes individuais que acontecem
dentro do comportamento. Neste sentido, no existe nenhuma razo por que um
caso de uso no possa enderear mais que um requisito. Tambm perfeitamente
aceitvel que um conjunto de casos de uso satisfaam apenas um requisito.

Na abordagem do ICONIX, os requisitos do usurio precisam ser endereados

em conjunto com cada artefato produzido na anlise e projeto. Par tal, torna-se
necessrio:

revisar as alocaes dos requisitos para os casos de uso, usando os

diagramas de casos de uso original e os diagramas de robustez. Cada
requisito deve ser alocado, pelo menos, para um caso de uso;
 79

verificar que cada requisito seja tratado, pelo menos, por uma classe no
modelo esttico;

trilhar para que o nvel dos requisitos descritos nos casos de uso satisfaa o
projeto atual atravs dos diagramas de seqncia.

Os dez itens mais importantes para lembrar sobre requisitos, destacados por
Rosenberg & Scott (1999) so:

1. O time deve fazer uma lista completa dos requisitos, to cedo quanto
possvel, em vez de iniciar diretamente com o cdigo;

2. Os requisitos so requisitos; os casos de uso so casos de uso. Os requisitos

no so casos de uso; os casos de uso no so requisitos;

3. Existem vrios tipos de requisitos, incluindo funcionais, no funcionais e

restries;

4. O time deve demonstrar conexo direta com, pelo menos, um caso de uso
para cada requisito durante a reviso dos requisitos;

5. O time deve demonstrar conexo direta com, pelo menos, uma classe para
cada requisito durante a reviso dos requisitos;

6. Cada caso de uso deve servir para ambas as entradas, tanto para o processo
de desenvolvimento quanto para os testes de aceitao de usurio;

7. O time deve localizar a alocao de requisitos para os casos de uso e classes

de domnio como parte da reviso de requisitos;

8. Quando todos os requisitos do usurio estiverem mapeados em algum lugar

do projeto, o processo de implementao pode ser iniciado;

9. O projeto detalhado, como refletido nos diagramas de seqncia, dever ser

certificado com o texto de cada caso de uso como parte da reviso do projeto;

10. Deve-se ter, pelo menos, um teste para verificar cada requisito.
 80

4.9 Consideraes Finais

Nesta seo foi apresentado o ICONIX, o qual um processo iterativo e

incremental, dirigido por casos de uso e com modelagem visual baseada em UML
(OMG, 2001). Silva & Videira (2001) destacam que o ICONIX, por meio de uma
abordagem essencialmente prtica, ensina a modelar um sistema de software
segundo o paradigma OO. Ainda de acordo com Silva & Videira (2001), o objetivo
global do ICONIX , a partir de um conjunto de requisitos inicialmente definido, a
construo do modelo de classes que suporte a implementao de determinado
sistema. O prximo captulo apresenta os procedimentos metodolgicos utilizados
para a realizao do trabalho. apresentado anda, o ambiente da aplicao e como
foi realizada a coleta das informaes por meio da aplicao do XP e da aplicao
do ICONIX.
 81

5 PROCEDIMENTOS METODOLGICOS

Neste captulo, ser apresentada a metodologia aplicada no trabalho. A pesquisa

de campo ser realizada na forma de observao direta intensiva, de forma
exploratria (GIL apud SILVA, 2001) para levantar e analisar dados quantitativos e
qualitativos sobre os processos XP e ICONIX. A inteno obter, dos lderes e
participantes das comunidades de desenvolvimento, os aspectos particulares de
cada processo, e correlacionar estes dados para sintetizar um conjunto comparativo
entre os dois modelos.

Para realizar o levantamento, foram definidos dois projetos e serem estudados. O

modelo XP ser analisado no projeto Gratificao de Incentivo a Docncia (GID) do
Centro Federal de Educao Tecnolgica de Santa Catarina (CEFET/SC); o modelo
ICONIX ser analisado no projeto Pronturio Mdico e Odontolgico (InfoSade)
da Secretaria Municipal da Sade de Florianpolis.

Alm do levantamento de informaes, foi elaborado um questionrio, o qual foi

aplicado individualmente nos especialistas de domnio (clientes) e nos analistas de
desenvolvimento (tcnicos e alunos). Este questionrio indicou as preferncias,
facilidades e dificuldades encontradas em cada processo.

Para a execuo do trabalho, os processos foram aplicados paralelamente em

ambos os projetos. Desta forma, acreditou-se conseguir uma forma de comparao
mais precisa.

5.1 Ambiente da Aplicao e Escalonamento dos Processos

O ambiente da aplicao, o escalonamento dos processos e, a infra-estrutura

tecnolgica e de pessoal foram determinados conforme a disponibilidade e as
necessidades do cliente. Tambm foi realizado remanejamento de pessoal para que
fosse possvel atender os requisitos necessrios em cada modelo proposto.

5.1.1 Infra-estrutura e tecnologia de desenvolvimento

Para a aplicao do XP foi adotada a seguinte estrutura:

 82

banco de dados o Oracle9i;

ferramenta de programao o Oracle Forms Builder e PL/SQL;

ferramentas de modelagem o ERwin 4.0 e o Microsoft Visio 2000;

ferramenta de teste de aceitao o Microsoft Excel;

time composto por 4 membros.

Para a aplicao do ICONIX foi adotada a seguinte estrutura:

banco de dados o SQL Server 2000;

linguagem de programao o Borland Delphi 6;

ferramentas de modelagem o ERwin 4.0 e o Enterprise Architect (EA);

time composto por 5 membros.

Embora o EA permita realizar o modelo de dados (entidade-relacionamento)

atravs de uma extenso do modelo de classe, foi utilizado o ERwin 4.0 por ser uma
ferramenta mais completa e devido ao time ter experincia com ela.

5.1.2 Escalonamento dos processos X sistemas

A escolha da utilizao do processo XP no sistema GID se deu pelo fato que, o

XP se destina a projetos nos quais o cliente no necessita de uma documentao
formal, o time envolvido deve ser pequeno e o prazo de execuo dura poucos
meses. Alm disso, o XP trabalha em ambientes dinmicos, ou seja, os requisitos
podem sofrer freqentes mudanas (ZABEU, 2002) (WELLS, 2001).

Por sua vez, a escolha da utilizao do processo ICONIX no sistema InfoSade

se deu pelo fato que, a necessidade de uma documentao de requisitos e de uma
modelagem formal era fundamental para a execuo do projeto. importante
destacar que, os requisitos e os casos de uso foram elaborados de forma que o
especialista de domnio pudesse compreender e validar a funcionalidade dos
mesmos.

Nas sees seguintes ser apresentado como foi aplicado o processo XP e o

processo ICONIX.
 83

5.2 Aplicao do XP

O trabalho foi iniciado com a fase de explorao, conceituada anteriormente na

seo 3.4.1, cujo objetivo foi compreender o que o sistema precisava fazer, bem o
suficiente para que pudesse ser estimado (WAKE, 2002). Essa estimativa foi
preliminar, e partiu das primeiras histrias escritas pelo cliente. Em paralelo as
histrias dos clientes, foram avaliadas as diferentes tecnologias e exploradas as
possibilidades para a arquitetura do sistema. Nesta etapa, foi utilizado tambm, o
diagrama de atividades da UML (OMG, 2001).

Durante a fase de planejamento, foi especificado o projeto, as iteraes e o dia-a-

dia. Foi elaborada uma estimativa com base nos cartes de histria, na metfora e
em uma soluo simples (ASTELS et al., 2002). O objetivo desta fase foi estimar o
menor tempo e o maior nmero de histrias para a primeira verso (BECK, 2000). O
projeto tambm poderia ser replanejado se uma alterao significativa, repassada
pelo cliente ou pelos desenvolvedores, fosse identificada.

5.2.1 Composio e tarefas do time

Todos os contribuintes do projeto sentavam-se juntos como membros de um time

(JEFFRIES, 2001). O time incluiu um especialista de domnio - o cliente - que
definia os requisitos, fixava as prioridades e guiava o projeto. O time possua uma
dupla de programadores, os quais tambm absorveram a tarefa de ajudar o cliente a
definir os testes de aceitao e os requisitos. Alm destes, existia um gerente que
provia recursos, mantinha a comunicao externa e coordenar as atividades.
Nenhum destes papis foi necessariamente de propriedade exclusiva de um s
indivduo. Todos os membros do time contriburam de todas as formas que puderam,
conforme suas capacidades. Jeffries (2001) destaca que os melhores times no tm
nenhum especialista, mas contribuintes gerais com habilidades especiais.

5.2.2 Descrio do sistema

O aplicativo foi construdo para calcular a Gratificao de Incentivo a Docncia

(GID) e teve como base o regulamento elaborado pelo Comit de Avaliao Docente
 84

do CEFET/SC. Este regulamento estabelece os critrios e procedimentos de

avaliao e desempenho docente para a implementao da GID.

O sistema mantm uma lista de todos os docentes de carreira de 1 e 2 Graus

que ministram aulas nos cursos regulares do CEFET/SC ou que desempenham
outras atividades previstas no regulamento. Uma lista simples de atividades tambm
mantida.

Para efeito de pontuao, os professores so classificados em grupos. Conforme

o grupo, existe um critrio para avaliao, ou seja, uma seqncia de procedimentos
e clculos que o sistema executa. O centro do sistema o gerenciamento dos
pontos obtidos pelo professor, que proporcional ao seu desempenho docente. A
principal finalidade do sistema foi gerar informaes para os recursos humanos.

Neste momento, identificou-se a necessidade de um diagrama que mostrasse de

forma genrica o fluxo do negcio. Neste sentido, foi escolhido o diagrama de
atividades que ilustra o fluxo de atividades, representado na figura 24. Torna-se
importante ressaltar que este diagrama parte da especificao UML (OMG, 2001).

Figura 24: Diagrama de atividades da GID

 85

5.2.3 Metfora

A metfora foi usada para superar os problemas de conceituao e comunicao

inicial com o cliente (ASTELS, 2002). Quando se comeou a pensar sobre o sistema,
se achou que ele era direto o suficiente para se adotar simplesmente uma metfora
ingnua, um sistema de nomes baseado no domnio. Entretanto, o cliente em
determinado momento, da fase de explorao, comentou:

Pensei inicialmente em utilizar uma planilha do Excel para realizar os clculos.

Pois, a entrada dos dados facilitada e consigo visualizar os critrios de avaliao e,
rapidamente tenho o resultado.

Ento, este comentrio passou a ser a metfora para o sistema da GID. A

principal vantagem da metfora foi que o time conseguiu, rapidamente, pensar em
uma interface para o usurio. Alm disso, o formulrio para coletar as informaes
nas gerncias dos cursos foi exibido em formato tabular (ver figura 25).

Figura 25: Planilha para coleta e simulao da GID

5.2.4 Histrias do usurio

Nesta seo, esto relacionados os cartes de histria elaborados pelo cliente.

Todas as histrias de interesse foram anotadas e discutidas pelo time. Inicialmente,
houve uma pequena dificuldade do cliente em elaborar uma histria. Entretanto, no
existiu resistncia. Partiu-se com as histrias centrais e, posteriormente, adicionou-
se algum detalhe.
 86

importante ressaltar que um carto de histria apenas um lembrete de uma

conversao com o cliente (ASTELS, 2002). Uma histria no contm todos os
detalhes que so necessrios para codificar o comportamento. Para isto, foram
realizadas conversas diretas com o cliente.

A primeira histria, representada pela figura 26, est em seu formato original. As
demais histrias, representadas pela figura 27, esto em formato resumido para
melhor organizao deste trabalho.

CARTO DE HISTRIA E TAREFA

Data: 23/04/2002 Tipo de Atividade Nova: X Dificuldade Valor:
Nmero da Histria 001 Calcular GID Prioridade do Usurio:
Referncia Anterior: Risco: Estimativa do Tcnico:
Descrio da Tarefa: Calcular a GID com base no grupo que o professor est. O grupo especificado pelo
regime de trabalho e nmero de horas/aula do professor, num total de 5 grupos.
Sendo que para os grupos I-II-II calcular a GID, para o grupo IV dar 48 pontos
(calcular somente se o professor solicitar) e o grupo V no recebem GID.
Notas: Os professores dos grupos I-II-III so atribudos um total de pontos multiplicando-se 80 pontos
vezes o nmero de professores de cada grupo.
Acompanhamento da Tarefa:
Data Estado Para Realizar Comentrio
23/04 Questionar OK Quais informaes guardar mensal/semestral
30/04 OK Guardar mensal: horas/aula e semestral: avaliao
quantitativa e participao projetos

Figura 26: Carto de histria e tarefas

N histria Descrio
002 Coletar os dados dos professores atravs de formulrios que estaro disponveis para cada
gerncia. Estes dados servem de base para o clculo da GID. Os dados so referentes carga
horria, nmero de alunos, avaliao quantitativa, e participao em projetos.
003 Considerar no clculo da GID:
- se o professor se afastar: ter como gratificao pontuao obtida no perodo anterior.
- se no houver pontuao anterior, ou se o afastamento for superior ao de avaliao, a GID
ser calculada com base em 60% do limite mximo de pontos .
- nos meses de frias ser considerada mdia dos ltimos 12 meses.
afastamento por doena e/ou invalidez, ser calculado pela mdia dos ltimos 12 meses.
004 Gerar o clculo com informaes dos ltimos 6 meses para as gerncias, com possibilidade de
alterar os resultados no perodo de 21 dias (7 dias recurso / 14 dias julgamento). Relatrio final
dever ser entregue a GDRH Gerencia de Recursos Humanos que ir vigorar no semestre
subseqente ao clculo.
005 Imprimir o resultado do total dos pontos e a converso em reais.
Imprimir dados do professor para conferncia.

Figura 27: Carto de histria e tarefas resumido

 87

5.2.5 Estimativa, priorizao e planejamento

Assim que as histrias foram coletadas, o cliente as classificou por prioridade:

alta, mdia, baixa. As histrias sinalizadas como alta eram imediatamente
necessrias, o sistema no teria validade sem elas. As histrias marcadas como
mdia eram requeridas, mas a sua ausncia poderia ser contornada por algum
tempo. As histrias sinalizadas como baixa seriam interessantes, mas apenas aps
a concluso das outras histrias.

Posteriormente, o time de programao estimou as histrias pontuando em

semanas, se uma histria consumisse mais de trs semanas o programador
retornava a histria para que o cliente a dividisse em histrias menores. Definidas as
estimativas e prioridades, foram designadas as iteraes. Decidiu-se por duas
iteraes (ver Tabela 1).

importante observar que os cartes de histria formaram a funcionalidade

bsica do aplicativo. Desta forma, optou-se por constituir a primeira verso do
sistema. Provavelmente, outras verses sero necessrias para aperfeioamento e
complemento de recursos.

Tabela 1: Dados dos cartes de histria

Histria Prioridade Estimativa Iterao

001 - Calcular GID alta 2 semanas 1
002 - Coletar dados alta 1 semana 1
003 Excees do clculo mdia 1 semana 1
004 Gerar pontos mdia 2 semanas 1
005 Imprimir resultados mdia 1 semana 2

Logo aps, a realizao das provveis estimativas, as histrias foram divididas

em tarefas. Com o objetivo de maximizar o trabalho, foi elaborada uma lista
simplificada de tarefas para os cartes de histria (ver Tabela 2). Esta deciso foi
tomada para facilitar o trabalho do time, uma vez que, existia apenas um par de
programadores.
 88

Tabela 2: Diviso das histrias em tarefas

Histria Tarefa (s) Realizada

001 - Calcular GID Criar e manipular professores OK
Criar e manipular projetos OK
Criar e manipular grupos OK
Manipular dados mensais de carga horria e alunos OK
Manipular dados semestrais avaliao quantitativa OK
Manipular dados semestrais projetos de pesquisa OK
Mapear as frmulas do clculo OK
002 - Coletar dados Elaborar formulrio para coleta dos dados OK
Gerenciar lista de informaes atualizadas OK
003 Excees do clculo Guardar informaes de perodos anteriores OK
Prever meses de frias OK
Guardar mdia dos ltimos 12 meses OK
004 Gerar pontos Gerar os pontos de todos os professores validando o grupo OK
Listar todas as informaes geradas OK
Pesquisar resultado por professor OK
005 Imprimir resultados Imprimir dados na tela e em papel OK
Imprimir lista de resultados: matricula nome pontos valor OK
Imprimir dados individuais para conferncia OK

5.2.6 Teste de aceitao

Para validar cada caracterstica desejada, o cliente realizou os testes de

aceitao manualmente por meio da interface grfica do usurio (GUI Graphical
User Interface). Foi assentado que a GUI era suficientemente simples para que os
testes de aceitao fossem executados mo. Alm disso, um teste de simulao
da GID foi construdo na planilha do Microsoft Excel, cujo objetivo era mostrar que os
resultados esperados estavam corretamente implementados.

Para Jeffries (2001), os melhores times XP valorizam os testes do cliente da

mesma forma que consideram os testes do programador. Uma vez que os testes
funcionem, o time deve manter esta verso como correta.

5.2.7 Desenvolvimento orientado por teste

O time realizou o desenvolvimento orientado por teste, trabalhando em ciclos

muito pequenos, onde foram acrescentados os testes. Primeiramente, se escreveu o
teste que especificou e validou o comportamento desejado e, em seguida, foi criado
e desenvolvido o cdigo que o implementou. Desta forma, o time produziu o cdigo
com grande parte dos testes cobertos, o que foi um grande avano.
 89

A construo dos testes foi iniciada com a definio de procedures. O objetivo

do primeiro teste foi examinar a pontuao docente obtida atravs da frmula para
calcular carga horria. O teste seguinte foi modelado para validar os pontos
obtidos atravs da relao de responsabilidades docentes, conforme o nmero de
alunos. Um terceiro teste foi elaborado para a avaliao quantitativa das aulas
ministradas, limitando pontos por assiduidade e atribuies didtico-pedaggicas. O
ltimo teste realizado para atender a histria 001 Calcular GID, foi atribuir pontos
pela participao em projetos de pesquisa utilizando a frmula conforme o grupo do
professor.

Cada teste, inclusive o cdigo, foi desenvolvido de forma incremental, incluindo

um teste de cada vez e fazendo com que ele fosse validado. Isto ajudou os
programadores a terem um retorno imediato de como eles estavam procedendo.
Esse padro de desenvolvimento se repetiu em toda a aplicao. Embora, tenham
sido realizados testes somente para as histrias e tarefas que o time considerou
como cruciais para o sistema.

Neste contexto, Jeffries (2001) enfatiza que o retorno dos testes realizados
muito importante no desenvolvimento do sistema, pois um bom resultado exige bons
testes. Desta forma, o sistema da GID foi construdo.

5.2.8 Entrega da verso para produo

O sistema entrou em produo aps a execuo de todos os testes de aceitao

realizados pelo cliente. Desta forma, um projeto pequeno e simples foi desenvolvido
no modelo do XP. Parte da interface pode ser visualizada na figura 28.

importante ressaltar que alguns requisitos surgiram medida que o

desenvolvimento progrediu. Um requisito que se pode destacar, foi habilidade de
simular o clculo do professor com dados fictcios. Neste caso, no foi necessrio
alterar muito o planejamento. A nova histria foi incorporada adicionando-se mais
uma iterao.
 90

Figura 28: Tela de entrada dos dados mensais da GID

5.3 Aplicao do ICONIX

O trabalho foi iniciado com um levantamento informal de todos os requisitos que,

a princpio, deveriam fazer parte do sistema InfoSade. Posteriormente, conforme as
etapas de anlise de requisitos, anlise e projeto preliminar, projeto e
implementao foram acontecendo, esses requisitos foram transformando-se em
outros artefatos. As tarefas mais importantes contempladas nesta seo referem-se
fase de concepo, em particular as tarefas de identificao de requisitos, de
anlise e de desenho.

Quando se optou por utilizar o ICONIX neste projeto, estava claro que havia a
necessidade de produzir alguns documentos. Inicialmente, estes documentos no
pareceram muito teis. Entretanto, logo se percebeu que estes artefatos eram
essenciais para se construir o projeto dentro do melhor caminho. Borca (2000)
considera que cada documento ajuda a desenvolver uma parte do projeto. O projeto
InfoSade foi dividido em mltiplos passos. Sendo que, um artefato foi produzido
como resultado de cada passo. Estes artefatos so apresentados nas sees
seguintes.

5.3.1 Descrio do sistema

O sistema foi desenvolvimento para automatizar o processo de agendamento de

consultas e acompanhamento do paciente atravs do pronturio mdico e
 91

odontolgico. Alm de gerar informaes estatsticas e financeiras para Secretaria

da Sade. O pronturio mdico mantm o histrico referente sade do paciente
(exames, vacinas, partos, medicamentos, etc.) e o pronturio odontolgico contm
os dados relativos situao dentria (odontograma) e a higiene bucal do paciente.

Integram o InfoSade um conjunto de profissionais, os quais pertencem a uma

especialidade. Para cada especialidade definida a durao da consulta, que
automaticamente gera a estrutura da agenda com a quantidade de consultas
disponveis para o profissional. Adicionalmente, cada especialidade d acesso a
determinadas partes (fichas) do pronturio.

O InfoSade ainda integra vrias estruturas de codificao utilizadas pelo

Ministrio da Sade, como a tabela do Sistema de Informaes Ambulatoriais (SIA)
e a tabela do Cdigo Internacional de Doenas (CID). Com base nessas
codificaes so geradas informaes para o Relatrio Ambulatorial de Atendimento
Individual (RAAI). O RAAI resume um atendimento e possui dados sobre o tipo de
consulta (1 consulta, gestantes), procedimentos realizados no paciente (curativo,
presso arterial), vacinas aplicadas e medicamentos fornecidos.

5.3.2 Atores (utilizadores)

Como foi discutido na seo 4.5, os atores so entidades externas que interagem
com o sistema. Neste contexto, Silva & Videira (2001) destacam que o conjunto de
todos os atores reflete todos os elementos que interagem com o sistema.

O InfoSade suporta os seguintes tipos de atores, que foram identificados no

incio do levantamento dos requisitos:

Corpo clnico: Conjunto de profissionais registrados no sistema que possuem

um identificador prprio (CRM, CRO). Estes atores tm acesso a todas as
informaes que fazem parte do pronturio do paciente. Podem incluir e
modificar os dados. So responsveis pelo contedo e sigilo das informaes.

Enfermeiro: Conjunto de profissionais cadastrados no sistema que tem um

identificador prprio (CREA). Acessam pacientes que j possuem consulta
agendada para realizar procedimentos de triagem (colher informaes bsicas
 92

do paciente). Tambm acessam o pronturio para realizar consultas de

enfermagem. Tem restrio de acesso ao receiturio e atestados.

Recepcionista: So usurios do sistema com acesso para manipular a agenda

dos profissionais e cadastrar pacientes do posto.

Coordenador: Atores responsveis pela gesto e configurao das

informaes do sistema. Controla as operaes introduo, remoo e
alterao de atores, define a estrutura da agenda, tipos de exames, etc. So
ainda responsveis pela emisso de todas as informaes gerenciais.

5.3.3 Anlise de requisitos

5.3.3.1 Modelo de domnio

A primeira tarefa que a equipe desempenhou foi coleta de todos os documentos

utilizados no Posto de Sade. Com base nestes documentos foi realizado uma
leitura e interpretao das informaes. Desta forma, se identificou todos os objetos
do mundo real e todas as relaes de generalizao e associao possveis. Alm
disso, foi realizado um conjunto restrito de entrevistas com os atores e especialistas
de domnio. O resultado desta tarefa correspondeu ao diagrama de domnio (ver
figura 29).
n

n
re

re
EA

EA

EA
lV

lV
-U

-U
te

te

Pessoa Medicamento
ia
ia

n
is

is
10

10

Especialidade
io

io
Tr

Tr
eg

eg

1
rs

rs
3.

3.

3
d

d
nr

nr
e

Ve
re

re
EA

EA

EA
lV
-U

-U
te

te

receitado para
l
ia
ia

tem
n

n
is

is
10

10
io

io
Tr
Tr
eg

eg

1
rs

rs
3.

3.

Profissional PrimeiraConsulta
3

Paciente
d
d
nr

nr
e

Ve

feita em
re
re
EA

EA

EA

Raai
lV
-U

-U

te
te

l
ia

ia
n

n
is
is
10

10
io

io
Tr
Tr

eg
eg

1
rs

rs
3.

3.

pertence
3
d

d
nr
nr

gera
e

Ve
re

re
EA

EA

EA
lV

realizada por feita em um

-U
-U

tem tem
te

te

aplicada no Ev oluo
l
ia

ia
n

n
is

is
10
10

io

io
Tr

Tr

Consulta
eg

eg

1
rs

rs
3.
3.

3
d

d
nr

nr

SiaSus CID_10
e

Ve

realizado em
re

re
EA

EA

EA
lV
-U

-U

te
te

l
ia

ia
n

n
is

is

Exame Vacina
10

10
io

io
Tr

Tr
eg

eg

1
rs

rs
3.

3.

pode ter
3
d

d
nr

nr
e

Ve
re

re
EA

EA

EA
lV
-U

-U

te
te

TipoAgendamento Agenda
l
ia

ia
n

n
is

is
10

10
io

io
Tr

Tr
eg

eg

1
rs

rs
3.

3.

3
d

d
nr

nr
Ve

Ve
re

re
EA

EA

EA
-U

-U
te

te
al

al
n

Figura 29: Diagrama de domnio do InfoSade

 93

Silva & Videira (2001) destacam que uma prtica comum para a identificao das
classes candidatas abstrair dos textos e documentos os nomes e os substantivos.
Por sua vez, a identificao de relacionamento de associao entre as classes pode
ser captada a partir de verbos e expresses verbais.

5.3.3.2 Prototipagem de GUI

O prottipo de GUI permitiu ao cliente ter uma idia visual do sistema InfoSade.
A idia foi produzir uma interface mais prxima da realidade do usurio, ou seja,
intuitiva, priorizando a simplicidade e a facilidade de uso.

Os primeiros esboos da interface foram produzidos a partir de tcnicas simples,

sem a utilizao de ferramentas grficas. A representao foi feita atravs de
storyboards. Cybis (1997) conceitua que Um storyboard uma seqncia de
desenhos contando uma estria sobre um usurio e a tarefa a ser realizada em uma
determinada unidade de apresentao. A realizao do desenho das principais
telas, como o agendamento de consulta e abertura de pronturio, permitiu que se
realizassem, rapidamente, alguns testes de usabilidade junto ao cliente.

5.3.3.3 Diagramas de caso de uso

Esta atividade consistiu na identificao da funcionalidade do sistema a partir da

atuao dos atores envolvidos. Os casos de uso foram estruturados em
agrupamentos lgicos em funo dos atores, representados atravs do diagrama de
casos de uso (ver figura 30 e 31).
ia

ia
on

on
is

is
0

10
Tr

Tr
eg
eg

Agendamento
si

si
3.
er

er
ed

d
nr

nr

re
lV

lV
EA
-U

-U
er

te

Cadastra
ia

ia
on

on
st

is

Paciente
0

10
Tr

Tr
gi

eg
si

si
e

3.
er

er
ed

d
nr

nr

re
lV

lV

Agenda
EA
-U

-U
er

te

Recepcionista Consulta
ia

ia
on

on
st

is
0

10
Tr

Tr
gi

eg
si

si
e

3.
er

er
ed

d
nr

nr

re
lV

lV
EA
-U

-U
er

te
ia

ia
on

on
st

is

Coordenador
0

10

Configura
Tr

Tr
gi

eg
si

si
e

Agenda
3.
er

er
ed

d
nr

nr

re
lV

lV
EA
-U

-U
er

te
ia

ia
on

on
st

Cadastra
is
0

10
Tr

Tr
gi

eg
si

si

Profissional
e

3.
er

er
ed
ed
nr

nr
lV

lV
EA
-U

-U
er

er
ia

ia
on

on
st

st
0

10
Tr

Tr
gi

gi
si

si

Figura 30: Diagrama de casos de uso da recepcionista e coordenador

 94

A figura 30 apresenta os casos de uso do recepcionista e do coordenador.

importante destacar que o caso de uso Configura Agenda da figura 30, consiste na
montagem da agenda conforme os horrios e a especialidade do profissional. Desta
forma, viabilizam o procedimento do caso de uso Agenda Consulta. Na figura 31,
pode-se notar uma delimitao chamada de Pronturio Mdico, onde o objetivo foi
representar claramente os casos de uso que fazem parte do pronturio do paciente.
Os casos de uso Atende Paciente e Preenche RAAI fazem parte do atendimento
com um todo. Isso definido pelo ICONIX como sendo a classificao dos casos de
uso em pacotes.

E
10

10
eg re

eg re
re

re
on io
l V al
n

n
t e st e st e st e ste st e st e st e ste st e

t e st e st e st e ste st e st e st e ste st e
Ate n d im e n to P ro n tu rio M d ic o
s
i

i
3.

3.
Tr

Tr
U

U
er

i
i
-

-
d

d
E
10

10
re

re
Ca da s tr a 1
ia
nr

nr
Ate nde
si

i
3.

3.
Cons ulta
Tr

Tr
U

U
er

P a c ie nte

A
i

i
-

-
lV
eg

eg

d
d

on

E
10

10

re
re

ia
nr

nr
si

i
3.

3.
Tr

Tr
U

U
er

Ac om pa nha

A
i

i
-

-
lV
eg

eg
d

d
Ge s ta nte
on

E
10

10
re

re
ia
nr

nr
si

i
3.

3.
Tr

Tr
U

U
er

i
i
-

-
lV

eg
eg

d
on

Re c e ita
10

10
re

re
ia

nr
nr

si

M e dic a m e ntos

i
3.

3.
Tr

Tr
U
U

er

A
i

i
-
-

lV
eg

eg
d

d
on

E
10
10

re

re
ia
nr

nr
si

Cor po Clnic o

i
3.
3.

Infor m a
Tr

Tr
U

U
er

Evolu o
A
i

i
-

-
lV
eg

eg

d
d

on

E
10

10

re
re

ia
nr

nr
si

i
3.

3.
Tr

Tr
U

U
er

A
i

i
-

-
lV
eg

eg
d

d
on

E
10

10

S olic ita Ex a m e
re

re
ia
nr

nr
si

i
3.

3.
Tr

Tr
U

U
er

A
i

i
-

-
lV
eg

eg
d

P r e e nc he
on

E
10

10
re

re
ia
nr

nr

RAAI
si

i
3.

3.
Tr

Tr
U

U
er

Tr a ta De nte s
A
i

i
-

-
lV
eg

eg
d

d
on

E
10

10
re

re
ia
nr

nr
si

i
3.

3.
Tr

Tr
U

U
er
is

is
A
V
d

Figura 31: Diagrama de casos de uso do corpo clnico

5.3.3.4 Requisitos Funcionais

Como apresentado na seo 4.8, no ICONIX, os requisitos e os casos de uso so

conceitos distintos, existindo uma relao de muito para muitos entre si. Alm de
realizar a associao entre requisitos e casos de uso. Robertson (1999) enfatiza que
os requisitos so coisas a descobrir antes de comear a construir um produto.
Desta forma, foi elaborada uma lista de requisitos funcionais. A figura 32 apresenta
uma viso parcial desta lista.
 95

d
n

n
e

e
re

re
EA

EA

EA
-U

-U
lV

lV
RF-001 O sistema deve permitir que um usurio RF-002 O sistema deve permitir alterar o n que

te

te
ia

ia
possa efetuar o login no sistema. identifica o pronturio do paciente pelo nmero do

is
is

on

on
10

10

10
Tr

Tr
eg
eg
carto SUS. Deve guardar o antigo n de pronturio

si

si
3.

3.
3.

nr
nr

d
er

er
EA

EA
EA

re
re

-U
-U

lV

lV
te

te
RF-003 O sistema deve permitir que o do paciente RF-004 O sistema deve permitir escolher uma

ia

ia
is

is
on

on
10

10
10

possa fazer parte de um ou mais programa (capital especialidade para o profissional. Para cada

Tr

Tr
eg
eg

si

si
3.

3.
3.

criana, sispr-natal, cesta bsica) especialidade definido a durao da consulta.

nr

nr
d

d
er

er
re

re

EA
EA
EA

-U

-U
lV

lV
te

te
RF-005 O sistema deve montar a agenda com base

ia

ia
RF-006 O sistema deve permitir marcar a consulta
is

is
n

n
10

10
10

Tr
Tr

io

io
eg

eg
na nos horrios de cada profissionais e na durao visualizando os dias, horrios, vagas disponveis
3.

3.
3.

rs
rs
nr

nr
d

d
da consulta, conforme a especialidade. para cada profissional e as j agendadas.
Ve

Ve
EA

EA
re

EA

re
-U

-U

te
te

l
ia

ia
is
is

on

on
10

10
10

RF-007 O sistema deve garantir que os dados da RF-008 O sistema deve permitir somente incluir
Tr

Tr
eg
eg

si

si
3.

3.
3.

primeira consulta no sero alterados. Fica como dados da evoluo do paciente. No pode ter
nr

nr
ed

ed

er
er

EA
EA

EA
histrico do paciente. alterao nem excluso de dados.
-U

-U
lV

lV
er

er
t
t

ia

ia
is

is
n

n
10

10

10
Tr

Tr
io

io
eg

eg
RF-008 O sistema deve ter de informaes para RF-009 O sistema deve incluir, para cada consulta
3.

3.

3.
rs
rs
nr

nr
d

d
paciente gestacionais. Com estes dados deve ginecolgica, uma nova ficha de acompanhamento
Ve

Ve
EA

EA

EA
re

re
-U

-U
gerar o grfico da curva uterina e do heredrograma. clnico, ou contracepo, ou preveno.
te

te
l

l
ia

ia
is

is

on
on
10

10

10
Tr
Tr

eg
eg

si
si
3.

3.

3.
RF-010 O sistema deve controlar todas as vacinas RF-011 O sistema deve disponibilizar ao corpo
nr

nr
ed

ed

er
er
EA

EA

EA
aplicadas em adultos e em crianas e registrar se clnico a consulta dos exames laboratoriais para
-U

-U

lV
lV
er

er
de campanha ou de rotina. emitir a requisio de solicitao.

t
t

ia
ia
is

is
on

on
10

10

10
Tr
Tr

eg
eg

si

si
3.

3.

3.
nr
nr

d
d

er

er
RF-012 O sistema deve controlar a solicitao de

re
EA

re

EA

EA
RF-013 O sistema deve disponibilizar para o
-U
-U

lV

lV
te
te

medicamento, atravs do receiturio, e a entrega paciente somente um odontograma, mas vrios

ia

ia
is
is

n
10

10

10
dos mesmos na farmcia. fichas de tratamento.

Tr
Tr

io

io
eg
eg
3.

3.

3.
rs

rs
nr

nr
d

d
Ve

Ve
EA

EA

EA
re

re
U

Figura 32: Lista de requisitos funcionais

5.3.4 Projeto preliminar

Nesta etapa, a primeira atividade consistiu em detalhar os casos de uso, que

foram identificados anteriormente. Para tal, foram descritos textualmente todos os
cenrios correspondentes a cada caso de uso, sendo em geral contemplados os
cenrios do fluxo principal, alternativo e de exceo.

A principal sugesto do ICONIX, nesta atividade, que no se deve perder muito

tempo com descrio textual. Entretanto, se deve usar um estilo consistente que
seja adequado ao contexto do projeto (SILVA & VIDEIRA, 2001).

Ser apresentado, como exemplo, a descrio textual de um caso de uso, que

pode ser visualizado na figura 33. A formatao deste modelo, foi resultado da
compilao de vrios livros (FOWLER, 2000), (LARMAN, 2000) e (KULAK &
GUINEY, 2000), sugesto de profissionais da rea e, experincia da prpria autora.
Tambm utilizado no caso de uso, a especificao da verso, para o controle de
verses.
 96

Verso: 2.0 Fase: Anlise Autor(es): Decka Cortese Data Criao: 19/10/2001 17:02
Cristina Bona Data Atualizao: 26/12/2002 21:04
USE CASE UC-008 Configura Agenda

Configura
Agenda

Breve Descrio Configurar a agenda do profissional conforme o horrio de trabalho no posto de

sade
Ator Coordenador
Pr-condies A especialidade que o profissional pertence deve possuir agenda.
Fluxo Principal 1. O sistema apresenta uma tela para informar o Profissional e as opes de incluir,
remover ou editar um horrio de trabalho.
2. O coordenador informa o cdigo do profissional e seleciona a edio.
3. O sistema apresenta uma tela de manipulao dos horrios, com a seleo de
data de incio e fim.
4. O coordenador preenche os horrios que o profissional selecionado estar
disponvel ou no, e solicita a gravao.
5. O sistema valida as informaes.
6. O sistema grava as informaes fornecidas pelo coordenador.
Fluxos Alternativos e No item 2, o coordenador pode solicitar a busca de um profissional ou pode
Excees preencher parcialmente um cdigo:
2.1 O sistema apresenta uma tela de busca.
2.2 O coordenador preenche o cdigo ou o nome (pode ser parcial) e confirma.
2.3 O sistema busca os profissionais de acordo com as informaes fornecidas e
mostra o resultado na prpria tela de busca.
2.4 O coordenador seleciona o profissional e vai para o passo 3.
No item 2, o coordenador pode optar pela excluso
No item 2, o coordenador pode optar pela incluso
A qualquer momento o Coordenador pode cancelar a operao e retornar ao passo 1.
Ps-condies Montar a agenda de atendimento do profissional.
Pendncias
Fonte ou documentos Diretor de planejamento: Silvio
relacionados Modelo de Agenda utilizada no posto. Anexo 12.
Regras de negcio A data de fim somente deve ser preenchida se o perodo de configurao do trabalho
por tempo determinado.
O tipo de horrio deve ser marcado com uma das opes.
1. Normal: horrio padro de trabalho. Enquanto for o horrio vlido no deve
possuir data de fim. Tem prioridade 0 (zero), ou seja, se existir outro registro
com outro tipo de horrio, estes vo prevalecer.
2. Frias: perodo de frias. Tem prioridade 1 (um), vai sobrepor o Normal. No
item 4 se o tipo de horrio for marcado como Frias, dever apresentar na agenda
para cada dia de frias a informao Frias, destacado em vermelho. No deve
mostrar os horrios das consultas.
3. Outros: horrio de exceo. Por exemplo: Licena, folga, etc. Deve ter horrio de
incio e fim, se no for informado o horrio de fim vai ficar valendo este horrio
como padro. Pode se Tem prioridade 2 (dois), sobrepe o Normal e Frias.
Deve ser informado para cada dia da semana se o profissional trabalha e qual o
horrio de inicio e fim do turno da manh e da tarde.

Figura 33: Modelo textual de caso de uso do InfoSade

 97

A segunda atividade desta etapa, foi ilustrar graficamente as interaes entre os

objetos participantes do caso de uso, atravs do diagrama de robustez. No projeto
do InfoSade, foram realizados diagrama de robustez somente para os casos de uso
que a o time sentiu necessidade de validar a descrio textual com a especificao
do comportamento dos objetos. Na figura 34, apresentado um exemplo do
diagrama de robustez do caso de uso Configura Agenda, mostrado na figura 33.
eg

eg
1

1
T

T
si

si
3.

3.

3.
d
d
nr

nr
er

er
re
re
EA

EA

EA
-U

-U

-U
lV

lV
te
te

ia
is
is

on
10

10
10
i

io
Tr

Tr
eg
eg

si
rs
3.

3.

3.
d

d
nr
nr

er
e
re

re
EA

EA

EA
-U
-U

-U
lV

lV
te

te
ia

ia
is

is
n

on
10

10

10
:TelaSeleoProfissional :LocalizadorProfissional :Profissional
io
Tr

Tr
eg

eg

si
rs
3.

3.

3.
d

d
nr

nr

er
e
re

re
EA

EA

EA
-U

-U

-U
lV

lV
te

te
ia

ia
is

is
n

on
10

10

10
io
Tr

Tr
eg

eg

si
rs
3.

3.

3.
Coordenador
d

d
nr

nr

er
Ve
re

re
EA

EA

EA
-U

-U

-U
lV
te

te
al

ia
is

on
n

10
10

10
i

gi
io
Tr

Tr
eg

si
e
rs

3.
3.

3.
:GerenteConfigAgenda

d
d
nr

nr

er
Ve

e
re
EA

EA

EA
-U

-U

-U
lV
er
te

al

st

ia
is

n
:TelaCadastroHorrio

10
10

10
i

i
io

io
Tr

Tr
eg

eg

:HorrioDisponvel
rs

rs
3.

3.

3.
d
d
nr

nr
Ve

Ve
re
re
EA

EA

EA
-U

-U

-U
te

te
al

al

Figura 34: Diagrama de robustez do caso de uso Configura Agenda

Posteriormente realizao dos diagramas de robustez, foi atualizado o

diagrama de domnio. Alm das classes j definidas, foram descobertas novas
classes como LocalizadorProfissional e GerenteConfigAgenda. Tambm foram
descobertos atributos e includos no diagrama de classe (domnio). A representao
detalhada do diagrama de classe poder ser visualizada na seo seguinte.

5.3.5 Projeto detalhado

O principal objetivo desta fase especificar o comportamento detalhado do

sistema, atravs da construo o diagrama de seqncia e atualizao do modelo
esttico. Para a realizao desta atividade, necessrio considerar a infra-estrutura
computacional e a tecnologia de desenvolvimento envolvida, que foi apresentada
anteriormente na seo 5.1.1.

No projeto preliminar, o comportamento de um caso de uso foi especificado

atravs do diagrama de robustez. Nesta fase, a primeira atividade foi especificar o
 EA EA EA EA EA EA EA EA EA EA EA EA EA EA EA
3 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3.
10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U
nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr

:Coordenador
eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg
is is is is is is is is is is is is is is is i
te te te te te te te te te te te te te te te
re re re re re re re re re re re re re re re
d d d d d d d d d d d d d d d

EditaClick()
ConfirmaClick()
Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr
ia ia ia ia ia ia ia ia ia ia ia ia ia ia ia
lV lV lV lV lV lV lV lV lV lV lV lV lV lV lV
er er er er er er er er er er er er er er er
si si si si si si si si si si si si si si si si
on on on on on on on on on on on on on on on o :TelaSeleoProfissional

Show()
Edita()
Refresh()
SetDados(Dados)
BuscaProfiss(CodProf)

EA EA EA EA EA EA EA EA EA EA EA EA EA EA EA
3 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3.
10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U
:GerenteConfigAgenda

nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr
eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg
i

ValidaHorario()
is is is is is is is is is is is is is is is
te te te te te te te te te te te te te te te
re re re re re re re re re re re re re re re
d d d d d d d d d d d d d d d

MontaTelaCadHor()

SalvaClick()
Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr
OBJETO Profissional

ia ia ia ia ia ia ia ia ia ia ia ia ia ia ia
LocalizaProfiss(CodProf)

lV lV lV lV lV lV lV lV lV lV lV lV lV lV lV
er er er er er er er er er er er er er er er
si si si si si si si si si si si si si si si si
o

[Horarios Ok]:Salva()
on on on on on on on on on on on on on on on
GetHorariosDisponiveis()

LISTA OBJETOS HorarioDisponivel

:LocalizadorProfissional

ESTADO do Horario

[Horarios Ok]:SetHorariosDisponiveis(Dados)
Show()

Salva(Dados)
*[para cada horrioDisponvel]:GetDados()

EA EA EA EA EA EA EA EA EA EA EA EA EA EA EA
:Profissional

3 3. 3. 3. 3. 3. 3. 3.3. 3. 3. 3. 3. 3. 3. 3.
10 10 10 10 10 10 10 10
10 10 10 10 10 10 10 10
-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U
nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr
eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg
is is is is is is is is is is is is is is is i
te te te te te te te te te te te te te te te
:HorrioDisponvel

re re re re re re re re re re re re re re re
d d d d d d d d d d d d d d d
Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr Tr
ia ia ia ia ia ia ia ia ia i al ia ia ia ia ia
l l l l l
ilustra o diagrama de seqncia relativo ao caso de uso Configura Agenda.

lV lV lV lV lV lV lV lV lV Ve Ve Ve Ve Ve Ve
er er er er er er er er er rs rs rs rs rs rs

Figura 35: Diagrama de seqncia do caso de uso Configura Agenda

si
on
si
on
si
on
si
on
si
on
si
on
si
on
si
on
si
on
si
on i on ion i on i on ion io

simplicidade e facilidade de leitura no se introduziu todas as classes identificadas.

:TelaCadastroHorrio

sua vez, identificaram as operaes que fazem parte das classes correspondentes.
A atividade seguinte construo do diagrama de seqncia, foi o trmino do

A figura 36 apresenta parte do diagrama de classe do InfoSade. Por motivos de

98

detalhadas, baseado nos diagramas de seqncia que foram desenvolvidos, que por
evidenciar o fluxo de mensagens trocadas entre os objetos e os atores. A figura 35
comportamento detalhado atravs do diagrama de seqncia. Pois, o objetivo

modelo esttico. Para isso, o diagrama de classe foi atualizado com informaes
 99

A definio e utilizao de padres de projeto tambm faz parte desta fase final
do projeto do diagrama de classe. Fernandes & Lisboa (2001) destacam que o
grande atrativo da utilizao de padres de projetos, permitir a reutilizao de
solues previamente encontradas. Uma vez que, documentam um problema, suas
caractersticas e solues. Mais informaes sobre padres de projeto pode ser
encontradas em (GAMMA et al, 1995), (LARMAN, 2000) e (APPLETON, 2000).
A

A
3.

3.

3.
M e dic a m e nto
Es pe c ia lida de P e s s oa
10

10
10
P r im e ir a Cons ulta
E

E
A

A
-

-
-
- C o d ig o : in t
- C o d ig o : in te g e r - N o m e : s trin g
U

U
3.

3.

3.
- N o m e : s trin g
nr

nr

nr
- N o m e : s trin g - D a ta : d a te
10

10

10
e

e
E

E
+ G e tN o m e () : s trin g
gi

gi

gi
A

A
-

-
-
+ G e tC o d ig o () : in te g e r + G e tD a ta () : d a te
st

st

st
+ G e tC o d ig o () : in te g e r
U

U
3.

3.

3.
te m + G e tN o m e () : s trin g
er

er

er
nr

+ S a lva () : vo id

nr
nr
+ G e tN o m e () : s trin g
10

10
10
ed

ed

ed
e

e
+ G e tQ td a d e () : in te g e r
E

E
gi

gi

gi
A
A

A
-

-
Tr

Tr

Tr
st

Evolu o

st

st
re ce ita d o p a ra
U

U
P r ofis s iona l fe ita e m
3.
3.

3.
er

er

er
ia

ia

ia
nr

nr

nr
10

10

10
l V al V al V al V al V al V al V al V al V al V al V al V

l V al V al V al V al V al V al V al V al V al V al V al V

l V al V al V al V al V al V al V al V al V al V al V al V
ed

ed

ed
e
e

e
E

E
gi - D e s crica o : s trin g
gi

gi
- C o d P ro f: in te g e r
A

A
P a c ie nte
-

-
-
er

er
Tr

Tr

Tr
st

st
st

- P e s o : in t
U

U
U
3.

3.

3.
si

si
er

er

er
i

i
nr

nr
nr

- Altu ra : in t
o n io n io n io n io n io n io n io n io n io n io n

on
10
10

10
+ G e tC o d P ro f() : in te g e r
ed

ed

ed
- C a rta o S U S : in te g e r
e

e
E

E
- P A: in t
gi

gi

gi
+ G e tN o m e () : s trin g p e rte n ce
A

A
-

-
er

er
Tr

Tr

Tr
st

st

st
U

U
+ G e tE s p e cia liza ca o () : s trin g
3.

3.

3.
s

si
+ G e tC a rta o S U S () : in te g e r

er
er

er
i

i
nr

nr

nr
+ G e tD e s c rica o () : s trin g

on
10

10
10

ed
ed

ed

+ G e tN o m e () : s trin g
e

e
E

E
+ S a lva Atu a l() : vo id
gi

gi

gi
A
A

A
-

-
er

er

Tr
Tr

Tr
st

st

st
+ In clu i() : vo id
U

U
3.
3.

3.
s

Loc a liza dor P r ofis s iona l

si
er

er

er

i
i

i
nr

nr

nr
re a liza d a p o r on + E d ita Atu a l() : vo id
10

10

10
fe ita e m u m
ed

ed

ed
e
e

e
E

E
gi
gi

gi
A

A
-

-
-
er

er
Tr

Tr

Tr
st

st
st

+ Fin d P ro fis s B yC o d P ro f() : co lle c tio n

U

U
U
3.

3.

3.
s

si

Cons ulta
er

er

er
i

i
nr

nr
nr

+ Fin d P ro fis s B yN o m e () : co lle ctio n Hor a r ioDis ponive l

on
10

10
10
ed

ed

ed
e

e
E

E
gi

gi

gi
A

A
-

-
er

er

- C o d ig o : in te g e r
Tr

Tr

Tr
st

st

st
- C o d ig o : in te g e r
U

U
3.

3.

3.
s

si

TipoAge nda m e nto

er
er

er

- D a ta : d a te
i

i
nr

nr

nr
- D a ta In icio : d a te
on
10

10
10

ed
ed

ed
e

e
E

Ge r e nte ConfAge nda - D a ta Fim : d a te E

gi

gi

gi
A

A
-

-
-

+ G e tC o d ig o () : in te g e r
er

er

- C o d ig o : in te g e r

Tr
Tr
Tr
st

st

st
U

U
U
3.

3.

3.
si
s

+ G e tD a ta () : d a te
er

er

er
- D e s c ri o : s trin g
i

i
nr

nr
nr

+ G e tC o d ig o () : in te g e r
on
10

10

+ L o ca liza P ro fis s () : vo id 10
ed

ed

ed
e

e
e
E

+ G e tD a ta In ic io () : d a te
gi

gi

gi
A

+ G e tH o ra rio D is p o n ive l() : vo id

-

-
-

+ G e tC o d ig o () : in te g e r
er

er
Tr

Tr

Tr
st

st

st
+ G e tD a ta Fim () : d a te
U
U

p o d e te r U
3.

3.

3.
s

si

+ L is ta H o ra rio D is p o n ive l() : vo id + G e tN o m e () : s trin g

er

er

er
i

i
nr
nr

nr
on
10

10

10
ed

ed

ed
+ Mo n ta Te la C a d H o r() : vo id
e
e

e
E

E
gi
gi

Age nda gi
A

A
-

+ S a lva H o rD is p () : vo id
er

er
Tr

Tr

Tr
st
st

st
U
U

U
3.

3.

3.
s

si

+ In s e re H o rD is p () : vo id
er
er

er
i

i
nr

nr

nr
on
10

10

10

ed
ed

ed
e
e

+ D e le ta H o rD is p () : vo id + G e tH o ra rio D is p o n ive l() : vo id

E

E
gi

gi

gi
A
A

A
-

-
-
er

er

+ Va lid a H o ra rio () : vo id
Tr
Tr
Tr

st

st
st
U

U
3.
3.

3.
s

si
er

er
er

i
nr

nr

nr
on
10

10

10
ed

ed
ed

Te la Age nda m e nto

e

Te la Ca da s tr oHor a r io
E

E
gi

gi

gi
A

A
-

-
-
er

er

Te la S e le c a oP r ofis s iona l
Tr

Tr
Tr
st

st

st
U
U

U
3.

3.

3.
s

si
er

er

er
i

i
i

nr
nr

nr

+ S h o w () : vo id + S h o w () : vo id
on
10

10

10
ed

ed

ed
e
e

e
E

+ In s e re H o ra rio () : vo id + In s e re C o n s u lta () : vo id
gi
gi

gi

+ S h o w () : vo id
A

A
-
-

-
er
er
Tr

Tr

Tr
st

st
st

+ S a lva H o ra rio () : B o o le a n + S a lva C o n s u lta () : vo id

U

U
U

+ B u s ca P ro fis s () : vo id
3.

3.

3.
si
s
er

er

er
i

i
nr

nr
nr

+ D e le ta H o ra rio () : vo id + D e le ta C o n s u lta () : vo id
on
10

10

10

+ S e le cio n a P ro fH o ra () : vo id
ed

ed
ed

e
e
E

E
gi

gi
gi
A

A
-

-
-
er

er
T

T
st

st

st
U

U
3

Figura 36: Diagrama de classe, parcial, do InfoSade

5.3.6 Implementao

O ICONIX considera que a atividade de implementao est fora do seu mbito e

foco de interesse (SILVA & VIDEIRA, 2001). Entretanto, disponibiliza em conjunto
restrito de sugestes. Algumas destas sugestes auxiliaram o time a atribuir
determinadas tarefas e atividades aos diferentes membros da equipe. Como por
exemplo, o ICONIX sugere que:
 100

os casos de uso sejam escritos por pessoas com experincia em desenho de

interface ou por tcnicos com experincia na produo de manuais de
usurio;

os modelos de domnio e diagramas de classe detalhados sejam construdos

por pessoas com experincia em projeto de base de dados;

os programadores de sistema devem pensar em aspectos como desempenho,

segurana, e serem responsveis pelos diagramas de estado e colaborao,
se forem utilizados.

a tarefa de desenho detalhado, em especial o diagrama de seqncia, seja

realizada, ou pelo menos supervisionada, por pessoas com experincia em
modelao OO.

Desta forma, o sistema Infosade foi implementado e testado. Os testes foram

realizados com base nos casos de uso. O resultado dos testes, foram descritos em
arquivos textos que retornavam a equipe de programadores. Os programadores
realizaram as devidas correes e as enviam novamente os testadores. Este ciclo se
repetiu at que o sistema estivesse livre de erros.

5.3.7 Entrega da verso para produo

O InfoSade entrou em produo aps a execuo dos testes e uma

demonstrao do funcionamento para toda a equipe de especialistas de domnio e
usurios finais. Alm disso, foi dado treinamento de utilizao do sistema. As turmas
foram montadas conforme a ao que o usurio ir realizar no sistema. A ao do
usurio, estava quase sempre relacionada ao do ator. Por sua vez, o sistema foi
disponibilizado para produo. Parte da interface pode ser visualizada na figura 37 e
38. A figura 37 o resultado dos artefatos anteriormente detalhados Configura
Agenda. A figura 38 mostra a agenda gerada com base nos dados da configura;ao
da agenda.

Para a incorporao de novos requisitos no InfoSade, uma nova verso

planejada. Ento, o time parte novamente da anlise, projeto, implementao e
teste, ou seja, aplica-se o conceito de processo iterativo e incremental.
 101

Figura 37: Tela de configurao da agenda do InfoSade

Figura 38: Tela de agendamento de consultas do InfoSade

 102

6 ANLISE DOS RESULTADOS

Aplicando-se os passos descritos no item 5.2 e no item 5.3, procedeu-se a

avaliao dos processos XP e ICONIX, com o objetivo produzir subsdios para
abstrair os pontos positivos e negativos. Alm disso, o comportamento dos recursos
de cada processo foi comparado, sendo um dos pontos de destaque deste trabalho.
Tambm foi elaborado um questionrio, em que se procurou indagar alguns pontos
polmicos do XP, e finalmente foi realizada uma entrevista com clientes sobre a
preferncia entre os dois processos.

6.1 Pontos Positivos do XP

Pode-se considerar que XP adequado em projetos onde os clientes no sabem

exatamente por onde iniciar o desenvolvimento e que a probabilidade de mudarem
de idia grande. Uma vez que o software rapidamente produzido e que o projeto
de desenvolvimento recebe feedback rpido, apenas parte do planejamento
realmente perdido. Ento, se o projeto feito para atender as variaes internas e
de requisitos, o XP parece o mais adequado.

Isto encurta o ciclo para entrega de uma verso, sendo uma das foras primrias
do XP. Realmente, isto muito positivo: os clientes vem rapidamente por aquilo
que eles pagaram, embora incompleto, e os desenvolvedores permanecem mais
interessados e na trilha certa. Os desenvolvedores tm mais liberdade para escolher
suas tarefas e para consertar problemas, o que incorpora motivao para o time.

Outra importante caracterstica e que tambm um dos principais slogans do XP

: sempre faa a coisa mais simples que poderia possivelmente funcionar. O
pensamento que Beck (2000) mostra, ao longo do seu livro, que a simplicidade deve
ser sempre maximizada. Percebeu-se que, a busca da simplicidade no sistema GID
trouxe reduo de tempo para o seu trmino, quando comparado a um projeto
complexo. Alm disso, ele tambm fcil de entender e modificar.

A integrao contnua outra idia muito interessante para desenvolver um

projeto. O fato de o XP trabalhar com pequenas verses e que todo o cdigo
 103

testado, d uma viso confortvel de progresso e mantm os desenvolvedores

entusiasmados tendo as tarefas mo.

Beck (2000) argumenta que os testes extensivos e a integrao contnua, so

tarefas que devem ser executadas pelos prprios membros do time. Realmente, este
argumento mantm a entrega da verso do produto simplificada, e os
desenvolvedores podem conhecer todo o sistema.

6.2 Pontos Negativos e Problemas com XP

Um problema importante de implementao com XP que ele um modelo difcil

de ser usado quando se pretende vender servios para outras companhias. Isto fica
evidente quando o cliente deseja um levantamento explcito de requisitos ou, pelo
menos, queira um preo fixo e o tempo de produo estimado. Convencer o cliente a
contratar um servio sem estas informaes muito difcil.

Em relao ao custo de mudanas ser baixo com XP, existem controvrsias.

McBreen (2002), afirma que no existe nenhum dado real, para uma afirmao ou
para a outra, que estime o custo de mudanas em software moderno. Realmente,
estimar o custo de uma mudana de requisitos no fcil porque depende do
impacto que ir refletir no sistema. O XP parece combinar com negcios onde a
mudana de requisitos rpida e emergente, porque esta mudana nova e no
poderia ter sido prevista. A abordagem tradicional provavelmente melhor em
ambientes mais estveis, em que os requisitos so bem conhecidos e a mudana
mais fcil de ser prevista. Por sua vez, quando se olha para custo de mudana,
necessrio olhar tanto para o time de desenvolvedores quanto para a comunidade
de usurios.

A metodologia XP tem uma propenso para tentar convencer por choque. Nega
muitas prticas que foram tentadas por dcadas, algumas consideradas eficientes
como a documentao e o levantamento de requisitos, somente porque o
desenvolvimento de software em geral tem problemas. Entretanto, isto no significa
que tudo o que foi realizado at o momento no funciona.

A anlise do problema, por exemplo, nunca mencionada como algo para ser
realizado. Os clientes devem ter uma boa idia das histrias que eles precisam
 104

escrever inicialmente. Isto poderia ser facilmente contornado com a ajuda do analista
de sistemas, antes de iniciar o processo XP. Mas isto no citado. Somente quando
o cliente j est executando seu papel, ele teria suporte de um desenvolvedor. A
inteno de integrar o cliente no processo, escrevendo histrias, pode exigir muito
esforo do cliente.

Neste contexto, destaca-se tambm o problema da ausncia de uma fase de

engenharia de requisitos mais especfica. Os requisitos no so construdos para
engessar desenvolvedores, mas uma fase na qual o problema continuamente
refletido e refinado, at que uma soluo coerente e simples seja tomada.
importante pensar sobre o problema, especialmente porque se no for gasto uma
poro significativa de tempo antes de iniciar o projeto, a chance de planejar
corretamente para evitar refactoring perdida. Isto no significa dizer que se deva
passar tempo excessivo com requisitos e com planejamento, especialmente se eles
mudam com freqncia. Porm, uma idia global do problema a ser resolvido e um
caminho para a soluo acordados so sempre boas vantagens.

O XP parece ser adequado para projetos onde o ritmo durante o desenvolvimento

rpido. Quando o processo de desenvolvimento amadurece e menos
funcionalidade solicitada, no existe nenhuma especificao sobre como o XP se
comporta em uma manuteno reduzida no desenvolvimento. O XP parece no
suportar projetos em que o desenvolvimento segue um ritmo mais lento.

O problema descrito acima pode no parecer bvio, ento pode-se esclarecer

que, pouca ou nenhuma documentao significa o cdigo e que o conhecimento do
projeto deve estar confiado nas pessoas. Infelizmente, estes recursos no so
sempre confiveis. comum alguns desenvolvedores deixarem o projeto (isto
previsto em XP), mas ocasionalmente todos ou a maioria dos desenvolvedores
deixam o projeto. Ento, como ningum sabe explicar como o cdigo funciona, a
barreira para a entrada de um novo desenvolvedor grande. Porm, se existir
documentao e que esteja corretamente mantida, mesmo que informal, pode ajudar
a reduzir este problema. Esse um problema que o XP evita mencionar.

Boehm (apud Ambler, 2002) mencionou que um projeto documentado ajuda um

perito externo a diagnosticar problemas. Entretanto, Beck (apud Ambler, 2002)
discorda, e expe que um perito externo passa tempo considervel diagnosticando
 105

projetos e acaba incomodando as pessoas como detalhes pouco significativos e no

tcnicos na documentao.

O XP confia muito na possibilidade de aplicar a tcnica de refactoring e retrofitting

(reajustar) no cdigo existente com o objetivo de aumentar a funcionalidade. Isto
pode funcionar se as mudanas forem simples. Mas, muitas vezes se encontram
problemas significativos durante o desenvolvimento e adaptao do cdigo. Em
alguns casos, podem ser encontrados problemas at em mudanas simples. Neste
sentido, destaca-se que simples um valor percebido e no um objetivo, quando o
assunto desenvolvimento de software. Pequenas mudanas podem causar srios
impactos e um planejamento adequado de pr-codificao poderia ajudar a resolver
este problema.

Em relao aos testes, se uma grande parte do projeto exigir implementao de

interface com o usurio, pode ser um problema para os desenvolvedores criarem
testes automatizados. De acordo com Myers & Rosson (apud REIS, 2000), os
estudos mostram que normalmente 50% de todo cdigo dedicado para interfaces
com os usurios. Obviamente, os testes podem ser trabalhados manualmente,
embora mais incmodos. Porm, o XP conta com desenvolvimento orientado por
teste; problemas com teste podem significar desenvolvimento lento.

McBreen (2003) critica a posio de que um bom time XP pelo menos seis
vezes mais produtivo que um time de engenharia de software tradicional. Alm
disso, os programadores do XP so considerados todos profissionais capacitados e
com muita disposio para executar uma tarefa. Realmente, pode-se dizer que
algum no capacitado ou no disposto no deve fazer parte do time. Entretanto,
em algum momento, um desenvolvedor poder passar por uma fase ruim ou no
estar disposto a executar determinada tarefa que lhe foi designada. Em um grupo,
isto comumente pode acontecer. Uma soluo para tarefas que ningum quer, ou
que esto sendo mal executadas realizar uma votao ou criar normas de
negociao. Mas, isto pode gerar conflito com a idia de livre escolha e de
propriedade (ownership) que o XP sugere.

importante observar que a integrao contnua no uma idia que surgiu com
o XP e todos processos modernos que adotam ciclos de vida como o modelo em
 106

espiral, o RAD (Rapid Application Development) ou o modelo iterativo, empregam a

filosofia de integrao contnua.

6.3 Pontos Positivos do ICONIX

O ICONIX adequado a sistemas em que no se descarta anlise e projeto.

Neste contexto, o ICONIX destaca-se, pois apresenta claramente as atividades de
cada fase. Exibe a seqncia de passos que devem ser seguidos e oferece suporte
atravs da abordagem UML (OMG, 2001).

Duas caractersticas importantes do processo consistem na identificao e

representao do modelo de domnio e dos casos de uso. Positivamente, a partir
destes dois modelos tudo se desenrola de forma iterativa e incremental. Pois, cada
caso de uso detalhado atravs de uma descrio textual e com o respectivo
diagrama de robustez. Em seguida, so identificados novos objetos e detalhes, os
quais so incorporados ao diagrama de domnio (verso de alto nvel do diagrama
de classe). Logo aps, se elaboram os diagramas de seqncia, onde se identifica o
comportamento (operaes) dos objetos. Finalmente, as operaes so adicionadas
na verso detalhada e final do diagrama de classe.

Outro ponto positivo do ICONIX ser orientado por casos de uso. Ou seja, pode
haver rastreamento a partir dos casos de uso para qualquer outro artefato gerado no
processo. Os casos de uso so criados especialmente nas fases de concepo e
elaborao, onde 80% deles so identificados (SANTIAGO, 2000). Por sua vez, um
caso de uso mais eficaz quando elaborado do ponto de vista do usurio. Desta
forma, os casos de uso representam o fluxo das aes do usurio e as respostas do
sistema para estas aes. Portanto, o foco deve ser na viso externa do sistema, na
viso que os atores tem dele.

A rastreabilidade, tambm foi avaliada como sendo um ponto positivo no ICONIX.

Pois, em todo o caminho percorrido deve ser traado uma referncia aos requisitos
identificados. Desta forma, a equipe se mantm prxima s necessidades do usurio
e assegura que no vai omitir quaisquer requisitos durante a implementao. A
rastreabilidade chave, pois elucida cada rastro de requisito em um ou mais casos
de uso e, em uma ou mais classes do modelo de domnio e como trabalham juntos.
 107

Neste caso, quando for analisado o choque de propor uma mudana em um

requisito especfico, a rastreabilidade revelar realmente quais elementos do sistema
que podem ser afetados com a mudana.

6.4 Pontos Negativos e Problemas com ICONIX

O ICONIX no sugere explicitamente nenhum diagrama para modelar processo

de negcio na fase preliminar do projeto. Mesmo sendo o ICONIX um processo que
pretende ser prtico e simples, poderia no entanto, se beneficiar do diagrama de
atividades disponvel na UML (OMG, 2001) para modelar processos de negcios.
Da mesma forma que, outros processos igualmente simples e prticos como o
Grapple, abordado por McConnell (apud SILVA & VIDEIRA, 2001) sugere a
utilizao do diagrama de atividades para modelar processos de negcio na fase
preliminar.

Um aspecto crtico de modelagem de casos de uso envolve os fluxos alternativos.

fundamental pensar sobre todos os fluxos alternativos possveis para cada caso
de uso, sempre que possvel. Considerando que o fluxo principal mais fcil de
identificar e escrever, no significa, porm, que o fluxo alternativo deva ser
postergado at que o projeto detalhado seja implantado. De fato, se isto acontecer
pode causar omisses srias nestes pontos, gastando muito tempo para escrever o
fluxo alternativo, frente aos demais artefatos j definidos. Este um cuidado que o
prprio ICONIX ressalta. Quando importantes fluxos alternativos no so
descobertos at a fase de codificao e depurao, o programador responsvel por
escrever o cdigo tender a tratar isto de forma mais conveniente no momento. Isto,
no saudvel para o projeto. Ento, pergunte vrias vezes: Existe alguma coisa
que pode acontecer? Existe outra forma tratamento? Isto est correto? Garanta com
isto um conjunto rico de fluxos alternativos.

Outra caracterstica forte do ICONIX a distino entre requisitos e casos de

uso. Uma desvantagem clara desta posio do ICONIX obrigar a equipe de projeto
identificar e elaborar de uma lista de requisitos, assim como a manter as
associaes entre os requisitos e os casos de uso. Isto requer um esforo adicional
e um acrscimo do volume de trabalho, que poderia ser evitado em um processo
que pretende ser rpido e simples.
 108

6.5 Comparao do XP e do ICONIX

Sero examinados simultaneamente os recursos do processo XP e do ICONIX

para determinar as semelhanas, as diferenas e/ou as relaes entre ambos. A
comparao pode ser visualizada na Tabela 3.

Tabela 3: Comparao dos processos

RECURSO XP ICONIX
Requisitos prprios cartes de histria: no lista de requisitos bem definidos.
especifica formalmente.
Regras de negcio definidas pelo cliente; definidas pelo cliente;
estimadas pelo cliente: escopo, estimadas pelo time: no especifica
prioridade, composio de verso e detalhes.
data das verses.
Regras tcnicas estimadas pelos tcnicos: tempo, no especifica formalmente.
riscos tcnicos, tecnologia.
Papis time especifica. no especifica.
Usurios do sistema no especifica. especifica atravs dos atores.
Cliente deve fazer parte do time (on-site) no precisa fazer parte do time.
Documentao cartes de histria (temporria); lista de requisitos;
direto no cdigo fonte. casos de uso (texto);
diagramas da UML.
Programao em pares. individual.
Refactoring utiliza. no especifica.
Orientado por testes. casos de uso.
Testes testes de unidade (obrigatrio); testes de unidade (sugerido);
testes funcionais (preferencialmente testes de funcionais (no sugere
automatizados). automatizao).
Metfora utiliza no utiliza
Interface no especifica prottipo de GUI
Ciclo de vida iterativo incremental. iterativo incremental.
Diagramas no utiliza. utiliza padro UML:
modelo de domnio;
diagrama de casos de uso;
diagrama de robustez;
diagrama de seqncia;
diagrama de classe.
Fases do processo especifica, mas as fases so confusas: especifica, as fases so claras:
explorao; anlise de requisitos;
planejamento; projeto preliminar;
iterao da primeira verso; projeto detalhado;
produo; implementao.
manuteno.
 109

Tempo estimado especifica nos cartes de histria. no especifica formalmente, mas

Adotar mudana de paradigma.
Nmero de programadores de 2 a 10 programadores.
Implementao o foco do XP, e as atividades que
auxiliam so:
propriedade coletiva;
programao em pares;
histrias do usurio;
refactoring;
testes de unidade.
Definio da arquitetura na fase de explorao.
Foco do processo baseado nas pessoas.
Conhecimento programao OO;
refactoring.
os casos de uso podem ser
pontuados.
procedimento normal.
no especifica limite.
no o foco do ICONIX, mas
apresenta atividades que auxiliam:
ar diagrama de componente (se for
necessrio);
testes de unidade;
testes de integrao;
testes de aceitao do usurio.
antes da fase de anlise de
requisitos.
baseado em artefatos.
programao OO;
UML.

6.6 Questionrio

A partir de um questionrio, foi aplicada uma srie de 6 (seis) perguntas ao grupo

de alunos da Universidade de So Paulo (USP) e aos Professores que ministraram a
disciplina de Laboratrio de Programao Extrema. A proposta da disciplina o
desenvolvimento de um sistema de mdio porte utilizando as tcnicas do XP (mais
informaes podem ser encontradas em http://www.ime.usp.br/~xp/). Tambm foi
aplicado o questionrio ao time da CEFET/SC que utilizou o XP. As questes so
listadas a seguir e o resultado de cada uma representado graficamente nas figuras
39, 40, 41, 42, 43 e 44. Participaram do questionrio 13 (treze) pessoas.

1 Questo - Gosta de programar em par (programao pareada)?

 110

Gosta de programar em pares?

No
31%

Sim
69%

Figura 39: Gosta de programao em pares

Comentrio: existe sempre uma condio, dos prprios programadores, que se o

par bom, a programao pareada agradvel e as experincias podem ser
compartilhadas. Porm, se o par no to capacitado, acaba atrapalhando o fluxo
do trabalho, pois perde-se tempo ensinando ou supervisionando, ou ainda, assume-
se a programao sozinho. Enfim, difcil conseguir um time de programadores com
conhecimento homogneo e disposio para executar as tarefas no mesmo ritmo.

2 Questo: A velocidade de produo da programao em par equivalente

maior que a velocidade da programao individual, ou seja, a dupla produz quase o
dobro que um programador isolado?

Programao em pares produz mais que a isolada?

No
100%

Sim
0%

Figura 40: Velocidade de programao

Comentrio: um argumento dos programadores que, se o critrio for o nmero

de linhas a resposta deve ser no, mas se o critrio for qualidade do software
gerado a resposta deve ser sim. Este um dos pontos mais discutidos entre
defensores e crticos do XP. A programao pareada faz bastante sentido no
 111

contexto do XP, uma vez que a atividade de projeto realizada juntamente com a
atividade de teste. Entretanto, se voc tiver um time de programadores experientes
trabalhando isolados, provvel que a qualidade das linhas de cdigo seja to
aceitvel quando a programao pareada.

3 Questo: O cliente, teve dificuldade em escrever as histrias (story cards)?

Dificuldade em escrever as histrias?

No
62%

Sim
38%

Figura 41: Dificuldade de escrever histrias

Comentrio: quando o cliente tem alguma experincia, mesmo que informal, de

escrever requisitos, as primeiras verses rapidamente so elaboradas, e como XP
recomenda as histrias vo evoluindo com o tempo. Porm, se o cliente no tem
muita noo do que realmente importante estar escrito nas histrias, para que o
desenvolvedor execute seu trabalho, pode exigir um esforo inicial desgastante.

4 Questo: Sentiu necessidade de alguma documentao mais formal, como

diagramas?

Sentiu falta de documentao?

No
8%

Sim
92%

Figura 42: Necessidade de documentao

 112

Comentrios: A necessidade de documentao de projeto foi grande. Para suprir

a carncia, os times acabaram utilizando os diagramas da UML. Na verdade,
construir software sem projeto documentado muito complicado, o mesmo que
retroceder e negar anos de estudo os da engenharia de software.

5 Questo: Voc aplicou tcnica de refatoramento (refactoring) durante a

programao?

Aplicou refactoring ?

No
15%

Sim
85%

Figura 43: Aplicao de refactoring

Comentrios: aplicar a tcnica de refactoring ajudou os grupos melhorarem o

cdigo constantemente. Considerando sempre, pequenas mudanas.

6 Questo: Observando a sistemtica do time, atendeu a prtica de integrao

contnua (o sistema construdo integrado cada vez que uma tarefa completada)?

Atendeu a prtica de integrao contnua?

No
8%

Sim
92%

Figura 44: Aplicao da integrao contnua

 113

Comentrios: os grupos utilizaram ferramentas de controle de verso para

auxiliar esta prtica. Realmente, estas ferramentas ajudam muito, pois pode-se
facilmente atualizar a ltima verso, alm disso, todos sabem quem est
modificando o que. Entretanto, o suo destas ferramentas sempre recomendado,
independentemente do processo adotado.

Alm do questionrio, foram entrevistados 10 (dez) clientes, contratantes de

servios de desenvolvimento de software, sobre a preferncia de trabalharem com
XP ou com ICONIX. Para tanto, foram explanadas as principais caractersticas de
cada processo; do XP foram relatadas as 12 prticas, comentadas anteriormente na
seo 3.3; e do ICONIX foram explanadas as tarefas e os marcos, discutido
anteriormente na seo 4.2. O resultado pode ser visualizado na figura 45.

Preferncia dos clientes

ICONIX
90%

XP
10%

Figura 45: Preferncia dos clientes entre o XP e o ICONIX

Comentrios: Quando so expostas as caractersticas como, pouca ou nenhuma

documentao, cliente on-site e escrevendo histrias, a rejeio e desconfiana no
processo so grandes. Talvez por ser uma mudana de paradigma muito grande e
ainda ser extremamente recente se comparado ao tempo de existncia das
metodologias chamadas de tradicionais. Por sua vez, o ICONIX imprime ao cliente
o aspecto de um trabalho mais profissional, alm de uma transparncia maior no
progresso do desenvolvimento e nas fases bem definidas.
 114

6.7 Consideraes Finais

No decorrer deste captulo, foi representado, atravs da especificao dos pontos

positivos e negativos e dos grficos e tabelas, as avaliaes obtidas com a aplicao
dos processos descritos metodologicamente no captulo 5. Pode-se observar que,
ambos os processos podem ser utilizados dependendo das caractersticas exigidas
pelos clientes e dos conhecimentos do time. Entretanto, existe ainda um longo
caminho a ser percorrido em busca do estado da arte para o processo de software.
O captulo seguinte apresenta as concluses, recomendaes e trabalhos futuros.
 115

7 CONCLUSO

Neste trabalho foram apresentadas algumas reflexes fundamentais relativas

importncia do processo de software, principalmente como base para o
levantamento de requisitos, para o planejamento de projeto e para o apoio ao
desenvolvimento. Alm de dar suporte aos especialistas de domnio (clientes) e aos
desenvolvedores (tcnicos) na escolha do processo que melhor se adapta a
necessidade da organizao.

Foram apresentados tambm, os fundamentos tericos do dois processos

aplicados, o XP e o ICONIX, bem como os conceitos relacionados Engenharia de
Software, como as fases do processo, as atividades e os modelos de ciclo de vida.
As metodologias geis foram abordadas como sendo metodologias modernas de
desenvolvimento e como uma reao a modelos extremamente conceituais e a
metodologias monumentais (FOWLER, 2001). Por fim, foi aplicado e demonstrado
o processo XP e o processo ICONIX, mostrando todo o ciclo evolutivo, desde a
concepo at a entrega da primeira verso. Esta aplicao gerou subsdios para
avaliar os processos. Uma vez que, o objetivo foi abstrair os pontos positivos e
negativos e comparar o comportamento dos recursos de cada processo,
contemplando a proposta desta pesquisa.

Adicionalmente, foi elaborado um questionrio, indagando alguns pontos

polmicos do XP. Um ponto importante a destacar que a falta de documentao
prejudica a adoo do XP. Essa necessidade sentida tanto pelos clientes, que
ficam inseguros tendo como documentao somente com o cdigo, quanto pelos
desenvolvedores, que no tem visualizao grfica de projeto. Finalmente, foi
realizada uma entrevista com clientes, contratantes de servio de software, sobre a
preferncia entre os dois processos (ver figura 45). Esse levantamento mostrou
claramente que, 90% dos clientes preferem o ICONIX ao XP. Mais uma vez, a falta
de documentao foi determinante para a escolha do processo. Neste caso, tambm
pode-se considerar que a necessidade do cliente on-site foi um agravante.

Esse trabalho espera ter deixado duas contribuies principais. A primeira delas
est relacionada exemplificao textual e grfica da aplicao dos dois processos.
A aplicao, alm de servir como instrumento de estudo para os acadmicos, pode
 116

ser utilizada como suporte para a tomada de deciso sobre qual processo melhor de
adapta a realidade da empresa ou para a construo de um determinado sistema,
que pretenda empregar o processo XP ou o ICONIX.

A segunda contribuio est relacionada busca constante de um modelo de

processo que possa ser aplicado de forma produtiva em um ambiente de
desenvolvimento de softwares. Uma das barreiras na aplicao de determinadas
metodologias est relacionada ao excesso de recursos e controles que a mesma
requer, pois acaba demandando um tempo excessivo construo e atualizao de
artefatos, gerando custos. Considerando esse tipo de dificuldade, a comunidade de
Engenharia de Software busca alternativas, como s metodologias geis (XP) e as
metodologias prticas ou intermedirias (ICONIX). A definio de um processo ideal,
que seja produtivo e que proporcione garantia de qualidade ao software produzido,
ainda um desafio a ser enfrentado e vencido pelos pesquisadores da Engenharia
de Software. Enfim, existe um longo caminho a ser percorrido na busca do estado da
arte para o processo de software.

7.1 Trabalhos Futuros

Apesar deste trabalho ter alcanado os objetivos propostos, verificou-se que

alguns detalhes e acrscimos podem ser elaborados a partir dos resultados obtidos.
Sendo assim, foram feitas as seguintes recomendaes e propostas de trabalhos
futuros:

Aprofundar a pesquisa, aplicando e avaliando outros processos de software. A

partir desta aplicao, adicionar a avaliao a tabela comparativa de recursos
dos processos, proporcionando novos subsdios;

O teste de unidade foi conceituado e explicado o seu funcionamento. A partir

destas informaes, explorar o uso de teste de unidade automatizado, e
avaliar os resultados;

Pode-se avaliar um conjunto de ferramentas de refactoring fornecendo

procedimentos de utilizao e recursos disponveis;

Elaborar um novo processo de software, baseado na ponderao dos

aspectos que estabeleceram caractersticas de produtividade e qualidade.
 117

O propsito destas recomendaes resumem-se em tornar a avaliao de

processos mais abrangente e com maior potencial de escolha.
 118

REFERNCIAS BIBLIOGRFICAS

AMBLER, Scott W. The Agile Edge: Duking it Out. Software Development.

Canad, v.10, n.7, p.53-55, jul. 2002.

APPLETON, Brad. Patterns and Software: Essential Concepts and Terminology,

fev, 2000. Disponvel em: <http://www.enteract.com/~bradapp/docs/patterns-
intro.html>. Acesso em: 12 ago. 2002.

ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming

Explained: Guia Prtico. Rio de Janeiro: Ed. Campus, 2002.

BECK, Kent. Extreme Programming Explained: Embrace change. Reading,

Massachusetts: Ed. Addison-Wesley, 2000.

BORCA, Oliver. Project Engineering Process, set, 2000. Disponvel em:

http://pst.web.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/IC-
ProjectManagement.pdf>. Acesso em: 29 jul. 2002.

BORILLO, Dante. The ICONIX approach, set, 2000. Disponvel em:

<http://pst.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/iconix.
html>. Acesso em: 09 mai. 2002.

CANTOR, Murray R. Object-Oriented Project Management with UML.

New York: Ed. John Wiley & Sons, 1998. Cap.03, p.93-95.

COCKBURN, Alistair. Crystal Methodologies, 2001. Disponvel em:

<http://crystalmethodologies.org/index.html>. Acesso em: 18 abr. 2002.

CORDEIRO, Marco A. Bate Byte 100 Foco no Processo, ago, 2000. Disponvel
em: <http://www.pr.gov.br/celepar/celepar/batebyte/>. Acesso em: 20 jun. 2002.

CYBIS, Walter. Apostila do LabUtil: Recomendaes para Design Ergonmico de

Interfaces. In: ___. Tcnicas de Projeto. Programa de Ps-graduao em
Engenharia de Produo. Florianpolis: UFSC, 1997. Cap.06, p.73-78.
 119

EVANS, Gary K. Palm-Sized Process Point-of-sale gets agile. Software

Development. Canada, v.9, n.9, p.29-32, set. 2001.

FERNANDES, Acauan P.; LISBOA, Maria L. B. Implementao Reflexiva de um

Padro de Projeto para Recuperao de Estado de Objetos. Revista do CEEI.
Bag, v.5, n.8, p.42-43, ago. 2001.

FOWLER, Martin. Refactoring: Improving the Design of Existing Code. In: ___.
Principles in Refactoring. Massachusetts: Addison-Wesley Longman, 1999.
Cap.02, p.53-71.

FOWLER, Martin. The New Methodology, nov, 2001. Disponvel em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: 18 abr.
2002.

FOWLER, Martin; FOEMMEL, Matthew. Continuous Integration, 2000. Disponvel

em: <http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 09
abr. 2002.

FOWLER, Martin; SCOTT, Kendall. UML Essencial: Um breve guia para a

linguagem-padro de modelagem de objetos. Porto Alegre: Ed. Bookman, 2000.

GAMMA, Erich et al. Design Patterns: Elements of Reusable Object-Oriented

Software. Massachusetts: Addison-Wesley, 1995.

JEFFRIES, Ron. XP Magazine Contents: What is Extreme Programming?.

XProgramming.com an Extreme Programming Resource, nov, 2001.
Disponvel em: <http://www.xprogramming.com/xpmag/index.htm>. Acesso em: 11
mar. 2002.

HIGHSMITH, Jim. Does Agility Work? Software Development. Canad, v.10, n.6,
p.30-36, jun. 2002.

KULAK, Daryl; GUINEY, Eamonn. Use Cases: Requirements in Context. New

York: ACM Press, 2000.
 120

LARMAN, Craig. Utilizando UML e Padres: Uma introduo anlise e ao projeto

orientados a objetos. In: ___. Casos de Uso: Descrevendo Processos. Porto
Alegre: Bookman, 2000. Cap.01, p.66-86.

LEACH, Ronald J. Introduction to Software Engineering. Florida: CRC Press LLC,

2000. Cap.01, p.1-27.

MARTINS, Vidal. Bate Byte 89 - O Processo Unificado de Desenvolvimento de

Software, 1999. Disponvel em: <http://www.pr.gov.br/celepar/celepar/batebyte/>.
Acesso em: 15 jun. 2002.

MCBREEN, Pete. Questioning Extreme Programming. Indianapolis: Ed. Person

Education, 2003.

MICROSOFT. Microsoft Solutions Framework: Solutions Development

Discipline. California, Silicon Valley Campus: Microsoft Corporation, 1996.

OMG. Object Management Group - Unified Modeling Language Specification

(2.0), 2001. Disponvel em: <http://www.omg.org>. Acesso em: 18 jul. 2002.

OSHIRO, Adriane et al. Extreme Programming, um novo modelo de processo

para o desenvolvimento de software, jul, 2001. Disponvel em:
<http://www.icmc.sc.usp.br/~percival/>. Acesso em: 03 abr. 2002.

PASCOAL, Sandro M. et al. Tutorial sobre ciclo de vida dos sistemas, jun, 2001.
Disponvel em: <http://www.inf.cesumar.br/sandro/ciclo_vida.htm>. Acesso em: 30
abr. 2002.

PRESSMAN, Roger. S. Software Engineering: A practitioner's approach. New York:

Ed. McGraw-Hill, 1997. p. 22-53.

REIS, Christian. A commentary on the Extreme Programming development

process, ago, 2000. Disponvel em: <http://www.async.com.br/~kiko/papers/xp/>.
Acesso em: 04 abr. 2002.

REZENDE, Denis A. Engenharia de Software e Sistemas de Informao. Rio de

Janeiro: Brasport, 2002. p.122-151.
 121

ROBERTSON, James & Suzanne. Mastering the Requirements Process. [s.l.] :

ACM Press ; Addison-Wesley, 1999. ISBN 0201 360462.

ROSENBERG, Doug; SCOTT, Kendall. Use Case Driven Object Modeling with
UML: A Practical approach. Massachusetts: Addison-Wesley Longman, 1999.

ROSENBERG, Doug; SCOTT, Kendall. Software Development Online: Give Them

What They Want, jun, 2001. Disponvel em: <http://www.sdmagazine.com/>. Acesso
em: 09 set. 2002.

SANTIAGO, Ricardo M. XPers Perguntas e Respostas, 2000. Disponvel em:

<http://www.xpers.hpg.ig.com.br>. Acesso em: 09 set. 2002.

SCHNEIDER, Ricardo L. Modelagem de Sistemas de Informao II, dez, 1996.

Disponvel em: < http://www.dcc.ufrj.br/~schneide/>. Acesso em: 15 jun. 2002.

SCHWABER, Ken. SCRUM Development Process Advanced Development

Methods, 1997. Disponvel em: <http://jeffsutherland.com/oopsla/schwapub.pdf.>
Acesso em: 19 abr. 2002.

SCHWARTZ, Jonathan I. Construction of software. In: Practical Strategies for

Developing Large Systems. Menlo Park: Ed. Addison-Wesley, 1975.

SEMEGHINI, Jlio. Ncleo Softex Campinas Misso Japo 2001, nov, 2001.
Disponvel em: < http://www.cps.softex.br/relatorio.htm>. Acesso em: 24 jul. 2002.

SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e Ferramentas

Case. Lisboa: Centro Atlntico, 2001.

SILVA, Edna L. da; MENEZES, Estera. Metodologia da Pesquisa e Elaborao de

Dissertao. Florianpolis: Laboratrio de Ensino a Distncia da UFSC, 2001.

SOMMERVILLE, Ian. Software Engineering. Lancaster University, Lancaster: Ed.

Addison-Wesley, 1995. p. 7.

SUTHERLAND, Jeff. SCRUM Software Development Process, jan, 2000.

Disponvel em: <http://jeffsutherland.com/scrum/index.html>. Acesso em: 19 abr.
2002.
 122

THIRY, Marcello. Processo de Desenvolvimento de Software com UML, jun,

2001. Disponvel em: <http://www.eps.ufsc.br/disc/procuml/>. Acesso em: 29 abr.
2002.

ULIANA, Ronie M. SystemMetaphor by Objective Wiki, 2001. Disponvel em:

<http://www.xispe.com.br/wiki/wiki.jsp?topic=SystemMetaphor>. Acesso em: 21 jun.
2002.

XP2002. Extreme Programming Conference, out, 2000. Disponvel em:

<http://www.xp2002.org/.>. Acesso em: 18 abr. 2001.

WAKE, William C. Extreme Programming Explored. Reading, Massachusetts: Ed.

Addison-Wesley, 2002.

WELLS, Don. Extreme Programming: A gentle introduction, 2002. Disponvel em:

<http://www.extremeprogramming.org>. Acesso em: 18 mar. 2002.

WILLIAMS, Laurie et al. IEEE Software Strengthening the Case for Pair
Programming, jul/ago, 2000. Disponvel em:
<http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.pdf>. Acesso em: 25
jun. 2002.

WILLIAMS, Laurie. Pair Programming, an Extreme Programming practice, mar,

2001. Disponvel em: <http://www.pairprogramming.com/>. Acesso em: 24 jun. 2002.

WUESTEFELD, Klaus. Xisp Extreme Programming, 2001. Disponvel em:

<http://www.xispe.com.br/index.html>. Acesso em: 18 mar. 2002.

ZABEU, Sheila B. PC World XP: Bom senso ao extremo, fev, 2002. Disponvel
em: <http://pcworld.terra.com.br/pcw/testes/programacao/0016.html>. Acesso em: 04
jul. 2002.