Universidade da Amazônia Centro de Ciências Exatas e Tecnologia

Curso de Bacharelado em Ciência da Computação

Oscar Nogueira de Souza Neto

Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis

Belém/PA 2004

Universidade da Amazônia Centro de Ciências Exatas e Tecnologia

Curso de Bacharelado em Ciência da Computação

Oscar Nogueira de Souza Neto

Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis

Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação do Centro de Ciências Exatas e Tecnologia da UNAMA – Universidade da Amazônia, como exigência parcial para obtenção do título de Bacharel em Ciência da Computação. Elaborado sob orientação do Prof. M.Sc. Sandro Ronaldo Bezerra Oliveira.

Belém/PA 2004

__________________________________

Cláudio Alex Jorge da Rocha

__________________________________

Professor 1 (Avaliador)

__________________________________

Professor 2 (Avaliador)

Belém-PA, de de 2004

iv

A meus pais, familiares, professores e amigos, que me fortaleceram e fortalecem, para que fosse possível concluir esta jornada em minha vida, além de encorajar-me a alçar vôos maiores.

v

Agradeço a Deus, que me deu oportunidades em minha vida para que fosse possível chegar ao ponto que estou hoje. Agradeço aos meus pais, Lúcia Peres e Luiz Oscar, que com muito custo e esforço me tornaram a pessoa que sou hoje. Devo tudo a eles. À minha namorada, Roberta Bassalo, que esteve sempre comigo, acompanhando-me neste momento, que ao mesmo tempo é final e inicial em minha vida. Aos meus amigos, que me divertem, apóiam e sabem criticar-me quando necessário. E ao meu grande professor, orientador, mestre e, acima de tudo, amigo, Sandro Bezerra, que mesmo à distância me ajudou a chegar onde estou, e certamente contribuiu para formar o profissional e pessoa que sou. Obrigado a todos,

Oscar Nogueira de Souza Neto

vi

“ The whole is bigger than the parts .” Kent Beck

vii

Resumo

Desde a crise do software o processo de desenvolvimento de software vem

evoluindo e se estruturando para que erros que caracterizaram esta crise, como a

má qualidade do que foi desenvolvido, não ocorram com projetos atuais.

Para isso linguagens para modelagem do sistema, como a UML, foram

criadas. Além das linguagens, principalmente, foram desenvolvidas metodologias de

desenvolvimento de software, onde passos eram detalhados para que o processo de

desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária.

Com o tempo, as metodologias se tornaram mais complexas e distintas

melhorando a qualidade do produto, independente do foco do sistema sempre

haveria uma metodologia para manter a qualidade.

Este trabalho propõe uma análise comparativa de duas frentes destas

metodologias, as tradicionais, que têm como característica a grande quantidade de

documentos gerados, “atrasando” o desenvolvimento do projeto, e as metodologias

ágeis, que se opõem às tradicionais evitando, sempre que possível, a documentação

e focando a codificação do projeto.

Palavras-chave: Metodologias Ágeis, Metodologias Tradicionais, RUP,

eXtreme Programming, Engenharia de Software, Fábrica de software.

viii

Abstract

Since the software crisis, the software development process improves and

structures itself to avoid the same errors that lead to that crisis, like the poorly quality

of the software, start to happen again.

For that, modeling languages, like UML, were created. Besides that, software

development methodologies where raised, where steps were detailed to maintain a

standardization of the process, always achieving the desired quality.

With time, these methodologies became complex and distinct, always

improving system quality, doesn’t matter which focuses the system should take, there

would be a methodology to trail the path.

The proposal of this work is a comparative analysis of the two sides of these

methodologies, the traditional methodologies, where documentation is very important

and a large amount of documents are written before and after software

implementation; and agile methodologies, where source code is the most important

item, leaving documentation in second view.

Keywords: Traditional Methodologies, Agile Methodologies, RUP, eXtreme

Programming, Software Engineering, Software Factory.

ix

Sumário

CAPÍTULO 1. INTRODUÇÃO ................................................................................................................... 1

1.1 CONTEXTO DO TRABALHO....................................................................................................1 1.2 OBJETIVOS E METODOLOGIA DO TRABALHO..........................................................................3 1.3 ESTRUTURA DO TRABALHO ..................................................................................................4

CAPÍTULO 2. DESENVOLVIMENTO DE SOFTWARE: VISÃO GERAL ......................................... 6

2.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE SISTEMATIZADO .......................................7 2.2 FASES DO DESENVOLVIMENTO DE SOFTWARE ......................................................................8

2.2.1 Fase de Definição......................................................................................................8 2.2.2 Fase de Desenvolvimento.........................................................................................9 2.2.3 Fase de Manutenção.................................................................................................9

2.3 MODELOS DE PROCESSO DE SOFTWARE ............................................................................10 2.3.1 Modelo Seqüencial Linear.......................................................................................11 2.3.2 Modelo de Prototipagem .........................................................................................12 2.3.3 Modelo RAD – Rapid Application Development......................................................13

2.4 MODELOS DE PROCESSOS EVOLUCIONÁRIOS .....................................................................15 2.4.1 Modelo Incremental .................................................................................................15 2.4.2 Modelo Espiral.........................................................................................................16

CAPÍTULO 3. METODOLOGIAS DE DESENVOLVIMENTO TRADICI ONAIS OU PESADAS.. 18

3.1 RUP – RATIONAL UNIFIED PROCESS..................................................................................19 3.1.1 Arquitetura do RUP .................................................................................................20

CAPÍTULO 4. METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS O U LEVES ........................ 26

4.1. INDIVÍDUOS E ITERAÇÕES AO INVÉS DE PROCESSOS E FERRAMENTAS ..................................26 4.2. SOFTWARE FUNCIONAL AO INVÉS DE DOCUMENTAÇÃO DETALHADA......................................27 4.3. COLABORAÇÃO DO CLIENTE AO INVÉS DE NEGOCIAÇÃO DE CONTRATOS. .............................28 4.4. RESPONDER ÀS MUDANÇAS AO INVÉS DE SEGUIR UM PLANO ...............................................29 4.5. XP – EXTREME PROGRAMMING ........................................................................................33

4.5.1. O que é a eXtreme Programming? ........................................................................33 4.5.2 Regras ou Práticas da XP .......................................................................................34

CAPÍTULO 5. ANÁLISE COMPARATIVA ENTRE METODOLOGIAS TRADICIONAIS E ÁGEIS ............................................................................................................................................... 41

5.1 ALOCAÇÃO DE TEMPO E ESFORÇO .....................................................................................42 5.1.1 O que as fases do RUP equivalem na XP? ............................................................44 5.1.2 O que as fases da XP se equivalem no RUP ? ......................................................45

5.2 ARTEFATOS ......................................................................................................................46 5.3 ATIVIDADES.......................................................................................................................49 5.4 DISCIPLINAS E WORKFLOWS ..............................................................................................50 5.5 PAPÉIS .............................................................................................................................51 5.6 CONCLUSÃO DO COMPARATIVO..........................................................................................52 5.7 RELATOS COMERCIAIS DE USO DAS METODOLOGIAS ..........................................................53

5.7.1 Qualiti Software Processes .....................................................................................53 5.7.2. CESAR – Centro de Estudos e Sistemas Avançados do Recife ...........................54 5.7.3. VANguard ...............................................................................................................55 5.7.4. Elógica....................................................................................................................55 5.7.5. CI&T .......................................................................................................................56

5.8. MAPEAMENTO DAS METODOLOGIAS ..................................................................................57

CAPÍTULO 6. CONCLUSÃO.................................................................................................................... 59

6.1 CONTRIBUIÇÕES DO TRABALHO..........................................................................................59 6.2 FUTUROS TRABALHOS .......................................................................................................60

x

6.2.1 Especificação de uma Metodologia Híbrida............................................................60 6.2.2 Definição de uma Fábrica de Software ...................................................................60

REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................... 61

xi

Lista das Figuras

Figura 3.1 - Relação fases x disciplinas do RUP............................................22 Figura 4.1 - Práticas na XP.............................................................................36

xii

Lista de Tabelas

Tabela 5.1 - Pequeno projeto ........................................................................ 43 Tabela 5.2 - Grande projeto ........................................................................... 43 Tabela 5.3 - Mapeamento de Fábricas de Software x Tipos de Projetos x

Processos de Software ...................................................................... 57

1

Capítulo 1

Introdução

Este capítulo visa explanar quais as principais características do trabalho, in-

cluindo informações referentes à estrutura da monografia e qual o contexto do mes-

mo. Deixando claro, ainda, sua finalidade, justificando o porquê desse comparativo

ter grande utilidade para empresas desenvolvedoras de software e estudiosos da

área de Engenharia de Software.

O capítulo está divido em 3 (três) partes, o Contexto do Trabalho, que explica

a finalidade e onde o estudo se enquadra, os Objetivos e Metodologias do Trabalho,

esclarecendo quais técnicas foram utilizadas para a composição do trabalho, e fi-

nalmente, a Estrutura do Trabalho, no qual organiza e orienta o leitor sobre os poste-

riores capítulos e seus conteúdos abordados.

1.1 Contexto do Trabalho

Desde a Crise do Software, que forçou com que as Software Houses realizas-

sem projetos de desenvolvimento de Software de uma maneira mais profissional e

organizada, gerando uma documentação para acompanhar o produto, muitas meto-

dologias para esse desenvolvimento surgiram. Linguagens foram criadas para mo-

delar e facilitar o entendimento do produto pelo cliente e pela própria empresa de-

senvolvedora [PRESSMAN 02].

Essa documentação gerada a partir na análise da especificação dos projetos,

era acompanhada de um método de desenvolvimento para especificar ao cliente o

que seria desenvolvido e como isso seria feito. Foi então que surgiram Métodos para

2

visualizar o processo de desenvolvimento, dividindo-o em etapas, sempre com foco

na qualidade final do produto.

Os processos sempre começavam com uma primeira etapa de Análise, onde

os requisitos eram estabelecidos de acordo com a necessidade do cliente. Depois

da Análise, tem-se a Modelagem que gera os documentos necessários e por último

o Desenvolvimento e a fase de Testes [XISPE 04].

Levando-se em consideração que o processo de desenvolvimento é bastante

mutável, pois o surgimento de novos requisitos (tanto funcionais como não-

funcionais) por parte do cliente é normal, assim como a não conformidade de algu-

mas solicitações, era necessário alterar constantemente a documentação e o produ-

to em si. Isso demandava muito tempo.

Para circular esse problema de constantes alterações, assumindo que essas

mudanças fazem parte do processo de desenvolvimento surgiram os Métodos Ágeis,

aqueles com foco no código e otimizados para alterações de requisitos [XISPE 04],

como a Extreme Programming1 [WELLS 04], esses métodos também prezam pela

qualidade do Software, mas a sua filosofia de desenvolvimento é diferente, dando

ênfase principalmente no código, sendo que as alterações necessárias não devem

acarretar em tanto tempo gasto.

Com o surgimento recente de novas Metodologias de Desenvolvimento de

Software – MDS, que dividiram o processo de desenvolvimento de Software, para

organizá-lo, planejá-lo e facilitar o entendimento do mesmo, existem agora duas

principais áreas de atuação, o Desenvolvimento chamado Tradicional, com emba-

samento na Análise e Projeto, mantendo tudo em documentos, porém se tornando

lento para mudanças, e o Desenvolvimento Ágil, baseado em código, totalmente a-

1 Principal expoente do Desenvolvimento Ágil, citado no capítulo 4 deste trabalho.

3

daptável a mudanças nos requisitos, entretanto fraco na parte contratual e de docu-

mentos.

O trabalho faz um comparativo entre as Metodologias de Desenvolvimento

Tradicional e o Ágil, analisando pontos fortes e fracos de cada uma e os pontos em

comum. Ainda coleta informações de grandes empresas de consultoria e de desen-

volvimento de softwares, informando como ambas metodologias são utilizadas tanto

na fase de desenvolvimento, quanto na análise do projeto e como elas se adaptam

comercialmente.

1.2 Objetivos e Metodologia do Trabalho

O foco principal do trabalho é um comparativo entre as metodologias, anali-

sando cada uma de acordo com características comuns a um processo de software,

a fim de concluir onde e por que uma é superior a outra conforme diferentes visões.

No entanto, para termos informações suficientes sobre ambas as metodologi-

as foi necessário estudar cada uma separadamente, analisando o processo de cada

uma, além de estudarmos o principal expoente de cada, sendo o RUP – Rational

Unified Process – das metodologias tradicionais e o XP – eXtreme Programming –

como referencial das metodologias ágeis.

Como metodologia de pesquisa para reunir informações foi usada a pesquisa

Bibliográfica, a fim de conhecer profundamente cada Metodologia a ser estudada.

Assim como a Internet para obter conhecimento sobre o que havia de novo sendo

desenvolvido e quais as exigências do mercado, além de meio de comunicação en-

tre as empresas contatadas para a pesquisa de mercado.

Como técnica de pesquisa, foi adotada, a pesquisa analítica, visto que basea-

do em experiências de análise tanto de cunho Tradicional como Ágil, foram analisa-

4

dos os pontos referenciais que as diferem e o que as assemelham, baseados em

características destas metodologias.

Finalmente, para recolher informações de outras empresas foram promovidas

entrevistas com membros responsáveis de algumas empresas da área de Engenha-

ria de Software, tanto na área de consultoria, quanto desenvolvimento de aplicações.

1.3 Estrutura do Trabalho

Além deste capítulo 1 introdutório, que trata dos objetivos do trabalho e quais

as técnicas e metodologias utilizadas, assim como o contexto do trabalho e divisão

dos capítulos, o trabalho é dividido segundo a estrutura a seguir.

O capítulo 2, intitulado “Desenvolvimento de Software: Visão Geral”, trata de

características comuns entre todas as metodologias de desenvolvimento, tanto tradi-

cionais quanto ágeis, mostrando que todas partem de um mesmo princípio. Assim

como aborda uma breve introdução de como surgiram as metodologias.

O capítulo 3, intitulado “Metodologias de Desenvolvimento Tradicionais ou

Pesadas”, aborda unicamente as metodologias tradicionais, também conhecidas

como pesadas, mostrando suas características e processos. Como parte final deste

capítulo, é apresentado o Rational Unified Process – RUP, que será utilizado como

um dos processos do comparativo.

O capítulo 4, intitulado “Metodologias de Desenvolvimento Ágeis ou Leves”,

descreve as principais características das metodologias ágeis, mostrando de forma

análoga ao capítulo anterior, características e processos dessa metodologia. Ao final

do capítulo é apresentada a eXtreme Programming – XP, expoente maior das meto-

dologias ágeis e, também, processo de nosso comparativo.

5

O capítulo 5, intitulado “Análise Comparativa Entre as Metodologias Tradicio-

nais e Ágeis”, é a parte principal do trabalho, fazendo um comparativo entre as me-

todologias, sendo esse comparativo seguido de relatos de empresas de desenvolvi-

mento de software e consultoria, referentes a utilização destes processos por elas.

Finalmente, o capítulo 6 conclui o trabalho mostrando a relevância do trabalho

e citando futuros trabalhos que podem ser desenvolvidos a partir deste estudo.

6

Capítulo 2

Desenvolvimento de Software: Visão Geral

Na década de 70, a atividade “desenvolvimento de software” era executada

de forma desorganizada, desestruturada e sem planejamento, gerando um produto

final de má qualidade, pois não existia documentação ou era entregue fora do prazo

ou o levantamento de tempo e esforço não correspondia com a real necessidade.

Muitas vezes, esta atividade não satisfazia as necessidades do cliente, desperdi-

çando recursos da empresa e aumentando gastos, que não viriam a ser compensa-

dores para o cliente, demandando tempo, esforço e dinheiro, essa época ficou co-

nhecida com Crise do Software [PRESSMAN 02].

A partir deste cenário, surgiu a necessidade de tornar o Desenvolvimento de

Software como um processo estruturado, planejado e padronizado, para que as ne-

cessidades fossem atendidas e os gastos com informatização de processos de in-

formações se tornassem compensadores.

Para o atendimento desta padronização, surgiram Metodologias de Desenvol-

vimento, que dividem o processo de desenvolvimento em fases pré-definidas. Essas

Metodologias se adequam às características organizacionais e ao ambiente de de-

senvolvimento implementado em uma organização, ao paradigma de desenvolvi-

mento e ao tipo de plataforma que o Software deve ser desenvolvido, e às caracte-

rísticas dos projetos: o tempo que pode ser gasto e a real necessidade do cliente, a

fim de estimar custos e prazos reais.

Entretanto, a Crise do Software perdura até hoje, onde, mesmo com técnicas

avançadas de desenvolvimento e padrões consolidados na área de criação de Soft-

7

wares, ainda existem características da época da Crise, como Projetos atrasados,

erros de estimativa de custos e de tempo, que tornam o Processo, ainda que siste-

matizado, passível de muitos erros.

2.1 Processo de Desenvolvimento de Software Sistema tizado

No início da padronização do Processo de Desenvolvimento, foram mantidos

conceitos típicos de Engenharia, que ajudaram a sistematizar o processo, e mais

tarde, criando a Engenharia de Software.

Fritz Bauer [PRESSMAN 02] define a Engenharia de Software como: “A cria-

ção e utilização de sólidos princípios da Engenharia a fim de obter software de ma-

neira econômica, que seja confiável para trabalhar eficientemente em máquinas re-

ais”. Engenharia é a análise, o projeto, a construção (desenvolvimento), a verificação

e a gestão de elementos técnicos.

O Processo de Desenvolvimento de Software, assim como qualquer outro,

tem um compromisso com qualidade, sendo que esse enfoque na qualidade se de-

senvolveu com o passar do tempo, dando surgimento a métodos e abordagens de

Engenharia de Software cada vez amadurecidos, para gerar produtos de qualidade

melhor e a menores custos.

A Engenharia de Software é dividida em camadas, que tem como foco princi-

pal a qualidade final do produto gerado, e como maneira de chegar até ela é o aper-

feiçoamento do Processo de Desenvolvimento, que consiste na criação de docu-

mentos, artefatos e marcos capazes de representar o contexto do software, levando

em consideração recursos, ferramentas, prazos, restrições, e outros aspectos que

envolvem o desenvolvimento de um produto de software [PRESSMAN 02].

8

Para auxiliar nesse processo existem Métodos de Engenharia de Software

que fornecem técnicas de construção, que abrangem a análise de requisitos, proje-

tos, construção de programas, testes e manutenção. E ainda as Ferramentas, que

servem apenas para fornecer apoio automatizado para processos e métodos.

Numa visão geral do processo de desenvolvimento de um software pode-se

subdividí-lo em três fases genéricas, ou seja, independem da área de aplicação, ta-

manho ou complexidade do projeto.

2.2 Fases do Desenvolvimento de Software

Numa visão geral do processo de desenvolvimento de software, a literatura

especializada costuma subdividi-lo em três fases genéricas [SOMMERVILLE 00], ou

seja, independem da área de aplicação, tamanho ou complexidade do projeto. Estas

três fases serão detalhadas a seguir [SOMMERVILLE 00].

2.2.1 Fase de Definição

É uma das fases principais do projeto, pois é onde se procura identificar fun-

cionalidades, restrições, validações, interfaces e, principalmente, os requisitos-

chave, que o projeto necessita.

É uma fase de muita interação com o cliente para validar todas as informa-

ções por ele passadas e com ele coletadas, a fim de que todos os requisitos-chave

sejam atendidos de maneira correta no decorrer da implementação do produto de

software.

É composta de três sub-tarefas principais, que são executadas independente

dos métodos utilizados nesta fase, que podem variar de acordo com o paradigma

usado. As sub-tarefas são: a Engenharia de Sistemas, que visa entender e definir

objetivos do sistema; o Planejamento do Projeto, que tenta determinar com o máxi-

9

mo de exatidão, custos, tempo, esforço e recursos que são necessários para con-

clusão do projeto; e a Análise de Requisitos, a fim de entender os requisitos (neces-

sidades) específicos necessários para construir um software de qualidade.

2.2.2 Fase de Desenvolvimento

Tenta definir como os dados serão estruturados, como a função deve ser im-

plementada. Em outras palavras, é quando o projeto, que antes estava todo docu-

mentado em papel, passa a ser transformado em código para entrar em operação de

fato.

Linguagens de programação, técnicas e métodos, podem ser diferentes, de-

pendendo da metodologia escolhida, porém tarefas básicas, comuns a todas as me-

todologias, devem ser realizadas, como o Projeto de Software, parte central do de-

senvolvimento, que mostra o que e como será desenvolvido, e a Geração de Códi-

go, que é traduzir em linguagem de programação o que foi especificado no projeto

de software.

Alguns autores colocam a fase de testes dentro da fase de Desenvolvimento,

como parte das tarefas básicas dessa fase, porém o mais importante é que ela, não

pode deixar de existir, pois é justamente nesta fase que se encontram não conformi-

dades com aquilo que foi especificado na fase de Definição, que não atende as exi-

gências do cliente, diminuindo assim a qualidade final do produto.

2.2.3 Fase de Manutenção

É a fase final, pois nela se analisa todo o produto. Tem como foco principal as

modificações, sejam elas correções de erros, adaptações necessárias e novas fun-

cionalidades (melhorias) para evoluir o software. Como alterações ocorrem, a fase

de manutenção engloba algumas características das fases anteriores, porém seu

10

enfoque passa a ser um software já existente. É nesta fase onde as empresas que

desenvolvem softwares obtêm maior parte dos lucros, pois contratos de manutenção

são assinados garantindo receita fixa.

Existem quatro tipos de modificações que podem ocorrer, durante a fase de

manutenção. São elas:

• Manutenção Corretiva : visa corrigir defeitos que ocorreram durante a

fase de desenvolvimento;

• Manutenção Adaptativa : modifica o software para adaptá-lo à altera-

ções no ambiente externo, composto de variáveis que não do escopo

do sistema, como uma mudança de sistema operacional;

• Manutenção Perfectiva : adiciona novas funcionalidades ao software.

Essas novas especificações estão fora do projeto original, e devem ser

consideradas como melhorias de produto;

• Manutenção Preventiva : assume que mudanças, tanto no ambiente

externo, quanto de especificações, vão ocorrer, portanto já prepara o

produto para que o impacto causado por essas alterações não afete o

software. Também é conhecida como Reengenharia de Software, que

nada mais é que a reconstrução de algo real que já foi desenvolvido,

para melhorá-lo.

2.3 Modelos de Processo de Software

Para tornar o desenvolvimento de software uma atividade menos caótica,

surgiram os Modelos de Processo de Software, que visam organizar o desenvolvi-

mento utilizando as técnicas e métodos descritos acima. [SOMMERVILLE 00]

11

Dependendo do tipo de projeto a ser desenvolvido modelos diferentes serão

utilizados, porém todos seguem um determinado ciclo, onde existem quatro fases

distintas, que vão caracterizar o modelo.

A primeira fase é a Situação Atual, que define como está o ambiente. A Defi-

nição do Problema indica qual o problema específico que está se tentando resolver.

O Desenvolvimento Técnico, que resolve o problema de maneira que satisfaça as

necessidades, e, por último, a Integração da Solução, que entrega a solução ao cli-

ente.

Essas quatro fases, quando colocadas em seqüência, formam um ciclo, sen-

do que dentro de cada uma dessas fases desse ciclo, existe um outro ciclo mais in-

terno com um problema em escala menor, e assim sucessivamente, deixando uma

idéia de recursividade. Essa recursividade acaba em níveis racionais, quando uma

solução resolver o problema definido [PRESSMAN 02].

As seções a seguir descrevem sucintamente cada um dos modelos encontra-

dos nas literaturas especializadas [SOMMERVILLE 00], [PRESSMAN 02].

2.3.1 Modelo Seqüencial Linear

Esse modelo, proposto em 1970, é também conhecido como Modelo

em Cascata onde as fases definidas são sistematicamente seguidas de maneira li-

near [PRESSMAN 02].

É o modelo mais usado em todo o mercado, porém não é o mais eficaz, pois

raros projetos seguem esse fluxo linear, além das mudanças de requisitos que ocor-

rem no decorrer do projeto não serem de fácil adaptação, porque alteram toda a do-

cumentação já desenvolvida, o que implica em re-trabalho [PRESSMAN 02].

Mesmo com todos estes problemas, este modelo ainda é bem melhor e mais

eficiente que um projeto que não segue nenhum padrão.

12

O modelo é dividido em etapas pré-definidas, que são: Modelagem, uma vez

que o software interage com o sistema, é importante saber como o mesmo funciona

a fim de prover a compatibilidade com os demais módulos existentes do sistema

como um todo. Análise, onde os requisitos do software são levantados (elicitados) e

definidos para entender como o software funcionará. Projeto, que é a representação

dos requisitos, é sub-dividido em 4 atributos: Estrutura de Dados, que é a maneira

que os dados vão ser tratados, Arquitetura de Software, que define a base estrutural

de como o sistema deve ser desenvolvido, Caracterizações das Interfaces, repre-

sentam o meio entre o usuário e o sistema, bem como entre os módulos do sistema,

e Detalhes Procedimentais [PRESSMAN 02]. A Codificação, que traduz os requisitos

especificados nas estapas anteriores em linguagem de máquina. Testes, os quais

são responsáveis por identificar se todas as funcionalidades desenvolvidas estão

funcionando perfeitamente, ou seja, garantir que esteja de acordo com o que foi es-

pecificado. Por último a Manutenção, que corrige erros encontrados após a liberação

para o cliente, implementando melhorias ao produto – isso implica em um novo ciclo

de desenvolvimento.

2.3.2 Modelo de Prototipagem

Esse modelo é muito utilizado quando nem todos os requisitos de sistema são

definidos de maneira clara pelo cliente. Apenas os objetivos de sistema são descri-

tos, mas não a maneira com que os dados serão processados e como a saída será

mostrada.

A característica principal desse modelo é gerar protótipos do sistema com de-

finições de requisitos dadas pelo cliente. Essas definições geram documentos que,

por sua vez resultam no protótipo. Esse protótipo é então testado pelo cliente para

validar suas funcionalidades [PRESSMAN 02].

13

Após o teste do protótipo o ciclo de desenvolvimento se repete. O engenheiro

de software, que é aquele responsável por fazer a coleta das necessidades do clien-

te, juntamente com o cliente faz o levantamento de novas funcionalidades, que se-

rão desenvolvidas e adicionadas ao protótipo já criado.

Quando todas as funcionalidades que o sistema deveria prover estiverem de-

senvolvidas e validadas, o protótipo é descartado para que o sistema real seja de-

senvolvido com base no que foi especificado com o protótipo, agora dando ênfase,

também, a características não-funcionais: segurança, manutenibilidade e qualidade

do produto; procurando soluções ideais para os problemas.

O modelo de prototipagem tem a grande vantagem de gerar resultados visí-

veis para o cliente de uma maneira veloz, e ao final de cada ciclo, onde novas fun-

cionalidades são adicionadas, pode mostrar a evolução do sistema.

Por se tratar de protótipos, nem sempre a solução escolhida para resolver tal

problema é a ideal, pois não leva em consideração as variáveis de ambiente, como o

sistema operacional onde o software funcionará ou se a linguagem de programação

é adequada. O desenvolvedor pode acabar se acostumando com a idéia de utilizar o

protótipo que foi gerado como parte integral do sistema, deixando “brechas” e possí-

veis erros [PRESSMAN 02].

2.3.3 Modelo RAD – Rapid Application Development

O RAD é um modelo incremental, considerado uma adaptação para projetos

curtos, usualmente com prazo máximo de 90 dias, do modelo sequencial linear. Sua

principal característica é que o produto de software seja desenvolvido em compo-

nentes, pois a reutilização de código permite que a equipe de desenvolvimento pos-

sa desenvolver um sistema completamente funcional em pouco tempo.

Igualmente aos outros modelos, o RAD é subdividido em fases, que são:

14

• Modelagem de Negócios : responsável por definir arquiteturas que

permitam ao negócio (sistema) utilizar informações colhidas de manei-

ra efetiva;

• Modelagem de Dados : responde a questões relacionadas a objetos

de dados utilizando diagramas como o modelo de entidade e relacio-

namento (MER);

• Modelo de Processo : descreve os processos básicos para manipular

as informações contidas nos objetos de dados gerados pela fase ante-

rior, montando assim um fluxo de informações;

• Geração da Aplicação : utiliza ferramentas automatizadas para criar

ou reusar componentes já desenvolvidos;

• Teste e Entrega : testa a integração entre componentes já criados em

outros projetos que foram reutilizados e os que foram desenvolvidos

para o atual projeto. Testa-se também as interfaces criadas.

O RAD, assim como outros modelos, possui desvantagens. Visto que a prin-

cipal característica do RAD é a modularização, e para isso os requisitos precisam

estar bem definidos e com um certo grau de independência entre eles. Se uma das

situações citadas não ocorrerem o modelo pode não ser adequado.

Para que o RAD possa ser utilizado de maneira eficiente, é necessário que

existam uma quantidade de recursos suficientes para montar as equipes RAD de

desenvolvimento. Isto é considerado como um grande problema nos projetos gran-

des, pois são mais difíceis de gerenciar.

15

2.4 Modelos de Processos Evolucionários

Assumindo que os sistemas tendem a evoluir durante o desenvolvimento e

essa evolução acrescenta novas funcionalidades ao projeto, que aumenta as especi-

ficações e, como uma “bola de neve”, crescem até que estouram o prazo definido na

negociação, os modelos evolucionários têm como principal característica a interativi-

dade, com isso é possível desenvolver versões do sistema que a cada novo lança-

mento (release) agrega novas funcionalidades.

As seções a seguir descrevem alguns exemplos de Modelos Evolucionários

[PRESSMAN 02], [SOMMERVILLE 00].

2.4.1 Modelo Incremental

Esse modelo é a “versão” evolucionária do Modelo Sequencial Linear. Apenas

assume que o software desenvolvido pode sempre crescer e agregar novas funcio-

nalidades, sendo que cada uma dessas funcionalidades, ou o conjunto delas, será

desenvolvido por um incremento e esse incremento segue todas as etapas descritas

no modelo linear [PRESSMAN 02].

O primeiro incremento deste modelo é chamado de Núcleo do Produto, pois

nele estarão as principais funcionalidades do sistema, aquelas consideradas vitais.

Os próximos incrementos desenvolvidos agregarão as funções do Núcleo do Produ-

to e dos incrementos anteriores já desenvolvidos. Esse modelo é análogo a uma

“bola de neve” que cresce e atinge sua totalidade quando o produto está completa-

mente desenvolvido [PRESSMAN 02].

O modelo incremental é muito utilizado em projetos longos e que tendem a

crescer com o passar do tempo e o prazo de entrega é curto. Como, ao final de cada

16

incremento, é gerada uma versão do produto final, é possível mostrar ao cliente co-

mo está o andamento do projeto e atingir as metas definidas no começo do projeto.

2.4.2 Modelo Espiral

O Modelo Espiral é um modelo iterativo, como o modelo de prototipagem, e

sistemático como o Modelo Linear. Isso facilita com que sejam lançadas versões

utilizáveis do projeto ao final de cada iteração do modelo, similar ao modelo incre-

mental. É muito utilizado no desenvolvimento de softwares em conjunto com o para-

digma da orientação a objetos, onde o desenvolvimento em módulos, somado ao

processo de integração, se encaixa nos conceitos do paradigma [PRESSMAN 02].

Esse modelo se subdivide em Regiões de Tarefa. Essas regiões abrigam con-

juntos de tarefas que crescem proporcionalmente ao risco e ao tamanho do projeto.

Basicamente existem 6 regiões, sendo que todas podem ser usadas, ou não, em um

projeto. São elas: Comunicação com o Cliente, a fim de manter contato com o clien-

te, adquirindo informações úteis ao sistema; Planejamento, que definirá custo e tem-

po de desenvolvimento; Análise de Risco, gerenciamento e recuperação de riscos;

Engenharia, que á construção da representação da aplicação; Construção e Libera-

ção, onde acontecem a implementação, testes, instalação e suporte da aplicação, e

Avaliação pelo Cliente, quando se tem o feedback quanto ao incremento desenvolvi-

do [PRESSMAN 02].

Uma forte característica desse modelo, que o difere de outros modelos e o

torna bastante utilizado pelas empresas, é o fato de acompanhar toda a vida do

software, mesmo depois da entrega ao cliente, pois é na manutenção que muitas

empresas desenvolvedoras têm o principal foco de atuação.

17

Este modelo é o considerado mais realístico possível, pois assume que usuá-

rios, analistas e desenvolvedores adquirem maior conhecimento sobre o projeto com

o decorrer do tempo [SOMMERVILLE 00].

18

Capítulo 3

Metodologias de Desenvolvimento Tradicionais ou “Pesadas”

Metodologia de Desenvolvimento é um conjunto de práticas recomendadas

para o Desenvolvimento de Softwares, sendo que essas práticas, geralmente, pas-

sam por fases ou passos, que são subdivisões do processo para ordená-lo e melhor

gerenciá-lo [SOMMERVILLE 00].

As metodologias consideradas tradicionais, também chamadas de “pesadas”,

têm como característica marcante serem divididas em etapas e/ou fases. Essas fa-

ses são muito bem definidas e englobam atividades como Análise, Modelagem, De-

senvolvimento e Testes.

Cada fase concluída gera um marco, que geralmente é algum documento,

protótipo do software ou mesmo uma versão do sistema. Esses marcos, dependen-

do do final de que etapa foram criados, podem ser documentos, como Diagramas de

UML2, ou algum protótipo do software.

Muitas “metodologias” pesadas são desenvolvidas no modelo em cascata o

que dificulta o controle do projeto, pois a cada alteração em determinado ponto do

projeto, como os requisitos, será necessário uma volta ao início do mesmo para alte-

ração de documentação ou outro marco [PRESSMAN 02].

O foco principal das metodologias tradicionais é a previsibilidade dos requisi-

tos do sistema, que traz a grande vantagem de tornar os projetos completamente

2 UML – Unified Modeling Language – é a linguagem padronizada de modelagem de sistemas orientados a objetos para visualização, construção, especificação e documentação do sistema.

19

planejados, facilitando a gerência do mesmo, mantendo sempre uma linha, caracte-

rizando o processo como bastante rigoroso [OLIVEIRA 04].

3.1 RUP – Rational Unified Process

Para melhor analisarmos as características das metodologias pesadas, vere-

mos o principal framework utilizado comercialmente no mercado, o RUP.

O maior expoente das metodologias “pesadas” é o RUP, um Processo de En-

genharia de Software criado pela Rational Software Corporation e oriundo do Pro-

cesso Unificado – UP – para descrever como desenvolver um software usando téc-

nicas comerciais com o objetivo de aumentar a qualidade dos softwares gerados

pela empresa desenvolvedora.

O RUP é aplicável em classes de projetos variadas, sendo considerado um

framework genérico para os processos de desenvolvimento, a contar que este deve

ser configurado de acordo com o tamanho e a necessidade de cada projeto.e/ou

empresa desenvolvedora.

O RUP é uma metodologia iterativa, ou seja, trabalha em ciclos de desenvol-

vimento. Isso provê vários benefícios como [KRUCHTEN 00]:

• Gerenciamento de Requisitos: após do começo do desenvolvimento,

é comum que os requisitos mudem, fazendo com que haja alterações

na documentação. Desenvolvendo iterativamente, essas alterações

são facilmente gerenciáveis;

• Integração dos Elementos : quando cada módulo é desenvolvido este

é integrado ao sistema como um todo, evitando que este seja um pro-

blema no final do projeto;

20

• Gerenciamento de Riscos : a cada iteração é possível analisar pontos

críticos e planejar estratégias para não se perder tempo durante o de-

senvolvimento;

• Testes : os testes são realizados ao final de cada módulo, permitindo

que erros e não-conformidades possam ser tratados ainda dentro do

mesmo ciclo.

3.1.1 Arquitetura do RUP

O RUP é dividido, primariamente, em fases, sendo que essas fases podem

conter várias iterações, que são ciclos onde cada etapa acontece. As 4 (quatro) fa-

ses do RUP são [KRUCHTEN 00]:

• Concepção : neste momento define-se o escopo total do projeto, defi-

nindo se este seria, ou não, viável economicamente e se o mesmo re-

solveria os problemas para qual será desenvolvido;

• Elaboração : visa eliminar principais riscos e, principalmente, definir a

arquitetura que o sistema será desenvolvido. Sendo que esta deverá

ser a mais estável e a que permita o sistema evoluir;

• Construção :Nesta fase o sistema começa a ser desenvolvido (codifi-

cado), sendo que este desenvolvimento, assim como todo o projeto,

ocorre de maneira iterativa. Ao final de cada ciclo, pode ser gerada

uma versão utilizável que crescerá a cada iteração;

• Transição : Esta fase implanta é responsável pela implantação do sis-

tema. O Software é passado aos usuários para que estes possam fazer

suas considerações.

21

Outro conceito encontrado do RUP são as disciplinas, também chamada de

workflows. As disciplinas servem para organizar logicamente atividades de engenha-

ria de software de acordo com sua natureza. Elas descrevem o que deve ser feito

em cada iteração a respeito de atividades, responsáveis e documentos. Existem 9

(nove) disciplinas básicas, sendo que 6 (seis) são de engenharia de software e as

outras 3 (três) são de suporte. São elas:

• Modelagem de Negócios: visa entender a estrutura e a dinâmica da

organização para qual se vai desenvolver o projeto, deixando uma úni-

ca visão para cliente, usuários e desenvolvedores, além de derivar re-

querimentos que suportam a organização;

• Requisitos : Definir, documentar e organizar as funcionalidades do sis-

tema, bem como gerenciar o escopo e as mudanças destas funcionali-

dades;

• Análise e Projeto : Traduz os requisitos em uma linguagem que des-

creve como o sistema deve ser implementado. A linguagem utilizada é

a UML (Unified Modeling Language);

• Implementação : Fluxo muito importante. Nele o sistema é codificado

na linguagem de programação especificada. Também são feitos testes

e a integração com módulos desenvolvidos em outros ciclos;

• Testes : Testa todo o sistema, verificando se este está de acordo com o

que foi especificado. Valida também a integração entre objetos já im-

plementados. Tem como meta, encontrar defeitos antes da implemen-

tação do software;

• Implantação: Implanta o sistema para o usuário final, dando ênfase no

treinamento, instalação e suporte;

22

• Gerência de Projeto: Engloba o gerenciamento de riscos, planejamen-

to e o acompanhamento do projeto;

• Gerência de Configuração e Mudanças : Gerencia documentos gera-

dos no decorrer do projeto, para que estes sempre estejam em con-

formidade ao que já foi desenvolvido;

• Ambiente: Define como o RUP foi configurado para ser utilizado no

projeto, além da organização do ambiente de trabalho para toda a e-

quipe de desenvolvimento.

A figura 3.1 mostra a relação entre as fases, mostradas na horizontal, e as

disciplinas, ou workflows, mostradas na vertical.

Para encontrar não-conformidades e falhas no sistema, de acordo com o que

foi especificado no início do projeto, é gerado ao final de cada fase e de cada itera-

ção um documento (marco), que neste processo é chamado de milestone. Este do-

Figura 3.1 – Relação fases x disciplinas do RUP

23

cumento é responsável por verificar se todos os objetivos da determinada fase foram

alcançados.

Existem dois tipos de milestone, os minor milestones, gerados ao final de ca-

da iteração, independentes de que fase de desenvolvimento. Com este documento

são analisados os resultados obtidos durante a iteração, revisando o planejamento

caso seja necessário [KRUCHTEN 00].

E ao final de cada fase, é gerado um major milestone, sendo que este analisa

os resultados obtidos durante a fase. A cada major milestone gerado, é feito uma

verificação total no projeto, onde é determinado se este continua sendo desenvolvi-

do, ou é abortado ou replanejado.

Após a conclusão da última fase, o ciclo pode recomeçar, o que representa

uma evolução do sistema, passando por todas as fases novamente, gerando novos

documentos e novas versões do sistema, caso haja algum desenvolvimento.

O RUP também se utiliza de Artefatos, que são produtos utilizados durante o

desenvolvimento do projeto. Usualmente os artefatos são documentos (relatórios de

riscos), modelos (Casos de uso) e modelo de elementos (Diagrama de Classes).

Esses artefatos são agrupados em disciplinas (workflows), já que cada uma produz

um conjunto de artefatos diferentes.

O conceito central mais importante de todo o processo é o de Workers, ato-

res, em português. Um Worker (ator) define o comportamento e as responsabilida-

des de um indivíduo, ou de um grupo deles trabalhando como uma equipe, dentro do

contexto de uma empresa de engenharia de software.

Workers são os papéis desempenhados por indivíduos dentro do projeto, que

definem como estes devem trabalhar. Esses papéis irão definir as principais ativida-

24

des e responsabilidades do indivíduo, ou grupo de indivíduos, mostrando como es-

tes devem se comportar.

As Atividades são as ações realizadas por um ator que geram algum resulta-

do significativo para o projeto. As atividades são usadas para medir o rendimento de

um determinado indivíduo desempenhando determinado papel.

As Atividades têm um propósito claro, que geralmente é criar ou atualizar al-

gum artefato, seja ele um diagrama ou modelo.

Essas atividades usualmente variam de poucas horas a poucos dias, e são

designadas especificamente a um determinado worker. Servem também como ele-

mento de decisão de planejamento.

Como o RUP é um processo iterativo, as atividades repetidas podem voltar a

ocorrer, principalmente se tratando de alterações em artefatos de diagramas e mo-

delagem, pois estes devem ser alterados a cada mudança na especificação de re-

quisitos.

As atividades são divididas em passos e esses passos podem se encaixar em

3 (três) categorias:

• Pensar: os workers entendem a natureza da tarefa, juntam e exami-

nam os artefatos de entrada, formulando a saída;

• Agir: aonde ocorre efetivamente à criação ou alteração dos artefatos;

• Revisar : os workers analisam o que foi desenvolvido, baseando-se em

algum critério.

Por fim pode-se dizer que o Ciclo de vida do RUP é baseado e suas 4 (qua-

tro) fases. O ciclo é, em sua visão menor, analisando as cada fase, iterativo, já que

implementa perfeitamente o conceito de iteração, porém numa visão total do proces-

so, quando leva-se em consideração todos os passos e a seqüência exata do pro-

25

cesso, é considerado em série. Novas versões e releases (artefatos) podem ser de-

senvolvidos e agregados ao projeto original, encaixando-se no modelo incremental.

26

Capítulo 4

Metodologias de Desenvolvimento Ágeis ou Leves

No começo de 2001, motivados pela observação de times de desen-

volvimentos, perdidos entre os processos que existiam na época, alguns experts da

indústria do desenvolvimento de softwares se uniram para encontrar valores e prin-

cípios relacionados ao desenvolvimento, que seriam capazes de fazer com que os

times, também chamados de equipes, de desenvolvimento pudessem responder

mais rápidos às mudanças nas especificações e que o projeto fosse desenvolvido

mais rapidamente.

Depois de algum tempo de pesquisa, esses experts escreveram um

manifesto, que ficou conhecido como Manifesto for Agile Software Development

[FOWLER 01]. Esse manifesto destacava 4 (quatro) valores. São eles:

• Indivíduos e iterações ao invés de processos e ferramentas;

• Software funcional ao invés de documentação detalhada;

• Colaboração do Cliente ao invés de negociação de contratos;

• Responder às mudanças ao invés de seguir um plano.

Analisando individualmente cada um desses 4 (quatro) valores; as seções a

seguir explicam sucintamente suas definições [BECK 99], [WELLS 04] e [XISPE 04].

4.1. Indivíduos e iterações ao invés de processos e ferramentas

É certo que a qualidade dos profissionais envolvidos no desenvolvimento do

projeto afeta diretamente a qualidade do produto e o bom desempenho da equipe no

27

projeto. Ter excelentes profissionais, no entanto, não é certeza de sucesso, pois es-

tes dependem diretamente do processo. Um mau processo pode fazer com que os

melhores desenvolvedores não sejam capazes de usar de todo o seu talento.

Além da mistura certa do processo adequado com bons profissionais, é preci-

so que todo o grupo possa interagir perfeitamente entre si. Comunicação é mais im-

portante do que simples talento para programação. Um desenvolvedor médio com

bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivo que um

excelente programador trabalhando sozinho.

É importante levar em consideração que, as ferramentas utilizadas são impor-

tantes para o sucesso final do projeto, porém elas não podem ter mais importância

que seus utilizadores. Mais importante que o meio onde se vai trabalhar é a quali-

dade e o grau de interação da equipe.

4.2. Software funcional ao invés de documentação de talhada

A documentação de um projeto é extremamente necessária para o sucesso

do projeto, já que o código não é o melhor meio de comunicação entre o racional e a

estrutura do sistema. A documentação legível para descrever o sistema ainda se faz

necessária na tomada de decisões do projeto.

É preciso tomar muito cuidado com a documentação, pois em excesso é pior

do que a falta dela. De nada adianta uma extensa gama de documentos que demo-

ram muito tempo para serem gerados, se eles não estão em sincronia com o que

está sendo desenvolvido e o que foi especificado. Documentos sem essa sincronia

desvirtuam a realidade do projeto, fazendo com que decisões erradas possam ser

tomadas.

28

O que é sugerido pelo Manifesto é que somente a documentação necessária

seja gerada, e esta esteja sempre sincronizada com o sistema. Para evitar erros

quais documentos devem ser gerados, é levada em conta a seguinte prerrogativa:

“Nenhum documento é gerado a não ser que seja necessário e significante.”

O fato de só existir a documentação necessária ajuda na integração da equi-

pe, pois a transferência de conhecimento sobre o projeto é feita trabalhando lado a

lado, utilizando-se do código, sendo que este não permite duplas interpretações da

funcionalidade e do que o sistema faz, e de alguns dos membros da equipe ajudan-

do quando necessário.

4.3. Colaboração do Cliente ao invés de negociação de contratos.

A venda de um software é muito diferente de um produto qualquer. Não se

consegue um bom software escrevendo suas necessidades num papel e entregando

à empresa que vai desenvolver, esperando que tudo esteja como foi solicitado no

final do prazo estipulado. Projetos tratados desta maneira são falhos, gerando um

produto final de pouca qualidade.

As metodologias ágeis, assumem que para um projeto obter sucesso e acei-

tação, gerando um produto de boa qualidade, é preciso que exista sempre um feed-

back do cliente para garantir que o software esteja sendo desenvolvido de maneira

que atenda as necessidades.

Contratos que determinam requisitos, prazos e custo de um projeto são, fun-

damentalmente, falhos. Isso porque no decorrer do desenvolvimento alguns requisi-

tos passam a se tornarem dispensáveis enquanto surge a necessidade de se adicio-

nar outros não previstos em contrato ou especificação. Portanto, o melhor contrato é

29

aquele que determinará como será a comunicação e o relacionamento do cliente

com a equipe desenvolvedora.

4.4. Responder às mudanças ao invés de seguir um pl ano

Assumindo que mudanças de especificação sempre vão ocorrer em todos os

projetos, é possível afirmar, que melhor será o projeto que mais se adaptar a estas

mudanças. A flexibilidade é fator fundamental para o sucesso do projeto, ela deter-

mina o quão adaptável o projeto é.

Planos devem, sim, ser traçados, porém, como não é possível prever o futuro,

as visões desses planos não podem ir muito longe. Muito deve ser planejado para

poucas semanas, pouco se planeja para o próximo mês e quase nada se planeja

para próximos anos, pois com as alterações que invariavelmente irão aparecer, mui-

to difícil será seguir a risca estes planos mais longos.

Os valores citados como fundamentais dentro do Manifesto inspiraram 12

(doze) princípios básicos, que são características que diferenciam as Metodologias

Ágeis de outras Metodologias chamadas tradicionais.

Esses princípios serão discutidos a seguir [FOWLER 01], [BECK 99]:

a) A maior prioridade é satisfazer o cliente, lançando versões em pouco tem-

po e continuamente.

Como a principal prioridade é por um produto final de qualidade, foram feitas

pesquisas para definir quais as características durante a fase de desenvolvimento,

que foram comuns nos processos que obtiveram sucesso.

O resultado desta pesquisa revelou que o quanto antes se entregasse uma

versão, mesmo que com poucas funcionalidades, do sistema, melhor seria a quali-

30

dade final, pois o sistema começaria a evoluir mais cedo. Sendo que essas versões

deveriam ser atualizadas e entregues num período curto de tempo.

Um processo ágil é aquele que entrega cedo é constantemente. Tenta-se en-

tregar o primeiro sistema já com algumas funcionalidades desenvolvidas e funcio-

nais em algumas semanas do início do projeto, sendo que novos pacotes de funcio-

nalidades continuam sendo desenvolvidos e integrados ao módulo anterior, no de-

correr de algumas semanas. Isso deve ocorrer constantemente.

É de opção do cliente, escolher se vai implantar o sistema ainda não todo

completo ou vai apenas testa-lo para definir novas funcionalidades ou encontrar não-

conformidades com aquilo que é necessário.

b) Mudanças dos requisitos são bem-vindas, mesmo tarde durante o desen-

volvimento. Processos Ágeis mudam para a vantagem do cliente.

Indica atitude. Os participantes dos Processos Ágeis não temem mudanças,

pois assumem que as mudanças são indicadores de que o time está aprendendo

sobre o sistema, possibilitando saber se vai satisfazer o mercado.

c) Entregar software funcional frequentemente, de duas semanas a dois me-

ses. Quanto mais rápido melhor.

A idéia é entregar softwares funcionais regularmente em um curto período de

tempo. Documentações e papéis não contam como entregas, pois não satisfazem à

necessidade atual do cliente.

d) Pessoas de Negócios e Desenvolvedores devem trabalhar em conjunto.

31

Um processo ágil precisa ser guiado constantemente, portanto é necessária a

interação freqüente de Clientes, Desenvolvedores e Partes Interessadas, pois todos

fazem parte do time.

e) A equipe deve estar motivada para o sucesso de um projeto.

Os indivíduos são parte fundamental do processo, como citados nos 4 (qua-

tro) valores das Metodologias Ágeis, portanto é fundamental para o sucesso do pro-

jeto que tos estejam motivados, seja com o apoio de outros membros da equipe ou

material e equipamento. Indivíduos motivados trabalham melhor.

f) A maneira mais rápida de se obter informações é conversando.

Conversação e Comunicação são valores básicos dos Processos Ágeis. Do-

cumentos e papéis são supérfluos, apenas escritos quando extremamente necessi-

tados e significantes. A maneira padrão de troca de informações é a conversação.

g) O progresso do projeto é medido pela quantidade de software funcional

que existe.

30% do projeto estão concluídos, quando 30% das funcionalidades necessá-

rias estiverem funcionando. O volume de documentos e qual fase do processo se

está não determinam o progresso atual do projeto.

h) Processos Ágeis promovem o desenvolvimento sustentável.

A velocidade do desenvolvimento nos Processos Ágeis deve ser sempre

constante. De nada adianta começar um projeto desenvolvendo de maneira rápida e

32

essa velocidade não ser mantida, pois isso irá iludir o cliente, causando a ele uma

impressão de falsa velocidade.

Desenvolver em velocidades diferentes cansa mais os desenvolvedores, fa-

zendo-os ficarem estressados isso diminui a qualidade final do produto, quebrando

um dos principais valores dos Processos Ágeis.

i) Atenção contínua a excelência técnica e boa modelagem aumentam a agi-

lidade.

Alta qualidade é a chave para a agilidade. Para manter rápido o desenvolvi-

mento é necessário deixar o software o mais limpo e o mais robusto possível. Isso

porque os times de Processos Ágeis estão compromissados em desenvolver códi-

gos da melhor qualidade.

j) Simplicidade é essencial.

O caminho a ser escolhido para desenvolver e projetar é sempre o caminho

mais simples e consistente que leve ao resultado final esperado. A escolha do cami-

nho mais simples implica em dizer que caso alguma mudança ocorra – e elas vão

ocorrer – será mais fácil alterar o que já foi feito.

k) As melhores Arquiteturas, Requisitos e Projetos vêm de equipes organiza-

das.

Decisões são tomadas por toda a equipe e não por apenas um indivíduo. Isso

caracteriza uma equipe organizada, pois todos trabalham juntos para o sucesso do

projeto.

33

Responsabilidades são compartilhadas pro todos os membros da equipe,

mostrando que todos estão envolvidos no processo de um projeto.

l) Em intervalos regulares a equipe debate como ela pode ser melhorada e

ajustada para melhores resultados.

Para uma equipe ágil melhorar é uma constante máxima. Sempre são feitas

reuniões com a equipe a fim de encontrar novos pontos onde o time pode ser melho-

rado para satisfazer as necessidades atuais do meio, que está em constante mu-

dança.

O meio está sempre mudando e para e equipe continuar ágil é necessário

que ela mude de acordo.

A seguir serão analisadas algumas características de uma das principais me-

todologias ágeis encontrada na literatura especializada.

4.5. XP – eXtreme Programming

A eXtreme Programming surgiu no início do ano de 1996, quando Kent Beck e

Ward Cunningham juntaram-se para desenvolver uma nova abordagem aos proje-

tos, de uma maneira mais simples, direta e eficiente.

Em março do mesmo ano, Beck conseguiu colocar em prática esses novos

conceitos e valores definidos pela dupla em um projeto na DaimlerChrysler. Agre-

gando a experiência adquirida com esse projeto utilizando essa nova Metodologia.

Como resultado surgiu a eXtreme Programming [WELLS 04].

4.5.1. O que é a eXtreme Programming?

eXtreme Programming – XP – é uma abordagem deliberada e disciplinada pa-

ra o desenvolvimento de software. A XP vem sendo bastante utilizada e vem toman-

34

do espaço que antes pertencia a metodologias tradicionais, como RUP – Rational

Unified Process [BECK 99].

Essa metodologia, por se enquadrar nas metodologias ágeis, carrega consigo

todas as características citadas anteriormente. Desde o foco principal na satisfação

do cliente até assumir que as mudanças nos requisitos sempre vão ocorrer, levando

esse ponto em consideração.

4.5.2 Regras ou Práticas da XP

Para delinear o processo de desenvolvimento, a XP foi estruturada segundo

algumas práticas que permitem aumentar a qualidade do software gerado, aumen-

tando assim a satisfação do cliente.

Essas regras e práticas se dividem em 4 (quatro) categorias que são: Plane-

jamento, Designing, Codificação e Testes [BECK 99]. Cada uma dessas categorias e

os itens de cada uma delas, serão vistos descritivamente nos itens a seguir [WELLS

04], [BECK 99], [XISPE 04] e ilustrativamente na figura 4.1 [WELLS 04].

a) Planejamento

• User Stories são escritas.

User Stories têm o mesmo propósito das Use Cases da UML – Unified Mode-

ling Language – que são utilizadas no RUP e em algumas metodologias tradicionais,

porém não são a mesma coisa.

Usualmente, cada User Story, é um conjunto de frases curtas, em média 3

sentenças, escritas pelo cliente para definir o que o sistema deve fazer para ele.

Essas Stories são levadas em consideração quando se é estipulado um prazo

para o desenvolvimento e, mais importante ainda, é analisar se o que foi desenvolvi-

do atende as necessidades especificadas na mesma.

• O Cronograma é definido pelo Release Planning.

35

O Release Planning é uma reunião onde são apresentados os User Stories,

para a definição de alguns fatores para a continuidade do projeto. Esses fatores são,

basicamente: o tempo ideal para o desenvolvimento de cada User Story, a priorida-

de de cada Story, feita em conjunto com o cliente, a Project Velocity, que pode ser

definida por tempo ou escopo, e quantas Stories podem ser agrupadas e desenvol-

vidas por iteração.

Essas reuniões são regradas por 4 (quatro) variáveis, que são: Escopo, o

quanto pode ser desenvolvido; Recurso, a quantidade de pessoas disponíveis; Tem-

po, quando o software ou release vai ser entregue; e a Qualidade, o quão bom é o

produto e o quanto ele foi testado.

• Fazer pequenos releases frequentemente.

Por ser uma metodologia iterativa, a XP tem como prática lançar releases fre-

qüentes do software, sendo que esta prática aumenta a qualidade final do produto,

pois é possível quem o cliente teste o sistema e veja o que está e o que não está de

acordo com suas necessidades.

• A Velocidade do Projeto é medida.

A Velocidade do Projeto (Project Velocity) é a medida de o quanto de trabalho

foi feito no projeto, a unidade de medida é a quantidade de User Stories que foram

concluídas durante uma iteração.

Pode ser mensurada por escopo, que vai basear quanto tempo durará a pró-

xima iteração, de acordo com a quantidade de User Stories implementadas na itera-

ção anterior. Também pode ser mensurada, por tempo, que determina a quantidade

de User Stories, que serão desenvolvidas na próxima iteração. Esse modelo por

tempo é mais usado, pois assim as iterações têm o mesmo tempo de desenvolvi-

mento, podendo lançar releases em um tempo pré-determinado.

36

• O Projeto é dividido em iterações.

As iterações (iterations) determinam o passo do projeto. Usualmente as itera-

ções têm a mesma duração, ficam no intervalo de uma a três semanas, permitindo

assim gerar releases frequentemente, melhorando a qualidade.

Durante o desenvolvimento em iterações, apenas é criado aquilo que estava

programado para a atual iteração, não sendo permitido desenvolver algo que esteja

previsto para alguma próxima iteração.

Durante uma iteração, primeiro são desenvolvidas as Stories mais importan-

tes, sendo esta importância definida pelo cliente, durante uma prévia reunião.

• Move People Around

Quando apenas um membro da equipe conhece determinada área do desen-

volvimento, e esta pessoa está bastante atarefada, ou algum imprevisto acontece, o

projeto pára. Isso é ruim, pois diminui o passo e provavelmente impede que o relea-

se/projeto, seja entregue no prazo determinado.

Figura 4.1 – Práticas na XP [WELLS 04]

37

Para evitar problemas como esse, é interessante que todos os membros da

equipe tenham o mesmo conhecimento do projeto, fazendo com que a perda de um

desenvolvedor seja menos impactante ao projeto.

A comunicação entre a equipe e o remanejamento constante dos membros

nas áreas do desenvolvimento e a capacitação interna da equipe impedem estas

“Ilhas de Conhecimento”. O Pair Programming, que será visto mais a frente, também

é uma maneira de evitar isso.

• Reuniões Stand-Up diárias.

Reuniões formais demoram muito e fazem com que os desenvolvedores per-

cam tempo que deveria ser gasto nas iterações. Para evitar isso a eXtreme Pro-

gramming diz que essas reuniões devem ser feitas informalmente, em pé, onde os

colaboradores podem trocar experiências e compartilhar soluções ao projeto. Essa

prática se torna mais comum quando a comunicação entre a equipe começa a ser

melhor explorada.

• Consertar o XP quando quebrar.

É comum quando os membros da equipe não estão acostumados a certas re-

gras e práticas, que o processo não ande como o esperado. Quando isso acontece,

é necessário que as regras sejam seguidas e adequadas conforme a realidade da

equipe e de cada desenvolvedor.

b) Designing

• Simplicidade é a chave.

Um projeto simples demora menos tempo para ser concluído do que um pro-

jeto complexo. Itens complexos do projeto devem ser substituídos por itens mais

simples que fazem o mesmo serviço. Sempre deve se procurar e desenvolver o mais

simples possível que tenha os melhores resultados, pois, caso haja, necessidade de

38

alteração o tempo gasto durante o desenvolvimento não seja grande, assim como o

tempo para as alterações.

• Escolha uma System Metaphor.

Escolher uma Metáfora para definir o Sistema facilita os desenvolvedores a

escolherem nomes verossímeis ao projeto, para classes e variáveis, mantendo o

projeto numa constante e facilitando a compreensão do sitema, inclusive na manu-

tenção.

c) Codificação

• O cliente está sempre disponível.

A XP tem como um dos valores principais a comunicação, portanto durante a

todo o decorrer do projeto, é muito importante que haja uma interação entre a equipe

de desenvolvimento e o cliente, sempre que possível e necessário. O cliente deve

ser considerado parte da equipe.

As User Stories são escritas pelo cliente e como elas delineiam as trilha do

desenvolvimento, é de suma importância que haja uma interação da equipe de de-

senvolvimento com o cliente nesta fase, pois é com base no que foi escrito que será

estimado tempo de desenvolvimento.

A comunicação ainda se faz necessária durante a release planning, quando é

decidido quais Stories farão parte da próxima iteração, de acordo com os objetivos

do cliente.

Outro momento muito importante da interação com o cliente é na fase de tes-

tes. Após os testes internos feito pela equipe de desenvolvimento, é fundamental

que os clientes testem o sistema e verifiquem se cada funcionalidade está de acordo

com aquilo que foi descrito na Story. Esse feedback deve ser o mais rápido possível,

39

enquanto o desenvolvimento se encontra ainda na etapa em que a não conformida-

de ocorreu, mantendo assim a agilidade do processo.

• Pair Programming

“Todo o código destinado ao projeto deve ser desenvolvido por duas pessoas

trabalhando juntas em um mesmo computador, compartilhando teclado e monitor”,

esse é o conceito de Pair Programming.

Duas pessoas trabalhando juntas produzem a mesma quantidade de código

quanto estivessem trabalhando separadas, e o mais importante, é código de melhor

qualidade. Com melhor qualidade economiza-se tempo.

Duas pessoas compartilhando um computador ainda diminui o tempo de dis-

persão e distração com outros acontecimentos do meio, como internet e conversas

sobre assuntos extra-projeto.

• Integrar constantemente.

É importante sempre estar atualizando o repositório de dados quando possí-

vel. Essa prática evita desperdício de esforço, pois se sabe ao certo o que já está

desenvolvido, sendo assim práticas da Programação Orientada a Objetos, como a

reutilização de código, podem ser aplicadas.

Essa integração constante permite que problemas de compatibilidade possam

ser descobertos antes e métodos para evitá-los podem ser desenvolvidos. Além de

economizar tempo no final do projeto quando se tenta integrar tudo de uma única

vez.

d) Testes

• Unidades de Testes.

40

As unidades de testes são fundamentais para o projeto. Usualmente são de-

senvolvidas antes do código em si, baseadas em algum framework de testes já exis-

tente ou desenvolvido para o projeto.

Todo o código adicionado ao repositório deve ser devidamente testado. Aque-

les que não forem testados não podem ser integrados ao que já foi desenvolvido.

Adicionar novas funcionalidades ao que já foi desenvolvido implica numa nova

bateria de testes. Caso estas alterações não estejam contempladas na unidade de

testes que foi desenvolvida, essa também deve ser modificada a fim de englobar

essas alterações.

Desenvolver as unidades de testes antes do código em si aumenta a possibi-

lidade de sucesso na primeira tentativa, pois os riscos já foram analisados.

• Testes de aceitação são feitos regularmente e seu resultado é publica-

do.

Esses testes, antes conhecidos como Testes Funcionais, são criados das U-

ser Stories fornecidas pelo cliente, em conjunto com a equipe de desenvolvimento. A

cada iteração são desenvolvidos testes de aceitação referente às funcionalidades

contempladas na iteração. Esses testes são feitos com cenários reais vividos no dia-

a-dia do cliente.

Os resultados destes testes são verificados pelo cliente que validará o grau de

precisão desses dados. Um resultado positivo do cliente determina que uma User

Story foi desenvolvida corretamente.

Os resultados dos testes são mostrados a equipe desenvolvedora para que

consertar aquelas funcionalidades que ainda não estão de acordo com as necessi-

dades do cliente.

41

Capítulo 5

Análise Comparativa entre Metodologias Tradi-cionais e Ágeis

Depois de analisar individualmente cada um dos principais expoentes (carac-

terísticas) das metodologias tradicionais, com o RUP (Rational Unified Process), e

das metodologias ágeis, com o XP (eXtreme Programming), analisaremos neste ca-

pítulo, comparativamente, ambas as abordagens de processos.

Esses dois processos que serão analisados têm pontos em comum que per-

mitem que a comparação seja possível. Esses processos são uma seqüência de

atividades, realizadas por papéis, que geralmente são indivíduos ou a equipe, a fim

de gerar artefatos ou produtos para serem entregues aos clientes.

Neste trabalho os itens comuns da análise comparativa das duas metodologi-

as são:

• Tempo e Esforço : discute como cada um dos dois processos lida com

o tempo e como é feita a alocação de esforço;

• Artefatos : compara os produtos do trabalho. Tudo aquilo produzido no

decorrer dos dois processos;

• Atividades : discute a maneira como cada processo determina a manei-

ra que os artefatos devem ser produzidos;

• Disciplinas : compara a maneira que o RUP e a XP delineiam as áreas

de preocupação da engenharia de software;

• Papéis : explora a diferença entre os perfis do RUP e os perfis das e-

quipes de XP.

42

5.1 Alocação de Tempo e Esforço

No desenvolvimento de software tudo gira em torno do tempo. Contratos são

determinados mais pela quantidade de tempo especificada do que pelo valor comer-

cial em si, portanto tal aspecto deve ser analisado exaustivamente, a fim de determi-

nar qual o processo que mais se adequa à necessidade do cliente.

O RUP, como dito antes, é divido em fases, essas fases são divididas em ite-

rações e essas iterações podem conter vários ciclos. Uma iteração do RUP leva en-

tre 2 (duas) semanas e 6 (seis) meses. Considerando que em um projeto o número

de iterações recomendadas fica entre 3 (três) e 9 (nove), pode-se concluir que a fai-

xa de tempo que um projeto orientado pelo processo dessa metodologia pesada leva

de 6 (seis) semanas a 54 (cinqüenta e quatro) meses, para sua conclusão [SMITH

01].

Analisando os valores padrões para a eXtreme Programming, considera-se

que as iterações levem 2 (duas) semanas para serem concluídas. Os releases na

XP são usualmente programados de 2 (dois) em 2 (dois) meses, visto que são de-

terminados em reuniões com os clientes e a equipe. Esses releases da XP equiva-

lem as iterações do RUP [SMITH 01].

Utilizando-se do COCOMO3 [BOEHM 81] como modelo para estimar custo,

esforço e tempo, considera-se que um time com 10 (dez) programadores é ideal pa-

ra um projeto de duração de 15 (quinze) meses. Projetos que venham a durar mais

tempo que isso, certamente devem ter uma equipe de desenvolvimento maior.

Desenvolver projetos muito longos com uma equipe pequena, geralmente

menor do que foi especificado pelo modelo, pode provocar alguns problemas, visto

3 COCOMO é um modelo utilizado para estimar custo, tempo e esforço quando se planeja o desenvolvimento de projetos de softwares

43

que a equipe desenvolverá de maneira serial, enquanto se fosse maior desenvolve-

ria paralelamente.

Analisando dois exemplos de projetos que se encaixam nos padrões da XP,

consegue-se mapear perfeitamente as relação entre as iterações do RUP e os rele-

ases da eXtreme Programming. As Tabelas 5.1 e 5.2 [SMITH 01] mostradas abaixo

ilustram como devem ser planejados dois projetos baseados no RUP. Os números

são indicativos, porém razoáveis para os padrões dos projetos.

Tabela 5.1 – Pequeno projeto

Concepção Elaboração Construção Transição Equipe 1,5 2,5 4 3

Duração em semanas 4 7 20 4 Número de iterações (duração

da iteração em semanas) 1 (4) 2 (7) 3 (7) 1 (4)

Para projetos dentro dos limites considerados padrões pela XP é visível que

as iterações do RUP coincidem com os releases tanto no quesito duração e inten-

ção.

Tal fato não ocorre com projetos grandes, aqueles que os padrões estão fora

do limite especificado pela XP. Esses projetos muitas vezes são guiados pelo RUP e

têm como característica a grande duração de suas iterações. A Tabela 5.2 mostra

uma estimativa para um grande projeto.

Tabela 5.2 – Grande projeto

Concepção Elaboração Construção Transição Equipe 35 70 140 100

Duração em Semanas 20 50 100 20 Número de iterações(duração

da iteração em semanas) 2 (10) 2 (25) 3 (33) 2 (10)

Em grandes projetos, usualmente as equipes são divididas para que se possa

ser desenvolvido paralelamente. Cada equipe ficará com um subsistema do projeto,

sendo que cada um desses subsistemas, geralmente, se encaixam nos padrões da

44

XP, porém como é necessário que o projeto seja tratado como um todo, o escopo

foge os limites da eXtreme Programming.

5.1.1 Em que ponto as fases do RUP equivalem na XP?

Na XP antes dos ciclos e releases começarem, é necessário uma análise pré-

via do escopo do projeto para definir se ele é viável ou não, determinar custo, esfor-

ço e tempo, esse momento na eXtreme Programming tem a mesma razão que a fa-

se de Concepção no RUP [SMITH 01].

Para iniciar um projeto é necessária essa análise, porém o que se difere nes-

sas duas metodologias é que, enquanto a XP prega que isso deve ser feito de ma-

neira rápida e objetiva, o RUP, entretanto, considera que esta fase levará o tempo

que for prudente, pois é feita a análise de risco, fator determinante no processo.

Os pontos, em comum, discutidos, mesmo que em escalas diferentes, são:

• Levantamento de requisitos;

• Planejamento;

• Negociação com o cliente;

• Restrições no projeto.

Outro ponto onde as metodologias se diferem é quanto a arquitetura e infra-

estrutura. A XP não se preocupa com um planejamento de infra-estrutura a longo

prazo, ou seja, em iterações diferentes, pois considera que somente as funcionali-

dades previstas para a atual iteração devem ser levadas em consideração. Já o

RUP, geralmente utilizado em grandes projetos e baseado na gerência de riscos,

não pode deixar este ponto de arquitetura e infra-estrutura sem planejamento, pois

45

refazer código pode levar mais tempo que o previsto, considerando o grau de com-

plexidade do projeto.

A ênfase do RUP no planejamento é com a intenção de que a visão inicial do

projeto não esteja totalmente correta, o que pode provocar mudanças bruscas no

escopo, fazendo com que essas mudanças sejam necessárias para o bem estar do

projeto.

Dependendo do nível de conhecimento da equipe do projeto é possível que o

tempo gasto com o planejamento seja reduzido, pois situações de menos risco ou

onde a solução seja desenvolvida em um framework comum na equipe, tendem a

ser menos analisadas e projetadas. Isso faz com que o ciclo de vida do RUP se a-

proxime do ciclo de vida da XP.

Já a fase de Construção do RUP se equivale aos releases da XP, desde que

ao final de cada iteração dentro da fase de Construção sejam entregues pacotes de

funcionalidade ao cliente.

A fase de Transição do RUP não encontra um equivalente dentro da XP, pois

ao final de cada release este já é entregue ao cliente.

5.1.2 Em que ponto as fases da XP se equivalem no R UP?

As fases da XP são, tanto para as iterações quanto para os releases, Explo-

ração, Compromisso e Steering. Durante os releases, essas fases se equivalem às

disciplinas do RUP. Analisando abaixo é possível visualizar as semelhanças.

O Ciclo de Vida de um projeto ideal da XP, numa visão mais abrangente do

projeto, consiste das fases de exploração, planejamento, iterações até o primeiro

release, desenvolvimento, manutenção e a “morte”. Cada release é composto de

uma fase de exploração antes do início das iterações, o que caracteriza essa fase

como um caminho obrigatório para cada iteração.

46

Comparando o ciclo de vida de ambas as metodologias é possível afirmar que

a XP entrega os releases mais rapidamente e com uma freqüência maior, exatamen-

te como é citado nas práticas da metodologia, pois não perde muito tempo nas fases

de exploração e planejamento, como perde o RUP nas duas primeiras fases. Isto se

deve ao fato de que este faz uma análise de risco, que consome algumas iterações

na fase de Elaboração, garantindo que a arquitetura desenvolvida não seja falha,

impedindo que no futuro seja necessária alguma alteração que impacte em re-

trabalho e perda de tempo muito grandes.

A XP assume que não ocorrerão erros e que o que foi desenvolvido e devi-

damente testado não está suscetível a algum erro.

Atualmente, o RUP vem fazendo com que sua abordagem também seja utili-

zada em pequenos projetos, mudando alguns conceitos que venham a torná-lo mais

ágil e menos burocrático. Tal fato torna o início da abordagem, no caso, a fase de

elaboração, menor economizando tempo e fazendo com que releases sejam entre-

gues mais rapidamente ao cliente.

5.2 Artefatos

Uma das principais características do RUP, atacada pelos adeptos da pro-

gramação extrema, ou outra metodologia ágil, é o excesso de burocracia e de do-

cumentos que a metodologia tradicional gera. Atualmente o RUP descreve mais de

100 (cem) documentos diferentes, sendo esse número um muito alto considerando a

abrangência de pequenos projetos.

O que não se tem discutido é que muitos desses documentos não precisam

ser gerados, sendo apenas escritos quando existe a necessidade dos mesmos, se-

guindo um princípio das metodologias ágeis.

47

A idéia de especificar com tantos documentos o projeto é deixar o processo

mais objetivo com metas bem definidas.

A eXtreme Programming é livre dessas críticas quanto a quantidade de do-

cumentos, fator de simples dedução quando se considera que é uma metodologia

ágil, adequada a projetos pequenos, que usualmente consistem em funcionalidades

não muito complexas.

O manifesto das metodologias ágeis diz que os documentos devem ser gera-

dos somente se muito necessários, sendo a XP uma metodologia ágil, essa caracte-

rística vale para a mesma. O que acontece é que esses documentos são sempre

exigidos no decorrer do projeto, seja como um release plan ou algumas user stories,

ambos vitais para o bom fluxo do projeto.

5.2.1 Por que a XP não precisa de todos dos documen tos do RUP?

Uma das razões é que as abordagens têm escopos diferentes. Enquanto o

RUP se encaixa, com alguns ajuste e padronizações, em todos os tipos de projetos,

a XP tem seu foco nos projetos pequenos, que acabam não necessitando de muita

documentação [SMITH 01].

Algumas comparações podem ser feitas para ilustrar a diferença de escopos.

Enquanto na XP, durante as reuniões com o cliente determina-se o intervalo de lan-

çamento dos releases, que geralmente fica entre 2 (duas) semanas e 2 (dois) me-

ses, sem utilizar artefato algum, no RUP esse processo tem aproximadamente 9

(nove) documentos [SMITH 01].

Outro possível motivo é a maneira que a XP trata a etapa inicial de coleta de

requisitos. Enquanto na programação extrema esses requisitos são coletados atra-

48

vés das User Stories, no RUP isso é feito através de entrevistas e questionários, que

serão transformados em outros artefatos no decorrer do processo.

A complexidade do que se está sendo desenvolvido, muitas vezes pode fazer

com que documentos sejam escritos. Uma abordagem sistemática, para esses ca-

sos, se faz necessária. As técnicas e valores da XP pregam que a interação com o

cliente é o mais importante, mas é válido frisar que nem sempre esses valores po-

dem ser seguidos sem a ajuda de documentos. Além do que esses documentos, na

maioria dos casos, dão uma visão mais abstrata do projeto, facilitando a compreen-

são.

Finalmente, a eXtreme Programming tem uma grande aversão a parte contra-

tual e de negociação do projeto e muitos dos documentos gerados para o projeto

são focados para esse momento. O RUP tem aproximadamente 15 (quinze) artefa-

tos possíveis de serem gerados para a negociação, sendo que, dependendo da

complexidade e tamanho do projeto, nem todos precisam ser escritos. Em pequenos

projetos, esses 15 (quinze) artefatos podem ser reduzidos para 6 (seis) [SMITH 01].

5.2.2 Comparando artefatos para pequenos projetos

Fica claro que pequenos projetos necessitam de menos documento do que os

grandes, e esse pequenos projetos é que são principal foco da programação extre-

ma, portanto é importante comparar as abordagens nesse ponto.

Quando o RUP é adaptado para pequenos projetos, a quantidade de docu-

mentos reduz para 30 (trinta), uma quantidade pequena, comparada com o que deve

ser documentado nos projetos de grande porte [SMITH 01].

Esse número se equivale à quantidade de documentos que podem ser gera-

dos, de acordo com as práticas da eXtreme Programming, esclarecendo em alguns

49

documentos aquilo que a XP não trata, pelo menos abertamente e documentalmen-

te.

O que acontece é que em quantidade de documentos as metodologias se e-

quivalem, mas na extensão e tamanho daquilo que é abordado em cada documento

são diferentes. Tomando como base os documentos gerados na etapa de testes o

RUP orientado para pequenos projetos gera apenas um único documento que é o

Modelo de Testes, já a XP gera 4 (quatro), que são os Testes de Aceitação, Testes

de Dados, Testes de Resultados e Unidades de Testes [BECK 99].

Esses 4 (quatro) documentos gerados na programação extrema são engloba-

dos num único documento no Processo Unificado da Rational, fazendo com que este

artefato se torne extenso e abrangente, porém sendo tratado como único [KRUCH-

TEN 00].

5.3 Atividades

Formalmente para o RUP as atividades são as tarefas desempenhadas por

um determinado papel, usando e modificando documentos, produzindo novos artefa-

tos. Cada atividade dessas está relacionada com uma disciplina (workflows) [KRU-

CHTEN 00].

As atividades têm como objetivo trabalhar cada artefato, fazendo com que e-

les se tornem menos abstratos e mais focados nas metas do projeto, ajudando a

determinar variáveis como custo, tempo e esforço. Esses artefatos servirão como

guias no decorrer do projeto.

Já na eXtreme Programming, por ter uma visão simplificada como abordagem

de um projeto, tem apenas 4 (quatro) atividades básicas, onde cada atividade dessa

se utiliza de técnicas ou práticas para atingir melhores resultados [BECK 99]. Os

50

conceitos para essas atividades abordados nas referências sobre XP fazem com

que elas se assemelhem as disciplinas do Processo Unificado da Rational.

5.4 Disciplinas e Workflows

Apesar de contar com 9 (nove) workflows básicos em seu processo, o RUP

não abrange todas as áreas de uma Fábrica de Software como contratação de cola-

boradores, marcado e contato com o cliente, que são fatores externos ao escopo do

projeto, porém de grande importância para que este possa ser executado com su-

cesso e qualidade [KRUCHTEN 00].

Na eXtreme Programming esse escopo é mais fechado ainda, pois conta a-

penas com 4 (quatro) atividades básicas que são seguidas através de algumas prá-

ticas da metodologia [BECK 99], algumas delas se equivalendo de algumas discipli-

nas do RUP, como a atividade de planejamento que se equivale a disciplina de Ge-

rência de Projeto no Processo Unificado da Rational [SMITH 01].

Ainda assim o RUP não abrange todas as atividades e práticas da XP, e o

mesmo acontece no caminho inverso. Workflows como o de Modelagem de Negó-

cios e Elicitação de Requisitos não fazem parte do escopo da programação extrema.

5.4.1 O Uso de práticas da XP no RUP

Muitas das práticas sugeridas na eXtreme Programming podem ser, e algu-

mas já são, implementadas no processo da Rational, como a Pair Programming

(programação em pares), que já tem sua eficácia comprovada, melhorando qualida-

de e aceitação do produto final. O que seria diferente na abordagem do RUP para a

pair programming é o momento que ela seria aplicada, que seria apenas quando

51

alguém da equipe fosse novo numa tecnologia, ou mesmo na empresa, fazendo com

que haja uma interação melhor [POLLICE 03].

Também podem ser consolidadas práticas como os testes serem desenvolvi-

dos primeiro que o sistema em si e a prática do suporte on-site no cliente, que en-

globa características típicas da XP como a comunicação com o cliente [POLLICE

03].

5.5 Papéis

As atividades são desempenhadas por papéis, que também tem a responsa-

bilidade de elaborar e alterar alguns determinados artefatos, que são gerados pelas

atividades que estes papéis desempenham [KRUCHTEN 00].

Em ambas as abordagens os papéis podem ser desempenhados por um úni-

co indivíduo da equipe ou por um grupo deles, sendo que o mesmo indivíduo, ou

grupo de, pode realizar mais de um papel.

O que mais difere entre as metodologias é a quantidade de papéis apresenta-

das em cada uma delas. Enquanto no Processo Unificado da Rational encontram-se

listado cerca de 30 (trinta) papéis distintos, na programação extrema esse número

fica em 7 (sete) [SMITH 01].

É fácil determinar o porquê de tanta diferença de números. O RUP caracteriza

melhor cada um desses papéis, sendo que isso facilita quando se procura um indiví-

duo com determinado perfil para assumir um papel, especializando melhor as fun-

ções/competências de quem vai se adequar ao papel. Já na XP, os poucos papéis

que existem são mais abrangentes, englobando vários papéis dentro do RUP, como,

por exemplo, o Programador que tem características do Implementador, Integrador e

Revisor de Código, no processo da Rational.

52

Além dos papéis da programação extrema serem mais abrangentes do que os

do RUP, não se pode deixar de levar em consideração o foco de cada metodologia.

Enquanto o RUP serve de processo tanto para pequenos, médios e grandes proje-

tos, sendo que quanto maior a complexidade maior a necessidade de especializar as

funções, a XP tem como principal alvo os projetos considerados pequenos e médios,

onde a especialização das funções não é tão necessária.

Quando se diminui a complexidade e o tamanho do projeto, a quantidade de

papéis que se fazem necessário à especialização diminuem, fazendo com que essa

quantidade se torne um número bastante inferior aos 30 papéis definidos pelo pro-

cesso como um todo.

5.6 Conclusão do Comparativo

Vendo as comparações conclui-se que ambas as abordagens têm pontos for-

tes e fracos, sendo que alguns pontos antes exclusivos das metodologias ágeis pas-

sam a ser englobados nas metodologias tradicionais e o caminho inverso também é

válido, fazendo com que haja uma espécie de metodologia híbrida entre elas.

Enquanto o principal foco do RUP são os grandes projetos, onde se necessi-

tam de especializações e especificações maior do projeto, a eXtreme Programming

tem seu foco nos pequenos projetos, onde o excesso de documentos e burocracia

recomendada pelo RUP é considerado perda de tempo [SMITH 01].

Dessa forma, as duas seções a seguir fazem uma espécie de levantamento

de algumas das principais Fábricas de Software do país que fazem uso nos seus

processos de desenvolvimento de software os expoentes tradicionais e ágeis. Poste-

riormente, um mapeamento das principais características dos tipos de processos

(tradicionais e ágeis), junto à classificação das Fábricas de Software segundo [FER-

53

NANDES 04] e os domínios dos diferentes projetos de software [SOMMERVILLE

00], é feita.

5.7 Relatos Comerciais de Uso das Metodologias

Abaixo seguem relatos de grandes empresas nacionais na área de engenha-

ria de software, sendo que cada fábrica listada se encaixa em um dos padrões, que

são: Código, Outsourcing, Componentes e Projetos [TEIXEIRA 04], além de uma

renomada empresa de Consultoria.

5.7.1 Qualiti Software Processes

A Qualiti é uma empresa de consultoria na área de desenvolvimento de soft-

ware, localizada em Recife – PE.

O relato a baixo foi cedido por um Consultor de Processos de Software da

empresa.

“A Qualiti é uma empresa que possui como um dos focos de sua atuação a

análise, especificação e implantação de processo de software em organizações cujo

o fim seja desenvolvimento de projetos de software.

Com o capitação cada vez maior de conhecimento acerca deste nicho de

mercado em experiência com algumas empresas de Recife, e outras cujo o foco de

atuação seja fora do território pernambucano, a Qualiti inicialmente fez uso de pro-

cessos tradicionais, já que pode-se mencionar como uma de suas vertentes o forma-

lismo do fluxo e um planejamento mais adequado de cada fase de desenvolvimento

do projeto de software.

Detectamos em nossa atuação que as atividades definidas em um processo,

principalmente as encontradas no fluxo de implementação, necessitavam de proce-

dimentos que provessem uma agilidade maior nas suas execução. Assim, passamos

54

a integrar em nossos processos algumas características dos processos ágeis, sendo

que estes sempre integrados a fim de prover aos nossos clientes uma melhor flexibi-

lidade dos atributos de composição de um processo de software e adequados aos

padrões definidos nos modelos e/ou normas de qualidade para processo de softwa-

re.”.

5.7.2. CESAR – Centro de Estudos e Sistemas Avançad os do Recife

O CESAR é um conhecido centro de estudos voltados à área de informática e

telecomunicações, surgido de um projeto da Universidade Federal de Pernambuco.

Hoje é uma fábrica de software voltada para projetos em parceria com grandes em-

presas nacionais e multinacionais, além de órgãos públicos.

Segundo um gerente de processos do CESAR: “O CESAR possui uma de su-

as áreas-chave a atuação como fábrica de software, o que a exige um processo bem

definido e controlado de acordo com as suas características organizacionais e domí-

nios de projetos de software.

Dessa forma, após a implantação de um processo tradicional em nossas á-

reas focadas em engenharia de software, sentimos a necessidade de abrir um linha

de negócio que provesse uma melhoria (aperfeiçoamento) contínuo deste processo,

a fim de sempre adequar as melhores-práticas das normas de qualidade de proces-

so de software implantadas em nosso linha de negócio.

Não chegamos a implantar as práticas dos processos ágeis formalmente em

nossos processos, no entanto tivemos em nossas áreas alguns projetos desenvolvi-

dos usando como uma tendência de alguns colaboradores os procedimentos de co-

dificação definidos nestes tipos de processos.”

55

5.7.3. VANguard

A VANguard é uma fábrica de software no ramo de componentes, que desen-

volve serviços de consultoria, implementação e treinamento na área de sistemas.

De acordo com o gerente de tecnologia da empresa: “Como uma das empre-

sas incubadas a partir da área de projetos de inovação mantida no CESAR – Centro

de Estudos e Sistemas Avançados do Recife, adotamos inicialmente o mesmo pro-

cesso implantado nesta fábrica de software.

Com a independência do nosso negócio, podemos instanciar o nosso proces-

so de engenharia de software de acordo com a nossa necessidade organizacional e

do projeto de software que provemos para a comunidade de nossos clientes.

Estamos, atualmente, adaptando o nosso processo que usa como base as ca-

racterísticas dos processos tradicionais, com os atributos e as especificações defini-

das aos processos ágeis.”

5.7.4. Elógica

O relato abaixo é do gerente de tecnologia da Elógica, uma fábrica de softwa-

re com foco no código. A empresa está sediada na cidade de Recife – PE.

“Nosso processo de desenvolvimento de software é instanciado constante-

mente pela Qualiti Software Processes de acordo com o domínio de projeto de soft-

ware no qual estamos atuando junto aos nossos clientes.

Inicialmente a Qualiti trouxe as habilidades providas em um processo tradicio-

nal, no entanto, detectamos em algumas de nossas reuniões e avaliações do pro-

cesso usado como base a necessidade de se usar a agilidade e os procedimentos

adotados como primordiais em um processo ágil. Hoje, usamos um processo que

56

agrega as características dos tipos de processos tratados na literatura especializa-

da.”

5.7.5. CI&T

A CI&T é uma grande empresa do interior de São Paulo, que tem como foco o

Outsourcing de serviços, sendo esses de consultoria, desenvolvimento e treinamen-

to. O relato abaixo é do consultor de qualidade da empresa.

“A CI&T possui hoje nível 3 do CMM, onde este foi atingido mediante uma a-

gregação das características dos processos tradicionais com as práticas-chave defi-

nidas em cada um dos níveis desta norma de qualidade para processo de software.

Detectamos que ao longo do uso do processo tradicional, a qualidade e a ge-

rência dos projetos sofreram uma alteração considerável em suas práticas. Isso se

deve ao fato de que o processo de engenharia de software adotado como linha de

negócio agrega práticas de melhoria contínua do processo e gerenciais dos projetos

de software alinhados ao PMBOK.

Não surgiu, ainda, a necessidade de adotarmos em nossos processos organi-

zacionais os atributos e procedimentos especificados nos processos ágeis.”

5.8. Mapeamento das Metodologias

Para ilustrar a utilização das Metodologias Ágeis e Tradicionais diante das

principais Fábricas de Softwares e Tipos de Sistemas, foi montada a tabela 5.3, que

faz uma referência cruzada entre as características centrais de cada metodologia e

as fábricas e tipos de sistemas.

57

Tabela 5.1 - Mapeamento de Fábricas de Software x T ipos de Projetos x Processos de Software

Processos Ágeis Tradicionais

Fábricas Itera-ções

Curtas

Peque-nas

Equi-pes

Orien-tado a Pesso-

as

Dinâ-mico

Garan-tia Alta de Qua-lidade

Gran-des

Equi-pes

Tarefas Cen-

tradas

Orientado a Planeja-

mento

Código X X X X Compo-nente

X X X X

Projeto X X X X

Outsour-cing

X X X X

Projetos (Sistemas)

Tempo-

Real X X X X X

Informa-ção

X X X X X X

Software Básico

X X X X X

Web X X X X X X

As principais fábricas de softwares escolhidas para fazer parte da tabela são

4 (quatro) [TEIXEIRA 04]: Código, onde o foco principal é gerar um produto de alta

qualidade, não se preocupando com especificações e excesso de documentos;

Componentes, desenvolvimento baseado em iterações, sendo que a cada iteração

será lançado um componente, que integrar-se-á com o restante do sistema; Projeto,

tem como objetivo gerar softwares com documentação e especificação feitas junto

às necessidades dos clientes; e Outsourcing, tipo de fábrica onde o desenvolvimento

tem seu núcleo dentro das dependências dos clientes, facilitando acesso a informa-

ções necessárias.

Para os tipos de sistemas, também chamados de tipos de projetos, temos os

projetos em Tempo-Real, onde a resposta precisa ser imediata e qualquer atraso

pode gerar prejuízos incalculáveis, exemplos são os sistemas de auto-atendimento

em bancos e sistemas de controle de tráfego aéreo. Do outro lado temos os Siste-

mas de Informação, que geralmente são sistemas de apoio à decisão, utilizados por

58

gerentes de empresas e tomadores de decisões. Os Softwares Básicos são aqueles

desenvolvidos para resolver um único tipo de problema, geralmente baseados em

tecnologia desktop sem foco em interação com o cliente. E por último os Sistemas

Web, desenvolvidos para internet que visão solucionar problemas de maneira remo-

ta, utilizando-se dos recursos oferecidos pela grande rede.

Fechando a referência cruzada, temos quatro principais características de ca-

da metodologia, sendo Iterações Curtas, Pequenas Equipes, Orientado a Pessoas, e

Dinâmico como características das metodologias ágeis e Garantia de Alta Qualida-

de, Grandes Equipes, Tarefas Centradas, e Orientado a Planejamento, como meto-

dologias tradicionais.

59

Capítulo 6

Conclusão

Este capítulo possui duas sub-seções, onde o primeiro mostra como este tra-

balho contribuiu para o estudo e a pesquisa, e o segundo cita possíveis trabalhos

futuros, que infelizmente não puderam ser abordados nesta monografia devido a

extensão de seu conteúdo e por estarem fora do escopo do trabalho.

6.1 Contribuições do Trabalho

Como qualquer projeto de desenvolvimento de aplicações, independente de

qual metodologia se utilize, o foco sempre será a qualidade final do produto e a sa-

tisfação do cliente.

Para chegar a tal ponto os processos foram desenvolvidos, porém nunca um

deles trará satisfação total somada com qualidade inquestionável, seja em qualquer

parte do projeto ou iteração de um processo. Invariavelmente, em algum ponto pe-

car-se-á, ou por causa do processo ou não.

O comparativo do trabalho ajudará uma melhor escolha quanto a qual meto-

dologia deva ser utilizada em determinados projetos, levando sempre em considera-

ção o foco da Fábrica de Software ou tipo de projeto que será desenvolvido. Tudo

isso com o objetivo de reduzir a possibilidade de erros que venham a comprometer a

qualidade do projeto e a satisfação do cliente.

Outro ponto do trabalho é analisar como tais metodologias estão se aplicando

no mercado, assim é possível saber como cada empresa possivelmente trabalha

com cada projeto e quais as tendências de mercado para o futuro, levando como

base uma análise do presente.

60

Finalmente, o trabalho serve como base para que outras pesquisas e estudos

possam ser realizados, tanto estudando cada metodologia separadamente ou am-

bas ao mesmo tempo, deixando um conjunto de futuros trabalhos listados na seção

a seguir.

6.2 Futuros Trabalhos

Esta seção apresenta uma coleção de possíveis trabalhos futuros, que com-

plementam a pesquisa realizada para desenvolver este trabalho.

6.2.1 Especificação de uma Metodologia Híbrida

Com esse trabalho e com a pesquisa entre as fábricas de softwares e consul-

toras, foi possível ver que características de ambas as metodologias são utilizadas.

Este trabalho visa propor uma metodologia híbrida entre as tradicionais e as ágeis

usando técnicas de ambas, para atingir maiores níveis de satisfação e qualidade,

diminuindo o tempo de desenvolvimento.

6.2.2 Definição de uma Fábrica de Software

Com base nas características dos processos de software analisados ao longo

deste trabalho, o foco deste tema retrata a implementação da estrutura de uma Fá-

brica de Software capaz de abordar as duas principais vertentes: qualidade e pro-

cessos de negócios. Atendendo, desta forma, uma realidade regional no que tange a

implantação de uma estrutura organizacional voltada ao desenvolvimento de produ-

tos e serviços de software com o fator agregado da qualidade.

61

Referências Bibliográficas

[BOEHM 81] BOEHM, B., Disponível em

http://sunset.usc.edu/research/COCOMOII, Visitado em

21/06/2004.

[OLIVEIRA 04] OLIVEIRA, S. R. B, ROCHA, T. A., VASCONCELOS, A. M.

L., “Adequação de Processos para Fábricas de Software”,

Anais do Simpósio Internacional de Melhoria de Processos

de Software – SIMPROS 2004, São Paulo, 2004.

[PRESSMAN 02] PRESSMAN, R. S., “Engenharia de Software”, 5ª Ed.,

Makron Books, 2002.

[SEBESTA 99] SEBESTA, R. W., “Concepts of Programming Languages”,

4th ed., Addison-Wesley, 1999.

[SOMMERVILLE 00] SOMMERVILLE, I., “Software Engineering”, 6th edition, Ad-

dison-Wesley, 2000.

[TEIXEIRA 04] FERNANDES, A. A., TEIXEIRA, D. S., “Fábrica de Software:

Implantação e gestão de Operações”, Atlas, São Paulo,

2004.

[VERGILIO 04] VERGILIO, S. R., “Software e Engenharia de Software”.

http://www.inf.ufpr.br/~silvia/ES/SweES, Visitado em

03/08/2004;

[WELLS 04] WELLS, D., Disponível em

http://www.extremeprogramming.org, Visitado em

20/09/2004;

[XISPE 04] XISPE, X., Disponível em http://www.xispe.com.br, Visitado

em 15/05/2004.

[BECK 99] BECK, K., “Extreme Programming Explained: Embrace

Change”, 1st Edition, Addison-Wesley, 1999.

[SMITH 01] SMITH, J., “A Comparison of RUP and XP”, Rational Softwa-

re White Paper, 2001.

[KRUCHTEN 00] KRUCHTEN, P., “The Rational Unified Process, An Introduc-

tion”, 2nd Edition, Addison-Wesley, 2000.

62

[FOWLER 01] FOWLER, M., BECK, K., Disponível em

http://www.agilemanifesto.org

[POLLICE 03] POLLICE, G., “Using the RUP for small projects: Expanding

upon Extreme Programming”. Disponível em http://www-

128.ibm.com/developerworks/rational/library/409.html