desenvolvimento distribuído de software e processos de
TRANSCRIPT
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 – Extreme Programming
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 orientados a 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ÇASCULTURAIS
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 deDesenvolvimento
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.
InexistenteMunicipal
RegionalContinental
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
empresariais desempenham 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 é capaz de identificar os riscos e decidir pela
melhor ação (figura 17).
Identificar Analisar
Controlar Planejar
Monitorar
Documentode avaliação
de riscos
os 10+
Documentode avaliação
de riscos
os 10+
RiscosIdentificados
1 2
3
4
5Riscos
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 deProjeto
Gerência deLogística
Gerência deProduto
Educação doUsuá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
FaseUm
Fase Quatro FaseTrê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çaram a 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. As atividades definidas para cada
um dos elementos (retângulos) podem variar, mas o nome de cada elemento não
muda.
Figura 20 – Os elementos de um
processo de desenvolvimento – Fonte: [COC 02]
Além disso, um modelo de processo de desenvolvimento ágil não precisa
necessariamente utilizar todos os elementos definidos na figura 20. Cada modelo tem
um escopo que é definido no início de cada projeto, e este escopo compreende os
papéis e as atividades que cobrem o projeto. O escopo de um modelo de processo de
desenvolvimento de software, segundo [COC 02], possue três dimensões: ciclo de
vida do projeto (indica todas as fases em que um projeto pode estar), papéis
(indica quais os papéis 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 três dimensões, como mostra a figura 21. Ou seja, todo o
projeto possui um modelo de processo, e o que muda são as preocupações e o escopo
de cada projeto.
Figura 21 – As três dimensões do escopo de um processo - Fonte: [COC 02]
47
Para entender melhor qual o conceito por trás do Agile Software Development,
a figura 22 mostra, como exemplo, a definição do escopo do Extreme Programming,
um processo de desenvolvimento de software que segue as práticas e princípios
definidos pelo ASD e será explicado mais adiante.
Figura 22 – A instância 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 mínimas, procurando antes de
qualquer coisa satisfazer as necessidades dos clientes.
2.5.1 Análise Crítica
O Agile Software Development surgiu como uma necessidade de um grupo de
17 pesquisadores para buscar soluções 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 idéia 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 período de tempo. E cada equipe vai definir o seu próprio
processo ágil de desenvolvimento, seguindo os 12 princípios que o ASD propõe. Além
disso, a aliança 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 idéias e conceitos [AGL 02].
Por outro lado, por existir esta liberdade de definição dos próprios hábitos de
desenvolvimento, a empresa ou a equipe que utiliza os conceitos e princípios do ASD
pode vir a ter um processo de desenvolvimento desorganizado, que trabalha por
resultados e que não se preocupa com alguns detalhes que podem ser úteis para
futuro, como documentação, padronização do processo, entre outros.
Finalizando, [COC 02] traz algumas idéias e observações sobre o
desenvolvimento distribuído de software dentro do conceito do Agile Software
Development. Ele considera alguns cenários e algumas formas de distribuição,
incluindo alguns descritos no capítulo 1 deste estudo. Mas nenhuma destas idéias é
uma prática ou uma atividade formal existente dentro do processo ágil de
desenvolvimento de software. São apenas idéias e observações do próprio autor, que
refletem a sua experiência e vivência com o desenvolvimento de software por muitos
anos.
2.6 Extreme Programming – XP
No início da década de 1990, um homem chamado Kent Beck começou a
pensar em melhores caminhos para se desenvolver software, baseado nas suas
experiências anteriores e em todas as dificuldades e desafios que estavam implícitos
nesta atividade. Ele então resolveu pensar nos fatores que tornavam o software fácil
de ser criado e em fatores que tornavam esta criação difícil. Sendo assim, em março
de 1996 Kent começou um projeto na DaimlerChrysler6 utilizando novos conceitos de
desenvolvimento de software. O resultado foi um novo processo de desenvolvimento,
o Extreme Programming, onde Kent percebeu que existiam quatro dimensões onde o
software poderia ser sempre melhorado (figura 23): é necessário sempre pensar em
melhorar a comunicação; a simplicidade sempre deve ser vista em primeiro plano; é
6 Uma das principais empresas de transporte e serviços automotivos do mundo. http://www.daimlerchrysler.com
49
necessário sempre obter feedback de como as atividades estão sendo executadas; e é
necessário sempre se ter coragem [XTP 02].
COMUNICAÇÃO
FEEDBACKCORAGEM
SIMPLICIDADE
Software
Figura 23 – As quatro dimensões 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: comunicação, simplicidade, feedback (melhorias) e coragem
[XPR 02].
A comunicação ocorre de forma contínua 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 construído e em que ordem isto
deve ocorrer. Com relação à simplicidade, é produzido o menor número de artefatos
possíveis que não sejam códigos, e o código está sempre sendo revisado e corrigido.
O software é liberado em pequenas versões que são continuamente testadas (testes
de unidade) e existe um mecanismo de feedback para avaliar o que foi construído até
então. E a coragem significa fazer tudo corretamente, mesmo quando não é a tarefa
mais sensata a ser feita. Significa que os desenvolvedores devem ser honestos e
devem saber o que pode e o que não pode ser feito.
Os desenvolvedores no XP têm liberdade e segurança para reagir a uma
mudança de requisitos do cliente, mesmo que esta mudança ocorra tarde. Além disso,
50
eles se comunicam tanto com os clientes quanto com os outros desenvolvedores. Eles
mantêm um projeto simples e limpo e têm a prática 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 possível e podem implementar sugestões se for o caso. Com essa
forma de trabalhar, os desenvolvedores que utilizam o XP como processo de
desenvolvimento estão aptos a responder às mudanças de requisitos e tecnologia de
uma forma eficaz e eficiente.
A aplicação proposta do Extreme Programming é indicada para pequenos
grupos de desenvolvedores, variando de 2 a 10. Não é necessário ter desenvolvedores
experientes e XP não é indicado para projetos com uma equipe muito grande.
Segundo [XTP 02], Extreme Programming difere dos outros processos no
sentido de ser composto por pequenos pedaços que separados não tem sentido
algum, mas que quando são integrados pode se enxergar o quebra-cabeça completo
montado e funcionando (figura 24). É uma forma diferenciada de se projetar e
construir software. Além disso, XP foi criado para agir num problema muito comum
que é a mudança de requisitos, pois muitas vezes os clientes não têm uma idéia
concreta do que o sistema deve fazer. Sendo assim, é necessário construir um sistema
onde as funcionalidades podem sofrer alterações a cada mês.
Figura 24 – O XP é visto como um conjunto de peças.
O XP é composto por quatro fases: planejamento, projeto, codificação e
teste. Cada uma destas fases possui uma série de regras e práticas que devem ser
seguidas. Além disso, doze práticas ao longo destas fases suportam as quatro
dimensões ilustradas anteriormente na figura 23[POL 01], [BEC 00]:
- Planejamento (The Planning Game): o desenvolvimento de software é
sempre um diálogo envolvendo o possível e o desejado. Sendo assim, não existe uma
superioridade entre as considerações técnicas e as considerações do negócio [BEC
00]. No XP, o planejamento envolve uma série de decisões e dois atores estão
51
envolvidos nelas: os analistas da área técnica e os analistas de negócio. Os analistas
de negócio são responsáveis pelas definições do escopo do projeto, ou seja, o quanto
é suficiente e o quanto é muito para ser feito. Além disso, eles definem prioridades
nas tarefas a serem executadas, bem como as características que farão parte das
próximas versões do software e as datas de liberação destas versões. Mas os analistas
de negócio só podem tomar estas decisões junto com os analistas da área técnica, que
fornecem subsídios para estas decisões. Sendo assim, os analistas da área técnica são
responsáveis por fornecer estimativas de tempo de implementação. Devem também
informar para os analistas de negócio sobre possíveis conseqüências que serão
influenciadas pelas decisões de negócio, tal como a escolha do banco de dados. Outra
responsabilidade dos analistas da área técnica é a de detalhar um cronograma
contendo tudo o que será desenvolvido dentro de uma versão, considerando riscos e
prioridades. Por último, devem definir como a equipe e o trabalho estarão
organizados;
- Liberação de pequenas versões (Small Releases): deve ocorrer uma
liberação do software freqüentemente para o cliente com pequenas versões
incrementais. Cada versão deve ser a menor possível, contendo os mais importantes
requisitos de negócio. Mas esta liberação deve ser feita de forma lógica, ou seja, não
se pode implementar metade de uma funcionalidade e enviar para o cliente, apenas
para tornar o ciclo de liberação menor. O ideal é planejar liberações em períodos 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 freqüentemente liberar uma versão. Mas isto deve ser feito da
melhor forma possível;
- Metáfora (Metaphor): a metáfora é apenas uma história ou descrição de
como o sistema trabalha. Cada projeto dentro do XP é guiado por uma metáfora. O
objetivo é apenas ajudar no entendimento do projeto e dos seus elementos básicos,
bem como nas relações entre eles. O XP também utiliza o conceito de user stories. Os
user stories servem para o mesmo propósito dos casos de uso utilizados no RUP, mas
52
não são iguais. Os user stories são utilizados para criar estimativas de
desenvolvimento e são utilizados em substituição aos extensos documentos de
especificação de requisitos. São escritos pelos clientes como funcionalidades que o
sistema deve ter, e são 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 código simples e removendo de forma contínua a
complexidade existente no código. Esta prática sugere que o projeto do sistema seja
sempre feito, seguindo um conselho oposto ao que normalmente se ouve:
“Implemente hoje e faça o projeto do sistema amanhã” [BEC 00].
- Teste (Testing): qualquer funcionalidade de um software sem um teste
automatizado simplesmente não 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.
Não é necessário escrever testes para cada método existente. Os testes devem ser
feitos para testar apenas o que pode quebrar o código, e o ideal é que sejam escritos
os casos de teste de um determinado módulo antes de iniciar o seu desenvolvimento;
- Reestruturação (Refactoring): esta é uma técnica simples para remover a
complexidade e a duplicação do código. Sempre após 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
reestruturação do sistema, de modo que no futuro a inclusão de uma nova
funcionalidade se torne uma tarefa mais fácil.
- Programação em Pares (Pair Programming): equipes de dois
desenvolvedores desenvolvem todo o código em um único computador, utilizando um
mouse e um teclado. Em cada par existem dois papéis: 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 estratégica, revisando o código para
53
procurar erros ou partes inconsistentes, definido casos de teste que podem quebrar o
código que está sendo implementado, além de maneiras de simplificar o sistema. A
programação em pares é dinâmica e qualquer um dentro da equipe pode ser um par;
- Posse Coletiva (Collective Ownership): todos são responsáveis por todo o
código. Isto significa que todos têm permissão para alterar qualquer parte do código a
qualquer momento. A vantagem é que todos têm algum conhecimento de cada parte
do código e se algum desenvolvedor for embora seu código continuará disponível e
ninguém terá dificuldade de entendê-lo. Se um par de desenvolvedores está
trabalhando e vê uma oportunidade de melhorar uma determinada parte do código,
eles não pensam duas vezes para alterar tudo o que for necessário;
- Integração Contínua (Continuous Integration): construir e integrar o
sistema várias vezes por dia mesmo que nenhuma tarefa de codificação foi realizada.
Isto pode ser feito utilizando uma máquina dedicada apenas para a integração.
Quando a máquina está livre, um par de desenvolvedores atualiza seu código,
verificando possíveis colisões com outras partes do sistema, e executam os testes de
integração até que o sistema não possua erros;
- 40 horas por Semana (Forty-hour Week): os desenvolvedores não podem
trabalhar com o máximo de esforço 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 não é possível ter
hora extra por duas semanas consecutivas. Uma pessoa pode ter horas extras em
uma semana, mas se no início da próxima semana ela concluir que para atingir seus
objetivos serão necessárias mais horas extras, é sinal de que já existe um problema e
que este problema não poderá ser solucionado apenas trabalhando-se mais do que o
seu horário;
- 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 dúvidas gerais. Entende-se por “cliente real” a pessoa
que utilizará o sistema quando ele estiver em produção. Mas o grande obstáculo desta
prática é que os “clientes reais” são muito valiosos para ficarem todo o tempo com a
equipe de desenvolvimento. E neste caso, os gerentes deverão decidir o que é melhor
fazer, pois durante o desenvolvimento, os desenvolvedores podem gerar inúmeras
questões e dúvidas por hora ou até por semana;
- Padrões de Código (Coding Standards): os desenvolvedores adotam uma
consistente padronização de código. Esta padronização é necessária, pois os
desenvolvedores trocam de pares e pulam de uma parte do código para outra a todo
instante. Esta padronização deve focar na comunicação e deve ser adotado
voluntariamente por toda a equipe.
2.6.1 Análise Crítica
O Extreme Programming é um processo de desenvolvimento de software
disciplinado que, antes de qualquer coisa, visa a satisfação completa do cliente. A
idéia básica do XP é entregar o software ao cliente quando ele deseja, e para isto este
mesmo cliente deve ter um papel muito ativo. Além disso, este processo possui quatro
dimensões que caracterizam as suas características principais, além de possuir
algumas práticas já citadas anteriormente.
Uma das vantagens desta abordagem proposta pelo XP é que ele propõe uma
nova forma de enxergar um dos grandes problemas do desenvolvimento de software:
a mudança de requisitos. Além disso, o cliente participa de várias definições ao longo
do processo, se sentindo como parte da equipe do projeto. Por último, a utilização do
XP pode diminuir os custos do desenvolvimento do software, pois é um processo
simples de ser implementado.
Por outro lado, o Extreme Programming também possui suas desvantagens.
Primeiramente, é um processo idealmente aplicado para projetos de pequeno porte,
com equipes não muito grandes, variando de 2 a 10 integrantes. Isto significa que o
XP não pode ser sempre utilizado. Além disso, não existe um formalismo que define as
documentações que devem ser geradas. O XP passa uma impressão de que a maior
55
parte dos documentos são gerados da forma como os desenvolvedores acharem
melhor. O importante é começar o desenvolvimento o mais rápido possível,
descobrindo possíveis problemas ao longo do projeto, tendo então como foco principal
o desenvolvimento. Por último, o XP não possui suporte para desenvolvimento de
software em ambientes fisicamente distribuídos, pois a sua prática sugere que o
cliente esteja sempre trabalhando junto com a equipe de desenvolvimento, fazendo
disto um obstáculo para distribuir este desenvolvimento. Alguns autores, como [BEC
01], até sugerem que em ambientes como estes exista dentro da prática do Planning
Game uma tarefa que é justamente decidir o que fazer em ambientes de DDS. Apesar
disto, diversos estudos têm analisado as práticas do Extreme Programming,
comparando estas práticas em ambientes geograficamente centralizados e em
ambientes geograficamente distribuídos [BAH 02], verificando a eficiência e a
necessidade de se definir algumas regras e atividades específicas para este tipo de
configuração de desenvolvimento. Mas muito trabalho ainda precisa ser feito.
Em suma, o XP é um processo inovador que trouxe diversas idéias para a área
do desenvolvimento de software, mas ele tem alguns limites que não tem como serem
ultrapassados. Grandes projetos não podem utilizar somente o processo proposto pelo
XP, pois ele não cobre todas as práticas necessárias que se exigem para um
desenvolvimento de um projeto de grande porte, seja ele em uma pequena, média ou
grande empresa. Mas o XP é reconhecidamente sugerido e efetivo para a construção
de sistemas pequenos dentro de um ambiente de mudança de requisitos.
Independente disto é possível unir algumas práticas propostas pelo Extreme
Programming com práticas 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 econômicos 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 propõe.
56
3 Análise Comparativa entre os Processos de Desenvolvimento
No capítulo anterior o objetivo foi descrever alguns dos principais processos de
desenvolvimento de software. Estes processos são 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 existência de
um processo para guiar o desenvolvimento de software é possível buscar melhorias de
qualidade e maturidade destes processos, além de ter a possibilidade de avaliar e
medir a aplicabilidade e o sucesso destes processos. O objetivo deste capítulo é fazer
uma análise comparativa dos processos descritos no capítulo anterior. Para isto,
identificou-se um conjunto de critérios de comparação, considerando o que é
importante e, dentre estes, quais são essenciais em um processo de desenvolvimento
de software.
3.1.1 Definição dos Critérios de Análise
Para analisar os processos descritos anteriormente, serão utilizados critérios
obtidos a partir de um estudo específico para este fim baseando-se em artigos e livros
que propõem critérios para comparações entre metodologias e processos de
desenvolvimento de software orientados a objetos [OBJ 95], [SMI 01] e [COC 02].
[OBJ 95] é um relatório preparado pela The Object Agency, Inc., com o
objetivo de ajudar as organizações a avaliarem as características, vantagens e
desvantagens de cada metodologia de desenvolvimento para o seu ambiente. Este
relatório 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 relatório é de 1995, a
comparação em si não foi utilizada para este estudo por estar desatualizada com os
57
processos existentes atualmente. Por isso, apenas foram utilizados alguns dos critérios
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 comparação está direcionada na natureza e
no estilo de cada processo, suas estruturas, hipóteses e apresentações. O artigo
também examina quais os potenciais “alvos” de cada processo e a conseqüência da
sua utilização.
[COC 02] descreve as propostas e princípios dos processos de desenvolvimento
de software como “regras de comportamento” e integra essas propostas e princípios
com a idéia de que cada projeto é único e tem suas próprias regras. É um estudo
baseado em casos empíricos propostos pelo autor.
A tabela 1 identifica os critérios encontrados na literatura, acrescentando
critérios próprios identificados neste estudo. Para uma maior facilidade de
comparação, estes critérios foram agrupados em algumas variáveis mais genéricas.
Sendo assim, este estudo comparativo foi feito por meio da análise de cada uma das
variáveis identificadas para cada processo de desenvolvimento de software analisado.
VARIÁVEIS FONTE CRITÉRIOS Fases de um projeto [SMI 01]
[OBJ 95]
[SMI 01]
Forma como o processo está organizado ao longo do tempo. Existência de fases bem definidas e os nomes de cada fase. Existência de entrada e saídas definidas para cada fase.
Artefatos [COC 02]
[SMI 01]
Número médio de artefatos existentes no processo. Existência de uma definição boa e formal dos artefatos.
Atividades e Disciplinas [SMI 01]
[COC 02]
Como as atividades são executadas para produzir os artefatos. Existência de disciplinas e práticas, modelagem do sistema, gerência de mudança de requisitos, programação em pares, etc.
Teste e Controle de Qualidade
[OBJ 95]
[OBJ 95] [COC 02]
Existência de atividades de controle de qualidade ao longo de todo o processo de desenvolvimento. Existência de uma atividade de teste. Geração de casos de teste, relatórios, etc.
Papéis e Regras [SMI 01] Número médio de papéis existentes dentro
58
[OBJ 95]
de um projeto. Existência de uma definição formal dos papéis e regras existentes.
Características Gerais [OBJ 95] [SMI 01]
Grau de formalismo existente no processo. Tamanho máximo 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
PRÓPRIO Existência de algum mecanismo que prevê uma coleta e feedback de informações dos projetos para serem analisadas e utilizadas para futuras melhorias.
Suporte para DDS - Desenvolvimento Distribuído de Software
PRÓPRIO Existência de um planejamento para projetos em um ambiente de DDS, além de mecanismos de suporte, estratégias a serem seguidas (considerando os diversos cenários e os problemas de cada um deles), definição de atividades específicas e mecanismos de avaliação do projeto, levando-se em consideração os 5 fatores de sucesso (diferenças culturais, coordenação, comunicação, confiança e cooperação).
Tabela 1 – Os critérios definidos para a análise comparativa.
3.1.2 Análise Comparativa
Após a definição dos critérios e das variáveis de análise no item anterior,
busca-se agora sintetizar os resultados da análise comparativa entre os modelos de
processo de desenvolvimento de software encontrados. Para isto a seguir serão
apresentadas, para cada critério, as características 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 saídas bem definidas, que pode ser um artefato, uma autorização do cliente, etc. Ao longo do tempo o processo evolui através das fases, cujos nomes são: concepção, elaboração, construção e transição. MSF Fases bem definidas, com o nome e as atividades variando de acordo com o tipo de projeto. As fases possuem entradas e saídas bem definidas. Ao longo do tempo o processo evolui através das fases, cujos nomes são: concepção, planejamento, desenvolvimento e estabilização. Em alguns tipos de projetos a última fase se chama distribuição. ASD As fases não são bem definidas. Cada projeto é configurado de uma forma diferente de acordo com o seu escopo e contexto, portanto não existem entradas e saídas por fase. Ao longo do tempo o processo evolui de acordo com as necessidades do cliente e com agilidade necessária para entregar o mais cedo possível. XP As fases são bem definidas, mas o foco é no desenvolvimento. Ao longo do tempo o processo evolui através das fases, que são: planejamento, projeto, codificação e teste, e o cliente tem participação freqüente.
59
Artefatos RUP Possui artefatos bem definidos para cada fase e atividade do projeto. Também possui modelos (templates) para estes artefatos. Tem uma média de 100 artefatos [SMI 01], mas um projeto não é 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 possível, produzir todos os artefatos necessários. ASD Não possui artefatos bem definidos. Possui alguns artefatos para atividades específicas e a proposta é a de gerar pouca documentação, somente o que for realmente necessário para o formalismo do projeto para o cliente ou outros projetos. XP Existem em torno de 30 artefatos [SMI 01] e eles não são bem definidos, pois o XP não dá muita importância para explicá-los em detalhes. Na literatura do XP é difícil encontrar as palavras “artefato” ou “documento”, mas na descrição do processo se encontram diversas definições que são 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 através da linguagem UML, utilizando casos de uso para modelagem de negócio e especificação de requisitos, além de outros diagramas ao longo do projeto. Possui práticas de gerência de mudança. MSF Possui diversas atividades e algumas delas são incorporadas da RUP e outros processos de desenvolvimento. A modelagem do sistema é feita através da UML ou outra representação que for necessária. Dá ênfase na gerência 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 colaboração do cliente, resposta à mudanças, indivíduos e interações para gerar um desenvolvimento rápido e com qualidade. Possui características tais como avaliação contínua do software. XP Possui diversas atividades e com ênfase no desenvolvimento, mas algumas não são bem definidas. Possui características diferenciadas, tais como a programação em pares, posse coletiva e geração de casos de teste por parte do cliente. A especificação de requisitos é feita utilizando-se user stories e a mudança de requisitos pode ocorrer a qualquer momento. Dá ênfase na comunicação, simplicidade, feedback e coragem. Teste e Controle de Qualidade RUP Possui práticas de controle de qualidade ao longo de todo o processo, mas elas não são bem descritas. Com relação aos testes, casos de testes são gerados visando testes de unidade, regressão, carga, entre outros. Relatórios de teste são gerados e os erros devem ser verificados e corrigidos. MSF Possui práticas de controle de qualidade ao longo de todo o processo, mas elas não são bem descritas. Também existe a atividade de teste, mas a descrição que é dada no material estudado é bem superficial. Um projeto não é liberado sem passar por todos os testes. ASD Possui práticas de controle de qualidade e padronização, bem como atividades de teste. A descrição é bastante genérica, visto que cada projeto trabalha da sua forma. Os testes têm grande importância por causa da avaliação e integração constantes.
60
XP O teste e o controle de qualidade têm uma grande importância por causa das constantes avaliações de pequenas versões por parte do cliente. Os casos de testes são escritos preferencialmente antes do desenvolvimento e os clientes escrevem todos os casos de teste das funcionalidades. Papéis e Regras RUP Existem papéis e regras bem definidos. Possui em torno de 30 papéis [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 papéis e regras bem definidos. Um dos aspectos mais importantes é a configuração da equipe de projeto e seus papéis. 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, não existem papéis bem definidos, pois isto depende de cada projeto. Existem apenas os papéis essenciais e o restante é definido por demanda. XP Possui alguns regras e papéis bem definidos, mas também possui papéis e regras que podem surgir ao longo de um projeto. Possui então em torno de 7 papéis [SMI 01] e algumas regras dentro de cada fase, com ênfase no desenvolvimento. Em comparação com o RUP, um papel do XP equivale a alguns papéis do RUP. Características Gerais RUP É um processo de desenvolvimento bem formal, bem definido, com tudo pronto para ser instanciado e aplicado, podendo assumir diversas configurações dentro do framework, dependendo das características de cada projeto. Cada configuração inclui as práticas 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 três tipos possíveis de projeto e as atividades e disciplinas variam um pouco em cada tipo. É focado nas pessoas, na gerência de risco e na tecnologia. ASD É um processo de desenvolvimento que não dá muita ênfase no formalismo e definição 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 satisfação do cliente. XP É um processo de desenvolvimento com definições básicas, com ênfase total no desenvolvimento, na resposta rápida e na satisfação do cliente. Não é muito formal e possui algumas limitações quanto ao tipo e tamanho de projeto. Ciclo de Vida RUP Possui um ciclo de vida em espiral, com um desenvolvimento iterativo e incremental. Também pode ser utilizado com um ciclo de vida em cascata (não se aconselha), ou em outras combinações 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 variações. ASD Possui um ciclo de vida baseado na prototipação e na avaliação constante, mesclado com o desenvolvimento iterativo e incremental.
61
XP Possui um ciclo de vida baseado na prototipação e na avaliação 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 prática de forma independente nas empresas que utilizam o RUP. Mesmo assim, existe um suporte constante ao usuário, mesmo após o término 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 servirão para futuras melhorias é a coleta constante de boas práticas da equipe de funcionários da Microsoft. Estas práticas são analisadas e podem ser integradas ao MSF no futuro. ASD Não possui um mecanismo formal para buscar a melhoria constante do processo. Possui uma constante avaliação do software por parte do cliente e 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. Como é um processo ágil, está sempre buscando melhorias. XP Não possui um mecanismo formal para buscar a melhoria constante do processo. Possui uma constante avaliação por parte do cliente que trabalha diariamente com a equipe de desenvolvimento. Suporte para DDS - Desenvolvimento Distribuído de Software RUP Não possui atividades que oferecem suporte ao DDS, mas dá importância para a comunicação. MSF Não possui atividades que oferecem suporte ao DDS, mas dá importância para a comunicação. ASD Não possui atividades e práticas formais que oferecem suporte ao DDS, mas dá importância para a comunicação. Em seu livro, [COC 02] expressa a sua opinião com relação ao DDS dentro do Agile Software Development, mas não são atividades formais, sendo apenas idéias que o autor sugere para serem aplicadas. XP Não possui atividades formas que oferecem suporte ao DDS, mas dá uma grande importância para a comunicação. Apesar disto, já existem alguns estudos que comparam algumas práticas do XP em ambientes geograficamente centralizados com ambientes geograficamente distribuídos.
Tabela 2 – Análise comparativa.
62
CONCLUSÕES
Este trabalho teve como objetivo principal apresentar um estudo de dois
tópicos relacionados: o estado da arte dos principais modelos de processos de
desenvolvimento de software existentes e um estudo sobre uma nova tendência que
as empresas estão cada vez mais absorvendo na sua realidade, que é o
desenvolvimento distribuído de software (DDS).
Com relação ao método de pesquisa, se desenvolveu uma extensa revisão
bibliográfica, 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
exploratório. Durante a evolução do estudo algumas análises e sínteses foram
realizadas, visando a consolidação das informações coletadas.
A síntese do estudo sobre DDS propiciou um maior entendimento de como os
ambientes de desenvolvimento geograficamente distribuídos podem estar
organizados, quais os atores que estão envolvidos e quais os critérios que definem
esta distribuição. Além disso, o estudo direcionou a pesquisa no sentido de indicar em
que nível de distribuição um processo de desenvolvimento de software deve se
preocupar em absorver práticas de DDS.
Já a análise comparativa dos principais modelos de processos de
desenvolvimento de software mostrou que existem diversas possibilidades disponíveis.
Estas possibilidades envolvem desde processos formais, seqüenciais e pesados até
processos mais informais, iterativos e ágeis. Estes modelos podem focar mais os
resultados ou os processos para a obtenção destes resultados, bem como podem
possuir um nível de organização mais ou menos rígidos. Um resultado importante foi
63
com relação à existência 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
práticas, um feedback ou uma reunião de avaliação, com o objetivo de melhorar o
processo como um todo. Estas informações são então analisadas e podem ser
transformadas em novas práticas para serem incorporadas ao processo. Outro
resultado relevante foi a definição de um padrão de análise de processos de
desenvolvimento de software em um ambiente distribuído (DDS).
Mas o principal resultado desta análise comparativa foi a percepção de que em
nenhum dos processos analisados existe a descrição de uma prática formal que prevê
um cenário de DDS. O desenvolvimento distribuído de software é cada vez mais
constante, principalmente nas grandes organizações. Esta realidade demanda por
novos conhecimentos e práticas a serem incorporadas nos processos de
desenvolvimento de software.
Finalmente, verificou-se que existe espaço para pesquisas na área de
Desenvolvimento Distribuído de Software. Se por um lado muitas empresas estão
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 formalização de práticas
quando se configura o DDS.
Nas próximas etapas desta pesquisa pretende-se explorar as possibilidades de
incorporação de contribuições em um modelo processo de desenvolvimento de
software com equipes geograficamente distribuídas, em todos os seus possíveis
cenários. Identificam-se demandas relativas a atividades como planejamento,
definição de estratégias, disciplinas, práticas e avaliação do processo.
64
REFERÊNCIAS BIBLIOGRÁFICAS
[AGL 02] Agile Alliance. Disponível em http://www.agilealliance.org, 2002.
[ALC 02] ALCÂNTARA, A. A., MACIEL, T. M. M., MEIRA, S. L., SILVA, F. Q. B. Uso
do Processo RUP na Implanatação da ISO9000-3. CESAR – Centro
de Estudos e Sistemas Avançados 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,
Março 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. Disponível 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, Março/Abril de 2000.
[IEC 02] IEC - International Electrotechnical Comission. Disponível em
http://www.iec.ch, 2002.
[ISO 98] ISO - International Standards Organization. ISO/IEC 12207 –
Software Life Cycle Process. Válida desde 30/11/1998. Direitos ABNT
– Associação Brasileira de Normas Técnicas, Rio de Janeiro, RJ, Outubro
de 1998.
[ISO 02] ISO - International Organization for Standardization. Disponível 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 edição, 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. Disponível
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
Prática, 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., MÓRA, 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
Ciência da Computação, 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.
Disponível 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. Disponível em
http://www.extremeprogramming.org, 1999.
[XPR 02] Third International Conference on eXtreme Programming and
Agile Processes in Software Engineering. Disponível em
http://www.xp2002.org, 2002.