Você está na página 1de 45

FACULDADE VITORIANA DE TECNOLOGIA FVT

Carlos Huhn de Paiva Siueira


Feli!e "uhn
CO#PARATIVO ENTRE #ETODOLOGIAS DE
DESENVOLVI#ENTO TRADICIONAL E $GIL
CASO DE USO %AUTO&ESCOLA'
Vi(oria & ES
)*+,
Carlos Huhn de Paiva Siueira
Feli!e "uhn
CO#PARATIVO ENTRE #ETODOLOGIAS DE
DESENVOLVI#ENTO TRADICIONAL E $GIL
CASO DE USO %AUTO&ESCOLA'
Trabalho de Concluso de Curso apresentado ao
Curso de Sistemas de nformao da Faculdade
Vitoriana de Tecnologia, orientado pela Prof.
Pedro David Netto Silveira, como requisito parcial
para obteno do ttulo de bacharel em Sistemas
de nformao.
Vi(oria & ES
)*+,
Carlos Huhn de Paiva Siqueira
Felipe Kuhn
CO#PARATIVO ENTRE #ETODOLOGIAS DE
DESENVOLVI#ENTO TRADICIONAL E $GIL
CASO DE USO %AUTO&ESCOLA'
Vitoria, 17 de setembro de 2013
____________________________________________
Pedro David Netto Silveira
____________________________________________
Professor 2
____________________________________________
Professor 3
4
Resu-o
A necessidade de se desenvolver um software de qualidade que atenda as
funcionalidades esperadas, alm de ser o objetivo de muitas empresas, tambm o
que o mercado est exigindo cada vez mais. A anlise detalhada de um problema
o primeiro passo para a escolha adequada de qual metodologia de desenvolvimento
devemos usar, pois ela est ligada diretamente com o sucesso do produto,
proporcionando um servio de qualidade sem perder o prazo e o oramento
estipulado. As Metodologias Tradicionais, assim como as Metodologias geis,
possuem caractersticas importantes que as diferenciam, devendo ser levado em
considerao seus pontos positivos e negativos para uma melhor tomada de deciso
durante todo o projeto. O envolvimento das partes interessadas em todo o processo
de desenvolvimento e a juno dessas metodologias primordial para se conseguir
alcanar esses objetivos de forma mais precisa, satisfazendo os clientes e
consequentemente ganhando espao nesse mercado to concorrido que o
mercado de software.
Palavras&.have/ Anlise do projeto. Metodologias de Desenvolvimento. Metodologia
Tradicional. Metodologia gil. XP. RUP.
5
A0s(ra.(
The need to develop quality software that meets the expected features,
besides being the mission of many companies, is also what the market is increasingly
demanding. The detailed analysis of a problem is the first step in the choice of
appropriate development methodology which we would use because it is linked
directly with the product's success, providing a quality service without losing the time
and budget. The traditional methodology, as well as the Agile methodology, possess
important features that set them apart, we must considerate their strengths and
weaknesses for better decision making throughout the project. The involvement of
stakeholders throughout the development process and the junction of these
methodologies is essential to achieve our goals more precisely, satisfying our
customers and gaining ground in this so competitive software market.
"e12ords/ Analysis of the project. Development Methodologies. Traditional
Methodology. Agile Methodology. XP. RUP.
6
SU#$RIO
1. NTRODUO..........................................................................................................8
1.1 Premissa para a pesquisa...................................................................................9
1.2 Metodologia adotada...........................................................................................9
1.3 OBJETVO...........................................................................................................9
2. REFERENCAL TERCO......................................................................................10
2.1 Modelos de Ciclo de Vida de Software..............................................................11
2.1.1 Modelo Cascata ou Clssico.......................................................................11
2.1.2 Modelo Espiral.............................................................................................15
2.1.3 terativo e ncremental.................................................................................17
2.1.4 Paradigma Evolutivo...................................................................................18
2.2 Metodologia Tradicional.....................................................................................20
2.2.1 Histria do Rational Unified Process (RUP)................................................21
2.2.2 Estrutura Bsica..........................................................................................22
3. MANFESTO GL.................................................................................................26
3.1 Valores...............................................................................................................26
3.1.1 ndivduos e interaes mais que processos e ferramentas.......................26
3.1.2 Software em funcionamento mais que documentao abrangente............26
3.1.3 Colaborao com o cliente mais que negociao de contratos..................27
3.1.4 Responder a mudanas mais que seguir um plano....................................27
3.2 Extreme Programming (XP)...............................................................................27
3.2.1 Valores.........................................................................................................28
3.2.1 Prticas do XP............................................................................................30
4. ESTUDO DE CASO: CFC FAV..............................................................................32
4.1 Modularizao, comparativo e especificao de Requisitos.............................34
4.2 Comparativo.......................................................................................................34
4.2 Questes a serem observadas pelos Gerentes de Projetos.............................37
4.2.1 Contratos de escopo fechado ou varivel...................................................38
4.2.2 Nmero de artefatos requeridos pelo cliente..............................................38
4.2.3 Tipo de escritrio disponibilizado para o projeto.........................................38
4.2.4 Clareza na definio dos requisitos............................................................39
7
4.2.5 Ambiente de Negcio se encontra estvel..................................................39
5. CONCLUSO..........................................................................................................40
6. REFERNCAS.......................................................................................................42
8
+3 INTRODU45O
Com os avanos do mercado e das tecnologias que os apoiam, grande parte
das pessoas se questionam que metodologia adotar no desenvolvimento de
software com o objetivo de reduzir o risco de falhas no processo de desenvolvimento
de software. Segundo Kruchten (2003, p.3), "software o combustvel dos negcios
modernos, com o qual se conectam melhor controles governamentais e sociedades,
e com a preocupao na qualidade de seu desenvolvimento que algumas
metodologias foram sendo adaptadas e evoludas.
Para Pressman (1995, p. 33), as metodologias tradicionais so os paradigmas
mais antigos e os mais amplamente usados na engenharia de software, porm, no
decorrer da ltima dcada, as crticas sobre ela fizeram com que at mesmo seus
ativos defensores questionassem sua aplicabilidade em todas as situaes. Apesar
de suas limitaes, o paradigma do ciclo de vida clssico ainda um modelo de
processo bastante utilizado, especialmente quando os requisitos esto bem claros
no incio do desenvolvimento. (CARVALHO; CHOSS, 2001, p. 34).
"Os processos geis utilizam o desenvolvimento iterativo para permitir que o
cliente aprenda ao longo do projeto e, com isso, possa gerar feedback para a equipe
de desenvolvimento (...), ela se baseia na premissa de que o cliente aprende ao
longo do desenvolvimento (...), onde se caracteriza por aprendizado permanente que
leva a melhorias e torna o produto final adequado para o seu prprio pblico
(TELES, 2004, p. 41 a 42).
O propsito desse trabalho destacar algumas caractersticas que diferem as
metodologias em Tradicionais ou geis, proporcionando um conhecimento
minucioso, facilitando nas tomadas de decises no desenvolvimento de software.
Para isso, utilizaremos um estudo de caso que ser analisado em mdulos e
destacaremos qual metodologia ser mais vivel para cada situao.
9
+3+ PRE#ISSA PARA A PES6UISA
Para aprofundamento dos estudos realizados durante a graduao e
esclarecimentos sobre como fazer a escolha de uma Metodologia de
Desenvolvimento para um projeto, foi elaborado um comparativo que tornasse mais
claro os motivos que um gerente de projeto poderia utilizar para respaldar sua
deciso quanto a Metodologia de Desenvolvimento escolhida para seu projeto.
+3) #ETODOLOGIA ADOTADA
Tambm foi utilizado o estudo de um caso fictcio subdividido em mdulos e
posteriormente ser selecionado um nico mdulo para extrair os possveis artefatos
gerados nas metodologias e realizar os comparativos pertinentes.
+3, O78ETIVO
Este trabalho tem por objetivo a comparao dos paradigmas de
desenvolvimento de softwares Tradicional e gil, face as dvidas frequentes
referentes a escolha da metodologia para o desenvolvimento de projetos de
sistemas de informao.
Para a realizao do trabalho foi feita uma pesquisa sobre ambos os
paradigmas e um aprofundamento das melhores tecnologias oriundas dos mesmos.
Ao final, ser apresentada uma tabela comparativa contendo os artefatos gerados
em cada metodologia e posteriormente comentados, de acordo com as
caractersticas do mdulo escolhido.
O estudo se dar primeiramente conceituando cada um dos paradigmas em
suas definies gerais, seguidos com as metodologias e ferramentas escolhidas
para representarem os artefatos produzidos em cada etapa proposta, em cada
metodologia em estudo.
10
)3 REFERENCIAL TE9RICO
Com as transformaes ocorridas no meio empresarial, a necessidade de se
administrar grandes volumes de dados nas organizaes foram primordiais para
dinamizar seus processos. Ucha (2008) afirma que a criao dos computadores
comerciais aps a Segunda Guerra Mundial favoreceu o aumento significativo na
dinamizao da indstria de computadores, assim como no processo de construo
de softwares, automatizando processos do cotidiano das organizaes.
A inteligncia e as funes oferecidas pelo software muitas vezes diferenciam
dois produtos de consumo em indstrias idnticas (PRESSMAN, 1995, p.3).
Segundo Parreiras e Oliveira (2004, p.1), o processo de desenvolvimento de
software est intimamente ligado gesto do conhecimento nas organizaes, uma
vez que por meio deste pode-se mapear, organizar, tratar e disseminar
adequadamente o conhecimento no ambiente empresarial.
Visando uma construo de software adequada, as metodologias de
desenvolvimento buscam atender as necessidades e os requisitos estabelecidos
pelo cliente e a escolha adequada que ir determinar, em parte, o sucesso do
projeto.
Para Teles (2004, p.32), as metodologias tradicionais so eminentemente
sequenciais, onde em alguns casos, a equipe deve construir o sistema
gradualmente, possibilitando lidar com nveis de complexidade cada vez mais
elevados.
No desenvolvimento gil, por sua vez, Teles (2004, p.41) afirma que o
aprendizado vem do feedback que fornecido durante o desenvolvimento, que
possibilita melhorias e torna o produto final adequado para o seu pblico.
11
)3+ #ODELOS DE CICLO DE VIDA DE SOFT:ARE
Descrevem como um software deve ser desenvolvido. Basicamente definem a
ordem global das atividades envolvidas em um contexto de projeto de software e
prope uma estratgia de desenvolvimento que pode ser aplicada a um determinado
contexto de projeto de software. Divide projetos em fases de forma a garantir um
melhor controle e encadeamento com as operaes estabelecidas.
*
+ )3+3+ #odelo Cas.a(a ou Cl;ssi.o
Segundo Pressman (1995, p.34), este o modelo de desenvolvimento de
software mais antigo e o mais amplamente usado da engenharia de software.
Alguns autores descrevem o modelo cascata das seguintes formas:
um paradigma que utiliza um mtodo sistemtico e sequencial, em que o
resultado de uma fase se constitui na entrada de outra [...]. Cada fase
estruturada como um conjunto de atividades que podem ser executadas por
pessoas diferentes, simultaneamente [...].Existem inmeras variaes desse
paradigma, dependendo da natureza das atividades e do fluxo de controle
entre elas. Os estgios principais do paradigma esto relacionados s
atividades fundamentais de desenvolvimento (CARVALHO; CHOSS, 2001,
p. 29).
Os processos obedecem a uma sequncia obrigatria de
desenvolvimento de software com demarcaes predefinidas de avaliao.
Se esse processo no permitir a flexibilidade do retorno nas sequncias, ele
torna o desenvolvimento do software altamente engessado e com
consequncias danosas para seu usurio final. (REZENDE, 2005, p.131).
Carvalho e Chiossi (2001, p. 34) relatam que a meta do modelo em cascata
continua sendo tentar a linearidade, para manter o processo previsvel e fcil de
monitorar. Os planos so baseados nessa linearidade e qualquer desvio
desencorajado, pois, vai representar um desvio do plano original e, portanto,
requerer um replanejamento.
12
Ainda segundo Carvalho e Chiossi (2001, p.29), o ciclo de vida clssico
composto por cinco passos, conforme mostra a Figura 1: A anlise e especificao
de requisitos; o projeto; a implementao e o teste unitrio; a integrao e teste do
sistema; e a operao e manuteno.
Fi<ura + Os cinco passos do ciclo de vida clssico.
Fonte: Carvalho e Chiossi, p. 29.
As fases de desenvolvimento do modelo Cascata:
- Anlise e Especificao de Requisitos:
Os principais pontos abordados durante essa fase, suas caractersticas e
suas limitaes so descritas da seguinte forma:
Durante essa fase do desenvolvimento, so identificados, atravs de
consultas aos usurios do sistema, os servios e as metas a serem
atingidas, assim como as restries a serem respeitadas. portanto,
identificada a qualidade desejada para o sistema a ser desenvolvido, em
termos de funcionalidade, desempenho, facilidade de uso, portabilidade, e
etc. O desenvolvedor deve especificar quais os requisitos que o produto de
software dever possuir, sem especificar como esses requisitos sero
obtidos atravs do projeto e da implementao (CARVALHO; CHOSS,
2001, p.30).
13
Os produtos gerados durante essa fase, segundo Carvalho e Chiossi (2001,
p.30), so: um documento de especificao de requisitos, que deve ser analisado e
confirmado pelo usurio para verificar se ele satisfaz todas as expectativas, esse
documento deve ser usado pelos desenvolvedores de software para obter um
produto que satisfaa os requisitos. Outro produto gerado nessa fase o plano de
projeto, baseado nos requisitos do produto a ser desenvolvido.
- Projeto
%O projeto de software envolve a representao das funes do sistema em
uma forma que possa ser transformada em um ou mais programas executveis
(CARVALHO; CHOSS, 2001, p.31).
O resultado nessa fase, conforme Carvalho e Chiossi (2001, p. 31), um
documento de especificao do projeto, que contm a descrio da arquitetura do
software, isto , o que cada parte deve fazer e a relao entre as partes.
- mplementao e teste unitrio
Essa fase consiste na codificao e testes individuais das unidades de
software conforme Carvalho e Chiossi descreve:
Essa a fase em que o projeto de software transformado em um
programa, ou unidades de programa, em uma determinada linguagem de
programao [...]. O teste unitrio tem por objetivo verificar se cada unidade
satisfaz suas especificaes [...]. O resultado dessa fase uma coleo de
programas implementados e testados (2001, p.31).
- ntegrao e teste do sistema
Os programas ou unidades de programa so integrados e testados como um
sistema completo para garantir que todos os seus requisitos sejam satisfeitos. A
integrao consiste na juno das unidades que foram desenvolvidas e testadas
separadamente. Essa fase nem sempre considerada separadamente da
implementao; desenvolvimentos incrementais podem integrar e testar os
componentes medida que eles forem sendo desenvolvidos (CARVALHO;
CHOSS, 2001, p.32).
- Operao e manuteno
14
Nessa fase o sistema instalado e colocado em operao. Segundo Carvalho
e Chiossi, esta a fase mais longa do ciclo de vida, onde a entrega do software
normalmente feita em dois estgios. No primeiro estgio, a aplicao distribuda
entre um grupo selecionado de usurios para executar uma experincia controlada,
obter feedback dos usurios e fazer as alteraes.
A manuteno envolve a correo dos erros e a evoluo do sistema para
atender aos novos requisitos e necessidades dos usurios, conforme Pressman
(1995, p.34) explica:
ndubitavelmente, o software sofrer mudanas depois que for entregue ao
cliente [...], ocorrero mudanas porque erros foram encontrados, porque o
software deve ser adaptado a fim de acomodar mudanas em seu ambiente
externo [...] ou porque o cliente exige acrscimos funcionais ou de
desempenho. A manuteno de software reaplica cada uma das etapas
precedentes do ciclo de vida a um programa existente, e no a um novo.
"Existem vrios problemas com o paradigma clssico, sendo um deles a
rigidez (CARVALHO; CHOSS, 2001, p. 34), ou seja, este modelo no contempla a
sobreposio das fases.
Para Kruchten (2003, p. 5) o problema bsico desta abordagem que adia o
risco de forma que torna caro desfazer erros de fases anteriores. A Abordagem em
cascata tende a mascarar os riscos reais para um projeto at que seja tarde para
fazer qualquer coisa significante neles.
[...] nesse paradigma todo o planejamento orientado para a entrega do
produto de software em uma data nica; toda a anlise executada antes
do projeto e da implementao e a entrega pode ocorrer muito tempo
depois. Quando se cometem erros de anlise e quando isso no
identificado durante as revises, o produto pode ser entregue ao usurio
com erros, depois de muito tempo e esforos terem sido gastos. Alm disso,
como o processo de desenvolvimento de sistemas complexos pode ser
longo, demandando talvez anos, a aplicao pode ser entregue quando as
necessidades do usurio j tiverem sido alteradas, o que vai requerer
mudanas imediatas na aplicao (CARVALHO; CHOSS, 2001, p. 34).
15
)
, )3+3) #odelo Es!iral
Com base em Carvalho e Chiossi (2001, p. 37) este paradigma se conceitua
da seguinte forma:
Tambm conhecido como paradigma Boehm [...], foi desenvolvido para
englobar as melhores caractersticas do ciclo de vida clssico e do
paradigma evolutivo, ao mesmo tempo em que adiciona um novo elemento
a anlise de risco que no existe nos dois paradigmas anteriores.
Weber (2002), citado por Souza (2004, p.59) o modelo espiral um modelo
orientado a riscos que reparte o projeto em miniprojetos e em cada miniprojeto
resolve um ou mais riscos maiores at que os riscos maiores sejam resolvidos.
"O paradigma espiral prev a eliminao de problemas de alto risco atravs
de um planejamento e projetos cuidadosos, em vez de tratar tanto problemas triviais
como no triviais da mesma forma (CARVALHO; CHOSS, 2001, p. 37).
Esse processo permite uma srie de iteraes entre as fases do
desenvolvimento. Cada iterao implica numa volta no modelo espiral, dessa forma
a equipe desenvolvedora pode obter produtos ou resultados em prazos mais curtos
(Rezende, 2005, p. 131).
Para Carvalho e Chiossi (2001, p. 37), no existem fases fixas nesse
paradigma e durante o planejamento que se decide como estruturar o processo de
desenvolvimento de software em fases.
Na Figura 2, h uma representao do modelo espiral, onde se define quatro
atividades principais deste paradigma. Carvalho e Chiossi (2001, p. 38) explicam
essas fases:
1) Definio dos objetivos, alternativas e restries: os objetivos para a
fase de desenvolvimento onde so definidos, tais como desempenho e
funcionalidade e so determinadas alternativas para atingir esses objetivos;
as restries relativas ao processo e ao produto so tambm determinadas;
um plano inicial de desenvolvimento esboado e os riscos e projeto so
16
identificados. Estratgias alternativas, dependendo dos riscos
detectados[...].
2) Anlise de risco: para cada um dos riscos identificados feita uma
anlise cuidadosa. Atitudes so tomadas visando reduo desses riscos
[...].
3) Desenvolvimento e validao: aps a avaliao dos riscos, um
paradigma de desenvolvimento escolhido [...].
4) Planejamento: o projeto revisado, e a deciso de percorrer ou no
mais um ciclo na espiral tomada. Se a deciso for percorrer mais um ciclo,
ento o prximo passo do desenvolvimento do projeto deve ser planejado.
"Se a anlise de risco indicar que h incerteza nos requisitos, a prototipagem
pode ser usada para auxiliar o desenvolvedor e o usurio. Simulaes e outros
modelos podem ser usados para melhor definir o problema e refinar os requisitos
(CARVALHO; CHOSS, 2001, p. 38).
Fi<ura ) Paradigma Espiral.
Fonte: Carvalho e Chiossi, p. 39.
17
Carvalho e Chiossi (2001, p. 38) veem uma diferena significativa entre o paradigma
espiral e os outros tipos e cita vantagens no uso desse modelo:
"A diferena mais importante entre o paradigma espiral e os outros
paradigmas a anlise de risco. O paradigma espiral possibilita ao
desenvolvedor entender e reagir aos riscos em cada ciclo. Usa prototipagem
como um mecanismo de reduo de risco e mantm o desenvolvimento
sistemtico sugerido pelo ciclo de vida clssico. ncorpora, ainda, um
componente iterativo que reflete o mundo mais realisticamente.
Rezende (2005, p. 131) alerta que esse modelo requer ateno especial dos
seus gestores no seu processo iterativo, principalmente quando qualidade de seus
produtos gerados.
= )3+3, I(era(ivo e In.re-en(al
Fi<ura ,/ Modelo terativo e ncremental
Fonte: http://voat.com.br/rdal/?tag=incremental
"Metodologias iterativas tm como objetivo o desenvolvimento de projetos de
forma incremental. A cada iterao uma parte do sistema desenvolvida, sendo o
produto de cada nova iterao superior da iterao anterior (VASCONCELOS;
ROULLER, 2006, p. 2).
Os requisitos de um sistema sempre evoluem durante o curso de um
projeto. Assim, a iterao do processo sempre faz parte do desenvolvimento
de grandes sistemas de software. teraes podem ser aplicadas a qualquer
18
modelo do ciclo de vida de software, mesmo no modelo cascata, como
vimos anteriormente. Nesse contexto, h duas abordagens relacionadas
que so mais adequadas para o tratamento de iteraes: desenvolvimento
espiral e desenvolvimento incremental (VASCONCELOS; ROULLER, 2006,
p. 33 e 34).
No modelo de desenvolvimento incremental, em vez de entregar o sistema
como um todo, o desenvolvimento e a entrega so divididos em incrementos, com
cada incremento representando parte da funcionalidade requerida, segundo
Vasconcelos e Rouiller (2006, p. 35).
Quanto aos requisitos do modelo incremental e as vantagens de usar esse
mtodo de desenvolvimento, Vasconcelos e Rouiller (2006, p. 35) descrevem da
seguinte forma:
Os requisitos dos usurios so priorizados e os considerados de mais alta
prioridade so includos nas iteraes iniciais. Uma vez que o
desenvolvimento de um incremento iniciado, os requisitos so
"congelados", embora possam continuar evoluindo para incrementos
posteriores [...]. As principais vantagens do modelo incremental que as
funcionalidades do sistema estaro disponveis mais cedo, pois ela
entregue a partir dos incrementos. Os incrementos iniciais agem como um
prottipo para ajudar a elicitar requisitos para incrementos finais,
diminuindo os riscos de falhas no projeto como um todo, assim, os
servios de prioridade mais alta do sistema tendem a receber mais testes.
> )3+3= Paradi<-a Evolu(ivo
Carvalho e Chiossi (2001, p.34) baseiam o paradigma evolutivo no
desenvolvimento e implementao de um produto inicial, que submetido aos
comentrios e crticas do usurio; o produto vai sendo refinado atravs de mltiplas
verses at que o produto de software almejado tenha sido desenvolvido.
"As atividades de desenvolvimento e validao so desempenhadas
paralelamente, com um rpido feedback entre elas (CARVALHO; CHOSS, 2001, p.
35).
Este modelo subdivide-se em dois tipos: o desenvolvimento exploratrio e o
prottipo descartvel.
19
- Desenvolvimento exploratrio
Esse modelo tem por objetivo trabalhar junto do usurio para descobrir seus
requisitos, de maneira incremental, at que o produto final seja obtido. O
desenvolvimento comea com as partes do produto que so mais bem entendidas, e
a evoluo acontece quando novas caractersticas so adicionadas medida que
so sugeridas pelo usurio (CARVALHO; CHOSS, 2001, p. 35).
Os sistemas desenvolvidos com esse modelo caracterizam-se por no
terem o escopo claramente definido, ou seja, a especificao do escopo
feita de forma intercalada ao desenvolvimento. Aps o desenvolvimento de
cada uma das verses do sistema, ele mostrado aos usurios para
comentrios, as modificaes sucessivas so feitas no sistema at que o
mesmo seja considerado adequado. A principal diferena dos outros
modelos a ausncia da noo de programa correto. Esse modelo tem sido
usado com sucesso para o desenvolvimento de Sistemas Especialistas, no
contexto da nteligncia Artificial (VASCONCELOS; ROULLER, 2006, p. 31
e 32).
- Prottipo descartvel
Este modelo tem por objetivo entender os requisitos do usurio e,
consequentemente, obter uma melhor definio dos requisitos do sistema, assim
Carvalho e Chiossi (2001, p. 35) descrevem.
"Atravs do exame do prottipo, os usurios podem descobrir quais so suas
reais necessidades (CARVALHO; CHOSS, 2001, p. 65).
O prottipo se concentra em fazer experimentos com os requisitos do
usurio que no esto bem entendidos e envolve projeto, implementao e
teste, mas no de maneira formal ou completa [...]. um processo que
possibilita ao desenvolvedor criar um modelo do software que ser
construdo (CARVALHO; CHOSS, 2001, p. 35).
Segundo Vasconcelos e Rouiller (2006, p. 32), este modelo tem sido usado
com sucesso para validar partes do sistema, como performance, portabilidade, etc.
20
O processo de prototipagem comea com um estudo preliminar dos
requisitos do usurio. A seguir, comea um processo iterativo de construo
do prottipo e avaliao junto dos usurios. Cada repetio permite que o
usurio entenda melhor seus requisitos, inclusive as implicaes dos
requisitos articulados nas iteraes anteriores. Eventualmente, um conjunto
final de requisitos pode ser formulado e o prottipo descartado (CARVALHO;
CHOSS, 2001, p. 65).
Carvalho e Chiossi (2001, p. 65) dizem que quando usada apropriadamente, a
prototipagem pode ser muito til para superar vrias dificuldades inerentes ao
processo de extrao de requisitos, especialmente as dificuldades de comunicao
e de articulao de necessidades pelo usurio.
Vasconcelos e Rouiller (2006, p. 32) descrevem que como na programao
exploratria, a primeira etapa prev o desenvolvimento de um programa (prottipo)
para o usurio experimentar. No entanto, ao contrrio da programao exploratria,
o prottipo ento descartado e o software deve ser reimplementado na etapa
seguinte, usando qualquer modelo de ciclo de vida, por exemplo o cascata.
)3) #ETODOLOGIA TRADICIONAL
Segundo Teles (2004, p.32), o desenvolvimento tradicional eminentemente
sequencial. A equipe deve construir o sistema avanando gradualmente nas fases
do desenvolvimento, o que permite que ela lide com nveis de complexidade cada
vez mais elevados. Alm da linearidade, existem outras caractersticas importantes
que costumam estar presentes no desenvolvimento tradicional: determinismo,
especializao e foco na execuo.
O foco principal das metodologias tradicionais a previsibilidade dos
requisitos do sistema, que traz a grande vantagem de tornar os projetos
completamente UML a linguagem padronizada de modelagem de sistemas
orientados a objetos para visualizao, construo, especificao e documentao
do sistema planejado, facilitando a gerncia do mesmo, mantendo sempre uma
linha, caracterizando o processo como bastante rigoroso (OLVERA; ROCHA;
VASCONCELOS, 2004, p.135).
Apesar das grandes vantagens, o desenvolvimento tradicional apresenta
problemas. Teles (2004, p.38) explica que as premissas em que se baseiam o
desenvolvimento tradicional somente so vlidas para o trabalho manual. Logo,
21
existe um problema: o desenvolvimento tradicional se baseia em premissas que no
so validas para o tipo de trabalho que ele envolve.
Um dos exemplos de metodologia tradicional o Rational Unified Process,
mais conhecido pela sigla RUP. "Ele fornece uma abordagem disciplinada para
assumir tarefas e responsabilidades dentro de uma organizao de
desenvolvimento (KRUCHTEN, 2003, p. 03).
Kruchten (2003,p.18) ainda afirma que muitas das organizaes lentamente
se deram conta da importncia do RUP para o sucesso dos seus projetos de
software, na qual um processo de desenvolvimento bem definido e bem
documentado proporciona (2003, p. 44).
?
@
A )3)3+ His(Bria do Ra(ional UniCied Pro.ess DRUPE
Criado pela Rational Software Corporation e adquirido em fevereiro de 2003
pela BM, o Processo Unificado Racionall (RUP), caracterizado segundo Martinez
(2010), como um processo de engenharia de software criado para apoiar o
desenvolvimento orientado a objetos, que fornece uma forma sistemtica para se
obter vantagens no uso da UML.
Martinez (2010) ainda menciona que o principal objetivo do RUP atender as
necessidades dos usurios, garantindo uma produo de software de alta qualidade
que cumpra um cronograma e um oramento previsvel.
Complementando, Piske (2003, p.02) define ainda, que o RUP mais do que
um software que auxilia no desenvolvimento, uma metodologia de
desenvolvimento com uma estrutura formal e bem definida, que assim como
qualquer outra, ela composta de conceitos, prticas e regras. Utiliza a abordagem
iterativa e incremental de desenvolvimento e personalizvel de acordo com as
necessidades especficas de cada projeto de desenvolvimento de software (LMA;
CAMPOS, 2009, p.02).
O surgimento da primeira verso do RUP, o 5.0, foi em 1998, proveniente da
evoluo de projetos anteriores, como o Rational Objectory Process, iniciado em
1996, e aps vrias melhorias de suas caractersticas surgiu a ento verso 2000.
Um exemplo de linguagem criada para apoiar a utilizao do RUP a Unified
Modeling Language, mais conhecida pela sigla UML, que oferece um conjunto de
modelos para auxiliar o desenvolvimento de software (MORERA; 2007, p.3).
22
No final de 1999 vrias empresas estavam empregando diversos domnios de
aplicaes em pequenos e grandes projetos, devido a grande versatilidade e ampla
aplicao que o RUP proporciona. Visa, Oracle, Volvo e ntel so alguns exemplos
de empresas que esto usando o Rational Unified Process (KRUCHTEN, 2003,
p.18).
F )3)3) Es(ru(ura 7;si.a
Sua estrutura bsica se apresenta em quatro fases, a Concepo, a
Elaborao, a Construo e a Transio (KRUCHTEN, 2003,p.19; VANNA, 2002).
Com base em Kruchten (2003, p.56 a 64), as fases do RUP se caracterizam de
acordo com a figura 4.
Fi<ura = Estrutura do processo RUP.
Fonte: KRUCHTEN, 2003,p.39.
Con.e!GHo
A concepo visa alcanar o consentimento de todos os interessados nos
objetivos do ciclo de vida para o projeto. Suas atividades essenciais so a captao
do contexto e dos requisitos mais importantes, planejar e preparar um caso de uso
23
do negcio, bem como avaliar as alternativas para o gerenciamento de riscos, com o
fornecimento de pessoal, plano de projeto e intercmbios entre custo, prazo e
rentabilidade, avaliando-os conforme decises de fazer, comprar e reutilizar, fazendo
assim que o custo, o prazo e os recursos possam ser calculados.
A criao dos artefatos so os resultados que essa fase proporciona, como o
documento de viso onde contm os requisitos centrais do projeto, caractersticas
fundamentais e as principais restries, inclui tambm uma avaliao inicial dos
riscos, um plano de projeto que mostra as fases e iteraes, um glossrio de projeto
inicial, a pesquisa do modelo de caso de uso que liste todos os casos de uso e
atores que podem ser identificados nesta fase prematura, entre outros artefatos.
O marco gerado por essa fase o produto que valida o final ciclo de vida.
Alguns critrios que avaliam esse marco o consentimento dos interessados na
definio da extenso, do custo, na estimativa de prazos e na compreenso dos
requisitos.
Ela0oraGHo
A fase de elaborao tem como propsito analisar o domnio do problema
onde estabelea uma base adequada, desenvolva o plano de projeto e elimine os
elementos de alto risco. Algumas decises devem ser tomadas com base em todo
sistema, a extenso, a funcionalidade principal e os requisitos no funcionais, assim
como os requisitos de desempenho, sendo assim considerada muitas vezes como a
mais crtica de todas as fases, pois corresponde transio de uma operao
mvel, gil e de pouco risco para um alto custo e uma operao de alto risco.
As atividades essenciais dessa fase uma viso mais elaborada com uma
compreenso detalhada dos casos de uso mais crticos que interferem nas decises
e no planejamento, a elaborao do processo, da estrutura e do ambiente de
desenvolvimento e a seleo dos componentes. No geral, na fase de elaborao,
alguns exemplos de resultado tm um modelo de caso de uso com pelo menos 80%
concludo, deciso na arquitetura de software, prottipo executvel, lista de riscos e
casos de uso do negcio revisado.
nessa fase que o segundo marco do projeto gerado, o marco de
arquitetura do ciclo de vida, onde os objetivos detalhados do sistema e sua
extenso, a escolha da arquitetura e a resoluo dos riscos principais so
24
examinados. Os critrios de avaliao principais envolvem respostas para perguntas
como: a viso do produto estvel? A arquitetura estvel? A demonstrao
executvel mostra os elementos de risco que foram endereados e solucionados
com segurana? A despesa de recurso atual versus a despesa planejada
aceitvel? Se o projeto falhar na avaliao de algum dos dois primeiros marcos, ele
pode ser cancelado ou repensado, para que atenda as necessidades iniciais para o
prosseguimento do projeto.
+* Construo
Na fase de construo, todos os componentes restantes e caractersticas da
aplicao so desenvolvidos e integrados ao produto, onde todas as caractersticas
so completamente testadas. Para atingir alguns objetivos bsicos dessa fase, como
minimizar custos de desenvolvimento e alcanar a qualidade adequada, algumas
atividades devem ser seguidas, como por exemplo, a administrao dos recursos, a
otimizao do processo, o desenvolvimento de componentes completos, os testes
contra os critrios de avaliao definidos e a avaliao dos lanamentos de produtos
contra os critrios de aceitao.
O resultado dessa fase consiste em no mnimo um produto de software
integrado nas plataformas adequadas, os manuais do usurio e uma descrio do
lanamento atual.
O marco gerado por essa terceira fase a capacidade operacional inicial, na
qual decide se o software, o local e os usurios esto prontos para operao, sem
expor o projeto a altos riscos. Nessa fase, a avaliao envolve respostas para as
seguintes perguntas: Este produto estvel e est amadurecido para ser distribudo
aos usurios? Todos os interessados esto prontos para essa transio? As
despesas de recursos atuais versus as despesas planejadas continuam aceitveis?
Caso o projeto no alcance esse marco, a transio poder ser adiada antes do
lanamento.
++
+)
+,
+=
+>
+?
25
+@ Transio
A quarta e ltima fase, a fase de transio, leva o produto de software aos
usurios. Normalmente aps sua entrega, novos lanamentos podero ser feitos
para a correo de alguns problemas ou caractersticas finais que foram adiadas.
Nesta fase inclui teste beta para validar o teste novo contra as expectativas de
usurios, operao paralela de substituio do sistema legado, conversao de
banco de dados, treinamentos de usurios e mantenedores, a sada do produto para
o marketing, a distribuio e as equipes de vendas.
A concluso dessa fase se d quando a linda base de desenvolvimento
alcana a viso completa e se focaliza nas atividades exigidas para colocar o
software nas mos dos usurios. As atividades dessa quarta fase so a engenharia
de desenvolvimento especfico, a afinao de atividades, inclusive fixar bug e
aprimorar para desempenho, a utilidade, a avaliao das linhas de desenvolvimento
contra a viso e os critrios de aceitao para o produto.
Seu marco o lanamento do produto. Nesse momento se decide se os
objetivos foram satisfeitos e se deveria comear outro ciclo de desenvolvimento,
podendo coincidir com o inicio da fase de concepo para o prximo ciclo. Os
critrios de avaliao da fase de transio envolvem as seguintes perguntas: O
usurio est satisfeito? As despesas de recursos atuais versus as despesas
planejadas ainda esto aceitveis? Dependendo do tipo de produto, esta atividade
pode ir de simples a extremamente complexa.
Com apoio da figura abaixo, observe em cada uma das fases sua principal
nfase, onde a cor mais escura tem mais nfase:
Levantamento
de Requisitos
Anlise Projeto mplementao Testes
Concepo
Elaborao
Construo
Transio
Fi<ura > - nfase principal em cada fase do processo RUP.
Fonte: http://www.laps.ufpa.br/yomara/paginav2/aps/processo%20unificado%20rup.pdf. Adaptado
pelos autores.
26
,3 #ANIFESTO $GIL
Em fevereiro de 2001, dezessete pessoas se reuniram na cidade de Utah,
pessoas estas consideradas como referencias no desenvolvimento de software e
que estavam procurando maneiras de melhorar o processo de desenvolvimento de
software. Em reunio foram destacados quatro valores, que so eles: ndivduos e
interaes mais que processos e ferramentas; Software em funcionamento mais que
documentao abrangente; Colaborao com o cliente mais que negociao de
contratos; Responder a mudanas mais que seguir um plano; "mesmo havendo valor
nos itens direita, valorizamos mais os itens esquerda. (Manifesto gil 2001).
,3+ VALORES
O manifesto contm quatro valores fundamentais. No se trata como poderia
parecer primeira vista, de um desprezo aos elementos e ferramentas tradicionais
do desenvolvimento de software, mas sim do estabelecimento de uma escala de
valores, na qual a flexibilidade e a colaborao so mais relevantes do que a rigidez
de processos e planejamento clssicos.
+A ,3+3+ IndivIduos e in(eraGJes -ais ue !ro.essos e Cerra-en(as
No desenvolvimento de um projeto deve levar em conta alm dos processos e
ferramentas escolhidas os indivduos participantes. ndivduos estes que no devem
ser escolhidos somente pela sua habilidade como desenvolvedor, mas tambm pela
sua capacidade de interao com o grupo, visto que esta interao que ir
proporcionar para a equipe o ganho de conhecimento e a mitigao das falhas dos
projetos. Os processos e ferramentas so muito importantes para a execuo de um
projeto, porm, no se pode ter mais importncia do que as pessoas que fazem
parte dele.
+F ,3+3) SoC(2are e- Cun.iona-en(o -ais ue do.u-en(aGHo a0ran<en(e
A documentao de um projeto um item extremamente importante para o
sucesso na sua execuo, visto que este o meio em que a comunicao com o
cliente se faz de forma mais transparente. As criaes de documentaes muito
27
extensas alm de demandarem um grande tempo dificilmente se mantero em
sincronia com o projeto, visto que as mudanas constantes ocorrem durante sua
execuo. O Manifesto defende somente das documentaes necessrias para
manter um sincronismo da documentao com o projeto e visto que o conhecimento
e alinhamento sobre as funes feito atravs do cdigo gerado, onde no cdigo no
haver duplas interpretaes.
)* ,3+3, Cola0oraGHo .o- o .lien(e -ais ue ne<o.iaGHo de .on(ra(os
Projetos desenvolvidos por base em especificao de necessidades feita pelo
cliente e entregues empresa responsvel pelo desenvolvimento geram produtos
falhos e com baixa qualidade. As metodologias geis trabalham com a participao
do cliente durante o desenvolvimento do produto para que tais necessidades de
modificao de prioridades e de funcionalidades possam ser facilmente detectadas,
reduzindo assim o nmero de funcionalidades no atendidas e de no
conformidades.
)+ ,3+3= Res!onder a -udanGas -ais ue se<uir u- !lano
Planejamento sempre necessrio para a execuo de um projeto, porm a
flexibilidade deste planejamento o fator chave defendido pelo manifesto gil onde
as mudanas so bem vindas a qualquer momento e de certa forma at desejadas
pela equipe para se ver uma evoluo da sua soluo.
,3) EKTRE#E PROGRA##ING DKPE
Destacamos como um exemplo de metodologia gil o Extreme Programming,
que segundo Souza (2007, p.03) um conjunto bem definido de regras, que vem
ganhando um grande nmero de adeptos por oferecer condies para que os
desenvolvedores respondam com eficincia mudanas no projeto, mesmo nos
estgios finais do ciclo de vida do processo, devido a quatro lemas adotados por
seus seguidores, a Comunicao, a Simplicidade, o Feedback e a Coragem.
A comunicao com o cliente mostra-se mais intensa que nos mtodos
tradicionais, devendo o cliente estar sempre disponvel para tirar as dvidas, rever
requisitos e atribuir prioridades, trazendo inmeros benefcios ao mercado, de forma
28
que o processo de desenvolvimento se torne mais gil e flexvel (SOUZA, 2007,
p.03).
Fi<ura ? Projeto de Extreme Programming
Fonte: http://www.extremeprogramming.org/map/iteration.html
)) ,3)3+ Valores
A metodologia XP apoiada em valores como simplicidade, comunicao, feedback
e coragem que nos submetem ao reconhecimento de que XP uma metodologia
baseada em comportamentos e atitudes. Dessa forma, ela propicia que o projeto
seja executado dentro do prazo e do oramento, fazendo ento com que o cliente
fique satisfeito e a equipe de desenvolvimento no fique "maluca por causa do
projeto
Feed0a.L
O compartilhamento das informaes um dos pontos fortes do XP onde
atravs do feedback, o cliente fornece equipe de desenvolvimento quando aprende
algo novo sobre o sistema, quando detecta novos requisitos ou formas de se
implementar, da mesma forma o cliente pode avaliar o seu sistema quando recebe
por parte dos desenvolvedores os posicionamentos como apontamento de riscos
tcnicos, alternativas de designer entre outras, rompendo assim o modelo mental
tradicional que apresenta uma forte diviso entre a produo e o consumo, dando ao
cliente a funo de produtor e consumidor (TELES, 2004, p. 44).
No processo tradicional, o ciclo produo consumo afetado por grandes
defasagens. O cliente produz a especificao. Um bom tempo depois, a
equipe a consume. Um bom tempo depois a equipe implementa o software.
29
Um bom tempo depois o cliente consume o software e o ciclo recomea. O
que o XP faz substituir a expresso "um bom tempo depois pelo termo
"rapidamente. (TELES, 2004, p. 45)
O processo rpido de feedback do XP proporciona uma repetio maior deste
ciclo e torna o produto final algo mais prximo as reais necessidades do usurio.
), Comunicao
Assim como o feedback importante para a relao da equipe com o cliente,
a comunicao interna e propagao do conhecimento entre a prpria equipe um
dos valores defendidos pelo XP. A prtica da comunicao entre a equipe feita
face-a-face pra que as informaes possam ser recebidas da melhor forma possvel
sendo enriquecia com gestos, entonaes de voz e expresses.
)= Simplicidade
A simplicidade apresentada pelo XP pode ser definida como a entrega de
partes simples e objetivas, afim de receber por parte do cliente o feedback o mais
rpido possvel para se realizar as correes necessrias caso sejam requisitadas.
Este valor est ligado diretamente busca da satisfao do cliente, promovendo da
forma mais simples a avaliao do cliente quanto as partes entregues, porm, no
tirando assim a credibilidade das avaliaes, pelo contrrio, tornando-as mais
confiveis.
Coragem
O XP por ser tratar de um processo incremental faz com que a equipe
assuma alguns "riscos como a alterao de mdulos antes entregues com
funcionalidades funcionando corretamente e a permisso da participao do cliente
durante o processo de priorizao de funcionalidades. A adoo do refactoring que
trabalha com a reviso de cdigos j prontos e funcionais com a finalidade de
melhor-los sem alterar suas funcionalidades, essa tcnica de certa forma pode ser
considerada uma demanda de tempo extra para se desenvolver o projeto, porm,
parte fundamental no XP para manter a simplicidade e clareza. A dedicao de
tempo para a criao de testes para confirmar o real funcionamento das
30
funcionalidades conforme previsto. Muitas equipes de desenvolvimento tomam para
si a documentao gerada para se defender quando projetos fracassam seja por
tempo, custo ou escopo no atendido. O XP se baseia na comunicao aberta,
portando no possvel conduzir um projeto com as prticas do XP com atritos de
relacionamento que levem as pessoas a se precaverem ao ponto de necessitarem
de documentos como forma de proteo conforme afirma Teles (2004, p. 55).
)>
)? ,3)3+ Pr;(i.as do KP
Para aplicar os valores e princpios durante o desenvolvimento
de software, KP prope uma srie de prticas. H uma confiana muito grande na
sinergia entre elas, os pontos fracos de cada uma so superados pelos pontos fortes
de outra.
)@ Cliente Presente
Em projetos tradicionais o desenvolvimento feito delegando ao cliente a
funo de expor suas necessidades e equipe a funo de implementar as
mesmas, criando uma diviso entre equipe e cliente. Para o XP, o cliente deve estar
presente durante o decorrer do projeto para que sua participao contribua no
alcance do sucesso, sua ausncia considerada fator srio de risco. Teles (2004, p.
57) ressalta que a participao do cliente possibilita a identificao da necessidade
de ajustes durante o decorrer do desenvolvimento, evitando assim mudanas
bruscas no decorrer do caminho.
)A Jogo do Planejamento
Esta pratica a estratgia onde sero distribudas as responsabilidades e a
equipe ir definir suas prioridades. O Planejamento repetido varias vezes durante
o projeto para manter a equipe focada naquilo que ir gerar maior valor para o
cliente.
)F Stand Up Meeting
31
Como uma forma de praticar a comunicao entre a equipe, diariamente ao
iniciar um dia de trabalho realizada uma etapa de cerca de dez minutos onde so
comentadas as atividades realizadas no dia anterior, esta reunio realizada com
todos os participantes em p para que a reunio no se torne longa. Nesta reunio
feita uma avaliao rpida do trabalho e oferece a chance de identificar pontos fortes
e fracos dentro do processo. Alm do posicionamento das atividades do dia anterior
as atividades a serem executadas ao longo do dia tambm so definidas. Em
resumo a reunio se define em trs perguntas: O que voc tem feito desde ontem?
O que voc est planejando fazer hoje? Voc tem algum problema impedindo voc
de realizar seu objetivo?
,* Programao em Par
nterpretada muitas vezes de forma errada pelas pessoas, a programao em
par tem a finalidade de executar reviso e proporcionar o questionamento de
cdigos complexos com a finalidade de torn-los simples e funcionais. A prtica da
programao em par produz a chamada "presso do par, que evita que o
programador se distraia com e-mails, mensagens instantneas, sites, entre outras
coisas que poderiam diminuir seu ritmo de trabalho. Um revezamento entre os
programadores sempre realizado a fim de manter o ritmo de produtividade. Alm
do revezamento entre navegador e condutor, devem-se trocar as duplas tambm
para promover a propagao do conhecimento.
,+ Refactoring
Esta prtica visa revisar cdigos j prontos afim de melhorar sua legibilidade e
funcionalidade, tornando sua manuteno mais fcil futuramente. Um cdigo mal
formulado cria dificuldades srias para quem um dia necessitar modific-lo ou
compreend-lo.
,) Desenvolvimento Guiado pelos Testes
Por se tratar de um desenvolvimento em mdulos em que cada parte passa
por alteraes constantes quando se tem de adicionar novas funcionalidades ou at
mesmo realizar refactoring, os cdigos testes so fundamentais para manter o
32
sistema rodando como previsto na hora da entrega. O XP utiliza dois mtodos de
teste, os testes unitrios e os testes de aceitao. Testes de unidades so
executados para verificar se uma determinada classe criada est totalmente em
conformidade e os testes de aceitao so para verificar a integrao de uma
determinada classe com as outras classes do projeto.
,, Cdigo Coletivo
Comumente um projeto desenvolvido por uma equipe dividido em partes,
certas partes so em geral entregues pessoas com conhecimento na rea do
mdulo em questo, criando assim "ilhas de conhecimento como intitulado por Teles
(2004, p. 144), que so pessoas que seriam necessrias para se efetuar futuras
modificaes nestas partes do cdigo, visto que o mesmo est ligado diretamente ao
seu conhecimento. O XP totalmente contra este tipo de situao e a prtica da
programao em pares atua diretamente neste tpico onde o conhecimento sempre
ser compartilhado para pelo menos uma pessoa durante o processo, que
posteriormente ser repassado outra, tornando assim um conhecimento comum a
todos da equipe.
=3 ESTUDO DE CASO/ CFC FAVI
A auto escola FAV solicitou um sistema para gerenciar as atividades bsicas
de um centro de formao de condutores, bem como a parte financeira, facilitando
suas tarefas e tornando preciso a parte contbil, para que o ganho de tempo seja
revertido completamente em melhorias para a empresa.
Por ser uma empresa ainda nova na cidade, ela s disponibiliza treinamentos
nas categorias A (moto) e B (carro), porm o sistema necessita ter a categoria C
(veculo voltado ao transporte de carga, cujo peso bruto total ultrapasse a 3.500kg),
pois em breve ser mais uma categoria que a auto escola disponibilizar.
Quando o aluno faz a inscrio, ele deve informar seu nome, sexo, data de
nascimento, endereo, telefone, CPF, identidade e a categoria da carteira desejada.
Antes do agendamento dos exames mdicos, o responsvel dever combinar
como ser feito o pagamento da auto escola, pois dependendo da forma de
33
pagamento e da categoria escolhida, o aluno receber descontos. J o pagamento
dos exames devem ser feitos na prpria auto escola e em uma nica parcela.
Aps aprovao nos exames mdicos, sero agendadas as aulas tericas. O
exame terico por sua vez marcado somente aps o cumprimento do mnimo de
aulas requeridas. Com a aprovao na parte terica, sero marcadas as aulas
prticas, por isso o sistema dever armazenar a data e a hora do exame e o
resultado do aluno, para que posteriormente ele possa fazer a prova prtica.
A auto escola escolher qual instrutor vai ser designado para fazer o
treinamento prtico. Para isso, o sistema deve armazenar alguns dados do instrutor,
como o nome, sexo, a data de nascimento, seu endereo, telefone, CPF, identidade,
nmero da CNH e a categoria que ele est habilitado para ensinar. Vale lembrar que
para melhor acompanhamento, cada aluno possuir apenas um instrutor e cada
instrutor poder ter vrios alunos, com um histrico de cada aluno para controlar seu
desenvolvimento.
O sistema dever ter um campo onde d para parcelar o pagamento do
processo, e ainda, dever ser possvel que a porcentagem de descontos possa ser
alterado a qualquer momento, dependendo do perodo que o aluno solicitou a
abertura do mesmo. Os valores alm de editveis pelo prprio gerente devem ser
precisos e seguros, e em hiptese nenhuma poder ser comprometido, uma vez que
desequilibrar toda a parte financeira da empresa.
Como uma forma de segurana, ainda na parte contbil, somente o usurio
superior poder fazer essas alteraes, evitando que pessoas no autorizadas
faam aes que no foram planejadas.
O aluno ter um controle de aulas entregue pela secretria, contendo a data e
a hora da aula e qual veculo ele utilizar. As aulas tero durao de 40 minutos, e
para todos os veculos da auto escola, deve-se saber a marca, ano, placa,
RENAVAM e cor, para as motos ainda ser necessrio saber a potencia.
Assim que o aluno fizer todas as etapas, a prova ser marcada e no sistema
dever conter se o mesmo obteve a habilitao ou no, bem como a data de
encerramento do processo (treinamento). Em caso de reprovao, o aluno deve
efetuar o pagamento de uma taxa para fazer uma nova tentativa, lembrando que as
tentativas no tem limite se estiverem dentro do prazo do processo.
34
=3+ #ODULARIMA45ON CO#PARATIVO E ESPECIFICA45O DE RE6UISITOS
Os mdulos utilizam uma tcnica que possibilita ainda nas etapas iniciais, a
abstraes sobre as tarefas a serem executadas. Estas abstraes so definidas
pelo seu efeito e constituem uma definio funcional da tarefa. Nas etapas
posteriores, cada descrio funcional substituda por trechos mais elaborados que
especificam e facilitam as etapas do processo (CHAVARETTE, 2011). A
modularizao uma ferramenta para a elaborao de programas visando os
aspectos de confiabilidade, legibilidade, manutenibilidade e flexibilidade.
Visando um melhor detalhamento do sistema, dividimos o problema em quatro
mdulos, onde cada rea com caractersticas especficas representam um mdulo.
Observe a figura abaixo:
Fi<ura @ Mdulos do Sistema CFC Favi
Fonte: Criado pelos autores
35
=3) CO#PARATIVO
Para detalhamento em estudo, utilizamos o Mdulo Financeiro, onde
especificamos os seus principais detalhes.
#odulo Finan.eiro
Reuisi(o Fun.ional Des.riGHo
CRUD Valores de Taxas
Manuteno dos valores dos servios
prestados pela empresa como Aulas,
agendamentos de exames, provas
entre outros.
CRUD Recebimento de Taxas
Controle dos pagamentos dos
servios prestados pela empresa.
Relatrio de Controle de Pagamentos
Relatrio individual informando
pendncias e acertos j realizados
Ta0ela + Requisitos Funcionais do Mdulo Financeiro
Fonte: Criada pelos autores
Abaixo segue uma tabela comparativa entre as duas metodologias no qual diz
respeito ao levantamento de artefatos
Levan(a-en(o de Ar(eCa(os
RUP KP
Documentao de viso do projeto:
caractersticas e restries
Questionrios sobre requisitos
Caso de Negcio Histria
Modelo de caso de uso Modelo de Caso de Uso
Plano de Projeto Padres de Codificao
Avaliao de riscos Plano de Liberao
Modelo de Teste Plano de terao
Modelo de mplementao Teste de Unidade
Descrio de Arquitetura do Software Teste de Aceitao
Plano de Desenvolvimento do
Software
Releases
Plano de terao Cdigo-fonte do produto
Modelo de Design
Plano de Aceitao do Produto
Documentao de Suporte
Prottipos
Ta0ela ) Levantamento de Artefatos do Mdulo Financeiro
Fonte: Criada pelos autores
Aplicativos da rea financeira apresentam um grande fator de risco devido a
ligao direta com o controle e movimentao financeira da empresa. Fator este que
36
influencia na escolha de uma metodologia por se tratar de algo que exige uma
documentao bem definida para embasar futuras auditorias no sistema.
Com base nos artefatos explicitados acima se v uma grande gama de
documentos gerados durante o desenvolvimento com o RUP, documentos estes que
em sua maior parte so criados durante a etapa de concepo do projeto com o
objetivo de embasar as decises dos Gerentes de Projeto e desenvolvedores.
O desenvolvimento atravs do XP tambm gera um considervel nmero de
documentos, porm estes documentos so em sua maioria documentos criados
durante as reunies e com a finalidade de somente registrar comentrios e
informaes passadas pelo cliente. Como uma das prticas do XP a no utilizao
de documentos como arma para defesa quanto a questionamentos do cliente ento
seus documentos so mais informais. O processo de criao dos documentos
apresentados acima se d no RUP de forma sequencial, ao contrrio do XP, que
gera seus artefatos de forma incremental.
O processo de desenvolvimento em um projeto com o XP est focado na
constante participao e aceitao pelo cliente, porm com baixo controle dos
riscos. J os projetos desenvolvidos com o RUP possuem uma ateno maior ao
gerenciamento dos riscos, no entanto, como o processo de consumo das
informaes pelo usurio programado e pontual, pode vir a gerar uma percepo
atrasada pelo usurio das no conformidades em virtude de sua identificao e
consequente, as mudanas a serem detectadas aps a etapa de anlise, fazendo
assim com que a cada fim de projeto no RUP se tenha um "prottipo para testes
enquanto no XP o produto entregue a release final do produto.
Conforme a tabela extrada de uma pesquisa publicada pela empresa
Rational Software, pode se ver que apesar do que se fala sobre a pouca
documentao dos projetos desenvolvidos pelas metodologias geis, so gerados
um considervel numero de documentos, porm sem uma formalidade to grande
quanto aplicada aos documentos das metodologias tradicionais.
37
Ta0ela , Mapeamento dos artefatos do XP para RUP
Fonte: http://www.riopomba.ifsudestemg.edu.br/dcc/dcc/materiais/
1447259264_compara%C3%A7%C3%A3o%20RUP%20X%20XP.pdf
=3) 6UESTOES A SERE# O7SERVADAS PELOS GERENTES DE PRO8ETOS
Alm das caractersticas apresentadas acima, foram elaboradas algumas
perguntas que auxiliaro o Gerente de Projetos selecionar a melhor estratgia a
ser adotada para o desenvolvimento de sistemas de informao, agregando assim,
valor escolha da metodologia de desenvolvimento a ser empregada no projeto.
38
,= =3)3+ Con(ra(os de es.o!o Ce.hado ou vari;vel
Teles (2006, p. 277) afirma que o XP pode ser utilizado para ambos os tipos
de contrato, porm por ser uma caracterstica da metodologia a espera de
mudanas, a utilizao do XP em contratos de escopo fechado se d como forma de
demonstrar ao cliente as vantagens geradas pela adoo de contratos de escopo
varivel.
Nas abordagens do desenvolvimento com o RUP seus mtodos favorecem a
contratos definidos com escopo fechado visto que a anlise feita somente uma vez
para se iniciar o projeto e possveis alteraes de escopo gerariam uma grande
demanda de esforo para recriar os planejamentos.
,> =3)3) NP-ero de ar(eCa(os reueridos !elo .lien(e
A produo de artefatos/documentaes quando exigida em grande nmero
pelo cliente cria uma barreira para a utilizao do XP visto que o mesmo defende a
criao de documentos somente quando necessrio como explicado no item 8.1.2.
Teles (2006, p. 277) afirma que: "Alguns clientes exigem a produo de uma pilha de
documentos e artefatos dos mais diversos ao longo do desenvolvimento. Se tal
exigncia no for flexibilizada, isso pode inviabilizar o uso do XP. Teles ainda diz
que alguns fornecedores iniciam o projeto utilizando XP, mas sempre buscando uma
flexibilizao ao longo do projeto por parte do cliente assim como citado no item
acima.
O RUP trabalha com itens bem definidos e documentados, assim projetos
com grande demanda de artefatos so mais bem atendidos por esta metodologia, j
projetos onde a demanda de artefatos no to grande gera-se certo nmero de
documentao desnecessria para o cliente em alguns casos.
,? =3)3, Ti!o de es.ri(Brio dis!oni0iliQado !ara o !roRe(o
Os projetos desenvolvidos com XP so altamente dependentes de
comunicao entre os membros da equipe e com o cliente. Esta dependncia cria
uma limitao quando ao tipo de espao utilizado para desenvolvimento conforme
Teles (2006, p.278) recomendado um ambiente onde a integrao da equipe seja
39
fcil, possua disponvel quadros para apoiar as discusses e mesas em que se
possa praticar a programao em par.
A segmentao do trabalho aplicada no RUP d a equipe do projeto uma
flexibilidade maior quanto a estrutura e localizao de seus escritrios podendo ser
realizadas as atividades em diferentes locais j que todo o desenvolvimento ser
baseado nas documentaes geradas, no dependendo da integrao direta entre
todos os membros para o desenvolvimento.
,@ =3)3= ClareQa na deCiniGHo dos reuisi(os3
Uma das grandes vantagens no desenvolvimento utilizando XP no ter de
extrair do cliente um requisito totalmente especificando porque o cliente estar
sempre presente com a equipe para poder esclarecer duvidas e apresentar mais
informaes quando for necessrio.
Como um ponto fraco o RUP apresenta a falta de flexibilidade para projetos
om baixa clareza de requisitos podendo gerar produtos que no atendam as
necessidades do usurio fato que justifica sua grande dedicao nas etapas de
anlise e levantamento de requisitos.
,A =3)3> A-0ien(e de Ne<B.io se en.on(ra es(;vel3
O ambiente de negcio e sua estabilidade quanto a modelos de processos de
atividades d ao Gerente de Projeto a base para a escolha da metodologia visto que
para ambientes de negcio que esto em fase de mudana, o desenvolvimento com
o XP resultar em produtos mais alinhados com as novas caractersticas de
mercado.
Projetos com ambientes em transio so dificilmente tratados no RUP
podendo ser uma soluo para estes problemas a diviso dos projetos em
microprojetos para que o seu desenvolvimento no sofra tanto devido a ter seu
tempo de produo menor e facilitando assim a deteco de mudanas necessrias
menos tardiamente.
40
>3 CONCLUS5O
Quando nos deparamos com um problema, em que o cliente busca em
nossos servios solues que os atenda da melhor forma possvel, estamos
firmando um compromisso de seriedade e de alternativas que facilitaro suas
tarefas.
O processo de desenvolvimento de software abrange todo escopo desde a
especificao do problema at a entrega do produto de software, para isso algumas
medidas devem ser tomadas, pois, no basta somente ter um produto eficaz,
devemos seguir limitaes de tempo e custo, nos preparando para que no ocorram
fatos inesperados durante o projeto.
Um bom envolvimento de todos interessados facilitam essa transio
problema soluo, pois essa integrao ir sanar dvidas antes mesmo de qualquer
execuo, inibindo assim alteraes ps trmino de fases, sendo elas o grande vilo
dos prazos estipulados.
Aps anlise do problema e o esclarecimento de dvidas, a escolha de qual
metodologia usaremos no desenvolvimento de software essencial para que
prossigamos de forma precisa.
Um dos tpicos que tambm vale ressaltar quanto a escolha de uma
metodologia a disposio e experincia da equipe na adoo do mtodo de
desenvolvimento. Para que um processo seja executado da melhor forma preciso
que toda a equipe esteja empenhada e interessada a praticar os fundamentos
propostos pela metodologia.
O comparativo objeto deste estudo tem a finalidade de demonstrar algumas
anlises, destacando pontos importantes entre as metodologias tradicionais e geis.
Por serem criadas em momentos distintos, essas metodologias possuem pontos
especficos que fazem toda a diferena para o desenvolvimento do software.
O XP se caracteriza como uma metodologia a ser utilizada em projetos onde
os requisitos no so claros, sendo assim muito flexvel, possuindo uma limitao de
uso em equipes pequenas, pois sua documentao no um fator de nfase e sim
para relatos de reunies, mantendo o foco em projetos mais simples, entende o a
burocracia e do excesso de documentos como perda de tempo, no sendo indicada
em projetos com equipes distribudas geograficamente distantes. A diviso das
41
tarefas e papis no XP tambm no muito especfica, sendo uma desvantagem
para a diviso de responsabilidades em projetos grandes. Por no possuir
preocupao formal com o planejamento de riscos, mesmo acontecendo com
frequncia em projetos desenvolvimento, a falta dessa anlise torna-se um fator
negativo.
O RUP por sua vez estrutura o projeto dividindo bem as tarefas e papis,
definindo vrios artefatos que so usados como produtos de entrada e de sada
entre os processos. Essa estruturao possibilita que o RUP seja utilizado em
projetos grandes e com distribuio geogrfica distinta. Sua documentao rica e
bem definida, visto que os seus requisitos devem ser bem claros. Por no possuir
tanta etapa de produtos entregues, a anlise de risco e segurana detalhada, pois
o produto entregue j ser o produto final, tornando assim mais seguro para
utilizao.
Alguns fatores destacados so primordiais dependendo do problema a ser
solucionado, ficando a responsabilidade do Gerente de Projetos avaliar a situao e
optar sobre a metodologia que melhor conduzir a equipe no atingimento dos
objetivos do projeto.
?3 REFERSNCIAS
AGLE MANFESTO. #aniCes(o A<ile SoC(2are Develo!-en( [nternet]. Disponvel
em: <http://agilemanifesto.org/iso/ptbr/ >. Acesso em: 21 de Ago. 2013.
CARVALHO, Ariadne Maria Brito Rizzoni; CHOSS, Thelma Ceclia dos Santos.
In(roduGHo T en<enharia de soC(2are3 2 ed. So Paulo: Editora da Unicamp,
2001. 148 p.
CHAVARETTE, Fbio Roberto. In(roduGHo T CiUn.ia da Co-!u(aGHo/
#odulariQaGHo de Al<ori(-os e Su0!ro<ra-aGHo [nternet]. So Paulo. 2011.
Disponvel em:
<ftp://ldc.feis.unesp.br/fabioch/ntroducaoComputacao_Civil/Modularizacao.pdf>. Acesso
em: 18 de Set. 2013.
KRUCHTEN, Philippe3 In(roduGHo ao RUP Ra(ional UniCied Pro.ess. 1.ed. Rio
de Janeiro: Editora Cincia Moderna Ltda., 2003. 255 p.
LBERAL, Claudemir Gonalves. Indi.adores de .iUn.ia e (e.nolo<ia/ .on.ei(o e
ele-en(os his(Bri.os [nternet]. Curitiba. 2005. Disponvel em:
<http://cienciaeopiniao.up.edu.br/arquivos/cienciaeopiniao/File/volume3/CienciaOpiniao3_art
6.pdf>. Acesso em: 13 de Set. 2013.
LMA, Alberto Sampaio; CAMPOS, Ldio Mauro Lima de. Geren.ia-en(o de
ProRe(os de Desenvolvi-en(o de SoC(2are .o- o RUP e o P#7O" [nternet]. Rio
de Janeiro. 2009. Disponvel em:
<http://www.aedb.br/seget/artigos09/163_seget_2009.pdf> Acesso em: 19 de Ago.
2013.
43
MARTNEZ, Marina. RUP [nternet]. Santa Catarina. 2010. Disponvel em:
<http://www.infoescola.com/engenharia-de-software/rup>. Acesso em: 11 de Set. 2013.
MNSTRO DA CNCA, TECNOLOGA E NOVAO. Indi.adores na.ionais de
.iUn.ia e (e.nolo<ia DCVTE [nternet]. Braslia. 2011. Disponvel em:
<http://www.mct.gov.br/index.php/content/view/740.html?execview>. Acesso em: 14 de
Set. 2013.
MNSTRO DO PLANEJAMENTO, ORAMENTO E GESTO. Pro<ra-a P76P &
Pro<ra-a 7rasileiro de 6ualidade e Produ(ividade [nternet]. Braslia. 2011.
Disponvel em:
<http://www.abrasil.gov.br/nivel3/index.asp?id=182&cod=BUSCA#top> . Acesso em: 14 de
Set. 2013.
MORERA, Albert Menezes. #ETODOLOGIAS DE DESENVOLVI#ENTO/ U#
CO#PARATIVO ENTRE EKTRE#E PROGRA##ING E RATIONAL UNIFIED
PROCESS [nternet]. So Paulo. 2007. Disponvel em:
<http://www.albertmoreira.com.br/?page_id=212 >. Acesso em: 10 de Set. 2013.
NASCMENTO, Clia Joseli do; MARNHO, Diva da Silva; WEBER, Kival Chaves.
Pro<ra-a 0rasileiro da ualidade e !rodu(ividade e- soC(2are/ (reQe anos
a.o-!anhado e disse-inando a .ul(ura da ualidade [nternet]. Paraba. 2011.
Disponvel em: <http://engenhariadesoftware.posterous.com/programa-brasileiro-da-
qualidade-e-produtivid >. Acesso em: 08 de Set. 2013.
NOGUERA, Elias. Situao do Desenvolvimento de Software com vises de Qualidade de
Software [nternet]. So Paulo. 2010. Disponvel em:
<http://sembugs.blogspot.com/2010/01/situacao-desenvolvimento-visao.html>. Acesso em:
14 de Set. 2013.
44
OLVERA, Sandro Ronaldo Bezerra; ROCHA, Thayssa guila da; VASCONCELOS,
Alexandre Marcos Lins de. AdeuaGHo de Pro.essos !ara F;0ri.as de SoC(2are
[nternet]. So Paulo. 2004. Disponvel em:
<http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_12_Simpros2004.pdf>.
Acesso em: 02 de Set. 2013.
PARRERAS, Fernando Silva; OLVERA, Gustavo Souza de. An;lise .o-!ara(iva
de !ro.essos de desenvolvi-en(o de soC(2are so0 a luQ da <es(Ho do
.onhe.i-en(o/ u- es(udo de .aso de e-!resas -ineiras [nternet]3 Braslia.
2004. Disponvel em:
<http://www.fernando.parreiras.nom.br/publicacoes/WGC_Parreiras04.pdf>. Acesso
em: 26 de Jul. 2013.
PSKE, Otvio Rodolfo. RUP Ra(ional UniCied Pro.ess [nternet]. Santa Catarina.
2003.Disponvel em:<http://www.angusyoung.org/arquivos/artigos/trabalho_rup.pdf>.
Acesso em: 13 de Set. 2013.
PRESSMAN, Roger S. En<enharia de SoC(2are. 3 ed. So Paulo: Makron Books,
1995. 1056 p.
REZENDE, Denis Alcides. En<enharia de SoC(2are e Sis(e-as de InCor-aGHo. 3.
ed. Rio de Janeiro: Editora Brasport, 2005. 344 p.
SMTH, John. U-a Co-!araGHo de RUP e KP [nternet]. Estados Unidos da
Amrica. 2002. Disponvel em:
SOUZA, Luciano Malaquias de. #WTODO $GIL KP DEKTRE#E PROGRA##INGE
[nternet]. So Paulo. 2007. Disponvel em:
45
<http://intranet.fia.edu.br/acesso_site/fia/academos/revista3/6.pdf> Acesso em: 01
Set. 2013.
UCHA, Juliana Prado. EvoluGHo da #e(odolo<ia de Desenvolvi-en(o [nternet].
So Paulo. 2008. Disponvel em:
<http://www.linhadecodigo.com.br/artigo/2108/evolu%C3%A7%C3%A3o-da-metodologia-do-
desenvolvimento-de-sistemas.aspx4 >. Acesso em: 05 de Out. 2013.
TELES, Vinicius Manhes. EX(re-e Pro<ra--in<. 1 ed. So Paulo: Novatec,
2004. 316 p.
VASCONCELOS, Alexandre Marcos Lins de; ROULLER, Ana Cristina;. In(roduGHo
T En<enharia de SoC(2are e T 6ualidade de SoC(2are [nternet]. Minas Gerais.
2006. Disponvel em:
<http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia
%26QualidadeSoftware_V.28.09.06.pdf>. Acesso em: 02 de Set. 2013.
VAZQUEZ, Carlos Eduardo. GerUn.ia de Reuisi(osN Desenvolvi-en(o $<il e
APF/ A 7us.a do EuilI0rio Perdido [nternet]. Rio de Janeiro. 2011. Disponvel
em: <http://www.fattocs.com.br/blog/?p=392> Acesso em: 14 de Set. 2013.
VANNA, Mauro. ConheGa o Ra(ional UniCied Pro.ess DRUPE [nternet]. Rio de
Janeiro. 2002. Disponvel em:
<http://www.linhadecodigo.com.br/colaborador.aspx?id=31>. Acesso em: 02 de Set. 2013.
XP. EX(re-e Pro<ra--in< [nternet]. Disponvel em:
<http://www.extremeprogramming.org/ >. Acesso em: 12 de Set. 2013.