PONTIFCIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL

FACULDADE DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO








Curso de Mestrado






Desenvolvimento Distribudo
de Software e Processos de
Desenvolvimento de Software






Trabalho Individual II




Rafael Prikladnicki




Orientador
Prof. Dr. Jorge Luis Nicolas Audy




Porto Alegre, 30 de agosto de 2002.
ii










































O que o desenvolvimento de software?
Uma arte, cincia, engenharia ou algo mais como um todo?
Ser que isto importa?
Sim, isto importa, e importa para todos ns.
Nossas aes e os resultados que so gerados podem ser diferentes,
de acordo com a definio que for mais correta.
Ento, a idia principal :
Todos ns precisamos que o nosso software seja desenvolvido
da forma mais rpida possvel e sem erros.
Mas muito mais do que isso,
ns precisamos sempre saber como a nossa equipe
est desenvolvendo ao longo deste caminho.

Alistair Cockburn

iii
SUMRIO
LISTA DE FIGURAS........................................................................................... v
LISTA DE TABELAS.......................................................................................... vi
LISTA DE ABREVIATURAS E SIGLAS...................................................................vii
INTRODUO .................................................................................................. 8
1 Desenvolvimento Distribudo de Software (DDS) ............................................. 10
1.1 Critrios que caracterizam o nvel de DDS................................................ 13
1.1.1 Distncia fsica dos atores ............................................................ 15
1.1.2 Distribuio da Equipe de Desenvolvimento..................................... 17
1.2 Alguns Cenrios de Desenvolvimento Distribudo de Software (DDS) ........... 18
1.2.1 Cenrio 1: Centro de Pesquisa em E-Business DELL/PUCRS............... 19
1.2.2 Cenrio 2: Centro de Desenvolvimento da Oikodomo Brasil ............... 20
1.3 Fatores de Sucesso de Desenvolvimento Distribudo de Software (DDS)....... 21
1.4 Sintetizando a Pesquisa sobre DDS......................................................... 22
2 Os Principais Processos de Desenvolvimento de Software ................................. 26
2.1 A ISO e a IEC ...................................................................................... 26
2.2 Norma ISO/IEC 12.207 (NBR ISO/IEC 12207) .......................................... 27
2.2.1 Os Processos Fundamentais .......................................................... 28
2.2.2 Processos de Apoio...................................................................... 28
2.2.3 Processos Organizacionais ............................................................ 29
2.2.4 Limitaes da NBR ISO/IEC 12207................................................. 30
2.3 Rational Unified Process RUP............................................................... 31
2.3.1 Anlise Crtica............................................................................. 35
2.4 Microsoft Solutions Framework MSF ..................................................... 37
2.4.1 Modelo de Gerncia de Risco do MSF.............................................. 37
2.4.2 Modelo de Equipe do MSF ............................................................. 38
2.4.3 Modelo de Processo do MSF .......................................................... 39
2.4.4 Anlise Crtica............................................................................. 40
iv
2.5 Agile Software Development - ASD......................................................... 42
2.5.1 Anlise Crtica............................................................................. 47
2.6 Extreme Programming XP................................................................... 48
2.6.1 Anlise Crtica............................................................................. 54
3 Anlise Comparativa entre os Processos de Desenvolvimento............................ 56
3.1.1 Definio dos Critrios de Anlise .................................................. 56
3.1.2 Anlise Comparativa .................................................................... 58
CONCLUSES ................................................................................................ 62
REFERNCIAS BIBLIOGRFICAS....................................................................... 64

v
LISTA DE FIGURAS
Figura 1 Mesma localizao Fsica. ................................................................. 15
Figura 2 Distncia Municipal. ......................................................................... 15
Figura 3 Distncia Regional. .......................................................................... 16
Figura 4 Distncia Continental. ...................................................................... 16
Figura 5 Distncia Global. ............................................................................. 17
Figura 6 Distribuio em sub-equipes. ............................................................ 17
Figura 7 Distribuio individual. ..................................................................... 17
Figura 8 Equipe de Desenvolvimento Centralizada. ........................................... 18
Figura 9 Ilustrao do Cenrio 1. ................................................................... 20
Figura 10 - Ilustrao do Cenrio 2. .................................................................. 21
Figura 11 Fatores de Sucesso do DDS............................................................. 21
Figura 12 Os trs atores envolvidos................................................................ 24
Figura 13 Critrios de definio do nvel de distribuio do DDS. ........................ 24
Figura 14 Relao da distncia com os processos de desenvolvimento. ................ 24
Figura 15 Estrutura da NBR ISO/IEC 12207. .................................................... 27
Figura 16 o Rational Unified Process - Fonte: [PRI 02a]..................................... 32
Figura 17 Gerncia de Risco no MSF. .............................................................. 38
Figura 18 Os papis definidos no MSF. ............................................................ 38
Figura 19 O modelo de processo do MSF. ........................................................ 40
Figura 20 Os elementos de um...................................................................... 46
Figura 21 As trs dimenses do escopo de um processo - Fonte: [COC 02] .......... 46
Figura 22 A instncia de um escopo................................................................ 47
Figura 23 As quatro dimenses do XP. ............................................................ 49
Figura 24 O XP visto como um conjunto de peas. ......................................... 50

vi
LISTA DE TABELAS
Tabela 1 Os critrios definidos para a anlise comparativa. ................................ 58
Tabela 2 Anlise comparativa. ....................................................................... 61



vii
LISTA DE ABREVIATURAS E SIGLAS
ACM - Association for Computing Machinery
ASD Agile Software Development
DDS Desenvolvimento Distribudo de Software
IEC International Electrotechnical Commission
ISO International Organization for Standardization
MCS Microsoft Consulting Services
MSF - Microsoft Solutions Framework
NBR Normas Brasileiras
OOPSLA - Object Oriented Programming, Systems, Languages and Applications
PDTSD - Process Support Distributed Team-Based Software Development
RUP Rational Unified Process
TI Tecnologia da Informao
XP Extreme Programming



8
INTRODUO
Hoje em dia, ao mesmo tempo em que a rea da engenharia de software se
desenvolve de uma forma cada vez mais rpida, necessrio desenvolver software de
altssima qualidade. Com o passar dos anos e durante a evoluo desta rea,
interessante observar como alguns dos princpios fundamentais desse
desenvolvimento permanecem os mesmos de 30 anos atrs e como os desafios que os
engenheiros de software encontram hoje so semelhantes aos existentes quando a
engenharia de software ainda engatinhava. Aps 30 anos, ainda temos que nos
esforar para desenvolver softwares confiveis [PET 01].
Neste contexto, percebe-se cada vez mais a necessidade das organizaes
desenvolverem software tendo por base um processo bem definido. De acordo com o
que foi escrito em [PRI 02b], um processo de software representado por um modelo.
Existem diversos modelos na rea de desenvolvimento de software. Sendo assim, as
empresas adotam um determinado modelo como referncia, customizando-o e
adequando este modelo de acordo com a sua realidade. Este modelo deve ser
operacionalizado por meio de uma metodologia, estabelecendo basicamente a
seqncia de atividades existentes e a relao entre elas, incluindo neste contexto os
mtodos e as ferramentas que do suporte ao modelo, procurando sempre a
qualidade total, tanto do processo como do produto final gerado seguindo-se o
processo.
Tambm se verificou em [PRI 02b] que existem diversos problemas e desafios
ainda presentes no processo de desenvolvimento de software. Um dos problemas mais
significativos o planejamento, pois ele o ponto de partida de qualquer atividade
relacionada ao desenvolvimento de software. Considerando os desafios apresentados,
um dos mais significativos envolve o processo de desenvolvimento de software
9
baseado em equipes e ambientes fisicamente distribudos, ou seja, o Desenvolvimento
Distribudo do Software (DDS). Hoje em dia as grandes organizaes esto cada vez
mais distribuindo seus processos de desenvolvimento de software ao redor do mundo,
visando ganhos de produtividade, reduo de custos, diluio de riscos e melhorias na
qualidade. Ou seja, o software est ficando cada vez mais sofisticado, o processo de
desenvolvimento de software est evoluindo de uma forma muito rpida e, alm disso,
se v a necessidade de distribuir o desenvolvimento, trazendo muitos benefcios para
as organizaes.
Por este motivo, o Trabalho Individual II tem como objetivo realizar um estudo
aprofundado sobre o estado da arte do Desenvolvimento Distribudo de Software
(DDS), suas caractersticas e definies, e dos principais modelos de processo de
desenvolvimento de software existentes. Pretende-se analisar os diferentes cenrios
do DDS e descrever e analisar os seguintes modelos de processo:
- o Rational Unified Process (RUP);
- o Microsoft Solutions Framework (MSF);
- o Agile Software Development (ASD);
- o Extreme Programming (XP).
Juntamente com a anlise comparativa, pretende-se verificar que tipo de
suporte cada um destes modelos de processo possui para um desenvolvimento
distribudo de software.
O captulo 1 ir abordar a questo do desenvolvimento distribudo de software,
analisando os diferentes cenrios existentes. O captulo 2 pretende descrever e
analisar os principais modelos de processo de desenvolvimento software, identificando
o estado da arte destes modelos. Por ltimo, o captulo 3 faz uma anlise comparativa
entre os processos analisados no captulo 2, procurando sistematizar esta anlise
atravs de um critrio de comparao previamente definido, e explicado no prprio
captulo.

10
1 Desenvolvimento Distribudo de Software (DDS)
Ao longo dos anos, cada vez mais se percebe que o desenvolvimento de
software nunca foi uma tarefa simples. Conforme foi abordado em [PRI 02b], viu-se
que existe uma srie de problemas e desafios inerentes ao processo de
desenvolvimento de software. Entre os problemas encontrados, os projetos de
software freqentemente apresentam cronogramas atrasados, execuo oramentria
abaixo do previsto e produtos defeituosos. Uma das razes para estas situaes,
especialmente para projetos grandes, est na coordenao das atividades da equipe
de projeto e na manuteno do controle do projeto.
Hoje em dia, gerenciar grandes projetos de desenvolvimento de software tem
se tornado uma tarefa cada vez mais complexa. No apenas por causa do crescimento
dos projetos, mas tambm por que as equipes de projeto vm se distribuindo no
tempo e no espao, inserido no conceito de globalizao que a sociedade tm
vivenciado nos ltimos anos. Isto configura ento o Desenvolvimento Distribudo de
Software (DDS), onde algumas pessoas envolvidas no processo de desenvolvimento
esto fisicamente distantes.
Vrias ferramentas e ambientes tm sido desenvolvidos ao longo dos ltimos
quatro anos para ajudar no controle e coordenao das equipes de desenvolvimento
que esto inseridas neste tipo de ambiente. Muitas destas ferramentas esto focadas
no suporte aos procedimentos de comunicao formal tais como elaborao de
documentos, processos automatizados e outros canais de comunicao no
interativos. Um estudo de caso feito por [KRA 95] concluiu que o desenvolvimento de
software necessita de um suporte extensivo para a comunicao informal e interativa.
Alm disso, viu-se em [PRI 02b] que trabalhar com DDS talvez seja um dos
maiores desafios que o atual ambiente de negcios apresenta do ponto de vista do
11
processo de desenvolvimento de software. Muitas empresas esto distribuindo seu
processo de desenvolvimento de software em pases como ndia e Brasil. Muitas vezes
este processo se d dentro de um mesmo pas, em regies com incentivos fiscais ou
de concentrao de massa crtica em determinadas reas. As empresas buscam
vantagens competitivas em termos de custos, qualidade ou flexibilidade na rea de
desenvolvimento de sistemas [PRI 02], alm de ganhos de produtividade e diluio de
riscos [McC 96]. Neste caso, ao optar por instanciar um ambiente de desenvolvimento
distante fisicamente da sua sede, uma organizao comea a encarar diversos
desafios de adaptao, diferenas culturais, planejamento do trabalho, treinamento da
nova equipe, entre outros. Sendo assim, surgem os conceitos de outsourcing e
offshore outsourcing, e todos os desafios existentes no DDS ganham propores
maiores.
Outsourcing a prtica de contratar uma organizao externa para
desenvolver um sistema, ao invs de desenvolver na sua prpria sede (in-house) [McC
96]. As organizaes que utilizam outsourcing podem se especializar em uma
determinada rea, ter mais desenvolvedores para trabalhar em um determinado
projeto e ter uma grande biblioteca de cdigo reutilizvel. A combinao destes
fatores pode resultar numa significativa reduo no tempo necessrio para
desenvolver um produto. Muitas vezes os custos de desenvolvimento tambm podem
diminuir. Uma das opes do outsourcing que vem se tornando bastante popular ao
longo dos ltimos anos o offshore outsourcing. Organizaes offshore so empresas
que esto localizadas em algum outro pas, e que oferecem custos mais baixos de
desenvolvimento. Alm disso, tambm oferecem uma qualidade que , no mnimo,
equivalente qualidade das organizaes localizadas no prprio pas [McC 96].
O desenvolvimento de ambientes tecnolgicos, modelos e ferramentas para
atuar neste tipo de ambiente um desafio cada vez mais importante, tanto para a
teoria na rea de engenharia de software como para as empresas que enfrentam as
dificuldades criadas por este tipo de ambiente. E por isto que nos ltimos anos
diversos estudos e eventos tm dado uma grande importncia para este assunto.
12
Em 2001, em uma conferncia anual em programao, sistemas, linguagens e
aplicaes orientados a objeto (OOPSLA
1
), promovida pela ACM (Association for
Computing Machinery), um painel com alguns dos principais pesquisadores da rea de
desenvolvimento de software que estavam participando da conferncia apresentou a
seguinte questo: Como possvel ter um desenvolvimento gil se a equipe de
desenvolvimento estiver fisicamente distribuda, cada um trabalhando na sua casa?.
Todos os painelistas foram mais ou menos pela mesma resposta, dizendo "We
wouldn't even try!, ou seja, Ns nunca tentamos! [DAD 02].
Alm disso, neste mesmo painel foram citados alguns pontos relacionados com
a questo apresentada e o cenrio mundial de desenvolvimento de software naquele
momento. O principal ponto discutido foi o de que diversas experincias envolvendo o
desenvolvimento distribudo de software estavam sendo realizadas, mas nenhuma
delas tratava de casos reais, incluindo as presses de prazos, custo e escopo, to
comuns em projetos da rea de software. Eram estudos basicamente acadmicos,
com o objetivo de aproximar os pesquisadores desta nova realidade, permitindo a
ampliao de conhecimento nesta rea. O que se sabia era que o DDS podia se
transformar em um caminho real a ser seguido no futuro. Desde ento, a comunidade
cientfica est desenvolvendo estudos empricos na rea de DDS.
Por este motivo, devido multiplicidade de possibilidades existentes neste
contexto de DDS, neste captulo busca-se identificar os principais critrios que
caracterizam um ambiente distribudo de desenvolvimento de software e seu nvel de
distribuio, alm de identificar cenrios que combinam alguns destes critrios e
ilustram o DDS. Alguns destes critrios j existem, como resultado de trabalhos
publicados em congressos internacionais, como o OOPSLA01 ou ainda o workshop
PDTSD02
2
. Outros critrios foram identificados atravs de um estudo aprofundado da

1
OOPSLA - http://oopsla.acm.org/, ACM - http://www.acm.org.
2
3o International Workshop on Process Support for Distributed Team-Based Software
Development, no 6o World MultiConference on Systemics, Cybernetics and Informatics
(SCI) - http://www.iiisci.org/sci2002.
13
realidade em que as empresas esto inseridas, considerando diversos cenrios
possveis para o DDS.
Estes critrios consideram a existncia de trs atores principais no processo,
tendo papis distintos uns dos outros, cada um com a sua importncia. Estes atores
so:

Equipe de Desenvolvimento
Cliente
Usurio
DD
CC
UU

A equipe de desenvolvimento representa todas as pessoas envolvidas no
desenvolvimento de um determinado projeto, podendo tambm ser formada por um
conjunto de sub-equipes. Esta equipe pode envolver pessoas responsveis pela rea
de negcios, gerncia de projetos, desenvolvimento, testes, controle de qualidade,
responsveis pelo suporte de ferramentas dentro do projeto, entre outros. O cliente
a pessoa fsica ou jurdica que solicitou e contratou o desenvolvimento de um
determinado projeto. O usurio representa as pessoas responsveis por fornecer
todas as informaes necessrias (requisitos) para o correto desenvolvimento do
projeto e so responsveis por utilizar o produto gerado. s vezes, clientes e usurios
podem ser as mesmas pessoas, representando os dois papis simultaneamente.
1.1 Critrios que caracterizam o nvel de DDS
Ao longo deste trabalho [ALT 98], [DAD 02], [EVA 00], [EVA 01], [BIU 02],
[HAY 00] [McC 96] foram encontrados diversos critrios que, envolvendo os atores
acima e combinados nas suas diversas possibilidades, podem caracterizar o nvel de
DDS. Os critrios encontrados so apresentados a seguir:
- Distncia fsica dos atores [DAD 02];
- Distribuio da equipe de desenvolvimento [DAD 02];
- Terceirizao do desenvolvimento [McC 96];
- Diferenas culturais [DAD 02], [EVA 01];
14
- Tamanho do projeto [DAD 02], [EVA 01];
Ao aprofundar-se a anlise referente a estes critrios, concluiu-se que:
- a terceirizao (normalmente citada na literatura como outsourcing) no se
caracteriza especificamente como um critrio de DDS. Diversas empresas tm
utilizado o conceito de outsourcing para representar uma estratgia de negcios onde
uma unidade (subsidiria) da empresa localizada em outro pas ou estado torna-se
responsvel pela atividade envolvendo o processo de desenvolvimento de software.
Neste caso, o outsourcing no envolve uma terceirizao no conceito tradicional, pois
a unidade responsvel pelo desenvolvimento da prpria empresa contratante. So
inmeros os exemplos de organizaes que adotam esta estratgia na rea de
desenvolvimento de software (DELL Computers, Nestl, HP, Bank of Boston, entre
outras). Neste sentido, a questo da terceirizao ser abordada como uma
caracterstica das equipes participantes do processo de desenvolvimento e no como
um critrio de DDS.
- cultura , por definio, um fator multidimensional que pode afetar em
diferentes maneiras a performance de projetos geograficamente distribudos [EVA 01].
As diferenas culturais em um ambiente de DDS surgem das diferenas culturais
entre os membros das equipes e entre os locais fisicamente distantes. Por isso,
diferenas culturais so aspectos importantes para o DDS, pois diversos problemas
podem ser causados por estas diferenas. Apesar de ser um critrio importante, ele
no se aplica para este estudo no sentido de ser um critrio que caracterize a
distribuio. As diferenas culturais so consideradas um fator crtico de sucesso no
processo de DDS.
- o tamanho de um projeto um critrio importante quando se opta pelo
DDS, pois este critrio pode indicar o tamanho da equipe, o volume de documentao
existente e exigido, etc. Mas este critrio tambm no se aplica para este estudo para
efeito de caracterizao do DDS e sim como uma dos fatores que podem levar uma
empresa a optar por um desenvolvimento distribudo, assim como custo ou prazos.
15
Sendo assim, a seguir sero detalhados os critrios julgados convenientes para
esta pesquisa, para efeito de caracterizao de um ambiente de DDS.
1.1.1 Distncia fsica dos atores
A distncia fsica dos atores participantes do processo um critrio utilizado
para definir o quo distantes esto os trs atores envolvidos e suas respectivas reas
de negcio. Para este critrio foram definidas cinco situaes que ajudam a verificar
qual o tipo de distncia fsica existente e suas caractersticas principais. As situaes
para a distncia fsica dos atores esto definidas da seguinte maneira:
- Mesma localizao fsica: esta a situao onde a empresa possui toda a
sua equipe instalada em um mesmo local (sala, prdio, universidade), considerando
todos os atores envolvidos. A figura 1 ilustra esta situao:
D
D
D
D
C
U
DD
D
D
D
C
U

Figura 1 Mesma localizao Fsica.
- Distncia municipal: esta uma situao onde a equipe est localizada
dentro da mesma cidade, estando fisicamente distante no mximo em 50km. Neste
cenrio a equipe pode se reunir quase que diariamente. A figura 2 ilustra esta situao
mostrando uma equipe localizada dentro da cidade de Porto Alegre.
D
C
U
DD
CC
UU

Figura 2 Distncia Municipal.
16
- Distncia Regional: esta situao caracteriza-se por ter a equipe localizada
dentro de um mesmo Estado ou de um mesmo Pas, estando distante entre trs e seis
horas de viagem de avio, em zonas de fuso horrio igual ou vizinho. Nesta situao,
a equipe pode se reunir em curtos intervalos de tempo. A figura 3 ilustra este cenrio,
mostrando uma equipe localizada dentro do estado do Rio Grande do Sul.
DD
CC
UU

Figura 3 Distncia Regional.
- Distncia Continental: esta situao caracteriza-se por ter a equipe
separada dentro de um mesmo continente, onde cada integrante deve estar em uma
zona de fuso horrio de no mximo 4 horas de diferena do outro. Nesta situao j
se torna inconveniente uma reunio com toda a equipe de forma freqente, mas
algumas viagens podem ocorrer. A figura 4 ilustra este cenrio, mostrando uma
equipe de desenvolvimento localizada dentro do continente Europeu.
DD
CC
UU

Figura 4 Distncia Continental.
- Distncia Global: esta situao caracteriza-se por ter a equipe separada,
onde cada integrante est em algum lugar do mundo, de forma que o tempo de uma
viagem para reunir toda a equipe em um lugar comum ultrapassa a durao de 24
horas. Nesta situao, normalmente os membros da equipe se renem por algumas
17
semanas no incio de um projeto. A figura 5 ilustra este cenrio, mostrando uma
equipe distribuda em 3 continentes (Amrica do Norte, Amrica do Sul e sia).
DD
CC
UU

Figura 5 Distncia Global.
1.1.2 Distribuio da Equipe de Desenvolvimento
Ter toda a equipe participante do processo de desenvolvimento de software
(cliente, usurio e equipe de desenvolvimento) distante fisicamente de acordo com
alguma das cinco situaes previstas no item anterior no indica que a equipe de
desenvolvimento esteja distribuda. Sendo assim, um ambiente de desenvolvimento
distribudo de software pode ter a equipe de desenvolvimento estruturada em duas
situaes principais:
- Equipe de desenvolvimento distribuda: esta situao indica que a equipe
de desenvolvimento pode ser distribuda de forma a trabalhar distante fisicamente.
Esta distribuio pode ter cada integrante da equipe distante fisicamente, ou podem
existir subequipes de desenvolvimento que esto distribudas. As figuras 6 e 7 a seguir
ilustram estas possibilidades:
DD DD DD DD

DD
DD
DD
DD

Figura 6 Distribuio em sub-equipes. Figura 7 Distribuio individual.
18
- Equipe de desenvolvimento centralizada: esta situao indica que a
equipe de desenvolvimento estar localizada no mesmo espao fsico, ou seja,
trabalhar sempre fisicamente junta. A figura 8 ilustra a equipe de desenvolvimento
localizada em um mesmo espao fsico.
DD DD
DD DD DD DD
DD DD

Figura 8 Equipe de Desenvolvimento Centralizada.
Cabe salientar que a distribuio da equipe de desenvolvimento no leva em
conta a localizao dos outros atores, cliente e usurio.
1.2 Alguns Cenrios de Desenvolvimento Distribudo de Software (DDS)
Um ambiente para o desenvolvimento distribudo de software (DDS) tem
diversas possibilidades de configurao. Conforme foi apresentado no item 1.1, dois
critrios podem auxiliar na definio do nvel de distribuio existente. Cada critrio
possui um conjunto de situaes, e a combinao de uma determinada situao de
cada critrio indica como a empresa realiza o desenvolvimento de um projeto de
software, considerando os atores envolvidos. Um ambiente DDS pode ser visto sob
duas perspectivas principais:
- Considerando apenas a equipe de desenvolvimento;
- Considerando a equipe de desenvolvimento, clientes e usurios.
O nvel de DDS a ser utilizado no processo de desenvolvimento de software
depende da organizao e do projeto a ser desenvolvido. Este processo de DDS pode
ser implementado internamente na prpria empresa, onde cliente, usurio e equipe de
desenvolvimento so da prpria empresa, ou envolvendo outras empresas, onde os
clientes e os usurios no pertencem empresa que desenvolver o projeto.
Baseando-se nestas perspectivas e nos critrios anteriormente citados, a seguir sero
19
apresentados dois cenrios diferentes, baseados em casos reais, que possuem um
desenvolvimento distribudo de software. O primeiro cenrio corresponde a uma
empresa que possui os trs atores (equipe de desenvolvimento, cliente e usurio) no
seu quadro de funcionrios, cada um na sua rea de negcio. J o segundo cenrio
corresponde a uma empresa que possui apenas uma equipe de desenvolvimento,
sendo que clientes e usurios so atores externos, que contratam o servio de
desenvolvimento de software desta empresa.
Para efeito deste estudo, foram considerados dois centros de desenvolvimento
de software, pertencentes a duas empresas localizadas em Porto Alegre (Dell
Computers e Oikodomo Brasil). Estes centros de desenvolvimento so cenrios reais
de desenvolvimento distribudo de software, cada um com suas caractersticas
especficas. Portanto, foram analisados:
- o Centro de Pesquisa em E-Business DELL/PUCRS;
- o Centro de Desenvolvimento da Oikodomo no Brasil;
1.2.1 Cenrio 1: Centro de Pesquisa em E-Business DELL/PUCRS
Neste cenrio, a empresa DELL Computers possui um centro de pesquisa e
desenvolvimento de software voltado para e-business, sendo responsvel, entre
outras atividades, pelo desenvolvimento dos softwares de e-business corporativos da
empresa, ou seja, sistemas que sero utilizados na prpria empresa (sistemas para
outros setores, automatizao de determinadas atividades, entre outros). Sabendo-se
dos dois critrios definidos no item 1.1, pode-se enquadrar este centro de pesquisa e
desenvolvimento no seguinte cenrio:
Considerando que a empresa possui este centro em Porto Alegre e a sua sede
est localizada nos Estados Unidos, os atores participantes do processo de
desenvolvimento possuem uma distncia continental, onde o cliente e/ou o usurio
podem estar localizados nos Estados Unidos enquanto que a equipe de
desenvolvimento est localizada em Porto Alegre. Alm disso, existe uma
possibilidade de distribuio da equipe de desenvolvimento, visto que o
analista de negcios pode estar nos Estados Unidos, bem como a pessoa responsvel
20
pela instalao do sistema, caso o sistema esteja sendo desenvolvido para ser
utilizado em toda a empresa e sua instalao seja feita na sede, ou seja, nos Estados
Unidos. Por ltimo, alguns integrantes da equipe de desenvolvimento podem ser
terceirizados, sendo contratados para um perodo especfico de tempo, mas estes
integrantes no esto distribudos, estando fisicamente prximos de todo o resto da
equipe. A figura 9 ilustra a configurao deste cenrio de desenvolvimento.
DD
CC UU
DD
DD

Figura 9 Ilustrao do Cenrio 1.
O que se percebe na figura 9 que os atores esto fisicamente distribudos,
mas a equipe de desenvolvimento est localizada no mesmo espao fsico, tendo um
integrante terceirizado.
1.2.2 Cenrio 2: Centro de Desenvolvimento da Oikodomo Brasil
Neste cenrio, a empresa Oikodomo Global Technologies possui um centro de
desenvolvimento de software no Brasil, localizado em Porto Alegre, sendo responsvel
por todo o desenvolvimento de software da empresa num mbito mundial, podendo
desenvolver para qualquer cliente, dentro ou fora da empresa. Sabendo-se dos dois
critrios definidos no item 1.1, pode-se enquadrar este centro de desenvolvimento de
software no seguinte cenrio:
Considerando que a empresa possui este centro de desenvolvimento em Porto
Alegre e a sua sede est localizada nos Estados Unidos, os atores participantes do
processo de desenvolvimento possuem uma distncia continental, onde o cliente e
o usurio esto localizados nos Estados Unidos enquanto que a equipe de
desenvolvimento est localizada em Porto Alegre e tambm nos Estados Unidos,
caracterizando assim a distribuio da equipe de desenvolvimento, visto que o
analista de negcios est nos Estados Unidos, enquanto que os outros integrantes da
equipe de desenvolvimento esto em Porto Alegre. Por ltimo, alguns integrantes da
21
equipe de desenvolvimento podem ser terceirizados, sendo contratados para um
perodo especfico de tempo, mas estes integrantes no esto distribudos, estando
fisicamente prximos de todo o resto da equipe. A figura 10 ilustra como ocorre o
desenvolvimento de um projeto de software dentro desta empresa, neste exemplo
especfico.
DD
CC UU
DD
DD
DD

Figura 10 - Ilustrao do Cenrio 2.
O que se percebe na figura 10 que, alm de os atores estarem fisicamente
distribudos, existe a distribuio da equipe de desenvolvimento, onde existe um
analista de negcios localizado nos Estados Unidos junto com clientes e usurios, e o
restante da equipe de desenvolvimento est localizada em Porto Alegre, tendo esta
equipe ainda um integrante terceirizado.
1.3 Fatores de Sucesso de Desenvolvimento Distribudo de Software (DDS)
A pesquisa realizada com relao identificao dos critrios de DDS [ALT 98],
[DAD 02], [EVA 00], [EVA 01], [BIU 02], [HAY 00], mostrou a existncia de uma srie
de fatores envolvidos no processo. Alguns destes fatores foram utilizados para
caracterizar o DDS e seu nvel de presena (distncia fsica e distribuio da equipe de
desenvolvimento). Outros fatores identificados podem ser considerados como fatores
crticos de sucesso dos processos de DDS. Desta forma, para o sucesso de um projeto
em um ambiente de DDS, identifica-se um conjunto de fatores (figura 11):
DDS
DIFERENAS
CULTURAIS
COORDENAO
COOPERAO
CONFIANA
COMUNICAO

Figura 11 Fatores de Sucesso do DDS
22
- Comunicao: a comunicao em um DDS a chave para o bom andamento
e execuo de um projeto. J a falta de comunicao faz com que as equipes
fisicamente distantes no saibam de informaes bsicas sobre o projeto, sobre a
equipe de projeto, entre outros. Por isso, deve existir um fluxo de informaes gil e
eficaz entre os membros da equipe;
- Confiana: confiana em um DDS de vital importncia para o bom fluxo de
informaes entre as equipes distribudas. Ter confiana ter segurana e firmeza no
trabalho da equipe como um todo, independente de quem faa este trabalho. Por isso,
torna-se essencial a procura de mecanismos que propiciem o estabelecimento de um
clima de confiana nas relaes e aes entre os atores envolvidos;
- Cooperao: cooperao em um DDS significa colaborao da equipe para
um objetivo comum, ou seja, ajudar e pensar como equipe. Por isso, fundamental a
cooperao entre as equipes fisicamente distantes, pois de nada adianta uma boa
coordenao e uma tima comunicao se no existir cooperao entre os membros
das equipes;
- Coordenao: a coordenao em um DDS um fator que visa dispor as
atividades de forma ordenada baseando-se em processos e regras previamente
definidos. Por isso, deve existir um eficiente suporte para a coordenao das
atividades de desenvolvimento;
- Diferenas Culturais: quando se desenvolve software em um cenrio onde
exista o DDS, uma das primeiras atividades deve ser verificar qual o nvel de
diferenas culturais existentes entre as equipes fisicamente distantes, pois s vezes
determinadas aes podem ser mal interpretadas pelo simples fato de ser parte da
cultura de uma equipe e no da outra. Estas diferenas devem ser identificadas e
acomodadas entre os participantes do processo.
1.4 Sintetizando a Pesquisa sobre DDS
A partir da anlise crtica do estudo realizado, buscou-se identificar os critrios
a serem adotados na pesquisa com relao ao DDS visando o futuro do trabalho. Num
23
primeiro momento procurou-se definir situaes onde exista o desenvolvimento
distribudo de software. Sendo assim, chegou-se na seguinte definio:
A caracterizao de um ambiente de Desenvolvimento Distribudo de
Software (DDS) ocorre sempre que pelo menos um dos atores envolvidos (equipe de
desenvolvimento, clientes, usurios) estiver fisicamente distante dos demais.
Ao considerar esta definio para DDS, verificou-se a necessidade de utilizar
uma escala para definir o nvel (grau) da distribuio existente. Verificaram-se
inmeras tentativas de representao, at chegar em uma representao tida como a
mais adequada. Como resultado deste estudo, propem-se os seguintes critrios que
definem o nvel de DDS.
- Distncia fsica inter-atores;
- Distncia fsica intra-atores.
A distncia fsica inter-atores o critrio que, considerando os trs atores
existentes (equipe de desenvolvimento, clientes e usurios), define a distncia fsica
existente entre estes atores. Por outro lado, a distncia fsica intra-atores o
critrio que define a distncia fsica existente dentro de cada equipe de atores (por
exemplo, dentro da equipe de desenvolvimento, ou do conjunto de usurios). Esta
distncia fsica, tanto inter-atores quanto intra-atores pode assumir qualquer uma das
cinco possibilidades existentes no item 1.1.1.
Apesar do DDS j estar caracterizado quando pelo menos um dos atores est
distante fisicamente dos demais, o problema do DDS torna-se crtico somente a partir
do momento que a distncia fsica inter-atores ou intra-atores passa a ser regional.
Isto se deve ao fato de que em uma distncia no mximo municipal, reunies entre
todos os integrantes da equipe so facilmente agendadas e relativamente fcil
seguir um processo de desenvolvimento de software usual, como o RUP, MSF,
Extreme Programming ou o Agile Software Development. J a partir de uma distncia
regional, outros tipos de mecanismos so necessrios para gerenciar as equipes e os
projetos fisicamente distribudos, tais como mecanismos de comunicao,
24
padronizao, alm de outras caractersticas importantes (citadas anteriormente neste
estudo).
Buscando-se uma representao grfica para os critrios que definem o nvel
de distribuio do DDS, prope-se primeiramente, na figura 12, uma representao
para os trs atores envolvidos na definio do nvel de distribuio de DDS.
Clientes Usurios
Equipe de
Desenvolvimento
DD CC UU

Figura 12 Os trs atores envolvidos.
Lodo a seguir, utilizando os atores identificados, a figura 13 representa
graficamente os critrios propostos para definir o nvel de distribuio do DDS (de
distncia fsica inter-atores e distncia fsica intra-atores) e a relao entre eles.
Clientes Equipe de
Desenvolvimento
Usurios
DD CC
UU
Distncia
Legenda
Inter-atores
Intra-atores Intra-atores
Intra-atores

Figura 13 Critrios de definio do nvel de distribuio do DDS.
Considerando a distncia que pode existir inter-atores ou intra-atores e
sabendo-se que o DDS torna-se crtico muitas vezes somente a partir da distncia
regional, possvel relacionar esta distncia com os processos de desenvolvimento
de software existentes hoje em dia, de acordo com a figura 14.
Inexistente
Municipal
Regional
Continental
Global
Processos de Desenvolvimento de Software Usuais
Processos de Desenvolvimento de Software voltado para DDS

Figura 14 Relao da distncia com os processos de desenvolvimento.
25
bom lembrar que os cenrios do item 1.2 ilustram os critrios previamente
definidos, utilizando para isto os atores existentes. Existem muitas outras
possibilidades de configurao para o DDS, e no difcil verificar nas empresas hoje
em dia diversas possibilidades de distribuio do desenvolvimento de software, pois
cada empresa tem suas prprias caractersticas e configura o desenvolvimento da
forma mais alinhada s suas estratgias, seja ele offshore ou no.
Alm disso, difcil encontrar na literatura um material que permita obter
critrios e classificaes genricas para ambientes distribudos. Neste sentido, muita
pesquisa vem sendo feita e muitos autores tm estudado este assunto [EVA 00], [EVA
01], [LAY 00], [HAY 00], mas o que se pode concluir que o desenvolvimento
distribudo de software (DDS) e o desenvolvimento offshore so processos bastante
dinmicos que podem ter inmeras configuraes e diversos cenrios possveis, dentro
de uma mesma empresa ou apenas dentro de uma mesma rea de uma empresa,
dependendo do tamanho desta empresa e dos seus objetivos com este tipo de
configurao.
Neste estudo no se aprofundou a anlise das razes que levam uma
organizao a adotar estratgias de distribuio do seu processo de desenvolvimento
de software. Aspectos como custos, oportunidades estratgicas e polticas
empresariais desempenham relevante papel neste sentido.
Finalmente, existe uma forte tendncia hoje em dia de as empresas
distriburem seu processo de desenvolvimento de software ao redor do mundo,
aproveitando os incentivos fiscais e buscando vantagens competitivas em termos de
custos, flexibilidade, qualidade e produtividade. Mas trabalhar com DDS um grande
desafio do atual ambiente de negcios, e ter mecanismos capazes de gerir e suportar
este tipo de configurao uma linha de pesquisa que est crescendo cada vez mais.
26
2 Os Principais Processos de Desenvolvimento de Software
Como foi descrito em [PRI 02b], no existe um nico processo ou metodologia
de desenvolvimento de software. Podem existir diversos modelos de processo de
desenvolvimento, que por sua vez podem ter diversas metodologias que os
operacionalizam. Por este motivo, neste captulo o objetivo descrever de forma clara
e objetiva alguns dos principais modelos de processos de desenvolvimento de software
existentes atualmente. Uma metodologia pode utilizar-se apenas de algumas partes
de um modelo de processo. Alm disso, prtica comum das empresas de utilizar
contribuies de um conjunto de diferentes metodologias e modelos.
A seguir sero descritos quatro modelos de processo de desenvolvimento de
software: o Rational Unified Process, o Microsoft Solutions Framework, o Agile
Software Development e o Extreme Programming. Mas antes de descrev-los,
considerou-se necessria a descrio de um norma ISO/IEC, a NBR ISO/IEC 12207,
que uma norma para organizar processos de ciclo de vida de software.
2.1 A ISO e a IEC
A ISO (International Organization for Standardization) e a IEC (International
Electrotechnical Commision), juntas, formam um sistema unificado para padronizao
no mbito mundial. Organismos nacionais que so membros da ISO ou da IEC
participam do desenvolvimento de Normas Internacionais atravs de comits tcnicos
criados pela respectiva organizao para tratar de reas especficas de atividades
tcnicas. Comits tcnicos da ISO e da IEC colaboram em campos de interesse mtuo.
Outras organizaes internacionais, governamentais ou no, mantm ligaes com a
ISO e a IEC e tambm participam deste trabalho de padronizao [ISO 02], [IEC 02].
27
2.2 Norma ISO/IEC 12.207 (NBR ISO/IEC 12207)
A NBR ISO/IEC 12207 tem como objetivo organizar processos de ciclo de vida
de software. Esta norma visa estabelecer uma estrutura comum para os processos de
desenvolvimento, sendo uma referncia para a indstria de software. Cabe ressaltar
que esta norma no detalha metodologias, mtricas e mtodos, nem ambientes,
ferramentas e tcnicas utilizadas nos processos. Ela se concentra apenas na definio
e descrio dos processos. Sendo assim, a seguir faz-se uma sntese da NBR ISO/IEC
12207 apresentando como um processo pode e deve ser estruturado [ISO 98].
A NBR ISO/IEC 12207 est dividida em trs conjuntos de processos, como
mostra a figura 15:
- Processos Fundamentais (Primary Processes);
- Processos de Apoio (Supporting Processes);
- Processos Organizacionais (Organizational Processes).
Cada conjunto formado por processos que possuem objetivos comuns que se
destinam a um mesmo fim. Cada processo formado por uma ou vrias atividades.

Figura 15 Estrutura da NBR ISO/IEC 12207.
A seguir ser apresentada uma descrio dos conjuntos de processos.
28
2.2.1 Os Processos Fundamentais
Os Processos Fundamentais visam descrever as partes indispensveis de um
ciclo de vida de software. Em termos gerais, so os processos que tratam desde a
aquisio, passando pelo desenvolvimento, manuteno, at o fornecimento do
software [ISO 98]. Estes processos so divididos em cinco processos menores, citados
logo a seguir:
- Processo de Aquisio (Acquisition): define as atividades e as tarefas de
quem adquire um produto ou servio de software atravs de um contrato.
- Processo de Fornecimento (Supply): define as atividades e as tarefas do
fornecedor de software.
- Processo de Desenvolvimento (Development): define as atividades e
tarefas das pessoas que desenvolvem um software. Isto inclui tanto um novo
desenvolvimento quanto um desenvolvimento em um produto de software j
existente;
- Processo de Operao (Operation): define as atividades e tarefas de um
operador de um sistema de software. O processo cobre a operao de software e o
suporte operacional aos usurios.
- Processo de Manuteno (Maintenance): define as atividades e tarefas
do responsvel pela manuteno de um produto de software, preservando a
integridade do produto existente;
2.2.2 Processos de Apoio
Os Processos Fundamentais, como foi dito anteriormente, so processos
indispensveis, ou seja, sem eles no existe software. Mas geralmente esses
processos necessitam de apoio, que pode ocorrer atravs de um conjunto de outros
processos, com intenes especficas de oferecer suporte para partes distintas dos
Processos Fundamentais. Tais processos so denominados de Processos de Apoio.
Os Processos de Apoio so utilizados por outros processos com o objetivo de
oferecer algum suporte a eles. Eles contribuem essencialmente com a qualidade e o
sucesso do projeto de software e so divididos em oito processos menores, que so:
29
- Processo de Documentao (Documentation): processo definido para
armazenar a informao produzida por um ciclo de processo, incluindo atividades de
planejar, projetar, desenvolver, editar, distribuir e manter todos os documentos;
- Processo de Gerncia de Configurao (Configuration Management):
processo definido para identificar, definir e criar uma linha de base para controlar
modificaes e liberao dos itens contidos em um software;
- Processo de Garantia da Qualidade (Quality Assurance): prov um
framework para garantir a qualidade e a aderncia dos produtos de software com os
seus requisitos e com o plano estabelecido para o desenvolvimento;
- Processo de Verificao (Verification): prov a avaliao de um produto
ou servio de uma atividade qualquer. As verificaes determinam quando os
requisitos de um sistema esto completos e corretos. Tambm indicam quando as
sadas de uma atividade iro satisfazer todos os requisitos ou condies impostas nas
atividades anteriores. Este processo cobre a verificao de processo, requisitos,
projeto, codificao, integrao e documentao;
- Processo de Validao (Validation): a validao determina se o sistema,
ao seu final, esta de acordo com o que foi especificado para o seu uso. A validao
no substitui outras avaliaes;
- Processo de Reviso Conjunta (Joint Review): prov um framework para
interaes entre o revisor e o revisado. As revises ocorrem tanto no nvel gerencial
quanto no nvel tcnico;
- Processo de Auditoria (Audit): prov um framework para uma auditoria
formal nos produtos e servios dos fornecedores;
- Processo de Resoluo de Problema (Problem Resolution): prov o
mecanismo para solucionar problemas e tomar as corretas providncias assim que os
problemas foram detectados.
2.2.3 Processos Organizacionais
Os Processos Fundamentais, alm de necessitarem de apoio para executar as
suas tarefas, tambm precisam ser administrados. Para isto, existem os Processos
30
Organizacionais, cujo objetivo a evoluo da organizao. Os Processos
Organizacionais esto comprometidos com o melhoramento contnuo da estrutura, das
pessoas e dos processos dentro de uma empresa. Estes processos geralmente so
empregados fora dos domnios dos projetos, mas seus ensinamentos podem e
devem contribuir para o melhoramento da organizao como um todo [ISO 98]. Estes
processos so divididos em quatro processos menores, a saber:
- Processo Gerencial (Management): define as atividades genricas e as
tarefas de um gerente, tais como os processos de aquisio, fornecimento, operao,
manuteno ou suporte;
- Processo de Infra-Estrutura (Infrastructure): define as atividades
necessrias para estabelecer e manter uma infra-estrutura base para o ciclo de vida
de software;
- Processo de Melhoria (Improvement): prov as atividades bsicas que
uma organizao necessita para avaliar, medir, controlar, e melhorar o seu ciclo de
vida de software;
- Processo de Treinamento (Training): processo utilizado para identificar e
fazer um plano de treinamento nos nveis tcnico e gerencial para os recursos e
habilidades que necessitam ser treinadas ou melhoradas.
2.2.4 Limitaes da NBR ISO/IEC 12207
A NBR ISO/IEC 12207 no substitui a gerncia e a engenharia disciplinada dos
sistemas de software. Ela apenas prov um framework onde os processos, atividades
e tarefas relacionadas com o software podem ser identificadas, planejadas e aes
podem ser realizadas. Um ponto que deve ser lembrado que a norma apenas
contm um conjunto de blocos bem definidos (processos). A organizao ou a pessoa
que utilizar esta norma deve selecionar e agrupar estes processos, suas atividades e
tarefas de tal modo que seja apropriado e efetivo para a organizao e para o projeto.
31
2.3 Rational Unified Process RUP
O Rational Unified Process (RUP) um framework para processos de
desenvolvimento de software criado por Ivar Jacobson, Grady Booch, James
Rumbaugh, auxiliado por outros nomes importantes, entre eles Philippe Kruchten, em
1998, na Rational Software Corporation
3
. Suas principais caractersticas so um
desenvolvimento iterativo e incremental, orientado a objetos, com foco na criao de
uma arquitetura robusta, anlise de riscos e utilizao de casos de uso para o
desenvolvimento. Ele cobre as seguintes prticas [KRU 00]:
- Processo interativo de desenvolvimento de software;
- Gerenciamento de requisitos;
- Uso de arquiteturas baseadas em componentes;
- Modelagem visual;
- Verificao contnua de qualidade;
- Controle de mudanas;
O RUP foi desenvolvido para ser aplicvel a uma grande classe de projetos
diferentes e pode ser considerado como um framework genrico para modelos de
processos de desenvolvimento. Isso significa que ele deve ser configurado para ser
usado eficientemente. A configurao pode ser feita para empresas (para definir o
processo padro de desenvolvimento da empresa) ou mesmo para projetos especficos
e normalmente envolve a remoo e/ou modificao de atividades do framework,
instanciando assim alguns modelos de processo de desenvolvimento [ALC 02].
O RUP composto por quatro fases bem definidas: concepo (inception),
elaborao (elaboration), construo (construction) e transio (transition),
cada uma com objetivos especficos.
Na fase de concepo deve-se estabelecer o escopo e a viabilidade econmica
do projeto. Na fase de elaborao o objetivo eliminar os principais riscos e
estabelecer uma arquitetura estvel a partir da qual o sistema poder evoluir.

3
Rational Software Corporation http://www.rational.com.
32
Na fase de construo um produto completo desenvolvido de maneira
iterativa at que esteja pronto para ser entregue aos usurios, o que ocorre na fase
de transio, onde uma verso beta do sistema disponibilizada.
No final da fase de transio pode ser iniciado um novo ciclo de
desenvolvimento para a evoluo do produto, o que envolveria todas as fases
novamente. Todas as fases so finalizadas com um milestone (marco) que verifica se
os objetivos da fase foram alcanados.
Cada fase pode comportar vrias iteraes e cada iterao, por sua vez, est
organizada em workflows (figura 16) que descrevem o que deve ser feito em termos
de atividades, responsveis e os artefatos que devem ser gerados, alm do fluxo das
atividades. O RUP fornece modelos (templates) para cada artefato e guias (guidelines)
para a execuo de suas atividades.
As iteraes tambm so finalizadas com milestones, que devem controlar se
foram cumpridos os objetivos especficos da iterao, como a modelagem de um
grupo de casos de uso, por exemplo.

Figura 16 o Rational Unified Process - Fonte: [PRI 02a].
O RUP possui 9 workflows, 6 de engenharia de software e 3 de suporte Os
workflows da engenharia de software so descritos sucintamente a seguir [RAT 98].
- Modelagem do Negcio (Business Modeling): um dos grandes problemas
hoje em dia que a comunidade da engenharia de software e a comunidade da
engenharia de negcios no se comunicam como deviam. Com isso, os requisitos de
negcio no so utilizados corretamente como entrada para o desenvolvimento de um
determinado software. Por isso, a modelagem do negcio envolve o entendimento da
33
estrutura e dinmica da organizao cliente, garantindo que clientes, usurios e
desenvolvedores tenham a mesma viso da organizao para a qual ser feito o
desenvolvimento. Isto feito atravs da documentao dos processos de negcio
utilizando casos de uso de negcio. Mesmo assim, muitos projetos optam por no
fazer a modelagem do negcio;
- Requisitos (Requirements): em linhas gerais, envolve a definio dos
requisitos do sistema e de como gerenciar escopo e mudanas de requisitos. O
objetivo descrever o que o sistema deve fazer e permitir que os desenvolvedores e o
cliente concordem com esta descrio. Para isto so gerados alguns artefatos para
documentar estes requisitos. Os requisitos podem ser funcionais (o que o sistema
deve fazer) e no-funcionais (interface, idioma, etc.). Os requisitos funcionais so
modelados utilizando-se casos de uso, enquanto que os requisitos no-funcionais so
descritor em uma especificao adicional;
- Anlise e Projeto (Analysis and Design): envolve a traduo dos
requisitos numa especificao que descreve como implementar o sistema. Nesta
atividade a linguagem UML utilizada para a modelagem do sistema. Esta atividade
deve ser feita de forma a satisfazer todos os requisitos e permitir uma estrutura
robusta com facilidade para possveis mudanas no futuro. O resultado um modelo
de projeto e opcionalmente um modelo de anlise, que servem como uma abstrao
do cdigo a ser implementado e devem estar centrados na noo de arquitetura do
sistema;
- Implementao (Implementation): envolve o desenvolvimento de cdigo.
O objetivo da implementao definir a organizao do cdigo, organizando os
subsistemas em camadas, alm de implementar as classes, objetos e componentes.
Alm disso, envolve o teste de unidade e o teste de integrao. O RUP trabalha muito
forte com o conceito de componentes e reutilizao, facilitando a manuteno do
sistema;
- Teste (Test): envolve a verificao do sistema como um todo. Devem ser
verificadas as interaes entre os objetos, a integrao entre todos os componentes
34
do software, a conformidade com todos os requisitos especificados e identificar e
assegurar que todos os defeitos encontrados devem ser resolvidos antes de liberar o
software para distribuio. O RUP prope esta atividade de forma iterativa, ou seja, o
teste deve ser feito ao longo de todo o projeto. Isto faz com que os erros sejam
identificados o mais cedo possvel, reduzindo os custos de possveis correes. Alm
disso, testes automatizados devem ser feitos e trs dimenses de qualidade devem
ser consideradas: confiabilidade, funcionalidade e performance;
- Distribuio (Deployment): envolve o empacotamento, distribuio e
instalao do software, alm de um treinamento para os usurios, assim como o
planejamento e conduo de beta testes. Tambm devem ocorrer migraes de dados
existentes em sistemas antigos, alm de ocorrer a aceitao formal por parte do
cliente. Embora quase todas as atividades estejam concentradas na fase de transio,
muitas delas podem e devem ser includas em fases anteriores, para preparar a
distribuio do software assim que acabar o seu desenvolvimento.
Os workflows de suporte compreendem atividades necessrias para a execuo
dos workflows de engenharia de software [RAT 98]. So eles:
- Gerncia de Projeto (Project Management): envolve o gerenciamento de
riscos, planejamento e acompanhamento do projeto. Para isto, o RUP prov um
framework para gerenciar os projetos de forma intensiva, com guias prticos de
planejamento, controle de recursos humanos, execuo e monitoramento dos
projetos;
- Gerncia de Configurao e Mudanas (Configuration and Change
Management): envolve o gerenciamento de todos os artefatos gerados durante o
desenvolvimento do software. Este gerenciamento ajuda a evitar confuses nos
artefatos gerados, bem como alteraes simultneas de um determinado artefato, ou
ainda, evita que sejam geradas mltiplas verses de um artefato ou do prprio
software. Este workflow descreve como se pode gerenciar um desenvolvimento
paralelo, alm de auxiliar na automatizao do processo de construo. Por ltimo,
prov mecanismos para gerncia de mudana, ou seja, como reportar os defeitos
35
encontrados ou alterao de requisitos, gerenci-los ao longo do desenvolvimento e
utilizar estes dados para gerar mtricas e controlar a evoluo do software ao longo
do tempo;
- Configurao do Ambiente (Environment): envolve a organizao do
ambiente de trabalho para a equipe do projeto e a configurao do RUP para o
projeto. A organizao do ambiente de trabalho envolve o suporte ao processo e s
ferramentas que sero utilizadas. Alm disso, este workflow fornece um Development
Kit com guias, modelos e ferramentas necessrias para personalizar o processo.
Aspectos tais como seleo, aquisio e funcionamento das ferramentas e a
manuteno do ambiente de desenvolvimento no so considerados neste workflow.
2.3.1 Anlise Crtica
O Rational Unified Process (RUP) um framework para processos de
desenvolvimento de software que permite a configurao e a instanciao de diversos
modelos de processos. Para ser utilizado, uma tarefa a ser executada justamente a
configurao do que ser utilizado.
Em junho de 2001, Martin Fowler publicou no seu website a sua viso sobre o
RUP. Ele disse que por vrias vezes ouviu as pessoas falarem que utilizavam o RUP
com um ciclo de vida de desenvolvimento tradicional (modelo cascata
4
). Para sua
surpresa, ele sabia que a equipe responsvel pelo RUP, entre eles Philippe Kruchten,
eram totalmente adeptos ao desenvolvimento iterativo e ao ciclo de vida de
desenvolvimento espiral
5
. Por isso, ele acha que os lderes do RUP devem enfatizar as
reais e principais caractersticas deste framework para o desenvolvimento de software,
para ele ser bem aproveitado.
Como vantagens, pode-se dizer que este framework tem sido utilizado por
diversas empresas desde o final de 1999, sendo aplicado em vrios contextos de
aplicaes (e-business, sistemas corporativos, etc.) e em diferentes portes de projeto.
Alem disso, verstil e tem mais de 50% do seu uso focado no e-business e no

4
Definies sobre o ciclo de vida tradicional podem ser encontradas em [PRI 02b].
5
Definies sobre o ciclo de vida espiral podem ser encontradas em [PRI 02b].
36
planejamento [KRU 01]. Hoje em dia um padro de referncia conceitual para as
empresas que trabalham com desenvolvimento de software e utilizado como base
para outros processos, tal como o Microsoft Solutions Framework (MSF), que utiliza
vrios conceitos da RUP dentro do seu processo de desenvolvimento.
Por outro lado, por ser um framework que possui diversas opes de modelos a
serem configurados, um processo que no diz exatamente o que deve ser feito, mas
diz tudo o que pode ser feito. Por este motivo, dependendo da configurao e de como
este framework utilizado, ele pode se transformar tanto num processo que utiliza
um ciclo de vida tradicional (cascata) ou num processo que utiliza um ciclo de vida
espiral. Isto significa que, por um lado o RUP pode se transformar num processo
pesado e seqencial, e por outro lado por ser um processo dinmico e gil. Uma outra
desvantagem que o RUP pode utilizar apenas a linguagem UML para modelar os
sistemas, pois ela faz parte do Processo Unificado, sendo um padro do prprio
framework. Por ltimo, pode-se dizer que o RUP no oferece suporte adequado para
gerncia de comunicao nem para a gerncia de recursos humanos, alm de ser
proprietrio, ou seja, no possvel encontrar, gratuitamente, informaes completas
sobre todas as suas prticas. Existem relatrios e artigos escritos por diversos autores
falando sobre o RUP, mas apenas adquirindo livros ou o prprio software de suporte
ao RUP possvel ter um conhecimento completo, configurar e coloc-lo em prtica.
Concluindo, as empresas que utilizam o RUP precisam saber como absorver
tudo o que ele pode oferecer em termos de desenvolvimento de software, para tornar
os seus modelos de processo condizentes com a realidade em que o mundo atual est
inserido e com os objetivos principais do RUP, que o desenvolvimento iterativo e
incremental. E hoje em dia se torna cada vez mais necessrio que o RUP oferea um
conjunto de atividades que d suporte para o Desenvolvimento Distribudo de
Software, desde o planejamento, passando pela execuo, at a avaliao dos
softwares desenvolvidos pelas empresas. E no RUP, tudo o que existe hoje em relao
ao DDS so apenas observaes e comentrios de alguns autores, mas nenhuma
prtica ou atividade formalizada.
37
2.4 Microsoft Solutions Framework MSF
Originalmente baseado nas best practices (melhores prticas) coletadas do
desenvolvimento de produtos da Microsoft, o Microsoft Solutions Framework foi criado
em 1994 para o Microsoft Consulting Services (MCS) promover a resoluo de
problemas de negcios utilizando-se de solues tcnicas. Devido ao sucesso
conseguido, a Microsoft saiu um pouco da sua misso original e comeou um plano de
desenvolvimento e expanso. Hoje em dia existe um grande grupo que coleta as
melhores prticas dos desenvolvedores, grupos de TI (Tecnologia da Informao),
consultores, clientes e parceiros em todo o mundo. Estas prticas so analisadas e
integradas ao MSF, que hoje formado por conceitos, modelos, prticas e princpios
utilizados pelo MCS, desenvolvedores, parceiros e consultores [MIC 99].
Segundo a Microsoft, a tecnologia no a nica pea em uma soluo de
sucesso. Pessoas, processos e a gerncia de risco tm um papel importante no
sucesso de um projeto, e so estes os trs fatores considerados mais importantes
dentro do MSF. Alm disso, trabalhar e ter uma comunicao efetiva, alinhando as
solues tcnicas com os requisitos de negcio so fatores crticos para o sucesso e
so as vezes os mais difceis de se alcanar [MIC 99].
A partir dos trs fatores citados anteriormente, a seguir sero detalhados os
modelos correspondentes a cada um destes fatores, que so considerados a base
deste framework de desenvolvimento de software proposto pela Microsoft. Estes
modelos procuram dar uma viso das melhores prticas com relao gerncia de
pessoal, gerncia de riscos, processos e tecnologia.
2.4.1 Modelo de Gerncia de Risco do MSF
O MSF identifica as seguintes caractersticas em um risco:
- O risco inerente em todo o projeto, est sempre presente como uma
possibilidade de acontecer, nunca como uma certeza;
- O risco no nem ruim nem bom, e no algo a ser evitado. apenas uma
oportunidade identificada;
38
- O risco no algo para se ter medo, mas sim algo para ser gerenciado,
minimizando as incertezas e criando solues para cada risco identificado.
O modelo de gerncia de risco do MSF utiliza trs estratgias para gerenciar o
risco: reduo do risco, transferir o risco e prevenir o risco. Alm disto, este modelo
possui cinco passos onde a equipe capaz de identificar os riscos e decidir pela
melhor ao (figura 17).
Identificar Analisar
Controlar Planejar
Monitorar
Documento
de avaliao
de riscos
os 10+
Documento
de avaliao
de riscos
os 10+
Riscos
Identificados
1 2
3
4
5
Riscos
Liberados
Este processo gera um documento de avaliao de
riscos que constantemente atualizado
Este processo gera um documento de avaliao de
riscos que constantemente atualizado

Figura 17 Gerncia de Risco no MSF.
A figura 17 mostra os cinco passos propostos pelo MSF para gerenciar os riscos
de um projeto. Aps serem identificados, os riscos so transformados em informao
que podem ser analisadas pelos integrantes da equipe com objetivo de tomar algumas
decises. Depois feito um planejamento para suportar as decises tomadas no passo
anterior, para ento monitorar os riscos e passar a control-lo.
2.4.2 Modelo de Equipe do MSF
O modelo de equipe do MSF composto por equipes pequenas e disciplinadas,
onde cada membro tem o seu papel e suas responsabilidades bem definidas. Existem
seis papis neste modelo (figura 18) e a chave para que este modelo funcione a
comunicao [MIC 99].
Gerncia de
Projeto
Gerncia de
Logstica
Gerncia de
Produto
Educao do
Usurio
Desenvolvimento
Teste
Comunicao

Figura 18 Os papis definidos no MSF.
39
Este modelo possibilita que as equipes de projeto sejam flexveis e escalveis,
para todos os tipos de projetos. O modelo pode ser aplicado tanto para pequenos
quando para grandes projetos. Embora o modelo possua seis papis, uma equipe no
necessita sempre de no mnimo seis pessoas. O importante que estes papis
estejam representados dentro de cada equipe, mas quando uma pessoa assume mais
de um papel comeam a surgir alguns riscos no projeto. O desenvolvimento, em
particular, no deve ser combinado com nenhum outro tipo de papel.
Para formar as equipes, o MSF considera trs tipos de projetos que podem
existir, que so:
- Enterprise Architecture (EA): projetos que incluem melhorias do processo
de negcio, desenvolvimento de aplicaes de negcio, consolidao de plataformas e
infra-estrutura de desenvolvimento, avaliaes de tecnologia, consolidao de
sistemas de negcios;
- Application Development (AD): projetos onde existe o desenvolvimento de
sistemas, com codificao, teste e resoluo de possveis problemas, antes que os
sistemas sejam liberados para uso em ambiente de produo;
- Infrastructure Deployment (ID): projetos que implementam tecnologias
no nvel de plataformas de desenvolvimento, foram testadas e estabilizadas e esto
prontas para serem liberadas. So projetos tais como sistemas operacionais ou
sistemas de transferncia de mensagens (Messaging Systems).
Em cada um destes tipos de projetos existe um conjunto de papis que devem
ser considerados na formao das equipes. Para mais detalhes, a descrio das
responsabilidades de cada papel em cada tipo de projeto pode ser vista em [MIC 99].
2.4.3 Modelo de Processo do MSF
O modelo de processo do MSF estabelece uma ordem para a execuo das
atividades. Hoje em dia existem diferentes tipos de modelos de processos e o modelo
do MSF se originou do processo utilizado pela Microsoft para desenvolver suas
aplicaes. A partir disto, ela utilizou modelos de processos que continham os
princpios que ela julgava serem mais efetivos e populares para criar um nico modelo
40
que poderia ser aplicado para qualquer tipo de projeto, baseando-se em fases, dirigido
por marcos ao longo do processo e seguindo um modelo iterativo. O processo do MSF
combina os melhores princpios do ciclo de vida espiral com o ciclo de vida em
cascata, incorporando os benefcios da possibilidade de planejamento, previses e
certezas do ciclo de vida em cascata com os benefcios do feedback e criatividade do
ciclo de vida espiral.
O modelo de processo do MSF tem como proposta a existncia de quatro fases
distintas. Cada fase acaba com um marco (milestone). O nome de cada fase ou marco
depende do tipo de projeto em que o modelo vai ser aplicado (figura 19).
F
a
s
e
D
o
is
F
a
s
e
U
m
F
a
s
e
Q
u
a
t
r
o
F
a
s
e
T
r

s
Marco
Marco
Marco Marco

Figura 19 O modelo de processo do MSF.
O processo proposto pelo MSF pode ser aplicado para todos os tipos de
projetos, e dependendo do tipo os nomes das fases mudam. Para os projetos do tipo
EA e AD o processo possui as fases de concepo, planejamento,
desenvolvimento e estabilizao. Nos projetos do tipo ID o processo possui as
fases de concepo, planejamento, desenvolvimento e distribuio. Cada uma
destas fases tem seus objetivos especficos e suas atividades so idnticas s
atividades propostas pelo RUP.
2.4.4 Anlise Crtica
O Microsoft Solutions Framework (MSF) formado por conceitos, modelos,
prticas e princpios originrios de coletas das melhores prticas utilizados pelos
funcionrios, parceiros e consultores da Microsoft.
Este framework tem uma grande vantagem que o fato de pertencer a
Microsoft, uma empresa com uma grande representatividade no mercado, e com uma
41
grande fora para fazer seus produtos serem vistos e aproveitados por outras
empresas, como a DELL Computers, que tem a maioria dos seus processos de
desenvolvimento baseados no MSF. Alm disso, o MSF baseado em trs fatores
principais: as pessoas, os processos e a gerncia de riscos. Isto significa que existe
uma preocupao um pouco mais abrangente, cujo objetivo assegurar que as
pessoas, os recursos e as tcnicas existentes so suficientes para garantir que a infra-
estrutura de tecnologia pode satisfazer os objetivos do negcio.
Desde a criao do MSF, uma grande quantidade de projetos dentro da
Microsoft j foi desenvolvida tendo como base este processo de desenvolvimento. E os
resultados tm sido bastante favorveis para a empresa, pois um framework que
est sendo sofrendo atualizaes, baseando-se na prtica dos seus funcionrios.
Apesar destas vantagens, o MSF tambm possui algumas desvantagens.
Mesmo sendo um processo abrangente, que engloba trs fatores muito importantes, o
MSF no possui muitos detalhes das definies que envolvem as atividades mais
tcnicas dentro de um projeto. Todos os documentos que explicam alguma parte deste
processo mostram apenas as atividades que devem existir, mas no existe um
workflow que descreva como as atividades devem ser feitas, como existe na RUP, por
exemplo. Alm disso, no se sabe como o MSF se aplicaria para ambientes
geograficamente distribudos. No existem prticas formalmente definidas para este
contexto especfico. Na literatura no se encontrou nada falando a respeito disto, e
por isso, seria interessante utilizar o MSF em alguma empresa que possui um cenrio
de DDS para ver como este processo seria utilizado e quais os problemas que seriam
encontrados.
Em suma, o Microsoft Solutions Framework muito mais do que um processo
de desenvolvimento de software. todo um ambiente construdo pela prpria
Microsoft para dar o mximo de suporte para suas equipes, oferecendo diversos
modelos de documentos e guias de desenvolvimento. Como suas prticas no se
aprofundam muito na parte tcnica, de como as atividades devem ser feitas, o MSF
utilizou-se de diversos princpios definidos pelo RUP no que diz respeito ao modo como
42
o desenvolvimento deve evoluir, que atividades devem ser feitas em cada fase, para
poder assim oferecer um suporte completo para o desenvolvimento de software,
considerando tipos de projetos, documentos, disciplinas, papis, alm de outras
prticas.
2.5 Agile Software Development - ASD
No comeo de 2001, num encontro ocorrido em Utah nos Estados Unidos, um
grupo de 17 pesquisadores, entre eles Martin Fowler, Alistair Cockburn, Jim Highsmith
e Kent Beck, motivados pela observao de equipes de desenvolvimento de software
em diversas empresas em todo o mundo, comearam a discutir sobre os valores e os
princpios que permitiam estas equipes a desenvolver software de forma rpida e ao
mesmo tempo responder mudanas. Neste encontro, com durao de dois dias, eles
trabalharam na criao de um documento com uma lista de valores e fundaram a
Agile Alliance [AGL 02]. O resultado deste trabalho foi a elaborao de um manifesto
da Agile Alliance [COC 02] para o desenvolvimento gil do software. A mensagem
principal deste manifesto, assinada pelos 17 pesquisadores, dizia:
Ns desejamos descobrir melhores caminhos para desenvolver software,
fazendo e ajudando outros a fazerem. Atravs deste trabalho, chegamos aos seguintes
valores:
- Indivduos e interaes atravs de processos e ferramentas;
- Desenvolvimento de software com uma documentao compreensiva;
- Colaborao do cliente atravs de contratos e negociaes;
- Resposta a mudanas atravs de um plano especfico;
Ou seja, enquanto existirem valores nos itens mais direita, possvel
manter os valores dos itens mais esquerda.
Este manifesto deu origem ao Agile Software Development (Desenvolvimento
gil do Software), um conjunto de idias que visa um objetivo comum: melhorar o
processo de desenvolvimento de software e sempre trazer novas idias. A palavra gil
surgiu para mostrar a importncia da necessidade de existirem processos geis.
43
importante comentar que esta proposta de desenvolvimento no contra os modelos
de processo j existentes, apenas uma proposta diferente que busca a melhoria dos
processos existentes, tornando-os mais geis e menos burocrticos.
Algumas idias que esta proposta defende a de que devem existir prticas
como a modelagem, documentao e planejamento do software que est sendo
construdo. Mas a modelagem no serve apenas para armazenar os diagramas em um
repositrio de dados de uma empresa, a documentao no serve apenas para gastar
papel escrevendo documentos que nunca mais sero alterados ou que freqentemente
sero utilizados e em um ambiente turbulento o planejamento tem seus limites e eles
devem ser conhecidos.
Assim como todos os modelos de processo de desenvolvimento citados at
agora, o Agile Software Development tambm possui alguns princpios. Os principais
princpios existentes so [FOW 01]:
- A prioridade satisfazer o cliente atravs da entrega contnua e
rpida de uma verso do software. Em um workshop, um gerente de projeto,
questionado sobre a importncia dos documentos de especificao de requisitos e
arquitetura, disse que estes documentos so muito importantes para o projeto, mas a
maioria dos clientes no quer saber dos documentos tcnicos, diagramas UML. Eles
esto interessados em saber quando ser possvel ver o software com alguma das
funcionalidades de negcio que ele pediu, para provar que o software pode satisfazer
as suas necessidade.
- Bem vindos mudana de requisitos, mesmo que ela ocorra tarde,
pois isto d uma vantagem competitiva ao cliente. Hoje em dia os ambientes
turbulentos, tanto no mundo dos negcios quanto da tecnologia, causam mudanas.
Estas mudanas podem ser vistas como uma ameaa ou uma grande oportunidade. Ao
invs de resistir s mudanas, os processos geis tentam acomod-las da maneira
mais fcil e eficiente, tendo plena conscincia das suas conseqncias. Embora muitas
pessoas concordam que o feedback importante, a maioria delas ignoram o fato de
que um feedback aceito pode ocasionar uma mudana. E os processos geis
44
consideram este feedback, pois acreditam que mais efetivo facilitar a mudana do
que tentar preveni-la.
- Entregar uma verso do software freqentemente, a cada semana ou
a cada ms, sempre visando o menor tempo possvel. Por muitos anos, muitos
especialistas da rea de processos de desenvolvimento diziam para utilizar um
desenvolvimento interativo e incremental, com mltiplas entregas a cada evoluo do
sistema que est sendo desenvolvido. Apesar de esta prtica ter aumentado e ser
essencial para um processo gil, ainda no o que predomina nas empresas. muito
importante no confundir a entrega com a liberao do software, pois a liberao
significa que um determinado mdulo j pode ir para produo, enquanto que a
entrega somente uma avaliao interna do produto que est sendo desenvolvido.
- As pessoas da rea de negcio e os desenvolvedores trabalham
juntos no projeto, diariamente. Muitas pessoas gostam de comprar um software da
mesma forma que compram um carro. Eles tm uma lista de caractersticas e
funcionalidades na cabea, negociam um preo e pagam pelo que solicitaram. Este
modelo pode ser interessante, mas para a maioria dos projetos de desenvolvimento
isto no funciona. Sendo assim, os desenvolvedores dentro dos processos geis
sofreram uma mudana bem radical com relao aos conceitos da especificao de
requisitos. No necessrio se comprometer com uma lista detalhada de requisitos no
incio do projeto. A idia ter uma viso geral dos requisitos, conhecendo aqueles que
podem sofrer mudanas ao longo do processo. Como isto no suficiente para
projetar e implementar o sistema, a existncia de freqentes interaes entre as
pessoas de negcio e os desenvolvedores se torna necessria.
- Ter uma equipe motivada e fornecer o ambiente, a confiana e o
suporte necessrios para o trabalho ser executado. Mesmo com as melhores
ferramentas, tecnologias, e processos, so as pessoas que fazem a diferena no
caminho entre o sucesso e o fracasso. Alm disso, as decises devem ser tomadas
pelas pessoas que tem mais conhecimento para isto. Isto significa que os gerentes
45
devem confiar na sua equipe e preparar cada integrante para tomar qualquer deciso
que esteja dentro do escopo do seu trabalho.
- O mtodo mais eficiente para trocar informaes dentro ou fora da
equipe de desenvolvimento uma conversa cara-a-cara. Os processos geis
no possuem uma grande quantidade de documentao. Eles consideram que a
diferena no est na documentao, mas sim no entendimento. Uma documentao
pode no dar o real entendimento para uma pessoa que a l. Sendo assim, a
documentao deve ser gerada por questes de obrigao e formalismo, mas sempre
que possvel deve se tambm tentar utilizar tcnicas de comunicao direta.
- A simplicidade essencial. Qualquer tarefa de desenvolvimento por ser
realizada de diferentes maneiras. Em um projeto que utiliza o conceito do
desenvolvimento gil importante a utilizao de uma forma simples para realizar as
tarefas, uma forma que seja simples de mudar. Em termos de resultado, uma pessoa
pode produzir muito mais se, ao invs de existirem regras rgidas e complexas, existir
apenas um conjunto bsico de regras que encoraje a sua criatividade.
- Em intervalos regulares de tempo, a equipe deve refletir sobre como
tornar o trabalho mais efetivo e ento ajustar seu comportamento de acordo
com esta reflexo. Processos geis no so prticas que existem apenas para ler,
aprender e serem seguidas. Sempre existe um processo aconselhado para uma
determinada situao, mas este processo pode deixar de ser vlido com o tempo. O
refinamento e a reflexo devem ser atividades sempre presentes dentro das equipes
de desenvolvimento. Por isso, confiar nas pessoas e acreditar que a capacidade
individual e o trabalho em grupo podem ser as chaves para o sucesso so fatores que
esto ligados confiana que uma equipe deve ter para monitorar e melhorar os seus
prprios processos de desenvolvimento.
Alm dos princpios anteriormente descritos, so vlidas algumas consideraes
sobre o ASD. Segundo [COC 02], um processo de desenvolvimento de software (no
livro o autor chama de metodologia), deve conter 13 elementos (figura 20). Estes
elementos so aplicveis tanto para o desenvolvimento de software como para
46
atividades como montanhismo ou escrever poesias. As atividades definidas para cada
um dos elementos (retngulos) podem variar, mas o nome de cada elemento no
muda.

Figura 20 Os elementos de um
processo de desenvolvimento Fonte: [COC 02]
Alm disso, um modelo de processo de desenvolvimento gil no precisa
necessariamente utilizar todos os elementos definidos na figura 20. Cada modelo tem
um escopo que definido no incio de cada projeto, e este escopo compreende os
papis e as atividades que cobrem o projeto. O escopo de um modelo de processo de
desenvolvimento de software, segundo [COC 02], possue trs dimenses: ciclo de
vida do projeto (indica todas as fases em que um projeto pode estar), papis
(indica quais os papis que podem fazer parte de um projeto) e atividades (define
quais as atividades de cada papel podem ser executadas). Independente do escopo,
todo o projeto deve ter um modelo de processo para ser seguido, considerando um
subconjunto dentro destas trs dimenses, como mostra a figura 21. Ou seja, todo o
projeto possui um modelo de processo, e o que muda so as preocupaes e o escopo
de cada projeto.

Figura 21 As trs dimenses do escopo de um processo - Fonte: [COC 02]
47
Para entender melhor qual o conceito por trs do Agile Software Development,
a figura 22 mostra, como exemplo, a definio do escopo do Extreme Programming,
um processo de desenvolvimento de software que segue as prticas e princpios
definidos pelo ASD e ser explicado mais adiante.

Figura 22 A instncia de um escopo
de processo - Fonte: [COC 02].
Em suma, o Agile Software Development defende a agilidade dos processos de
desenvolvimento, seguindo um conjunto de regras mnimas, procurando antes de
qualquer coisa satisfazer as necessidades dos clientes.
2.5.1 Anlise Crtica
O Agile Software Development surgiu como uma necessidade de um grupo de
17 pesquisadores para buscar solues de melhoria do desenvolvimento de software,
tornando ele mais gil e focado principalmente nas necessidades do cliente. Pode-se
comparar o ASD como um jogo, onde os integrantes da equipe de desenvolvimento
jogam sabendo que o objetivo final vencer. Mas ao longo do caminho eles devem
sempre absorver algum aprendizado e devem sempre ter em mente que eles nunca
jogaram da mesma forma mais de uma vez.
Assim como os dois processos anteriores, o ASD possui suas vantagens e
desvantagens. Como vantagens, existe a idia de que os integrantes da equipe, ou os
jogadores, devem ter uma mente aberta para diferentes metodologias e processos
de desenvolvimento, focando-se sempre no objetivo de desenvolver o software com
qualidade e em um curto perodo de tempo. E cada equipe vai definir o seu prprio
processo gil de desenvolvimento, seguindo os 12 princpios que o ASD prope. Alm
disso, a aliana formada por este grupo de pesquisadores indica que este maneira de
48
enxergar o processo de desenvolvimento de software estar sempre se reciclando,
buscando novas idias e conceitos [AGL 02].
Por outro lado, por existir esta liberdade de definio dos prprios hbitos de
desenvolvimento, a empresa ou a equipe que utiliza os conceitos e princpios do ASD
pode vir a ter um processo de desenvolvimento desorganizado, que trabalha por
resultados e que no se preocupa com alguns detalhes que podem ser teis para
futuro, como documentao, padronizao do processo, entre outros.
Finalizando, [COC 02] traz algumas idias e observaes sobre o
desenvolvimento distribudo de software dentro do conceito do Agile Software
Development. Ele considera alguns cenrios e algumas formas de distribuio,
incluindo alguns descritos no captulo 1 deste estudo. Mas nenhuma destas idias
uma prtica ou uma atividade formal existente dentro do processo gil de
desenvolvimento de software. So apenas idias e observaes do prprio autor, que
refletem a sua experincia e vivncia com o desenvolvimento de software por muitos
anos.
2.6 Extreme Programming XP
No incio da dcada de 1990, um homem chamado Kent Beck comeou a
pensar em melhores caminhos para se desenvolver software, baseado nas suas
experincias anteriores e em todas as dificuldades e desafios que estavam implcitos
nesta atividade. Ele ento resolveu pensar nos fatores que tornavam o software fcil
de ser criado e em fatores que tornavam esta criao difcil. Sendo assim, em maro
de 1996 Kent comeou um projeto na DaimlerChrysler
6
utilizando novos conceitos de
desenvolvimento de software. O resultado foi um novo processo de desenvolvimento,
o Extreme Programming, onde Kent percebeu que existiam quatro dimenses onde o
software poderia ser sempre melhorado (figura 23): necessrio sempre pensar em
melhorar a comunicao; a simplicidade sempre deve ser vista em primeiro plano;

6
Uma das principais empresas de transporte e servios automotivos do mundo.
http://www.daimlerchrysler.com
49
necessrio sempre obter feedback de como as atividades esto sendo executadas; e
necessrio sempre se ter coragem [XTP 02].
COMUNICAO
FEEDBACK
CORAGEM
SIMPLICIDADE
Software

Figura 23 As quatro dimenses do XP.
Extreme Programming (XP) uma proposta disciplinada para o
desenvolvimento de software. Esta proposta surgiu visando um objetivo principal:
entregar o software que o cliente desejar quando ele desejar. Alem disso, ela enfatiza
o trabalho em uma equipe nica. Gerentes, clientes e desenvolvedores formam uma
equipe dedicada a entregar um software com qualidade. O Exteme Programming
implementa uma forma simples e eficaz para permitir um desenvolvimento voltado
para groupware (equipe trabalhando junta em rede ou de forma corporativa) e d
nfase em quatro fatores: comunicao, simplicidade, feedback (melhorias) e coragem
[XPR 02].
A comunicao ocorre de forma contnua entre o cliente e a equipe de
desenvolvedores, pois desta forma o cliente est acompanhando de perto o progresso
do desenvolvimento. E o cliente decide o que deve ser construdo e em que ordem isto
deve ocorrer. Com relao simplicidade, produzido o menor nmero de artefatos
possveis que no sejam cdigos, e o cdigo est sempre sendo revisado e corrigido.
O software liberado em pequenas verses que so continuamente testadas (testes
de unidade) e existe um mecanismo de feedback para avaliar o que foi construdo at
ento. E a coragem significa fazer tudo corretamente, mesmo quando no a tarefa
mais sensata a ser feita. Significa que os desenvolvedores devem ser honestos e
devem saber o que pode e o que no pode ser feito.
Os desenvolvedores no XP tm liberdade e segurana para reagir a uma
mudana de requisitos do cliente, mesmo que esta mudana ocorra tarde. Alm disso,
50
eles se comunicam tanto com os clientes quanto com os outros desenvolvedores. Eles
mantm um projeto simples e limpo e tm a prtica de solicitar e receber feedbacks e
avaliar o software desde o primeiro dia de projeto. Eles entregam o sistema para os
clientes o mais cedo possvel e podem implementar sugestes se for o caso. Com essa
forma de trabalhar, os desenvolvedores que utilizam o XP como processo de
desenvolvimento esto aptos a responder s mudanas de requisitos e tecnologia de
uma forma eficaz e eficiente.
A aplicao proposta do Extreme Programming indicada para pequenos
grupos de desenvolvedores, variando de 2 a 10. No necessrio ter desenvolvedores
experientes e XP no indicado para projetos com uma equipe muito grande.
Segundo [XTP 02], Extreme Programming difere dos outros processos no
sentido de ser composto por pequenos pedaos que separados no tem sentido
algum, mas que quando so integrados pode se enxergar o quebra-cabea completo
montado e funcionando (figura 24). uma forma diferenciada de se projetar e
construir software. Alm disso, XP foi criado para agir num problema muito comum
que a mudana de requisitos, pois muitas vezes os clientes no tm uma idia
concreta do que o sistema deve fazer. Sendo assim, necessrio construir um sistema
onde as funcionalidades podem sofrer alteraes a cada ms.

Figura 24 O XP visto como um conjunto de peas.
O XP composto por quatro fases: planejamento, projeto, codificao e
teste. Cada uma destas fases possui uma srie de regras e prticas que devem ser
seguidas. Alm disso, doze prticas ao longo destas fases suportam as quatro
dimenses ilustradas anteriormente na figura 23[POL 01], [BEC 00]:
- Planejamento (The Planning Game): o desenvolvimento de software
sempre um dilogo envolvendo o possvel e o desejado. Sendo assim, no existe uma
superioridade entre as consideraes tcnicas e as consideraes do negcio [BEC
00]. No XP, o planejamento envolve uma srie de decises e dois atores esto
51
envolvidos nelas: os analistas da rea tcnica e os analistas de negcio. Os analistas
de negcio so responsveis pelas definies do escopo do projeto, ou seja, o quanto
suficiente e o quanto muito para ser feito. Alm disso, eles definem prioridades
nas tarefas a serem executadas, bem como as caractersticas que faro parte das
prximas verses do software e as datas de liberao destas verses. Mas os analistas
de negcio s podem tomar estas decises junto com os analistas da rea tcnica, que
fornecem subsdios para estas decises. Sendo assim, os analistas da rea tcnica so
responsveis por fornecer estimativas de tempo de implementao. Devem tambm
informar para os analistas de negcio sobre possveis conseqncias que sero
influenciadas pelas decises de negcio, tal como a escolha do banco de dados. Outra
responsabilidade dos analistas da rea tcnica a de detalhar um cronograma
contendo tudo o que ser desenvolvido dentro de uma verso, considerando riscos e
prioridades. Por ltimo, devem definir como a equipe e o trabalho estaro
organizados;
- Liberao de pequenas verses (Small Releases): deve ocorrer uma
liberao do software freqentemente para o cliente com pequenas verses
incrementais. Cada verso deve ser a menor possvel, contendo os mais importantes
requisitos de negcio. Mas esta liberao deve ser feita de forma lgica, ou seja, no
se pode implementar metade de uma funcionalidade e enviar para o cliente, apenas
para tornar o ciclo de liberao menor. O ideal planejar liberaes em perodos de 1
ou 2 meses, dependendo do tamanho do software a ser desenvolvido. Uma empresa
que est desenvolvendo um software muito grande e complexo pode enfrentar
dificuldades para freqentemente liberar uma verso. Mas isto deve ser feito da
melhor forma possvel;
- Metfora (Metaphor): a metfora apenas uma histria ou descrio de
como o sistema trabalha. Cada projeto dentro do XP guiado por uma metfora. O
objetivo apenas ajudar no entendimento do projeto e dos seus elementos bsicos,
bem como nas relaes entre eles. O XP tambm utiliza o conceito de user stories. Os
user stories servem para o mesmo propsito dos casos de uso utilizados no RUP, mas
52
no so iguais. Os user stories so utilizados para criar estimativas de
desenvolvimento e so utilizados em substituio aos extensos documentos de
especificao de requisitos. So escritos pelos clientes como funcionalidades que o
sistema deve ter, e so escritos na terminologia do cliente. A partir dos user stories se
derivam os casos de teste;
- Projeto do Sistema Simples (Simple design): manter o projeto do
sistema simples, mantendo o cdigo simples e removendo de forma contnua a
complexidade existente no cdigo. Esta prtica sugere que o projeto do sistema seja
sempre feito, seguindo um conselho oposto ao que normalmente se ouve:
Implemente hoje e faa o projeto do sistema amanh [BEC 00].
- Teste (Testing): qualquer funcionalidade de um software sem um teste
automatizado simplesmente no existe. [BEC 0O]. Os desenvolvedores devem
escrever testes de unidade para garantir que cada parte do software funciona
corretamente, enquanto que o cliente escreve os testes funcionais, a partir dos user
stories, para garantir que o programa funciona de acordo com o que foi especificado.
No necessrio escrever testes para cada mtodo existente. Os testes devem ser
feitos para testar apenas o que pode quebrar o cdigo, e o ideal que sejam escritos
os casos de teste de um determinado mdulo antes de iniciar o seu desenvolvimento;
- Reestruturao (Refactoring): esta uma tcnica simples para remover a
complexidade e a duplicao do cdigo. Sempre aps adicionar algumas
funcionalidades ao sistema, os desenvolvedores sempre querem saber se existe uma
maneira de tornar o software mais simples. isto nada mais do que a
reestruturao do sistema, de modo que no futuro a incluso de uma nova
funcionalidade se torne uma tarefa mais fcil.
- Programao em Pares (Pair Programming): equipes de dois
desenvolvedores desenvolvem todo o cdigo em um nico computador, utilizando um
mouse e um teclado. Em cada par existem dois papis: um desenvolvedor utiliza o
mouse e o teclado para pensar na melhor maneira de implementar o sistema; o outro
desenvolvedor pensa de uma forma mais estratgica, revisando o cdigo para
53
procurar erros ou partes inconsistentes, definido casos de teste que podem quebrar o
cdigo que est sendo implementado, alm de maneiras de simplificar o sistema. A
programao em pares dinmica e qualquer um dentro da equipe pode ser um par;
- Posse Coletiva (Collective Ownership): todos so responsveis por todo o
cdigo. Isto significa que todos tm permisso para alterar qualquer parte do cdigo a
qualquer momento. A vantagem que todos tm algum conhecimento de cada parte
do cdigo e se algum desenvolvedor for embora seu cdigo continuar disponvel e
ningum ter dificuldade de entend-lo. Se um par de desenvolvedores est
trabalhando e v uma oportunidade de melhorar uma determinada parte do cdigo,
eles no pensam duas vezes para alterar tudo o que for necessrio;
- Integrao Contnua (Continuous Integration): construir e integrar o
sistema vrias vezes por dia mesmo que nenhuma tarefa de codificao foi realizada.
Isto pode ser feito utilizando uma mquina dedicada apenas para a integrao.
Quando a mquina est livre, um par de desenvolvedores atualiza seu cdigo,
verificando possveis colises com outras partes do sistema, e executam os testes de
integrao at que o sistema no possua erros;
- 40 horas por Semana (Forty-hour Week): os desenvolvedores no podem
trabalhar com o mximo de esforo se eles estiverem cansados. Diferentes pessoas
possuem limites de horas diferentes para trabalhar. Uma pessoa pode trabalhar
concentrada durante 35 horas, outras podem trabalhar durante 45 horas, mas
nenhuma capaz de trabalhar 60 horas por semana por diversas semanas
consecutivas e estar sempre descansado, criativo e seguro. No XP no possvel ter
hora extra por duas semanas consecutivas. Uma pessoa pode ter horas extras em
uma semana, mas se no incio da prxima semana ela concluir que para atingir seus
objetivos sero necessrias mais horas extras, sinal de que j existe um problema e
que este problema no poder ser solucionado apenas trabalhando-se mais do que o
seu horrio;
- Cliente no local (On-site Customer): um cliente real trabalha no
ambiente de desenvolvimento todo o tempo para ajudar a definir o sistema, escrever
54
casos de teste e responder as dvidas gerais. Entende-se por cliente real a pessoa
que utilizar o sistema quando ele estiver em produo. Mas o grande obstculo desta
prtica que os clientes reais so muito valiosos para ficarem todo o tempo com a
equipe de desenvolvimento. E neste caso, os gerentes devero decidir o que melhor
fazer, pois durante o desenvolvimento, os desenvolvedores podem gerar inmeras
questes e dvidas por hora ou at por semana;
- Padres de Cdigo (Coding Standards): os desenvolvedores adotam uma
consistente padronizao de cdigo. Esta padronizao necessria, pois os
desenvolvedores trocam de pares e pulam de uma parte do cdigo para outra a todo
instante. Esta padronizao deve focar na comunicao e deve ser adotado
voluntariamente por toda a equipe.
2.6.1 Anlise Crtica
O Extreme Programming um processo de desenvolvimento de software
disciplinado que, antes de qualquer coisa, visa a satisfao completa do cliente. A
idia bsica do XP entregar o software ao cliente quando ele deseja, e para isto este
mesmo cliente deve ter um papel muito ativo. Alm disso, este processo possui quatro
dimenses que caracterizam as suas caractersticas principais, alm de possuir
algumas prticas j citadas anteriormente.
Uma das vantagens desta abordagem proposta pelo XP que ele prope uma
nova forma de enxergar um dos grandes problemas do desenvolvimento de software:
a mudana de requisitos. Alm disso, o cliente participa de vrias definies ao longo
do processo, se sentindo como parte da equipe do projeto. Por ltimo, a utilizao do
XP pode diminuir os custos do desenvolvimento do software, pois um processo
simples de ser implementado.
Por outro lado, o Extreme Programming tambm possui suas desvantagens.
Primeiramente, um processo idealmente aplicado para projetos de pequeno porte,
com equipes no muito grandes, variando de 2 a 10 integrantes. Isto significa que o
XP no pode ser sempre utilizado. Alm disso, no existe um formalismo que define as
documentaes que devem ser geradas. O XP passa uma impresso de que a maior
55
parte dos documentos so gerados da forma como os desenvolvedores acharem
melhor. O importante comear o desenvolvimento o mais rpido possvel,
descobrindo possveis problemas ao longo do projeto, tendo ento como foco principal
o desenvolvimento. Por ltimo, o XP no possui suporte para desenvolvimento de
software em ambientes fisicamente distribudos, pois a sua prtica sugere que o
cliente esteja sempre trabalhando junto com a equipe de desenvolvimento, fazendo
disto um obstculo para distribuir este desenvolvimento. Alguns autores, como [BEC
01], at sugerem que em ambientes como estes exista dentro da prtica do Planning
Game uma tarefa que justamente decidir o que fazer em ambientes de DDS. Apesar
disto, diversos estudos tm analisado as prticas do Extreme Programming,
comparando estas prticas em ambientes geograficamente centralizados e em
ambientes geograficamente distribudos [BAH 02], verificando a eficincia e a
necessidade de se definir algumas regras e atividades especficas para este tipo de
configurao de desenvolvimento. Mas muito trabalho ainda precisa ser feito.
Em suma, o XP um processo inovador que trouxe diversas idias para a rea
do desenvolvimento de software, mas ele tem alguns limites que no tem como serem
ultrapassados. Grandes projetos no podem utilizar somente o processo proposto pelo
XP, pois ele no cobre todas as prticas necessrias que se exigem para um
desenvolvimento de um projeto de grande porte, seja ele em uma pequena, mdia ou
grande empresa. Mas o XP reconhecidamente sugerido e efetivo para a construo
de sistemas pequenos dentro de um ambiente de mudana de requisitos.
Independente disto possvel unir algumas prticas propostas pelo Extreme
Programming com prticas propostas por outros processos de desenvolvimento, como
o RUP [SMI 01], [POL 01]. E nunca se deve esquecer do principal objetivo deste
processo de desenvolvimento: entregar o que o cliente desejar, quando ele desejar.
Se isto falhar, grandes impactos humanos e econmicos podem surgir. Por isso que o
XP diferente e por isso que ele foi criado. Para ser diferente, reconhecido e eficiente,
dentro dos limites em que ele se enquadra e dentro dos objetivos a que ele se prope.
56
3 Anlise Comparativa entre os Processos de Desenvolvimento
No captulo anterior o objetivo foi descrever alguns dos principais processos de
desenvolvimento de software. Estes processos so bastante utilizados hoje em dia em
diversas empresas com o objetivo de obter-se um processo de desenvolvimento de
software organizado e bem definido. As empresas sabem que a partir da existncia de
um processo para guiar o desenvolvimento de software possvel buscar melhorias de
qualidade e maturidade destes processos, alm de ter a possibilidade de avaliar e
medir a aplicabilidade e o sucesso destes processos. O objetivo deste captulo fazer
uma anlise comparativa dos processos descritos no captulo anterior. Para isto,
identificou-se um conjunto de critrios de comparao, considerando o que
importante e, dentre estes, quais so essenciais em um processo de desenvolvimento
de software.
3.1.1 Definio dos Critrios de Anlise
Para analisar os processos descritos anteriormente, sero utilizados critrios
obtidos a partir de um estudo especfico para este fim baseando-se em artigos e livros
que propem critrios para comparaes entre metodologias e processos de
desenvolvimento de software orientados a objetos [OBJ 95], [SMI 01] e [COC 02].
[OBJ 95] um relatrio preparado pela The Object Agency, Inc., com o
objetivo de ajudar as organizaes a avaliarem as caractersticas, vantagens e
desvantagens de cada metodologia de desenvolvimento para o seu ambiente. Este
relatrio serve como um guia para as pessoas que se interessam em entender o que
existe, para as pessoas que j utilizam alguma metodologia e querem saber se existe
algo melhor, e para as pessoas que querem justificar o porque de evitarem o uso de
alguma metodologia para o seu ambiente. Como este relatrio de 1995, a
comparao em si no foi utilizada para este estudo por estar desatualizada com os
57
processos existentes atualmente. Por isso, apenas foram utilizados alguns dos critrios
comparativos propostos.
[SMI 01] tem por objetivo comparar dois modelos de processo de
desenvolvimento de software descritos anteriormente: o Rational Unified Process
(RUP) e o Extreme Programming (XP). A comparao est direcionada na natureza e
no estilo de cada processo, suas estruturas, hipteses e apresentaes. O artigo
tambm examina quais os potenciais alvos de cada processo e a conseqncia da
sua utilizao.
[COC 02] descreve as propostas e princpios dos processos de desenvolvimento
de software como regras de comportamento e integra essas propostas e princpios
com a idia de que cada projeto nico e tem suas prprias regras. um estudo
baseado em casos empricos propostos pelo autor.
A tabela 1 identifica os critrios encontrados na literatura, acrescentando
critrios prprios identificados neste estudo. Para uma maior facilidade de
comparao, estes critrios foram agrupados em algumas variveis mais genricas.
Sendo assim, este estudo comparativo foi feito por meio da anlise de cada uma das
variveis identificadas para cada processo de desenvolvimento de software analisado.
VARIVEIS FONTE CRITRIOS
Fases de um projeto [SMI 01]

[OBJ 95]

[SMI 01]
Forma como o processo est organizado ao
longo do tempo.
Existncia de fases bem definidas e os
nomes de cada fase.
Existncia de entrada e sadas definidas
para cada fase.
Artefatos [COC 02]

[SMI 01]
Nmero mdio de artefatos existentes no
processo.
Existncia de uma definio boa e formal
dos artefatos.
Atividades e Disciplinas [SMI 01]

[COC 02]

Como as atividades so executadas para
produzir os artefatos.
Existncia de disciplinas e prticas,
modelagem do sistema, gerncia de
mudana de requisitos, programao em
pares, etc.
Teste e Controle de
Qualidade
[OBJ 95]


[OBJ 95]
[COC 02]
Existncia de atividades de controle de
qualidade ao longo de todo o processo de
desenvolvimento.
Existncia de uma atividade de teste.
Gerao de casos de teste, relatrios, etc.
Papis e Regras [SMI 01] Nmero mdio de papis existentes dentro
58

[OBJ 95]
de um projeto.
Existncia de uma definio formal dos
papis e regras existentes.
Caractersticas Gerais [OBJ 95]
[SMI 01]
Grau de formalismo existente no processo.
Tamanho mximo de projeto suportado
pelo processo.
Ciclo de Vida [OBJ 95] Ciclos de vida que podem ser utilizados no
processo.
Mecanismo para melhoria
constante do processo
PRPRIO Existncia de algum mecanismo que prev
uma coleta e feedback de informaes dos
projetos para serem analisadas e utilizadas
para futuras melhorias.
Suporte para DDS -
Desenvolvimento
Distribudo de Software
PRPRIO Existncia de um planejamento para
projetos em um ambiente de DDS, alm de
mecanismos de suporte, estratgias a
serem seguidas (considerando os diversos
cenrios e os problemas de cada um deles),
definio de atividades especficas e
mecanismos de avaliao do projeto,
levando-se em considerao os 5 fatores de
sucesso (diferenas culturais, coordenao,
comunicao, confiana e cooperao).
Tabela 1 Os critrios definidos para a anlise comparativa.
3.1.2 Anlise Comparativa
Aps a definio dos critrios e das variveis de anlise no item anterior,
busca-se agora sintetizar os resultados da anlise comparativa entre os modelos de
processo de desenvolvimento de software encontrados. Para isto a seguir sero
apresentadas, para cada critrio, as caractersticas encontradas em cada um dos
modelos de processo de desenvolvimento descritos.
Fases de um projeto
RUP
Fases bem definidas, com marcos (milestones) sinalizando o final de cada fase. As
fases possuem entradas e sadas bem definidas, que pode ser um artefato, uma
autorizao do cliente, etc. Ao longo do tempo o processo evolui atravs das fases,
cujos nomes so: concepo, elaborao, construo e transio.
MSF
Fases bem definidas, com o nome e as atividades variando de acordo com o tipo de
projeto. As fases possuem entradas e sadas bem definidas. Ao longo do tempo o
processo evolui atravs das fases, cujos nomes so: concepo, planejamento,
desenvolvimento e estabilizao. Em alguns tipos de projetos a ltima fase se chama
distribuio.
ASD
As fases no so bem definidas. Cada projeto configurado de uma forma diferente
de acordo com o seu escopo e contexto, portanto no existem entradas e sadas por
fase. Ao longo do tempo o processo evolui de acordo com as necessidades do cliente e
com agilidade necessria para entregar o mais cedo possvel.
XP
As fases so bem definidas, mas o foco no desenvolvimento. Ao longo do tempo o
processo evolui atravs das fases, que so: planejamento, projeto, codificao e teste,
e o cliente tem participao freqente.
59
Artefatos
RUP
Possui artefatos bem definidos para cada fase e atividade do projeto. Tambm possui
modelos (templates) para estes artefatos. Tem uma mdia de 100 artefatos [SMI 01],
mas um projeto no obrigado a produzir todos, apenas o que interessar.
MSF
Possui artefatos bem definidos para cada fase e atividade do projeto. Possui modelos
(templates) para estes artefatos e guias de como preencher. Um projeto deve, na
medida do possvel, produzir todos os artefatos necessrios.
ASD
No possui artefatos bem definidos. Possui alguns artefatos para atividades especficas
e a proposta a de gerar pouca documentao, somente o que for realmente
necessrio para o formalismo do projeto para o cliente ou outros projetos.
XP
Existem em torno de 30 artefatos [SMI 01] e eles no so bem definidos, pois o XP
no d muita importncia para explic-los em detalhes. Na literatura do XP difcil
encontrar as palavras artefato ou documento, mas na descrio do processo se
encontram diversas definies que so realmente artefatos e documentos.
Atividades e Disciplinas
RUP
Possui diversas atividades e disciplinas e um conjunto de 9 workflows que as
descrevem ao longo das fases. A modelagem do sistema feita somente atravs da
linguagem UML, utilizando casos de uso para modelagem de negcio e especificao
de requisitos, alm de outros diagramas ao longo do projeto. Possui prticas de
gerncia de mudana.
MSF
Possui diversas atividades e algumas delas so incorporadas da RUP e outros
processos de desenvolvimento. A modelagem do sistema feita atravs da UML ou
outra representao que for necessria. D nfase na gerncia de risco, recursos
humanos e processos.
ASD
Possui diversas atividades para tornar o processo gil. O cliente tem um papel muito
importante em algumas destas atividades. D nfase na colaborao do cliente,
resposta mudanas, indivduos e interaes para gerar um desenvolvimento rpido e
com qualidade. Possui caractersticas tais como avaliao contnua do software.
XP
Possui diversas atividades e com nfase no desenvolvimento, mas algumas no so
bem definidas. Possui caractersticas diferenciadas, tais como a programao em
pares, posse coletiva e gerao de casos de teste por parte do cliente. A especificao
de requisitos feita utilizando-se user stories e a mudana de requisitos pode ocorrer
a qualquer momento. D nfase na comunicao, simplicidade, feedback e coragem.
Teste e Controle de Qualidade
RUP
Possui prticas de controle de qualidade ao longo de todo o processo, mas elas no
so bem descritas. Com relao aos testes, casos de testes so gerados visando
testes de unidade, regresso, carga, entre outros. Relatrios de teste so gerados e os
erros devem ser verificados e corrigidos.
MSF
Possui prticas de controle de qualidade ao longo de todo o processo, mas elas no
so bem descritas. Tambm existe a atividade de teste, mas a descrio que dada
no material estudado bem superficial. Um projeto no liberado sem passar por
todos os testes.
ASD
Possui prticas de controle de qualidade e padronizao, bem como atividades de
teste. A descrio bastante genrica, visto que cada projeto trabalha da sua forma.
Os testes tm grande importncia por causa da avaliao e integrao constantes.
60
XP
O teste e o controle de qualidade tm uma grande importncia por causa das
constantes avaliaes de pequenas verses por parte do cliente. Os casos de testes
so escritos preferencialmente antes do desenvolvimento e os clientes escrevem todos
os casos de teste das funcionalidades.
Papis e Regras
RUP
Existem papis e regras bem definidos. Possui em torno de 30 papis [SMI 01],
definidos em cada workflow. Uma pessoa pode exercer mais de um papel, dependendo
do tamanho do projeto e do papel. O processo como um todo possui regras que
definem o que fazer e quando fazer e as responsabilidades de cada papel.
MSF
Existem papis e regras bem definidos. Um dos aspectos mais importantes a
configurao da equipe de projeto e seus papis. Cada papel possui regras que dizem
o que fazer em cada fase do projeto.
ASD
Como cada projeto um projeto diferente em termos de processo, no existem papis
bem definidos, pois isto depende de cada projeto. Existem apenas os papis essenciais
e o restante definido por demanda.
XP
Possui alguns regras e papis bem definidos, mas tambm possui papis e regras que
podem surgir ao longo de um projeto. Possui ento em torno de 7 papis [SMI 01] e
algumas regras dentro de cada fase, com nfase no desenvolvimento. Em comparao
com o RUP, um papel do XP equivale a alguns papis do RUP.
Caractersticas Gerais
RUP
um processo de desenvolvimento bem formal, bem definido, com tudo pronto para
ser instanciado e aplicado, podendo assumir diversas configuraes dentro do
framework, dependendo das caractersticas de cada projeto. Cada configurao inclui
as prticas j existentes e pode ser aplicado para qualquer tipo e tamanho de projeto.
focado na qualidade e no desenvolvimento baseado em componentes.
MSF
um processo de desenvolvimento formal, bem definido e que pode ser instanciado e
aplicado para qualquer tamanho de projeto. Define trs tipos possveis de projeto e as
atividades e disciplinas variam um pouco em cada tipo. focado nas pessoas, na
gerncia de risco e na tecnologia.
ASD
um processo de desenvolvimento que no d muita nfase no formalismo e
definio de todas as atividades, formando um guia de desenvolvimento. Pode ser
aplicado para qualquer tipo e tamanho de projeto, e para cada projeto pode existir um
processo diferente. focado na qualidade e satisfao do cliente.
XP
um processo de desenvolvimento com definies bsicas, com nfase total no
desenvolvimento, na resposta rpida e na satisfao do cliente. No muito formal e
possui algumas limitaes quanto ao tipo e tamanho de projeto.
Ciclo de Vida
RUP
Possui um ciclo de vida em espiral, com um desenvolvimento iterativo e incremental.
Tambm pode ser utilizado com um ciclo de vida em cascata (no se aconselha), ou
em outras combinaes de ciclo de vida.
MSF
Possui um ciclo de vida em espiral, com um desenvolvimento iterativo e incremental.
Pode ser utilizado com um ciclo de vida em cascata ou outras variaes.
ASD
Possui um ciclo de vida baseado na prototipao e na avaliao constante, mesclado
com o desenvolvimento iterativo e incremental.
61
XP
Possui um ciclo de vida baseado na prototipao e na avaliao constante, mesclado
com o desenvolvimento iterativo e incremental.
Mecanismo para melhoria constante do processo
RUP
Por ser um desenvolvimento iterativo e incremental, possui alguns mecanismos para
buscar a melhoria constante do processo. Mas a melhor forma de obter bons
resultados aplicar esta prtica de forma independente nas empresas que utilizam o
RUP. Mesmo assim, existe um suporte constante ao usurio, mesmo aps o trmino
do projeto. Isto pode ser uma outra fonte de entrada para futuras melhorias,
MSF
Por ser um desenvolvimento iterativo e incremental, possui alguns mecanismos para
buscar a melhoria constante do processo. Mas a principal fonte de dados que serviro
para futuras melhorias a coleta constante de boas prticas da equipe de funcionrios
da Microsoft. Estas prticas so analisadas e podem ser integradas ao MSF no futuro.
ASD
No possui um mecanismo formal para buscar a melhoria constante do processo.
Possui uma constante avaliao do software por parte do cliente e em intervalos
regulares de tempo a equipe deve refletir sobre como tornar o trabalho mais efetivo e
ento ajustar seu comportamento de acordo com esta reflexo. Como um processo
gil, est sempre buscando melhorias.
XP
No possui um mecanismo formal para buscar a melhoria constante do processo.
Possui uma constante avaliao por parte do cliente que trabalha diariamente com a
equipe de desenvolvimento.
Suporte para DDS - Desenvolvimento Distribudo de Software
RUP
No possui atividades que oferecem suporte ao DDS, mas d importncia para a
comunicao.
MSF
No possui atividades que oferecem suporte ao DDS, mas d importncia para a
comunicao.
ASD
No possui atividades e prticas formais que oferecem suporte ao DDS, mas d
importncia para a comunicao. Em seu livro, [COC 02] expressa a sua opinio com
relao ao DDS dentro do Agile Software Development, mas no so atividades
formais, sendo apenas idias que o autor sugere para serem aplicadas.
XP
No possui atividades formas que oferecem suporte ao DDS, mas d uma grande
importncia para a comunicao. Apesar disto, j existem alguns estudos que
comparam algumas prticas do XP em ambientes geograficamente centralizados com
ambientes geograficamente distribudos.
Tabela 2 Anlise comparativa.



62
CONCLUSES
Este trabalho teve como objetivo principal apresentar um estudo de dois
tpicos relacionados: o estado da arte dos principais modelos de processos de
desenvolvimento de software existentes e um estudo sobre uma nova tendncia que
as empresas esto cada vez mais absorvendo na sua realidade, que o
desenvolvimento distribudo de software (DDS).
Com relao ao mtodo de pesquisa, se desenvolveu uma extensa reviso
bibliogrfica, buscando-se ilustrar o estudo relativo ao DDS com dois exemplos reais
(Centro de Pesquisa em E-Business DELL/PUCRS e o Centro de Desenvolvimento da
Oikodomo Brasil). Considerando que este processo de pesquisa aborda um tema
pouco consolidado na literatura (DDS), trata-se de um estudo predominantemente
exploratrio. Durante a evoluo do estudo algumas anlises e snteses foram
realizadas, visando a consolidao das informaes coletadas.
A sntese do estudo sobre DDS propiciou um maior entendimento de como os
ambientes de desenvolvimento geograficamente distribudos podem estar
organizados, quais os atores que esto envolvidos e quais os critrios que definem
esta distribuio. Alm disso, o estudo direcionou a pesquisa no sentido de indicar em
que nvel de distribuio um processo de desenvolvimento de software deve se
preocupar em absorver prticas de DDS.
J a anlise comparativa dos principais modelos de processos de
desenvolvimento de software mostrou que existem diversas possibilidades disponveis.
Estas possibilidades envolvem desde processos formais, seqenciais e pesados at
processos mais informais, iterativos e geis. Estes modelos podem focar mais os
resultados ou os processos para a obteno destes resultados, bem como podem
possuir um nvel de organizao mais ou menos rgidos. Um resultado importante foi
63
com relao existncia de atividades que auxiliam na melhoria constante dos
processos. Nenhum dos processos analisados descreve clara e detalhadamente como
esta atividade ocorre, se uma atividade externa, interna ou inexistente. Alguns dos
modelos analisados apenas citam que em algum momento pode existir uma coleta de
prticas, um feedback ou uma reunio de avaliao, com o objetivo de melhorar o
processo como um todo. Estas informaes so ento analisadas e podem ser
transformadas em novas prticas para serem incorporadas ao processo. Outro
resultado relevante foi a definio de um padro de anlise de processos de
desenvolvimento de software em um ambiente distribudo (DDS).
Mas o principal resultado desta anlise comparativa foi a percepo de que em
nenhum dos processos analisados existe a descrio de uma prtica formal que prev
um cenrio de DDS. O desenvolvimento distribudo de software cada vez mais
constante, principalmente nas grandes organizaes. Esta realidade demanda por
novos conhecimentos e prticas a serem incorporadas nos processos de
desenvolvimento de software.
Finalmente, verificou-se que existe espao para pesquisas na rea de
Desenvolvimento Distribudo de Software. Se por um lado muitas empresas esto
cada vez mais distribuindo seu desenvolvimento ao redor do mundo visando algumas
vantagens competitivas, por outro lado existe uma grande lacuna a ser preenchida
nos processos de desenvolvimento de software existentes: a formalizao de prticas
quando se configura o DDS.
Nas prximas etapas desta pesquisa pretende-se explorar as possibilidades de
incorporao de contribuies em um modelo processo de desenvolvimento de
software com equipes geograficamente distribudas, em todos os seus possveis
cenrios. Identificam-se demandas relativas a atividades como planejamento,
definio de estratgias, disciplinas, prticas e avaliao do processo.




64
REFERNCIAS BIBLIOGRFICAS
[AGL 02] Agile Alliance. Disponvel em http://www.agilealliance.org, 2002.
[ALC 02] ALCNTARA, A. A., MACIEL, T. M. M., MEIRA, S. L., SILVA, F. Q. B. Uso
do Processo RUP na Implanatao da ISO9000-3. CESAR Centro
de Estudos e Sistemas Avanados do Recife, 2002.
[ALT 98] ALTMANN, J., WEINREICH R. An Environment for Cooperative
Software Development Realization and Implications. IEEE, 1998.
[BAH 02] BAHETI, P., WILLIAMS, L., GEHRINGER, E., STOTTS, D., SMITH, J. M.
Distributed Pair Programming: Empirical Studies and Supporting
Environments. Technical Report, Universidade da Carolina do Norte,
Maro de 2002.
[BEC 00] BECK, K. Extreme Programming Explained Embrace Change.
Editora Addison-Wesley, 2000.
[BIU 02] BIUK-AGHAI R. P. Customizable Software Engineering
Environments for Flexible Distributed Software Teams, 2002.
[COC 02] COCKBURN. A. Agile Software Development The Agile Software
Development Series. Editora Addison-Wesley, 2002.
[DAD 02] Dispersed Agile Software Development and Dispersed eXtreme
Programming. Disponvel em http://www.fastnloose.org/cgi-
bin/wiki.pl/dad, 2002.
[EVA 00] EVARISTO, J. R. and SCUDDER, R. Geographically Distributed Project
Teams: A Dimensional Analysis. Proceedings of the Thirty-third
Hawaii International Conference on Systems Sciences, 2000.
[EVA 01] EVARISTO, J. R. The Management of Distributed Projects Across
65
Cultures. Submission to the Special Issue of IEEE Transactions on
Engineering Management, 2001.
[FOW 01] FOWLER, M., HIGHSMITH, J. The Agile Manifesto, 2001.
[HAY 00] HAYWOOD, M. Working in Virtual Teams: A Tale of Two Projects
and Many Cities. IT PRO, IEEE, pp. 58-60, Maro/Abril de 2000.
[IEC 02] IEC - International Electrotechnical Comission. Disponvel em
http://www.iec.ch, 2002.
[ISO 98] ISO - International Standards Organization. ISO/IEC 12207
Software Life Cycle Process. Vlida desde 30/11/1998. Direitos ABNT
Associao Brasileira de Normas Tcnicas, Rio de Janeiro, RJ, Outubro
de 1998.
[ISO 02] ISO - International Organization for Standardization. Disponvel em
http://www.iso.ch/iso/en/ISOOnline.openerpage, 2002.
[KRA 95] KRAUT R.E., STREETER L.A.: Coordination in Software Development,
Communications of the ACM, Vol. 38, No. 3, ACM Press, New York,
N.Y., pp. 69-81, 1995.
[KRU 01] KRUCHTEN, P. The Rational Unified Process: An introducion. Editora
Addison-Wesley. 2 edio, 2001.
[LAY 99] LAYZELL, P., BRERETON, P. The Future of Software. Communications
of the ACM, Vol. 42, No 12. ACM Press, New York, N.Y., pp. 78-84,
1999.
[LAY 00] LAYZELL, P., BRERETON, P., FRENCH, A. Supporting Collaboration in
Distributed Software Engineering Teams. Proceedings of the Seventh
Asia-Pacific Software Engineering Conference (APSEC.00), 2000.
[McC 96] McCONNEL, S. Rapid Development. Microsoft Press, 1996.
[MIC 99] Microsoft Solutions Framework. Overview White Paper. Disponvel
em http://www.microsoft.com/msf, 1999.
[OBJ 95] The Object Agency, Inc. A Comparison of Object-Oriented
66
Methodologies, 1995.
[PET 01] PETERS, J. F., PEDRYCZ, W. Engenharia de Software, Teoria e
Prtica, Brasil, Editora Campus, 2001.
[POL 01] POLLICE, G. Using the Rational Unified Process for Small Projects:
Expanding Upon eXtreme Programming. Rational Software White
Paper, 2001.
[PRI 02a] PRIKLADNICKI, R., PERES, F., AUDY, J., MRA, M. C., PERDIGOTO, A.
Requirements specification model in a software development process
inside a physically distributed environment. Proceedings of ICEIS
2002, Ciudad Real, Spain, 2002.
[PRI 02b] PRIKLADNICKI, R. Problemas, Desafios e Abordagens do Processo
de Desenvolvimento de Software. Trabalho Individual I, Mestrado em
Cincia da Computao, PUCRS, 2002.
[RAT 98] Rational Software Corporation. Best Practices for Software
Development Teams. Rational Software White Paper, 1998.
[SIN 99] SINGH, R. An Introduction to International Standard ISO/IEC
12207, Software Life Cycle Process. Federal Aviation Administration.
Disponvel em http://www.abelia.com/docs/12207tut.pdf. Washington,
DC, EUA, 1999.
[SMI 01] SMITH, J. A comparison of RUP and XP. Rational Software White
Paper, 2001.
[XTP 02] Extreme Programming A Gentle Introduction. Disponvel em
http://www.extremeprogramming.org, 1999.
[XPR 02] Third International Conference on eXtreme Programming and
Agile Processes in Software Engineering. Disponvel em
http://www.xp2002.org, 2002.