Escolar Documentos
Profissional Documentos
Cultura Documentos
Belém/PA
2004
Universidade da Amazônia
Centro de Ciências Exatas e Tecnologia
Curso de Bacharelado em Ciência da Computação
Belém/PA
2004
__________________________________
__________________________________
Professor 1 (Avaliador)
__________________________________
Professor 2 (Avaliador)
Belém-PA, de de 2004
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.
iv
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,
v
“The whole is bigger than the parts.”
Kent Beck
vi
Resumo
evoluindo e se estruturando para que erros que caracterizaram esta crise, como a
vii
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
For that, modeling languages, like UML, were created. Besides that, software
improving system quality, doesn’t matter which focuses the system should take, there
The proposal of this work is a comparative analysis of the two sides of these
and a large amount of documents are written before and after software
implementation; and agile methodologies, where source code is the most important
viii
Sumário
x
Lista das Figuras
xi
Lista de Tabelas
xii
Capítulo 1
Introdução
mo. Deixando claro, ainda, sua finalidade, justificando o porquê desse comparativo
Desde a Crise do Software, que forçou com que as Software Houses realizas-
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-
que seria desenvolvido e como isso seria feito. Foi então que surgiram Métodos para
1
visualizar o processo de desenvolvimento, dividindo-o em etapas, sempre com foco
funcionais) por parte do cliente é normal, assim como a não conformidade de algu-
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
1
Principal expoente do Desenvolvimento Ágil, citado no capítulo 4 deste trabalho.
2
daptável a mudanças nos requisitos, entretanto fraco na parte contratual e de docu-
mentos.
comercialmente.
a fim de concluir onde e por que uma é superior a outra conforme diferentes visões.
Assim como a Internet para obter conhecimento sobre o que havia de novo sendo
Como técnica de pesquisa, foi adotada, a pesquisa analítica, visto que basea-
3
dos os pontos referenciais que as diferem e o que as assemelham, baseados em
Além deste capítulo 1 introdutório, que trata dos objetivos do trabalho e quais
cionais quanto ágeis, mostrando que todas partem de um mesmo princípio. Assim
como pesadas, mostrando suas características e processos. Como parte final deste
capítulo, é apresentado o Rational Unified Process – RUP, que será utilizado como
4
O capítulo 5, intitulado “Análise Comparativa Entre as Metodologias Tradicio-
e citando futuros trabalhos que podem ser desenvolvidos a partir deste estudo.
5
Capítulo 2
Desenvolvimento de Software: Visão Geral
final de má qualidade, pois não existia documentação ou era entregue fora do prazo
ç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-
rísticas dos projetos: o tempo que pode ser gasto e a real necessidade do cliente, a
Entretanto, a Crise do Software perdura até hoje, onde, mesmo com técnicas
6
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-
neira econômica, que seja confiável para trabalhar eficientemente em máquinas re-
tem um compromisso com qualidade, sendo que esse enfoque na qualidade se de-
pal a qualidade final do produto gerado, e como maneira de chegar até ela é o aper-
7
Para auxiliar nesse processo existem Métodos de Engenharia de Software
É uma das fases principais do projeto, pois é onde se procura identificar fun-
É 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
software.
dos métodos utilizados nesta fase, que podem variar de acordo com o paradigma
8
mo de exatidão, custos, tempo, esforço e recursos que são necessários para con-
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-
fato.
todologias, devem ser realizadas, como o Projeto de Software, parte central do de-
de software.
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-
É a fase final, pois nela se analisa todo o produto. Tem como foco principal as
9
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
fase de desenvolvimento;
produto para que o impacto causado por essas alterações não afete o
para melhorá-lo.
10
Dependendo do tipo de projeto a ser desenvolvido modelos diferentes serão
utilizados, porém todos seguem um determinado ciclo, onde existem quatro fases
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.
ente.
do que dentro de cada uma dessas fases desse ciclo, existe um outro ciclo mais in-
É 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-
Mesmo com todos estes problemas, este modelo ainda é bem melhor e mais
que o software interage com o sistema, é importante saber como o mesmo funciona
que os dados vão ser tratados, Arquitetura de Software, que define a base estrutural
sentam o meio entre o usuário e o sistema, bem como entre os módulos do sistema,
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
de desenvolvimento.
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.
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
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-
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,
veis para o cliente de uma maneira veloz, e ao final de cada ciclo, onde novas fun-
Por se tratar de protótipos, nem sempre a solução escolhida para resolver tal
protótipo que foi gerado como parte integral do sistema, deixando “brechas” e possí-
curtos, usualmente com prazo máximo de 90 dias, do modelo sequencial linear. Sua
ra efetiva;
namento (MER);
O RAD, assim como outros modelos, possui desvantagens. Visto que a prin-
estar bem definidos e com um certo grau de independência entre eles. Se uma das
Para que o RAD possa ser utilizado de maneira eficiente, é necessário que
14
2.4 Modelos de Processos Evolucionários
ficações e, como uma “bola de neve”, crescem até que estouram o prazo definido na
dade, com isso é possível desenvolver versões do sistema que a cada novo lança-
assume que o software desenvolvido pode sempre crescer e agregar novas funcio-
nalidades, sendo que cada uma dessas funcionalidades, ou o conjunto delas, será
“bola de neve” que cresce e atinge sua totalidade quando o produto está completa-
crescer com o passar do tempo e o prazo de entrega é curto. Como, ao final de cada
15
incremento, é gerada uma versão do produto final, é possível mostrar ao cliente co-
sistemático como o Modelo Linear. Isso facilita com que sejam lançadas versões
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-
do [PRESSMAN 02].
16
Este modelo é o considerado mais realístico possível, pois assume que usuá-
17
Capítulo 3
Metodologias de Desenvolvimento Tradicionais
ou “Pesadas”
sam por fases ou passos, que são subdivisões do processo para ordená-lo e melhor
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.
do do final de que etapa foram criados, podem ser documentos, como Diagramas de
projeto, como os requisitos, será necessário uma volta ao início do mesmo para alte-
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.
18
planejados, facilitando a gerência do mesmo, mantendo sempre uma linha, caracte-
empresa desenvolvedora.
19
• Gerenciamento de Riscos: a cada iteração é possível analisar pontos
senvolvimento;
mesmo ciclo.
conter várias iterações, que são ciclos onde cada etapa acontece. As 4 (quatro) fa-
tema. O Software é passado aos usuários para que estes possam fazer
suas considerações.
20
Outro conceito encontrado do RUP são as disciplinas, também chamada de
ria de software de acordo com sua natureza. Elas descrevem o que deve ser feito
dades;
tação do software;
21
• Gerência de Projeto: Engloba o gerenciamento de riscos, planejamen-
to e o acompanhamento do projeto;
quipe de desenvolvimento.
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-
22
cumento é responsável por verificar se todos os objetivos da determinada fase foram
alcançados.
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
uma evolução do sistema, passando por todas as fases novamente, gerando novos
Esses artefatos são agrupados em disciplinas (workflows), já que cada uma produz
definem como estes devem trabalhar. Esses papéis irão definir as principais ativida-
23
des e responsabilidades do indivíduo, ou grupo de indivíduos, mostrando como es-
As Atividades são as ações realizadas por um ator que geram algum resulta-
delagem, pois estes devem ser alterados a cada mudança na especificação de re-
quisitos.
3 (três) categorias:
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
24
cesso, é considerado em série. Novas versões e releases (artefatos) podem ser de-
25
Capítulo 4
Metodologias de Desenvolvimento Ágeis ou
Leves
mais rapidamente.
manifesto, que ficou conhecido como Manifesto for Agile Software Development
seguir explicam sucintamente suas definições [BECK 99], [WELLS 04] e [XISPE 04].
tes dependem diretamente do processo. Um mau processo pode fazer com que os
so que todo o grupo possa interagir perfeitamente entre si. Comunicação é mais im-
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-
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.
27
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
lado, utilizando-se do código, sendo que este não permite duplas interpretações da
do quando necessário.
à 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
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
28
aquele que determinará como será a comunicação e o relacionamento do cliente
projetos, é possível afirmar, que melhor será o projeto que mais se adaptar a estas
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-
po e continuamente.
versão, mesmo que com poucas funcionalidades, do sistema, melhor seria a quali-
29
dade final, pois o sistema começaria a evoluir mais cedo. Sendo que essas versões
nais em algumas semanas do início do projeto, sendo que novos pacotes de funcio-
completo ou vai apenas testa-lo para definir novas funcionalidades ou encontrar não-
pois assumem que as mudanças são indicadores de que o time está aprendendo
tempo. Documentações e papéis não contam como entregas, pois não satisfazem à
30
Um processo ágil precisa ser guiado constantemente, portanto é necessária a
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
que existe.
31
essa velocidade não ser mantida, pois isso irá iludir o cliente, causando a ele uma
lidade.
mento é necessário deixar o software o mais limpo e o mais robusto possível. Isso
j) Simplicidade é essencial.
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
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.
32
Responsabilidades são compartilhadas pro todos os membros da equipe,
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.
Ward Cunningham juntaram-se para desenvolver uma nova abordagem aos proje-
gando a experiência adquirida com esse projeto utilizando essa nova Metodologia.
33
do espaço que antes pertencia a metodologias tradicionais, como RUP – Rational
do cliente até assumir que as mudanças nos requisitos sempre vão ocorrer, levando
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 têm o mesmo propósito das Use Cases da UML – Unified Mode-
sentenças, escritas pelo cliente para definir o que o sistema deve fazer para ele.
para a definição de alguns fatores para a continuidade do projeto. Esses fatores são,
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-
Essas reuniões são regradas por 4 (quatro) variáveis, que são: Escopo, o
po, quando o software ou release vai ser entregue; e a Qualidade, o quão bom é o
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
foi feito no projeto, a unidade de medida é a quantidade de User Stories que foram
Pode ser mensurada por escopo, que vai basear quanto tempo durará a pró-
çã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-
35
• O Projeto é dividido em iterações.
ções têm a mesma duração, ficam no intervalo de uma a três semanas, permitindo
programado para a atual iteração, não sendo permitido desenvolver algo que esteja
tes, sendo esta importância definida pelo cliente, durante uma prévia reunião.
projeto pára. Isso é ruim, pois diminui o passo e provavelmente impede que o relea-
36
Para evitar problemas como esse, é interessante que todos os membros da
“Ilhas de Conhecimento”. O Pair Programming, que será visto mais a frente, também
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
prática se torna mais comum quando a comunicação entre a equipe começa a ser
melhor explorada.
gras e práticas, que o processo não ande como o esperado. Quando isso acontece,
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
37
alteração o tempo gasto durante o desenvolvimento não seja grande, assim como o
tenção.
c) Codificação
todo o decorrer do projeto, é muito importante que haja uma interação entre a equipe
As User Stories são escritas pelo cliente e como elas delineiam as trilha do
senvolvimento com o cliente nesta fase, pois é com base no que foi escrito que será
decidido quais Stories farão parte da próxima iteração, de acordo com os objetivos
do cliente.
com aquilo que foi descrito na Story. Esse feedback deve ser o mais rápido possível,
38
enquanto o desenvolvimento se encontra ainda na etapa em que a não conformida-
• Pair Programming
“Todo o código destinado ao projeto deve ser desenvolvido por duas pessoas
• Integrar constantemente.
vel. Essa prática evita desperdício de esforço, pois se sabe ao certo o que já está
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.
39
As unidades de testes são fundamentais para o projeto. Usualmente são de-
les que não forem testados não podem ser integrados ao que já foi desenvolvido.
testes que foi desenvolvida, essa também deve ser modificada a fim de englobar
essas alterações.
do.
Esses testes, antes conhecidos como Testes Funcionais, são criados das U-
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
consertar aquelas funcionalidades que ainda não estão de acordo com as necessi-
dades do cliente.
40
Capítulo 5
Análise Comparativa entre Metodologias Tradi-
cionais e Ágeis
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
as são:
• Tempo e Esforço: discute como cada um dos dois processos lida com
quipes de XP.
41
5.1 Alocação de Tempo e Esforç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-
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-
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
01].
XP são usualmente programados de 2 (dois) em 2 (dois) meses, visto que são de-
esforço e tempo, considera-se que um time com 10 (dez) programadores é ideal pa-
tempo que isso, certamente devem ter uma equipe de desenvolvimento maior.
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
42
que a equipe desenvolverá de maneira serial, enquanto se fosse maior desenvolve-
ria paralelamente.
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
Para projetos dentro dos limites considerados padrões pela XP é visível que
çã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
43
XP, porém como é necessário que o projeto seja tratado como um todo, o escopo
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-
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.
• Levantamento de requisitos;
• Planejamento;
• Restrições no projeto.
não pode deixar este ponto de arquitetura e infra-estrutura sem planejamento, pois
44
refazer código pode levar mais tempo que o previsto, considerando o grau de com-
plexidade do projeto.
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.
tempo gasto com o planejamento seja reduzido, pois situações de menos risco ou
ser menos analisadas e projetadas. Isso faz com que o ciclo de vida do RUP se a-
funcionalidade ao cliente.
uma fase de exploração antes do início das iterações, o que caracteriza essa fase
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
impedindo que no futuro seja necessária alguma alteração que impacte em re-
A XP assume que não ocorrerão erros e que o que foi desenvolvido e devi-
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-
5.2 Artefatos
100 (cem) documentos diferentes, sendo esse número um muito alto considerando a
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-
46
A idéia de especificar com tantos documentos o projeto é deixar o processo
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,
a XP tem seu foco nos projetos pequenos, que acabam não necessitando de muita
ç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
47
vés das User Stories, no RUP isso é feito através de entrevistas e questionários, que
com que documentos sejam escritos. Uma abordagem sistemática, para esses ca-
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.
são focados para esse momento. O RUP tem aproximadamente 15 (quinze) artefa-
projetos, esses 15 (quinze) artefatos podem ser reduzidos para 6 (seis) [SMITH 01].
grandes, e esse pequenos projetos é que são principal foco da programação extre-
mentos reduz para 30 (trinta), uma quantidade pequena, comparada com o que deve
48
documentos aquilo que a XP não trata, pelo menos abertamente e documentalmen-
te.
RUP orientado para pequenos projetos gera apenas um único documento que é o
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
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
de um projeto, tem apenas 4 (quatro) atividades básicas, onde cada atividade dessa
49
conceitos para essas atividades abordados nas referências sobre XP fazem com
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-
penas com 4 (quatro) atividades básicas que são seguidas através de algumas prá-
pair programming é o momento que ela seria aplicada, que seria apenas quando
50
alguém da equipe fosse novo numa tecnologia, ou mesmo na empresa, fazendo com
dos primeiro que o sistema em si e a prática do suporte on-site no cliente, que en-
03].
5.5 Papéis
bilidade de elaborar e alterar alguns determinados artefatos, que são gerados pelas
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-
que existem são mais abrangentes, englobando vários papéis dentro do RUP, como,
51
Além dos papéis da programação extrema serem mais abrangentes do que os
Enquanto o RUP serve de processo tanto para pequenos, médios e grandes proje-
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-
tes e fracos, sendo que alguns pontos antes exclusivos das metodologias ágeis pas-
válido, fazendo com que haja uma espécie de metodologia híbrida entre elas.
tem seu foco nos pequenos projetos, onde o excesso de documentos e burocracia
de algumas das principais Fábricas de Software do país que fazem uso nos seus
52
NANDES 04] e os domínios dos diferentes projetos de software [SOMMERVILLE
00], é feita.
ria de software, sendo que cada fábrica listada se encaixa em um dos padrões, que
empresa.
“A Qualiti é uma empresa que possui como um dos focos de sua atuação a
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-
do projeto de software.
dimentos que provessem uma agilidade maior nas suas execução. Assim, passamos
53
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-
padrões definidos nos modelos e/ou normas de qualidade para processo de softwa-
re.”.
Hoje é uma fábrica de software voltada para projetos em parceria com grandes em-
54
5.7.3. VANguard
Estamos, atualmente, adaptando o nosso processo que usa como base as ca-
5.7.4. Elógica
mente pela Qualiti Software Processes de acordo com o domínio de projeto de soft-
55
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
“A CI&T possui hoje nível 3 do CMM, onde este foi atingido mediante uma a-
nidas em cada um dos níveis desta norma de qualidade para processo de software.
rência dos projetos sofreram uma alteração considerável em suas práticas. Isso se
principais Fábricas de Softwares e Tipos de Sistemas, foi montada a tabela 5.3, que
56
Tabela 5.1 - Mapeamento de Fábricas de Software x Tipos de Projetos x Processos de Software
4 (quatro) [TEIXEIRA 04]: Código, onde o foco principal é gerar um produto de alta
tem como objetivo gerar softwares com documentação e especificação feitas junto
tem seu núcleo dentro das dependências dos clientes, facilitando acesso a informa-
ções necessárias.
mas de Informação, que geralmente são sistemas de apoio à decisão, utilizados por
57
gerentes de empresas e tomadores de decisões. Os Softwares Básicos são aqueles
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-
dologias tradicionais.
58
Capítulo 6
Conclusão
Este capítulo possui duas sub-seções, onde o primeiro mostra como este tra-
futuros, que infelizmente não puderam ser abordados nesta monografia devido a
qual metodologia se utilize, o foco sempre será a qualidade final do produto e a sa-
tisfação do cliente.
deles trará satisfação total somada com qualidade inquestionável, seja em qualquer
ção o foco da Fábrica de Software ou tipo de projeto que será desenvolvido. Tudo
com cada projeto e quais as tendências de mercado para o futuro, levando como
a seguir.
Esta seção apresenta uma coleção de possíveis trabalhos futuros, que com-
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
deste trabalho, o foco deste tema retrata a implementação da estrutura de uma Fá-
cessos de negócios. Atendendo, desta forma, uma realidade regional no que tange a
60
Referências Bibliográficas
61
[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
62