Desenvolvimento de Software Distribuído e Processos

Prévia do material em texto

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL 
FACULDADE DE INFORMÁTICA 
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO 
 
 
 
 
 
 
 
 
Curso de Mestrado 
 
 
 
 
 
 
Desenvolvimento Distribuído 
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, ciência, engenharia ou algo mais como um todo? 
Será que isto importa? 
Sim, isto importa, e importa para todos nós. 
Nossas ações e os resultados que são gerados podem ser diferentes, 
de acordo com a definição que for mais correta. 
Então, a idéia principal é: 
Todos nós precisamos que o nosso software seja desenvolvido 
da forma mais rápida possível e sem erros. 
Mas muito mais do que isso, 
nós precisamos sempre saber como a nossa equipe 
está desenvolvendo ao longo deste caminho. 
 
Alistair Cockburn 
 
 iii
SUMÁRIO 
LISTA DE FIGURAS........................................................................................... v 
LISTA DE TABELAS .......................................................................................... vi 
LISTA DE ABREVIATURAS E SIGLAS...................................................................vii 
INTRODUÇÃO .................................................................................................. 8 
1 Desenvolvimento Distribuído de Software (DDS) ............................................. 10 
1.1 Critérios que caracterizam o nível de DDS................................................ 13 
1.1.1 Distância física dos atores ............................................................ 15 
1.1.2 Distribuição da Equipe de Desenvolvimento..................................... 17 
1.2 Alguns Cenários de Desenvolvimento Distribuído de Software (DDS) ........... 18 
1.2.1 Cenário 1: Centro de Pesquisa em E-Business DELL/PUCRS............... 19 
1.2.2 Cenário 2: Centro de Desenvolvimento da Oikodomo Brasil ............... 20 
1.3 Fatores de Sucesso de Desenvolvimento Distribuído 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 Limitações da NBR ISO/IEC 12207................................................. 30 
2.3 Rational Unified Process – RUP ............................................................... 31 
2.3.1 Análise Crítica............................................................................. 35 
2.4 Microsoft Solutions Framework – MSF ..................................................... 37 
2.4.1 Modelo de Gerência 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 Análise Crítica............................................................................. 40 
 iv
2.5 Agile Software Development - ASD ......................................................... 42 
2.5.1 Análise Crítica............................................................................. 47 
2.6 Extreme Programming – XP ................................................................... 48 
2.6.1 Análise Crítica............................................................................. 54 
3 Análise Comparativa entre os Processos de Desenvolvimento ............................ 56 
3.1.1 Definição dos Critérios de Análise .................................................. 56 
3.1.2 Análise Comparativa .................................................................... 58 
CONCLUSÕES ................................................................................................ 62 
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 64 
 
 v
LISTA DE FIGURAS 
Figura 1 – Mesma localização Física. ................................................................. 15 
Figura 2 – Distância Municipal. ......................................................................... 15 
Figura 3 – Distância Regional. .......................................................................... 16 
Figura 4 – Distância Continental. ...................................................................... 16 
Figura 5 – Distância Global. ............................................................................. 17 
Figura 6 – Distribuição em sub-equipes. ............................................................ 17 
Figura 7 – Distribuição individual. ..................................................................... 17 
Figura 8 – Equipe de Desenvolvimento Centralizada. ........................................... 18 
Figura 9 – Ilustração do Cenário 1. ................................................................... 20 
Figura 10 - Ilustração do Cenário 2. .................................................................. 21 
Figura 11 – Fatores de Sucesso do DDS............................................................. 21 
Figura 12 – Os três atores envolvidos................................................................ 24 
Figura 13 – Critérios de definição do nível de distribuição do DDS. ........................ 24 
Figura 14 – Relação da distância 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 – Gerência de Risco no MSF. .............................................................. 38 
Figura 18 – Os papéis definidos no MSF. ............................................................ 38 
Figura 19 – O modelo de processo do MSF. ........................................................ 40 
Figura 20 – Os elementos de um ...................................................................... 46 
Figura 21 – As três dimensões do escopo de um processo - Fonte: [COC 02] .......... 46 
Figura 22 – A instância de um escopo................................................................ 47 
Figura 23 – As quatro dimensões do XP. ............................................................ 49 
Figura 24 – O XP é visto como um conjunto de peças. ......................................... 50 
 
 vi
LISTA DE TABELAS 
Tabela 1 – Os critérios definidos para a análise comparativa. ................................ 58 
Tabela 2 – Análise comparativa. ....................................................................... 61 
 
 
 
 vii
LISTA DE ABREVIATURAS E SIGLAS 
ACM - Association for Computing Machinery 
ASD – Agile Software Development 
DDS – Desenvolvimento Distribuído 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 Informação 
XP – ExtremeProgramming 
 
 
 
8 
INTRODUÇÃO 
Hoje em dia, ao mesmo tempo em que a área da engenharia de software se 
desenvolve de uma forma cada vez mais rápida, é necessário desenvolver software de 
altíssima qualidade. Com o passar dos anos e durante a evolução desta área, é 
interessante observar como alguns dos princípios fundamentais desse 
desenvolvimento permanecem os mesmos de 30 anos atrás e como os desafios que os 
engenheiros de software encontram hoje são semelhantes aos existentes quando a 
engenharia de software ainda engatinhava. Após 30 anos, ainda temos que nos 
esforçar para desenvolver softwares confiáveis [PET 01]. 
Neste contexto, percebe-se cada vez mais a necessidade das organizações 
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 referência, 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 
seqüência de atividades existentes e a relação entre elas, incluindo neste contexto os 
métodos e as ferramentas que dão suporte ao modelo, procurando sempre a 
qualidade total, tanto do processo como do produto final gerado seguindo-se o 
processo. 
Também 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 distribuídos, ou seja, o Desenvolvimento 
Distribuído do Software (DDS). Hoje em dia as grandes organizações estão cada vez 
mais distribuindo seus processos de desenvolvimento de software ao redor do mundo, 
visando ganhos de produtividade, redução de custos, diluição 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 rápida e, além disso, 
se vê a necessidade de distribuir o desenvolvimento, trazendo muitos benefícios para 
as organizações. 
Por este motivo, o Trabalho Individual II tem como objetivo realizar um estudo 
aprofundado sobre o estado da arte do Desenvolvimento Distribuído de Software 
(DDS), suas características e definições, e dos principais modelos de processo de 
desenvolvimento de software existentes. Pretende-se analisar os diferentes cenários 
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 análise comparativa, pretende-se verificar que tipo de 
suporte cada um destes modelos de processo possui para um desenvolvimento 
distribuído de software. 
O capítulo 1 irá abordar a questão do desenvolvimento distribuído de software, 
analisando os diferentes cenários existentes. O capítulo 2 pretende descrever e 
analisar os principais modelos de processo de desenvolvimento software, identificando 
o estado da arte destes modelos. Por último, o capítulo 3 faz uma análise comparativa 
entre os processos analisados no capítulo 2, procurando sistematizar esta análise 
através de um critério de comparação previamente definido, e explicado no próprio 
capítulo. 
 
10 
1 Desenvolvimento Distribuído 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 série de problemas e desafios inerentes ao processo de 
desenvolvimento de software. Entre os problemas encontrados, os projetos de 
software freqüentemente apresentam cronogramas atrasados, execução orçamentária 
abaixo do previsto e produtos defeituosos. Uma das razões para estas situações, 
especialmente para projetos grandes, está na coordenação das atividades da equipe 
de projeto e na manutenção do controle do projeto. 
Hoje em dia, gerenciar grandes projetos de desenvolvimento de software tem 
se tornado uma tarefa cada vez mais complexa. Não apenas por causa do crescimento 
dos projetos, mas também por que as equipes de projeto vêm se distribuindo no 
tempo e no espaço, inserido no conceito de globalização que a sociedade têm 
vivenciado nos últimos anos. Isto configura então o Desenvolvimento Distribuído de 
Software (DDS), onde algumas pessoas envolvidas no processo de desenvolvimento 
estão fisicamente distantes. 
Várias ferramentas e ambientes têm sido desenvolvidos ao longo dos últimos 
quatro anos para ajudar no controle e coordenação das equipes de desenvolvimento 
que estão inseridas neste tipo de ambiente. Muitas destas ferramentas estão focadas 
no suporte aos procedimentos de comunicação formal tais como elaboração de 
documentos, processos automatizados e outros canais de comunicação não 
interativos. Um estudo de caso feito por [KRA 95] concluiu que o desenvolvimento de 
software necessita de um suporte extensivo para a comunicação informal e interativa. 
Além disso, viu-se em [PRI 02b] que trabalhar com DDS talvez seja um dos 
maiores desafios que o atual ambiente de negócios apresenta do ponto de vista do 
 11
processo de desenvolvimento de software. Muitas empresas estão distribuindo seu 
processo de desenvolvimento de software em países como Índia e Brasil. Muitas vezes 
este processo se dá dentro de um mesmo país, em regiões com incentivos fiscais ou 
de concentração de massa crítica em determinadas áreas. As empresas buscam 
vantagens competitivas em termos de custos, qualidade ou flexibilidade na área de 
desenvolvimento de sistemas [PRI 02], além de ganhos de produtividade e diluição de 
riscos [McC 96]. Neste caso, ao optar por instanciar um ambiente de desenvolvimento 
distante fisicamente da sua sede, uma organização começa a encarar diversos 
desafios de adaptação, diferenças 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 proporções 
maiores. 
Outsourcing é a prática de contratar uma organização externa para 
desenvolver um sistema, ao invés de desenvolver na sua própria sede (in-house) [McC 
96]. As organizações 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 código reutilizável. A combinação destes 
fatores pode resultar numa significativa redução no tempo necessário para 
desenvolver um produto. Muitas vezes os custos de desenvolvimento também podem 
diminuir. Uma das opções do outsourcing que vem se tornando bastante popular ao 
longo dos últimos anos é o offshore outsourcing. Organizações offshore são empresas 
que estão localizadas em algum outro país, e que oferecem custos mais baixos de 
desenvolvimento. Além disso, também oferecem uma qualidade que é, no mínimo, 
equivalente à qualidade das organizações localizadas no próprio país [McC 96]. 
O desenvolvimento de ambientes tecnológicos, 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 têm dado uma grande importância para este assunto. 
 12
Em 2001, em uma conferência anual em programação, sistemas, linguagens e 
aplicações orientadosa objeto (OOPSLA1), promovida pela ACM (Association for 
Computing Machinery), um painel com alguns dos principais pesquisadores da área de 
desenvolvimento de software que estavam participando da conferência apresentou a 
seguinte questão: “Como é possível ter um desenvolvimento ágil se a equipe de 
desenvolvimento estiver fisicamente distribuída, cada um trabalhando na sua casa?”. 
Todos os “painelistas” foram mais ou menos pela mesma resposta, dizendo "We 
wouldn't even try!”, ou seja, “Nós nunca tentamos!” [DAD 02]. 
Além disso, neste mesmo painel foram citados alguns pontos relacionados com 
a questão apresentada e o cenário mundial de desenvolvimento de software naquele 
momento. O principal ponto discutido foi o de que diversas experiências envolvendo o 
desenvolvimento distribuído de software estavam sendo realizadas, mas nenhuma 
delas tratava de casos reais, incluindo as pressões de prazos, custo e escopo, tão 
comuns em projetos da área de software. Eram estudos basicamente acadêmicos, 
com o objetivo de aproximar os pesquisadores desta nova realidade, permitindo a 
ampliação 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 então, a comunidade 
científica está desenvolvendo estudos empíricos na área de DDS. 
Por este motivo, devido à multiplicidade de possibilidades existentes neste 
contexto de DDS, neste capítulo busca-se identificar os principais critérios que 
caracterizam um ambiente distribuído de desenvolvimento de software e seu nível de 
distribuição, além de identificar cenários que combinam alguns destes critérios e 
ilustram o DDS. Alguns destes critérios já existem, como resultado de trabalhos 
publicados em congressos internacionais, como o OOPSLA’01 ou ainda o workshop 
PDTSD’022. Outros critérios foram identificados através 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 estão inseridas, considerando diversos cenários 
possíveis para o DDS. 
Estes critérios consideram a existência de três atores principais no processo, 
tendo papéis distintos uns dos outros, cada um com a sua importância. Estes atores 
são: 
 
Equipe de Desenvolvimento
Cliente
Usuário
DD
CC
UU 
A equipe de desenvolvimento representa todas as pessoas envolvidas no 
desenvolvimento de um determinado projeto, podendo também ser formada por um 
conjunto de sub-equipes. Esta equipe pode envolver pessoas responsáveis pela área 
de negócios, gerência de projetos, desenvolvimento, testes, controle de qualidade, 
responsáveis pelo suporte de ferramentas dentro do projeto, entre outros. O cliente é 
a pessoa física ou jurídica que solicitou e contratou o desenvolvimento de um 
determinado projeto. O usuário representa as pessoas responsáveis por fornecer 
todas as informações necessárias (requisitos) para o correto desenvolvimento do 
projeto e são responsáveis por utilizar o produto gerado. Às vezes, clientes e usuários 
podem ser as mesmas pessoas, representando os dois papéis simultaneamente. 
1.1 Critérios que caracterizam o nível de DDS 
Ao longo deste trabalho [ALT 98], [DAD 02], [EVA 00], [EVA 01], [BIU 02], 
[HAY 00] [McC 96] foram encontrados diversos critérios que, envolvendo os atores 
acima e combinados nas suas diversas possibilidades, podem caracterizar o nível de 
DDS. Os critérios encontrados são apresentados a seguir: 
- Distância física dos atores [DAD 02]; 
- Distribuição da equipe de desenvolvimento [DAD 02]; 
- Terceirização do desenvolvimento [McC 96]; 
- Diferenças culturais [DAD 02], [EVA 01]; 
 14
- Tamanho do projeto [DAD 02], [EVA 01]; 
Ao aprofundar-se a análise referente a estes critérios, concluiu-se que: 
- a terceirização (normalmente citada na literatura como outsourcing) não se 
caracteriza especificamente como um critério de DDS. Diversas empresas têm 
utilizado o conceito de outsourcing para representar uma estratégia de negócios onde 
uma unidade (subsidiária) da empresa localizada em outro país ou estado torna-se 
responsável pela atividade envolvendo o processo de desenvolvimento de software. 
Neste caso, o outsourcing não envolve uma terceirização no conceito tradicional, pois 
a unidade responsável pelo desenvolvimento é da própria empresa contratante. São 
inúmeros os exemplos de organizações que adotam esta estratégia na área de 
desenvolvimento de software (DELL Computers, Nestlê, HP, Bank of Boston, entre 
outras). Neste sentido, a questão da terceirização será abordada como uma 
característica das equipes participantes do processo de desenvolvimento e não como 
um critério de DDS. 
- cultura é, por definição, um fator multidimensional que pode afetar em 
diferentes maneiras a performance de projetos geograficamente distribuídos [EVA 01]. 
As diferenças culturais em um ambiente de DDS surgem das diferenças culturais 
entre os membros das equipes e entre os locais fisicamente distantes. Por isso, 
diferenças culturais são aspectos importantes para o DDS, pois diversos problemas 
podem ser causados por estas diferenças. Apesar de ser um critério importante, ele 
não se aplica para este estudo no sentido de ser um critério que caracterize a 
distribuição. As diferenças culturais são consideradas um fator crítico de sucesso no 
processo de DDS. 
- o tamanho de um projeto é um critério importante quando se opta pelo 
DDS, pois este critério pode indicar o tamanho da equipe, o volume de documentação 
existente e exigido, etc. Mas este critério também não se aplica para este estudo para 
efeito de caracterização do DDS e sim como uma dos fatores que podem levar uma 
empresa a optar por um desenvolvimento distribuído, assim como custo ou prazos. 
 15
Sendo assim, a seguir serão detalhados os critérios julgados convenientes para 
esta pesquisa, para efeito de caracterização de um ambiente de DDS. 
1.1.1 Distância física dos atores 
A distância física dos atores participantes do processo é um critério utilizado 
para definir o quão distantes estão os três atores envolvidos e suas respectivas áreas 
de negócio. Para este critério foram definidas cinco situações que ajudam a verificar 
qual o tipo de distância física existente e suas características principais. As situações 
para a distância física dos atores estão definidas da seguinte maneira: 
- Mesma localização física: esta é a situação onde a empresa possui toda a 
sua equipe instalada em um mesmo local (sala, prédio, universidade), considerando 
todos os atores envolvidos. A figura 1 ilustra esta situação: 
D
D
D
D
C
U
DD
D
D
D
C
U
 
Figura 1 – Mesma localização Física. 
- Distância municipal: esta é uma situação onde a equipe está localizada 
dentro da mesma cidade, estando fisicamente distante no máximo em 50km. Neste 
cenário a equipe pode se reunir quase que diariamente. A figura 2 ilustra esta situação 
mostrando uma equipe localizada dentro da cidade de Porto Alegre. 
D
C
U
DD
CC
UU
 
Figura 2 – Distância Municipal. 
 16
- Distância Regional: esta situação caracteriza-se por ter a equipe localizada 
dentro de um mesmo Estado ou de um mesmo País, estando distante entre três e seis 
horas de viagem de avião, em zonas de fuso horário igual ou vizinho. Nesta situação, 
a equipe pode se reunir em curtos intervalos de tempo. A figura 3 ilustra este cenário, 
mostrando uma equipe localizada dentro do estado do Rio Grande do Sul. 
DD
CC
UU
 
Figura 3 – Distância Regional. 
- Distância Continental: esta situação caracteriza-se por ter a equipe 
separada dentro de um mesmo continente, onde cada integrante deve estar em uma 
zona de fuso horário de no máximo 4 horas de diferença do outro.Nesta situação já 
se torna inconveniente uma reunião com toda a equipe de forma freqüente, mas 
algumas viagens podem ocorrer. A figura 4 ilustra este cenário, mostrando uma 
equipe de desenvolvimento localizada dentro do continente Europeu. 
DD
CC
UU
 
Figura 4 – Distância Continental. 
- Distância Global: esta situação 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 duração de 24 
horas. Nesta situação, normalmente os membros da equipe se reúnem por algumas 
 17
semanas no início de um projeto. A figura 5 ilustra este cenário, mostrando uma 
equipe distribuída em 3 continentes (América do Norte, América do Sul e Ásia). 
DD
CC
UU
 
Figura 5 – Distância Global. 
1.1.2 Distribuição da Equipe de Desenvolvimento 
Ter toda a equipe participante do processo de desenvolvimento de software 
(cliente, usuário e equipe de desenvolvimento) distante fisicamente de acordo com 
alguma das cinco situações previstas no item anterior não indica que a equipe de 
desenvolvimento esteja distribuída. Sendo assim, um ambiente de desenvolvimento 
distribuído de software pode ter a equipe de desenvolvimento estruturada em duas 
situações principais: 
- Equipe de desenvolvimento distribuída: esta situação indica que a equipe 
de desenvolvimento pode ser distribuída de forma a trabalhar distante fisicamente. 
Esta distribuição pode ter cada integrante da equipe distante fisicamente, ou podem 
existir subequipes de desenvolvimento que estão distribuídas. As figuras 6 e 7 a seguir 
ilustram estas possibilidades: 
DD DD DD DD
 
DD
DD
DD
DD
 
Figura 6 – Distribuição em sub-equipes. Figura 7 – Distribuição individual. 
 18
- Equipe de desenvolvimento centralizada: esta situação indica que a 
equipe de desenvolvimento estará localizada no mesmo espaço físico, ou seja, 
trabalhará sempre fisicamente junta. A figura 8 ilustra a equipe de desenvolvimento 
localizada em um mesmo espaço físico. 
DD DD
DD DD DD DD
DD DD
 
Figura 8 – Equipe de Desenvolvimento Centralizada. 
Cabe salientar que a distribuição da equipe de desenvolvimento não leva em 
conta a localização dos outros atores, cliente e usuário. 
1.2 Alguns Cenários de Desenvolvimento Distribuído de Software (DDS) 
Um ambiente para o desenvolvimento distribuído de software (DDS) tem 
diversas possibilidades de configuração. Conforme foi apresentado no item 1.1, dois 
critérios podem auxiliar na definição do nível de distribuição existente. Cada critério 
possui um conjunto de situações, e a combinação de uma determinada situação de 
cada critério 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 usuários. 
O nível de DDS a ser utilizado no processo de desenvolvimento de software 
depende da organização e do projeto a ser desenvolvido. Este processo de DDS pode 
ser implementado internamente na própria empresa, onde cliente, usuário e equipe de 
desenvolvimento são da própria empresa, ou envolvendo outras empresas, onde os 
clientes e os usuários não pertencem à empresa que desenvolverá o projeto. 
Baseando-se nestas perspectivas e nos critérios anteriormente citados, a seguir serão 
 19
apresentados dois cenários diferentes, baseados em casos reais, que possuem um 
desenvolvimento distribuído de software. O primeiro cenário corresponde a uma 
empresa que possui os três atores (equipe de desenvolvimento, cliente e usuário) no 
seu quadro de funcionários, cada um na sua área de negócio. Já o segundo cenário 
corresponde a uma empresa que possui apenas uma equipe de desenvolvimento, 
sendo que clientes e usuários são atores externos, que contratam o serviço 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 são cenários reais 
de desenvolvimento distribuído de software, cada um com suas características 
específicas. Portanto, foram analisados: 
- o Centro de Pesquisa em E-Business DELL/PUCRS; 
- o Centro de Desenvolvimento da Oikodomo no Brasil; 
1.2.1 Cenário 1: Centro de Pesquisa em E-Business DELL/PUCRS 
Neste cenário, a empresa DELL Computers possui um centro de pesquisa e 
desenvolvimento de software voltado para e-business, sendo responsável, entre 
outras atividades, pelo desenvolvimento dos softwares de e-business corporativos da 
empresa, ou seja, sistemas que serão utilizados na própria empresa (sistemas para 
outros setores, automatização de determinadas atividades, entre outros). Sabendo-se 
dos dois critérios definidos no item 1.1, pode-se enquadrar este centro de pesquisa e 
desenvolvimento no seguinte cenário: 
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 distância continental, onde o cliente e/ou o usuário 
podem estar localizados nos Estados Unidos enquanto que a equipe de 
desenvolvimento está localizada em Porto Alegre. Além disso, existe uma 
possibilidade de distribuição da equipe de desenvolvimento, visto que o 
analista de negócios pode estar nos Estados Unidos, bem como a pessoa responsável 
 20
pela instalação do sistema, caso o sistema esteja sendo desenvolvido para ser 
utilizado em toda a empresa e sua instalação seja feita na sede, ou seja, nos Estados 
Unidos. Por último, alguns integrantes da equipe de desenvolvimento podem ser 
terceirizados, sendo contratados para um período específico de tempo, mas estes 
integrantes não estão distribuídos, estando fisicamente próximos de todo o resto da 
equipe. A figura 9 ilustra a configuração deste cenário de desenvolvimento. 
DD
CCUU
DD
DD
 
Figura 9 – Ilustração do Cenário 1. 
O que se percebe na figura 9 é que os atores estão fisicamente distribuídos, 
mas a equipe de desenvolvimento está localizada no mesmo espaço físico, tendo um 
integrante terceirizado. 
1.2.2 Cenário 2: Centro de Desenvolvimento da Oikodomo Brasil 
Neste cenário, a empresa Oikodomo Global Technologies possui um centro de 
desenvolvimento de software no Brasil, localizado em Porto Alegre, sendo responsável 
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 
critérios definidos no item 1.1, pode-se enquadrar este centro de desenvolvimento de 
software no seguinte cenário: 
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 distância continental, onde o cliente e 
o usuário estão localizados nos Estados Unidos enquanto que a equipe de 
desenvolvimento está localizada em Porto Alegre e também nos Estados Unidos, 
caracterizando assim a distribuição da equipe de desenvolvimento, visto que o 
analista de negócios está nos Estados Unidos, enquanto que os outros integrantes da 
equipe de desenvolvimento estão em Porto Alegre. Por último, alguns integrantes da 
 21
equipe de desenvolvimento podem ser terceirizados, sendo contratados para um 
período específico de tempo, mas estes integrantes não estão distribuídos, estando 
fisicamente próximos de todo o resto da equipe. A figura 10 ilustra como ocorre o 
desenvolvimento de um projeto de software dentro desta empresa, neste exemplo 
específico. 
DD
CCUU
DD
DD
DD
 
Figura 10 - Ilustração do Cenário 2. 
O que se percebe na figura 10 é que, além de os atores estarem fisicamente 
distribuídos,existe a distribuição da equipe de desenvolvimento, onde existe um 
analista de negócios localizado nos Estados Unidos junto com clientes e usuários, 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 Distribuído de Software (DDS) 
A pesquisa realizada com relação à identificação dos critérios de DDS [ALT 98], 
[DAD 02], [EVA 00], [EVA 01], [BIU 02], [HAY 00], mostrou a existência de uma série 
de fatores envolvidos no processo. Alguns destes fatores foram utilizados para 
caracterizar o DDS e seu nível de presença (distância física e distribuição da equipe de 
desenvolvimento). Outros fatores identificados podem ser considerados como fatores 
críticos 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
DIFERENÇAS
CULTURAIS
COORDENAÇÃO
COOPERAÇÃO
CONFIANÇA
COMUNICAÇÃO
 
Figura 11 – Fatores de Sucesso do DDS 
 22
- Comunicação: a comunicação em um DDS é a chave para o bom andamento 
e execução de um projeto. Já a falta de comunicação faz com que as equipes 
fisicamente distantes não saibam de informações básicas sobre o projeto, sobre a 
equipe de projeto, entre outros. Por isso, deve existir um fluxo de informações ágil e 
eficaz entre os membros da equipe; 
- Confiança: confiança em um DDS é de vital importância para o bom fluxo de 
informações entre as equipes distribuídas. Ter confiança é ter segurança e firmeza no 
trabalho da equipe como um todo, independente de quem faça este trabalho. Por isso, 
torna-se essencial a procura de mecanismos que propiciem o estabelecimento de um 
clima de confiança nas relações e ações entre os atores envolvidos; 
- Cooperação: cooperação em um DDS significa colaboração da equipe para 
um objetivo comum, ou seja, ajudar e pensar como equipe. Por isso, é fundamental a 
cooperação entre as equipes fisicamente distantes, pois de nada adianta uma boa 
coordenação e uma ótima comunicação se não existir cooperação entre os membros 
das equipes; 
- Coordenação: a coordenação 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 coordenação das 
atividades de desenvolvimento; 
- Diferenças Culturais: quando se desenvolve software em um cenário onde 
exista o DDS, uma das primeiras atividades deve ser verificar qual o nível de 
diferenças culturais existentes entre as equipes fisicamente distantes, pois às vezes 
determinadas ações podem ser mal interpretadas pelo simples fato de ser parte da 
cultura de uma equipe e não da outra. Estas diferenças devem ser identificadas e 
acomodadas entre os participantes do processo. 
1.4 Sintetizando a Pesquisa sobre DDS 
A partir da análise crítica do estudo realizado, buscou-se identificar os critérios 
a serem adotados na pesquisa com relação ao DDS visando o futuro do trabalho. Num 
 23
primeiro momento procurou-se definir situações onde exista o desenvolvimento 
distribuído de software. Sendo assim, chegou-se na seguinte definição: 
A caracterização de um ambiente de Desenvolvimento Distribuído de 
Software (DDS) ocorre sempre que pelo menos um dos atores envolvidos (equipe de 
desenvolvimento, clientes, usuários) estiver fisicamente distante dos demais. 
Ao considerar esta definição para DDS, verificou-se a necessidade de utilizar 
uma escala para definir o nível (grau) da distribuição existente. Verificaram-se 
inúmeras tentativas de representação, até chegar em uma representação tida como a 
mais adequada. Como resultado deste estudo, propõem-se os seguintes critérios que 
definem o nível de DDS. 
- Distância física inter-atores; 
- Distância física intra-atores. 
A distância física inter-atores é o critério que, considerando os três atores 
existentes (equipe de desenvolvimento, clientes e usuários), define a distância física 
existente entre estes atores. Por outro lado, a distância física intra-atores é o 
critério que define a distância física existente dentro de cada equipe de atores (por 
exemplo, dentro da equipe de desenvolvimento, ou do conjunto de usuários). Esta 
distância física, 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 crítico somente a partir 
do momento que a distância física inter-atores ou intra-atores passa a ser regional. 
Isto se deve ao fato de que em uma distância no máximo municipal, reuniões entre 
todos os integrantes da equipe são facilmente agendadas e é relativamente fácil 
seguir um processo de desenvolvimento de software usual, como o RUP, MSF, 
Extreme Programming ou o Agile Software Development. Já a partir de uma distância 
regional, outros tipos de mecanismos são necessários para gerenciar as equipes e os 
projetos fisicamente distribuídos, tais como mecanismos de comunicação, 
 24
padronização, além de outras características importantes (citadas anteriormente neste 
estudo). 
Buscando-se uma representação gráfica para os critérios que definem o nível 
de distribuição do DDS, propõe-se primeiramente, na figura 12, uma representação 
para os três atores envolvidos na definição do nível de distribuição de DDS. 
ClientesUsuáriosEquipe deDesenvolvimento
DD CCUU
 
Figura 12 – Os três atores envolvidos. 
Lodo a seguir, utilizando os atores identificados, a figura 13 representa 
graficamente os critérios propostos para definir o nível de distribuição do DDS (de 
distância física inter-atores e distância física intra-atores) e a relação entre eles. 
ClientesEquipe de
Desenvolvimento
Usuários
DD CC
UU
Distância
Legenda
Inter-atores
Intra-atores Intra-atores
Intra-atores 
Figura 13 – Critérios de definição do nível de distribuição do DDS. 
Considerando a distância que pode existir inter-atores ou intra-atores e 
sabendo-se que o DDS torna-se crítico muitas vezes somente a partir da distância 
regional, é possível relacionar esta distância 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 – Relação da distância com os processos de desenvolvimento. 
 25
É bom lembrar que os cenários do item 1.2 ilustram os critérios previamente 
definidos, utilizando para isto os atores existentes. Existem muitas outras 
possibilidades de configuração para o DDS, e não é difícil verificar nas empresas hoje 
em dia diversas possibilidades de distribuição do desenvolvimento de software, pois 
cada empresa tem suas próprias características e configura o desenvolvimento da 
forma mais alinhada às suas estratégias, seja ele offshore ou não. 
Além disso, é difícil encontrar na literatura um material que permita obter 
critérios e classificações genéricas para ambientes distribuídos. Neste sentido, muita 
pesquisa vem sendo feita e muitos autores têm estudado este assunto [EVA 00], [EVA 
01], [LAY 00], [HAY 00], mas o que se pode concluir é que o desenvolvimento 
distribuído de software (DDS) e o desenvolvimento offshore são processos bastante 
dinâmicos que podem ter inúmeras configurações e diversos cenários possíveis, 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 
configuração. 
Neste estudo não se aprofundou a análise das razões que levam uma 
organização a adotar estratégias de distribuição do seu processo de desenvolvimento 
de software. Aspectos como custos, oportunidades estratégicas e políticas 
empresariaisdesempenham relevante papel neste sentido. 
Finalmente, existe uma forte tendência hoje em dia de as empresas 
distribuírem 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 negócios, e ter mecanismos capazes de gerir e suportar 
este tipo de configuração é 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], não 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 capítulo 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. Além disso, é prática comum das empresas de utilizar 
contribuições de um conjunto de diferentes metodologias e modelos. 
A seguir serão 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 necessária a descrição 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 padronização 
no âmbito mundial. Organismos nacionais que são membros da ISO ou da IEC 
participam do desenvolvimento de Normas Internacionais através de comitês técnicos 
criados pela respectiva organização para tratar de áreas específicas de atividades 
técnicas. Comitês técnicos da ISO e da IEC colaboram em campos de interesse mútuo. 
Outras organizações internacionais, governamentais ou não, mantém ligações com a 
ISO e a IEC e também participam deste trabalho de padronização [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 referência para a indústria de software. Cabe ressaltar 
que esta norma não detalha metodologias, métricas e métodos, nem ambientes, 
ferramentas e técnicas utilizadas nos processos. Ela se concentra apenas na definição 
e descrição dos processos. Sendo assim, a seguir faz-se uma síntese da NBR ISO/IEC 
12207 apresentando como um processo pode e deve ser estruturado [ISO 98]. 
A NBR ISO/IEC 12207 está dividida em três 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 várias atividades. 
 
Figura 15 – Estrutura da NBR ISO/IEC 12207. 
A seguir será apresentada uma descrição dos conjuntos de processos. 
 28
2.2.1 Os Processos Fundamentais 
Os Processos Fundamentais visam descrever as partes indispensáveis de um 
ciclo de vida de software. Em termos gerais, são os processos que tratam desde a 
aquisição, passando pelo desenvolvimento, manutenção, até o fornecimento do 
software [ISO 98]. Estes processos são divididos em cinco processos menores, citados 
logo a seguir: 
- Processo de Aquisição (Acquisition): define as atividades e as tarefas de 
quem adquire um produto ou serviço de software através 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 Operação (Operation): define as atividades e tarefas de um 
operador de um sistema de software. O processo cobre a operação de software e o 
suporte operacional aos usuários. 
- Processo de Manutenção (Maintenance): define as atividades e tarefas 
do responsável pela manutenção de um produto de software, preservando a 
integridade do produto existente; 
2.2.2 Processos de Apoio 
Os Processos Fundamentais, como foi dito anteriormente, são processos 
indispensáveis, ou seja, sem eles não existe software. Mas geralmente esses 
processos necessitam de apoio, que pode ocorrer através de um conjunto de outros 
processos, com intenções específicas de oferecer suporte para partes distintas dos 
Processos Fundamentais. Tais processos são denominados de Processos de Apoio. 
Os Processos de Apoio são 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 são divididos em oito processos menores, que são: 
 29
- Processo de Documentação (Documentation): processo definido para 
armazenar a informação produzida por um ciclo de processo, incluindo atividades de 
planejar, projetar, desenvolver, editar, distribuir e manter todos os documentos; 
- Processo de Gerência de Configuração (Configuration Management): 
processo definido para identificar, definir e criar uma linha de base para controlar 
modificações e liberação dos itens contidos em um software; 
- Processo de Garantia da Qualidade (Quality Assurance): provê um 
framework para garantir a qualidade e a aderência dos produtos de software com os 
seus requisitos e com o plano estabelecido para o desenvolvimento; 
- Processo de Verificação (Verification): provê a avaliação de um produto 
ou serviço de uma atividade qualquer. As verificações determinam quando os 
requisitos de um sistema estão completos e corretos. Também indicam quando as 
saídas de uma atividade irão satisfazer todos os requisitos ou condições impostas nas 
atividades anteriores. Este processo cobre a verificação de processo, requisitos, 
projeto, codificação, integração e documentação; 
- Processo de Validação (Validation): a validação determina se o sistema, 
ao seu final, esta de acordo com o que foi especificado para o seu uso. A validação 
não substitui outras avaliações; 
- Processo de Revisão Conjunta (Joint Review): provê um framework para 
interações entre o revisor e o revisado. As revisões ocorrem tanto no nível gerencial 
quanto no nível técnico; 
- Processo de Auditoria (Audit): provê um framework para uma auditoria 
formal nos produtos e serviços dos fornecedores; 
- Processo de Resolução de Problema (Problem Resolution): provê o 
mecanismo para solucionar problemas e tomar as corretas providências assim que os 
problemas foram detectados. 
2.2.3 Processos Organizacionais 
Os Processos Fundamentais, além de necessitarem de apoio para executar as 
suas tarefas, também precisam ser administrados. Para isto, existem os Processos 
 30
Organizacionais, cujo objetivo é a evolução da organização. Os Processos 
Organizacionais estão comprometidos com o melhoramento contínuo da estrutura, das 
pessoas e dos processos dentro de uma empresa. Estes processos geralmente são 
empregados fora dos domínios dos projetos, mas seus ensinamentos podem e 
devem contribuir para o melhoramento da organização como um todo [ISO 98]. Estes 
processos são divididos em quatro processos menores, a saber: 
- Processo Gerencial (Management): define as atividades genéricas e as 
tarefas de um gerente, tais como os processos de aquisição, fornecimento, operação, 
manutenção ou suporte;- Processo de Infra-Estrutura (Infrastructure): define as atividades 
necessárias para estabelecer e manter uma infra-estrutura base para o ciclo de vida 
de software; 
- Processo de Melhoria (Improvement): provê as atividades básicas que 
uma organização 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 níveis técnico e gerencial para os recursos e 
habilidades que necessitam ser treinadas ou melhoradas. 
2.2.4 Limitações da NBR ISO/IEC 12207 
A NBR ISO/IEC 12207 não substitui a gerência 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 ações 
podem ser realizadas. Um ponto que deve ser lembrado é que a norma apenas 
contém um conjunto de blocos bem definidos (processos). A organização 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 organização 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 Corporation3. Suas principais características são um 
desenvolvimento iterativo e incremental, orientado a objetos, com foco na criação de 
uma arquitetura robusta, análise de riscos e utilização de casos de uso para o 
desenvolvimento. Ele cobre as seguintes práticas [KRU 00]: 
- Processo interativo de desenvolvimento de software; 
- Gerenciamento de requisitos; 
- Uso de arquiteturas baseadas em componentes; 
- Modelagem visual; 
- Verificação contínua de qualidade; 
- Controle de mudanças; 
O RUP foi desenvolvido para ser aplicável a uma grande classe de projetos 
diferentes e pode ser considerado como um framework genérico para modelos de 
processos de desenvolvimento. Isso significa que ele deve ser configurado para ser 
usado eficientemente. A configuração pode ser feita para empresas (para definir o 
processo padrão de desenvolvimento da empresa) ou mesmo para projetos específicos 
e normalmente envolve a remoção e/ou modificação de atividades do framework, 
instanciando assim alguns modelos de processo de desenvolvimento [ALC 02]. 
O RUP é composto por quatro fases bem definidas: concepção (inception), 
elaboração (elaboration), construção (construction) e transição (transition), 
cada uma com objetivos específicos. 
Na fase de concepção deve-se estabelecer o escopo e a viabilidade econômica 
do projeto. Na fase de elaboração o objetivo é eliminar os principais riscos e 
estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. 
 
3 Rational Software Corporation – http://www.rational.com. 
 32
Na fase de construção um produto completo é desenvolvido de maneira 
iterativa até que esteja pronto para ser entregue aos usuários, o que ocorre na fase 
de transição, onde uma versão beta do sistema é disponibilizada. 
No final da fase de transição pode ser iniciado um novo ciclo de 
desenvolvimento para a evolução do produto, o que envolveria todas as fases 
novamente. Todas as fases são finalizadas com um milestone (marco) que verifica se 
os objetivos da fase foram alcançados. 
Cada fase pode comportar várias iterações e cada iteração, por sua vez, está 
organizada em workflows (figura 16) que descrevem o que deve ser feito em termos 
de atividades, responsáveis e os artefatos que devem ser gerados, além do fluxo das 
atividades. O RUP fornece modelos (templates) para cada artefato e guias (guidelines) 
para a execução de suas atividades. 
As iterações também são finalizadas com milestones, que devem controlar se 
foram cumpridos os objetivos específicos da iteração, 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 são descritos sucintamente a seguir [RAT 98]. 
- Modelagem do Negócio (Business Modeling): um dos grandes problemas 
hoje em dia é que a comunidade da engenharia de software e a comunidade da 
engenharia de negócios não se comunicam como deviam. Com isso, os requisitos de 
negócio não são utilizados corretamente como entrada para o desenvolvimento de um 
determinado software. Por isso, a modelagem do negócio envolve o entendimento da 
 33
estrutura e dinâmica da organização cliente, garantindo que clientes, usuários e 
desenvolvedores tenham a mesma visão da organização para a qual será feito o 
desenvolvimento. Isto é feito através da documentação dos processos de negócio 
utilizando casos de uso de negócio. Mesmo assim, muitos projetos optam por não 
fazer a modelagem do negócio; 
- Requisitos (Requirements): em linhas gerais, envolve a definição dos 
requisitos do sistema e de como gerenciar escopo e mudanças de requisitos. O 
objetivo é descrever o que o sistema deve fazer e permitir que os desenvolvedores e o 
cliente concordem com esta descrição. Para isto são gerados alguns artefatos para 
documentar estes requisitos. Os requisitos podem ser funcionais (o que o sistema 
deve fazer) e não-funcionais (interface, idioma, etc.). Os requisitos funcionais são 
modelados utilizando-se casos de uso, enquanto que os requisitos não-funcionais são 
descritor em uma especificação adicional; 
- Análise e Projeto (Analysis and Design): envolve a tradução dos 
requisitos numa especificação 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 possíveis mudanças no futuro. O resultado é um modelo 
de projeto e opcionalmente um modelo de análise, que servem como uma abstração 
do código a ser implementado e devem estar centrados na noção de arquitetura do 
sistema; 
- Implementação (Implementation): envolve o desenvolvimento de código. 
O objetivo da implementação é definir a organização do código, organizando os 
subsistemas em camadas, além de implementar as classes, objetos e componentes. 
Além disso, envolve o teste de unidade e o teste de integração. O RUP trabalha muito 
forte com o conceito de componentes e reutilização, facilitando a manutenção do 
sistema; 
- Teste (Test): envolve a verificação do sistema como um todo. Devem ser 
verificadas as interações entre os objetos, a integração 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 distribuição. O RUP propõe 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 possível, reduzindo os custos de possíveis correções. Além 
disso, testes automatizados devem ser feitos e três dimensões de qualidade devem 
ser consideradas: confiabilidade, funcionalidade e performance; 
- Distribuição (Deployment): envolve o empacotamento, distribuição e 
instalação do software, além de um treinamento para os usuários, assim como o 
planejamento e condução de beta testes. Também devem ocorrer migrações de dados 
existentes em sistemas antigos, além de ocorrer a aceitação formal por parte do 
cliente. Embora quase todas as atividades estejam concentradas na fase de transição, 
muitas delas podem e devem ser incluídas em fases anteriores, para preparar a 
distribuição do software assim que acabar o seu desenvolvimento.Os workflows de suporte compreendem atividades necessárias para a execução 
dos workflows de engenharia de software [RAT 98]. São eles: 
- Gerência 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 práticos de 
planejamento, controle de recursos humanos, execução e monitoramento dos 
projetos; 
- Gerência de Configuração e Mudanças (Configuration and Change 
Management): envolve o gerenciamento de todos os artefatos gerados durante o 
desenvolvimento do software. Este gerenciamento ajuda a evitar confusões nos 
artefatos gerados, bem como alterações simultâneas de um determinado artefato, ou 
ainda, evita que sejam geradas múltiplas versões de um artefato ou do próprio 
software. Este workflow descreve como se pode gerenciar um desenvolvimento 
paralelo, além de auxiliar na automatização do processo de construção. Por último, 
provê mecanismos para gerência de mudança, ou seja, como reportar os defeitos 
 35
encontrados ou alteração de requisitos, gerenciá-los ao longo do desenvolvimento e 
utilizar estes dados para gerar métricas e controlar a evolução do software ao longo 
do tempo; 
- Configuração do Ambiente (Environment): envolve a organização do 
ambiente de trabalho para a equipe do projeto e a configuração do RUP para o 
projeto. A organização do ambiente de trabalho envolve o suporte ao processo e às 
ferramentas que serão utilizadas. Além disso, este workflow fornece um Development 
Kit com guias, modelos e ferramentas necessárias para personalizar o processo. 
Aspectos tais como seleção, aquisição e funcionamento das ferramentas e a 
manutenção do ambiente de desenvolvimento não são considerados neste workflow. 
2.3.1 Análise Crítica 
O Rational Unified Process (RUP) é um framework para processos de 
desenvolvimento de software que permite a configuração e a instanciação de diversos 
modelos de processos. Para ser utilizado, uma tarefa a ser executada é justamente a 
configuração do que será utilizado. 
Em junho de 2001, Martin Fowler publicou no seu website a sua visão sobre o 
RUP. Ele disse que por várias vezes ouviu as pessoas falarem que utilizavam o RUP 
com um ciclo de vida de desenvolvimento tradicional (modelo cascata4). Para sua 
surpresa, ele sabia que a equipe responsável pelo RUP, entre eles Philippe Kruchten, 
eram totalmente adeptos ao desenvolvimento iterativo e ao ciclo de vida de 
desenvolvimento espiral5. Por isso, ele acha que os líderes do RUP devem enfatizar as 
reais e principais características 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 vários contextos de 
aplicações (e-business, sistemas corporativos, etc.) e em diferentes portes de projeto. 
Alem disso, é versátil e tem mais de 50% do seu uso focado no e-business e no 
 
4 Definições sobre o ciclo de vida tradicional podem ser encontradas em [PRI 02b]. 
5 Definições sobre o ciclo de vida espiral podem ser encontradas em [PRI 02b]. 
 36
planejamento [KRU 01]. Hoje em dia é um padrão de referência 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 
vários conceitos da RUP dentro do seu processo de desenvolvimento. 
Por outro lado, por ser um framework que possui diversas opções de modelos a 
serem configurados, é um processo que não diz exatamente o que deve ser feito, mas 
diz tudo o que pode ser feito. Por este motivo, dependendo da configuração 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 seqüencial, e por outro lado por ser um processo dinâmico 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 padrão do próprio 
framework. Por último, pode-se dizer que o RUP não oferece suporte adequado para 
gerência de comunicação nem para a gerência de recursos humanos, além de ser 
proprietário, ou seja, não é possível encontrar, gratuitamente, informações completas 
sobre todas as suas práticas. Existem relatórios e artigos escritos por diversos autores 
falando sobre o RUP, mas apenas adquirindo livros ou o próprio software de suporte 
ao RUP é possível ter um conhecimento completo, configurar e colocá-lo em prática. 
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 necessário que o RUP ofereça um 
conjunto de atividades que dê suporte para o Desenvolvimento Distribuído de 
Software, desde o planejamento, passando pela execução, até a avaliação dos 
softwares desenvolvidos pelas empresas. E no RUP, tudo o que existe hoje em relação 
ao DDS são apenas observações e comentários de alguns autores, mas nenhuma 
prática ou atividade formalizada. 
 37
2.4 Microsoft Solutions Framework – MSF 
Originalmente baseado nas “best practices” (melhores práticas) coletadas do 
desenvolvimento de produtos da Microsoft, o Microsoft Solutions Framework foi criado 
em 1994 para o Microsoft Consulting Services (MCS) promover a resolução de 
problemas de negócios utilizando-se de soluções técnicas. Devido ao sucesso 
conseguido, a Microsoft saiu um pouco da sua missão original e começou um plano de 
desenvolvimento e expansão. Hoje em dia existe um grande grupo que coleta as 
melhores práticas dos desenvolvedores, grupos de TI (Tecnologia da Informação), 
consultores, clientes e parceiros em todo o mundo. Estas práticas são analisadas e 
integradas ao MSF, que hoje é formado por conceitos, modelos, práticas e princípios 
utilizados pelo MCS, desenvolvedores, parceiros e consultores [MIC 99]. 
Segundo a Microsoft, a tecnologia não é a única peça em uma solução de 
sucesso. Pessoas, processos e a gerência de risco têm um papel importante no 
sucesso de um projeto, e são estes os três fatores considerados mais importantes 
dentro do MSF. Além disso, trabalhar e ter uma comunicação efetiva, alinhando as 
soluções técnicas com os requisitos de negócio são fatores críticos para o sucesso e 
são as vezes os mais difíceis de se alcançar [MIC 99]. 
A partir dos três fatores citados anteriormente, a seguir serão detalhados os 
modelos correspondentes a cada um destes fatores, que são considerados a base 
deste framework de desenvolvimento de software proposto pela Microsoft. Estes 
modelos procuram dar uma visão das melhores práticas com relação à gerência de 
pessoal, gerência de riscos, processos e tecnologia. 
2.4.1 Modelo de Gerência de Risco do MSF 
O MSF identifica as seguintes características em um risco: 
- O risco é inerente em todo o projeto, está sempre presente como uma 
possibilidade de acontecer, nunca como uma certeza; 
- O risco não é nem ruim nem bom, e não é algo a ser evitado. É apenas uma 
oportunidade identificada; 
 38
- O risco não é algo para se ter medo, mas sim algo para ser gerenciado, 
minimizando as incertezas e criando soluções para cada risco identificado. 
O modelo de gerência de risco do MSF utiliza três estratégias para gerenciar o 
risco: redução do risco, transferir o risco e prevenir o risco. Além disto, este modelo 
possui cinco passos onde a equipe é capazde identificar os riscos e decidir pela 
melhor ação (figura 17). 
Identificar Analisar
Controlar Planejar
Monitorar
Documento
de avaliação
de riscos
os 10+
Documento
de avaliação
de riscos
os 10+
Riscos
Identificados
1 2
3
4
5
Riscos
Liberados
Este processo gera um documento de avaliação de 
riscos que é constantemente atualizado
Este processo gera um documento de avaliação de 
riscos que é constantemente atualizado
 
Figura 17 – Gerência de Risco no MSF. 
A figura 17 mostra os cinco passos propostos pelo MSF para gerenciar os riscos 
de um projeto. Após serem identificados, os riscos são transformados em informação 
que podem ser analisadas pelos integrantes da equipe com objetivo de tomar algumas 
decisões. Depois é feito um planejamento para suportar as decisões tomadas no passo 
anterior, para então 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 papéis neste modelo (figura 18) e a chave para que este modelo funcione é a 
comunicação [MIC 99]. 
Gerência de
Projeto
Gerência de
Logística
Gerência de
Produto
Educação do
Usuário
Desenvolvimento
Teste
Comunicação
 
Figura 18 – Os papéis definidos no MSF. 
 39
Este modelo possibilita que as equipes de projeto sejam flexíveis e escaláveis, 
para todos os tipos de projetos. O modelo pode ser aplicado tanto para pequenos 
quando para grandes projetos. Embora o modelo possua seis papéis, uma equipe não 
necessita sempre de no mínimo seis pessoas. O importante é que estes papéis 
estejam representados dentro de cada equipe, mas quando uma pessoa assume mais 
de um papel começam a surgir alguns riscos no projeto. O desenvolvimento, em 
particular, não deve ser combinado com nenhum outro tipo de papel. 
Para formar as equipes, o MSF considera três tipos de projetos que podem 
existir, que são: 
- Enterprise Architecture (EA): projetos que incluem melhorias do processo 
de negócio, desenvolvimento de aplicações de negócio, consolidação de plataformas e 
infra-estrutura de desenvolvimento, avaliações de tecnologia, consolidação de 
sistemas de negócios; 
- Application Development (AD): projetos onde existe o desenvolvimento de 
sistemas, com codificação, teste e resolução de possíveis problemas, antes que os 
sistemas sejam liberados para uso em ambiente de produção; 
- Infrastructure Deployment (ID): projetos que implementam tecnologias 
no nível de plataformas de desenvolvimento, foram testadas e estabilizadas e estão 
prontas para serem liberadas. São projetos tais como sistemas operacionais ou 
sistemas de transferência de mensagens (Messaging Systems). 
Em cada um destes tipos de projetos existe um conjunto de papéis que devem 
ser considerados na formação das equipes. Para mais detalhes, a descrição 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 execução 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 
aplicações. A partir disto, ela utilizou modelos de processos que continham os 
princípios 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 princípios do ciclo de vida espiral com o ciclo de vida em 
cascata, incorporando os benefícios da possibilidade de planejamento, previsões e 
certezas do ciclo de vida em cascata com os benefícios do feedback e criatividade do 
ciclo de vida espiral. 
O modelo de processo do MSF tem como proposta a existência 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). 
Fase Dois
Fa
se
Um
Fase Quatro Fa
se
Tr
ês
Marco
Marco
MarcoMarco
 
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 concepção, planejamento, 
desenvolvimento e estabilização. Nos projetos do tipo ID o processo possui as 
fases de concepção, planejamento, desenvolvimento e distribuição. Cada uma 
destas fases tem seus objetivos específicos e suas atividades são idênticas às 
atividades propostas pelo RUP. 
2.4.4 Análise Crítica 
O Microsoft Solutions Framework (MSF) é formado por conceitos, modelos, 
práticas e princípios originários de coletas das melhores práticas utilizados pelos 
funcionários, 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 força 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. Além disso, o MSF é baseado em três fatores 
principais: as pessoas, os processos e a gerência de riscos. Isto significa que existe 
uma preocupação um pouco mais abrangente, cujo objetivo é assegurar que as 
pessoas, os recursos e as técnicas existentes são suficientes para garantir que a infra-
estrutura de tecnologia pode satisfazer os objetivos do negócio. 
Desde a criação do MSF, uma grande quantidade de projetos dentro da 
Microsoft já foi desenvolvida tendo como base este processo de desenvolvimento. E os 
resultados têm sido bastante favoráveis para a empresa, pois é um framework que 
está sendo sofrendo atualizações, baseando-se na prática dos seus funcionários. 
Apesar destas vantagens, o MSF também possui algumas desvantagens. 
Mesmo sendo um processo abrangente, que engloba três fatores muito importantes, o 
MSF não possui muitos detalhes das definições que envolvem as atividades mais 
técnicas dentro de um projeto. Todos os documentos que explicam alguma parte deste 
processo mostram apenas as atividades que devem existir, mas não existe um 
workflow que descreva como as atividades devem ser feitas, como existe na RUP, por 
exemplo. Além disso, não se sabe como o MSF se aplicaria para ambientes 
geograficamente distribuídos. Não existem práticas formalmente definidas para este 
contexto específico. Na literatura não se encontrou nada falando a respeito disto, e 
por isso, seria interessante utilizar o MSF em alguma empresa que possui um cenário 
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 construído pela própria 
Microsoft para dar o máximo de suporte para suas equipes, oferecendo diversos 
modelos de documentos e guias de desenvolvimento. Como suas práticas não se 
aprofundam muito na parte técnica, de como as atividades devem ser feitas, o MSF 
utilizou-se de diversos princípios 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, papéis, além de outras 
práticas. 
2.5 Agile Software Development - ASD 
No começo 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 observação de equipes de desenvolvimento de software 
em diversas empresas em todo o mundo, começarama discutir sobre os valores e os 
princípios que permitiam estas equipes a desenvolver software de forma rápida e ao 
mesmo tempo responder à mudanças. Neste encontro, com duração de dois dias, eles 
trabalharam na criação de um documento com uma lista de valores e fundaram a 
Agile Alliance [AGL 02]. O resultado deste trabalho foi a elaboração de um manifesto 
da Agile Alliance [COC 02] para o desenvolvimento ágil do software. A mensagem 
principal deste manifesto, assinada pelos 17 pesquisadores, dizia: 
“Nós desejamos descobrir melhores caminhos para desenvolver software, 
fazendo e ajudando outros a fazerem. Através deste trabalho, chegamos aos seguintes 
valores”: 
- Indivíduos e interações através de processos e ferramentas; 
- Desenvolvimento de software com uma documentação compreensiva; 
- Colaboração do cliente através de contratos e negociações; 
- Resposta a mudanças através de um plano específico; 
“Ou seja, enquanto existirem valores nos itens mais à direita, é possível 
manter os valores dos itens mais à esquerda”. 
Este manifesto deu origem ao Agile Software Development (Desenvolvimento 
Ágil do Software), um conjunto de idéias que visa um objetivo comum: melhorar o 
processo de desenvolvimento de software e sempre trazer novas idéias. A palavra ágil 
surgiu para mostrar a importância da necessidade de existirem processos ágeis. É 
 43
importante comentar que esta proposta de desenvolvimento não é contra os modelos 
de processo já existentes, é apenas uma proposta diferente que busca a melhoria dos 
processos existentes, tornando-os mais ágeis e menos burocráticos. 
Algumas idéias que esta proposta defende é a de que devem existir práticas 
como a modelagem, documentação e planejamento do software que está sendo 
construído. Mas a modelagem não serve apenas para armazenar os diagramas em um 
repositório de dados de uma empresa, a documentação não serve apenas para gastar 
papel escrevendo documentos que nunca mais serão alterados ou que freqüentemente 
serão 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 também possui alguns princípios. Os principais 
princípios existentes são [FOW 01]: 
- A prioridade é satisfazer o cliente através da entrega contínua e 
rápida de uma versão do software. Em um workshop, um gerente de projeto, 
questionado sobre a importância dos documentos de especificação de requisitos e 
arquitetura, disse que estes documentos são muito importantes para o projeto, mas a 
maioria dos clientes não quer saber dos documentos técnicos, diagramas UML. Eles 
estão interessados em saber quando será possível ver o software com alguma das 
funcionalidades de negócio que ele pediu, para provar que o software pode satisfazer 
as suas necessidade. 
- Bem vindos à mudança 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 negócios quanto da tecnologia, causam mudanças. 
Estas mudanças podem ser vistas como uma ameaça ou uma grande oportunidade. Ao 
invés de resistir às mudanças, os processos ágeis tentam acomodá-las da maneira 
mais fácil e eficiente, tendo plena consciência das suas conseqüências. Embora muitas 
pessoas concordam que o feedback é importante, a maioria delas ignoram o fato de 
que um feedback aceito pode ocasionar uma mudança. E os processos ágeis 
 44
consideram este feedback, pois acreditam que é mais efetivo facilitar a mudança do 
que tentar preveni-la. 
- Entregar uma versão do software freqüentemente, a cada semana ou 
a cada mês, sempre visando o menor tempo possível. Por muitos anos, muitos 
especialistas da área de processos de desenvolvimento diziam para utilizar um 
desenvolvimento interativo e incremental, com múltiplas entregas a cada evolução do 
sistema que está sendo desenvolvido. Apesar de esta prática ter aumentado e ser 
essencial para um processo ágil, ainda não é o que predomina nas empresas. É muito 
importante não confundir a entrega com a liberação do software, pois a liberação 
significa que um determinado módulo já pode ir para produção, enquanto que a 
entrega é somente uma avaliação interna do produto que está sendo desenvolvido. 
 - As pessoas da área de negócio e os desenvolvedores trabalham 
juntos no projeto, diariamente. Muitas pessoas gostam de comprar um software da 
mesma forma que compram um carro. Eles têm uma lista de características e 
funcionalidades na cabeça, negociam um preço e pagam pelo que solicitaram. Este 
modelo pode ser interessante, mas para a maioria dos projetos de desenvolvimento 
isto não funciona. Sendo assim, os desenvolvedores dentro dos processos ágeis 
sofreram uma mudança bem radical com relação aos conceitos da especificação de 
requisitos. Não é necessário se comprometer com uma lista detalhada de requisitos no 
início do projeto. A idéia é ter uma visão geral dos requisitos, conhecendo aqueles que 
podem sofrer mudanças ao longo do processo. Como isto não é suficiente para 
projetar e implementar o sistema, a existência de freqüentes interações entre as 
pessoas de negócio e os desenvolvedores se torna necessária. 
 - Ter uma equipe motivada e fornecer o ambiente, a confiança e o 
suporte necessários para o trabalho ser executado. Mesmo com as melhores 
ferramentas, tecnologias, e processos, são as pessoas que fazem a diferença no 
caminho entre o sucesso e o fracasso. Além disso, as decisões 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 decisão 
que esteja dentro do escopo do seu trabalho. 
- O método mais eficiente para trocar informações dentro ou fora da 
equipe de desenvolvimento é uma conversa “cara-a-cara”. Os processos ágeis 
não possuem uma grande quantidade de documentação. Eles consideram que a 
diferença não está na documentação, mas sim no entendimento. Uma documentação 
pode não dar o real entendimento para uma pessoa que a lê. Sendo assim, a 
documentação deve ser gerada por questões de obrigação e formalismo, mas sempre 
que possível deve se também tentar utilizar técnicas de comunicação 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 utilização 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 invés de existirem regras rígidas e complexas, existir 
apenas um conjunto básico de regras que encoraje a sua criatividade. 
- Em intervalos regulares de tempo, a equipe deve refletir sobre como 
tornar o trabalho mais efetivo e então ajustar seu comportamento de acordo 
com esta reflexão. Processos ágeis não são práticas que existem apenas para ler, 
aprender e serem seguidas. Sempre existe um processo aconselhado para uma 
determinada situação, mas este processo pode deixar de ser válido com o tempo. O 
refinamento e a reflexão 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 são fatores que 
estão ligados à confiança que uma equipe deve ter para monitorar e melhorar os seus 
próprios processos de desenvolvimento. 
Além dos princípios anteriormente descritos, são válidas algumas considerações 
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 são aplicáveis tanto para o desenvolvimento de software como para 
 46
atividades como montanhismo ou escrever poesias.