YP

UNIVERSIDADE ESTADUAL DA PARABA
CAMPUS GOVERNADOR ANTONIO MARIZ

CENTRO DE CINCIAS EXATAS E SOCIAIS APLICADAS - CCEA
LICENCIATURA PLENA EM COMPUTAO
ELDER GONALVES PEREIRA
Implementando um Componente de Software com o Auxlio da Metodologia

gil easYProcess.
PATOS PB
2011
1

gil easYProcess.
Monografia apresentada ao Curso de Graduao

Licenciatura
Plena
em
Computao
da
Universidade Estadual da Paraba, em cumprimento

exigncia para obteno do grau de Licenciado em
Computao.
Orientador: Prof. Esp. Vitor Ablio Sobral Dias Afonso
PATOS PB
2011
2

gil easYProcess.
Monografia apresentada ao Curso de Graduao

Licenciatura
Plena
em
Computao
da
Universidade Estadual da Paraba, em cumprimento

exigncia para obteno do grau de Licenciado em
Computao.
PATOS PB
2011
AGRADECIMENTOS
Primeiramente a Deus, pois sem ele nada possvel, e em segundo a minha me, Maria de
Ftima Gonalves Pereira e todos os meus irmos, pela dedicao, companheirismo e
amizade. Ao professor Vitor Ablio Sobral Dias Afonso pelas leituras sugeridas e correes
ao longo dessa orientao, a todos os professores que fizeram isso se tornar realidade. E a
uma pessoa que me ajudou muito no processo gramatical desse trabalho, Luana Arajo.
RESUMO
O presente Trabalho de Concluso de Curso objetiva apresentar a metodologia gil de

desenvolvimento easYProcess (YP) aplicada implementao do Software para Controle de
Vendas (SysVenda), mostrando e especificando na prtica a quantidade de artefatos que esta
metodologia de desenvolvimento produz durante a elaborao do sistema de software.
Partindo do fato de que easYProcess (YP) encontra-se em sua verso original, datada do ano
de 2007, sem atualizaes, e competindo com outras metodologias geis presentes atualmente
no mercado de trabalho. Para essa realizao todos os artefatos necessrios para a
esquematizao do problema so definidos e especificados segundo a metodologia em
questo.
Palavras chaves: Engenharia de Software, desenvolvimento gil, easYProcess.
ABSTRACT
This Course's conclusion project is intended to present the agile methodology of development
easYProcess (YP) applied to software implemtation: Sales Management (SysVendas) , show
up and specifying on practice the amount of artifacts that this development's methodology
produces for software's system preparation. Keeping in mind that the easYProcess (YP) is in
your original version, from year 2007, without update and competing with others current
agile methodology existent on current market. To realize this project all artifacts necessary
to builindg the problem are defined and specified follow the methodology used in the study
keyword: Software engineering, agile development, easYProcess.
LISTAS DE FIGURAS
Figura 01: Modelo em Cascata ----------------------------------------------------------------- 20

Figura 02: Modelo em Espiral ------------------------------------------------------------------ 21
Figura 03: Sntese do Fluxo do Processo YP ------------------------------------------------- 29
Figura 04: Cadastro de Produto ---------------------------------------------------------------- 47
Figura 05: Venda de Produto ------------------------------------------------------------------- 48
Figura 06: Lista de Produto --------------------------------------------------------------------- 48
Figura 07: Confirmao de Venda ------------------------------------------------------------- 49
Figura 08: Modelo Arquitetural ---------------------------------------------------------------- 49
Figura 09: Modelo Relacional ------------------------------------------------------------------ 50
Figura 10: Interface de Venda ------------------------------------------------------------------ 74
LISTAS DE QUADROS
Quadro 01: Definio de papis --------------------------------------------------------------- 41

Quadro 02: Objetivo de usabilidade ---------------------------------------------------------- 43
Quadro 03: Uses Stories ------------------------------------------------------------------------ 45
Quadro 04: Matriz de Competncia ----------------------------------------------------------- 52
Quadro 05: Plano de Release 01 --------------------------------------------------------------- 53
Quadro 08: Plano de Iterao 02 --------------------------------------------------------------- 54
Quadro 09: Big Chat ----------------------------------------------------------------------------- 59
Quadro 10: Plano de Iterao 02 --------------------------------------------------------------- 60
Quadro 11: Risco --------------------------------------------------------------------------------- 61
SMARIO
1.
INTRODUO --------------------------------------------------------------------------- 12
1.1.
PROBLEMTICA ------------------------------------------- -------------------- 13
1.2
JUSTIFICATIVA ----------------------------------- ----------------------------- 14
1.3
DELIMITAO --------------------------------------- -------------------------- 15
1.4
OBJETIVOS ----------------------------------------- ----------------------------- 16
1.4.1 Geral ------------------------------------------- ------------------------------------ 16

1.4.2 Especficos ---------------------------------------- -------------------------------- 16
1.5
ESTRUTURA DO TRABALHO ----------------------------------------------- 16
ENGENHARIA DE SOFTWARE ------------------------- --------------------------- 17

2.1
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ---- --------- 18
2.2
METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAL ------- 20
2.3
METODOLOGIA DE DESENVOLVIMENTO GIL -----------------------22
2.4
MODELOS DE DESENVOLVIMENTO APOIADORES DO YP -------- 23
2.4.1 Extreme Programming - XP (programao extrema) -------------------- 23

2.4.1.1 Definio ..................................................................................................... 23
2.4.1.2 Princpio ...................................................................................................... 23
2.4.2 Rational Unified Process - RUP (processo unificado racional) ............ 25
2.4.2.1 Definio ..................................................................................................... 25
2.4.2.2 Principio ..................................................................................................... 25
2.4.3 Agile Modeling (AM) ................................................................................ 26
2.4.3.1 Definio ..................................................................................................... 26
2.4.3.2 Princpios ..................................................................................................... 27
2.4.3.3 Prticas ........................................................................................................ 27
EASY PROCESS ................................................................................................... 29

10
3.1
DEFINIO DE PAPIS ........................................................................... 30
3.2
CONVERSA COM O CLIENTE ................................................................ 32
3.2.1 Descrio ..................................................................................................... 32

3.2.2 Requisitos .................................................................................................... 32
3.2.3 Perfil do Usurio ........................................................................................ 33
3.2.4 Objetivos de Usabilidade ........................................................................... 33
3.3
INICIALIZAO ........................................................................................ 34
3.3.1 Modelo de Tarefa ........................................................................................ 34

3.3.2 User Stories e Teste de Aceitao .............................................................. 34
3.3.3 Prottipo da Interface ................................................................................ 34
3.3.4 Projeto Arquitetural .................................................................................. 35
3.3.5 Modelo Lgico de Dados ............................................................................ 35
3.4
PLANEJAMENTO ....................................................................................... 36
3.5
IMPLEMENTAO .................................................................................... 37
3.5.1 Integrao continua .................................................................................... 37

3.5.2 Boas Prticas de Codificao ..................................................................... 37
3.5.3 Propriedade Coletiva de Cdigo ................................................................ 38
3.5.4 Testes ............................................................................................................ 38
3.5.5 Pequenos Releases ....................................................................................... 39
3.6
REUNIO DE ACOMPANHAMENTO ..................................................... 40
SYS VENDA E YP .................................................................................................. 41

4.1
DEFINIO DE PAPIS ............................................................................. 41
4.2
CONVERSA COM O CLIENTE .................................................................. 42
4.3
INICIALIZAO ......................................................................................... 45
4.4
PLANEJAMENTO ........................................................................................ 52
4.5
IMPLEMENTAO ..................................................................................... 56
4.6
REUNIO DE ACOMPANHAMENTO ...................................................... 59
11
CONSIDERAES FINAIS ............................................................................... 63

5.1
TRABALHOS FUTUROS .......................................................................... 64
REFERNCIAS ................................................................................................................ 65
Apndice A: Estrutura Base do Sistema ............................................................................. 68
Apndice B: Modulo de Venda .......................................................................................... 70
Apndice C: Teste de Usabilidade ...................................................................................... 74
12
INTRODUO
Neste momento, o mundo encontra-se em uma sociedade informatizada que passa por
sucessivas modificaes, e em conseqncia disso, o comrcio internacional e nacional
precisa de solues computacionais disponibilizadas ao negcio do cliente o mais rpido
possvel, que possa auxiliar no ambiente de negcio de forma mais fcil e produtiva.
De acordo com Sommerville (2007), os softwares tm que ser desenvolvidos
rapidamente para que possam atender as necessidades de negcio do mercado, a entrega
rpida do software s vezes considerada o requisito mais crtico, isso devido as constantes
variaes no ambiente de negcio, os requisitos mudam rapidamente por que praticamente
quase que impossvel prever como o sistema se comportar, entretanto somente ao trmino
do sistema que os requisitos tornam-se claros.
Visando uma maneira de produzir software mais rpido, de qualidade e que atenda a
exigncia do cliente, a Engenharia de Software prope e estuda novas formas de
desenvolvimento baseadas unicamente em processos geis, conhecidos como Modelos de
Desenvolvimento geis. Este trabalho tem como fundamento apresentar easYProcess (YP)
como uma alternativa para o desenvolvimento gil de aplicaes. Para efetivao desse
trabalho, torna-se necessrio a modelagem e implementao de um componente de software
baseado no modelo de desenvolvimento em questo, onde os passos do processo de
desenvolvimento so relatados e analisados.
Normalmente uma metodologia de desenvolvimento requer uma quantidade mnima
de pessoas para o processo de construo do software, ao se tratar de um TCC (trabalho de
concluso de curso) os outros membros da equipe podem ser parcialmente omitidos. Sabendo
que o YP uma metodologia de desenvolvimento simples onde a mesma pessoa pode
desempenhar mais de um papel no processo de desenvolvimento.
Segundo GARCIA (2007), Um papel no corresponde necessariamente a uma pessoa
da equipe, ou seja, uma mesma pessoa pode desempenhar vrios papis simultaneamente.
13
1.1
PROBLEMTICA
Em algumas equipes de desenvolvimento de software um dos problemas encontrados

no processo est relacionado concluso do projeto em tempo programado, isso devido falta
de uma forma eficiente de gerenciamento que, fazem as entidades de uma equipe trabalhar
descoordenadamente.
Pensando neste tipo de problemtica, surgiu uma nova metodologia de
desenvolvimento baseada em agilidade. Como afirma Mansur (2007), o mercado de TI
responde que a metodologia gil permite reduzir o tempo de entrega de software para
introduzi-lo no ambiente de trabalho, como tambm um simples gerenciamento para o
projeto, atribuindo aos membros da equipe maior facilidade para o processo de
desenvolvimento de software.
Afirma Caetano (2009), que as metodologias de desenvolvimento geis oferecem aos
membros da equipe de software maior flexibilidade para o desenvolvimento, como tambm
uma maior participao e aproximao do usurio final. Com esse tipo de metodologia, a
efetivao do projeto realizada em etapas, resultando em tempos de entrega de software
menores em torno de trs a seis semanas.
Produtos de software com qualidade reprovada, oramentos estourados, gerenciamento
descoordenado, atraso na entrega do produto final do software, so alguns dos fatores que
levam vrios pesquisadores a definirem novas metodologias de desenvolvimento de software
que, auxilie um processo de desenvolvimento simplicista e eficiente. Onde a curva de
aprendizado do processo seja baixa, para os membros da equipe no desperdiarem muito
tempo ao analisarem a nova abordagem de desenvolvimento.
14
1.2
JUSTIFICATIVA
Apesar do curso de Licenciatura em Computao da Universidade Estadual da Paraba

(UEPB) oferecer uma disciplina na rea de engenharia de software, o conhecimento
apresentado considerado insuficiente para um mercado de trabalho to exigente quando o
assunto desenvolvimento de sistemas.
Sob essa tica, torna-se essencial a aquisio de mais conhecimento na rea de
Engenharia de Software por parte do formando, e em especial, abordando uma temtica
especfica que so os Processos de Desenvolvimento de Software, mais intrinsecamente a
Metodologia gil, fazendo com que o discente tenha mais atribuies na rea de interesse, e
torne-se mais qualificado para atuao e absoro do mercado tecnolgico, comprometendose com o setor desenvolvimentista.
A priori, o easYProcess (YP) foi escolhido para a modelagem e implementao do
desenvolvimento de um sistema, por ser considerado uma Metodologia de Desenvolvimento
de Software gil simples e eficiente, e apresentar uma curva de aprendizagem baixa.
Surgindo num cenrio acadmico da Universidade Federal de Campina Grande (UFCG), o YP
vem auxiliando os alunos nas disciplinas que envolvem desenvolvimentos de sistemas de
softwares desde o ano de 2003, com mais de 90% dos projetos chegando fase final.
O YP uma metodologia alternativa para ser adotada no s no meio acadmico, mas
como tambm no ambiente comercial, seja na categoria de Free-lance ou empresarial, os
usurios da mesma no precisam ter um conhecimento especfico na rea de Engenharia de
software, uma vez que apresenta uma abordagem dos processos de forma bem intuitiva.
15
1.3
DELIMITAO
A presente pesquisa aborda o processo de implementao de um componente de

software com o auxlio de uma metodologia gil de desenvolvimento, a saber, o easYProcess.
Apesar de o componente desenvolvido ser produzido em virtude de um trabalho
acadmico, o mesmo poder ajudar no auxlio de venda de produtos do comrcio em geral,
realizando todo o controle de estoque, o cenrio cadastral, dentre outras funcionalidades.
16
1.4
OBJETIVOS
1.4.1 Geral
Realizar, na prtica, um estudo referente a uma metodologia de desenvolvimento gil,

no caso, o easYProcess (YP); para tal ser modelado e implementado um componente de
software com auxlio desta.
1.4.2 Especficos
I.
Apresentar as caractersticas das metodologias de desenvolvimento geis e

tradicionais;
II.
Analisar as principais caractersticas das metodologias de desenvolvimento apoiadoras

do easYProcess;
III.
Especificar detalhadamente a metodologia de desenvolvimento gil easYProcess;
IV.
Modelar e implementar um componente de software com auxlio da metodologia de

desenvolvimento easYProcess;
V.
1.5
Avaliar a aderncia do YP no desenvolvimento de um Sistema.
ESTRUTURA DO TRABALHO
O restante do trabalho est dividido em quatro captulos:

A seo 2 (dois) apresenta a Reviso de Literatura acerca de Engenharia de Software;
A seo 3 (trs) aponta a Metodologia gil de Desenvolvimento com nfase em
easYProcess;
A seo 4 (quatro) aborda o Desenvolvimento de Software com o processo YP;
A seo 5 (cinco) apresenta as Consideraes Finais sobre Estudo em questo.
17
ENGENHARIA DE SOFTWARE
Engenharia a aplicao de conhecimentos cientficos, empricos e certas habilitaes

especificas que tem como objetivo converter recursos naturais para atender as necessidades
humanas, j o software o conjunto de componentes informacionais que no fazem parte do
equipamento fsico, podendo incluir dados e programas ele associado (AURLIO, 2004).
Para Pressman (2001), a Engenharia de Software um rebento da Engenharia de
Sistemas e Hardware, abrangendo trs fundamentaes, a saber: mtodos (tcnicas usadas
para simplificar o processo de desenvolvimento), ferramentas (softwares CASE1 que auxiliam
no processo de desenvolvimento) e procedimentos (uma ligao entre os mtodos e as
ferramentas usadas no processo de desenvolvimento). Dando ao gerente o controle para o
processo de desenvolvimento de software de alta qualidade.
Segundo Somerville (2007), a Engenharia de software uma disciplina que aborda
todos os aspectos na construo do software, desde a fase de especificao de requisitos
(processo no desenvolvimento que tem como funo coletar dados a respeito do sistema de
software a ser construdo), at a fase de manuteno (onde o sistema de software produzido
entra em operao e periodicamente submetido a novas especificaes e alteraes).
Sendo uma rea de conhecimento da computao voltada para construo de
softwares, aplicando tecnologias e prticas que englobam Linguagens de Programao, Banco
de Dados, Ferramentas CASE, Plataformas, Bibliotecas de Cdigo, Padres de Projeto e a
questo da Qualidade de Software (MOLINARI, 2007).
Manoel Silva e Thaissa Rocha 1

: Computer-Aided Software Engineering uma classificao que abrange
todas ferramentas baseadas em computadores que auxiliam atividades de engenharia de software, desde anlise
de requisitos e modelagem at programao e testes.
18
2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Processos de Desenvolvimento de Software so um conjunto de atividades requeridas

para a produo de um software com alta qualidade, onde todo controle do processo
administrado pelo gerente (PRESSMAN, 2001). Embora existam vrios tipos de processos de
desenvolvimentos de software, as atividades so consideradas genricas em relao aos
modelos
at
ento
existentes,
relacionadas
unicamente
as
seguintes
atividades
(SOMMERVILLE, 2007):
Requisitos: Especifica todas as funes e caractersticas do sistema que ser
produzido, dividido em duas categorias: requisitos funcionais (so as funes que
sistema dever suportar), e no funcionais (so caractersticas que o sistema dever
apresentar) do sistema de software em questo;
Projeto: responsvel de especificar o problema do cliente em diagramas, deixando
mais especficos para os membros da equipe, nesta fase so propostos vrios modelos
arquiteturais em formas de diagramas, e apenas um sendo selecionado e direcionado
para o processo de desenvolvimento;
Desenvolvimento: Neste momento comea a codificao propriamente dita do
sistema de software, nesta fase aconselhvel que os desenvolvedores tenham em
mente alguns padres de codificao de terceiros que apresente como objetivo auxiliar
os mesmos em uma codificao coerente, simples e de fcil entendimento entre os
membros da equipe;
Validao e Verificao: Nesta etapa o sistema de software ento j produzido
submetido prova, diversos aspectos relacionados ao funcionamento do produto de
software devem ser verificados e analisados, com um nico objetivo, encontrar falhas
que comprometam o bom desempenho do sistema de software, e ento direcion-las
aos desenvolvedores para correo;
Gerenciamento: A equipe de desenvolvimento deve ser gerenciada por um ou grupo
de pessoas que tenham um bom conhecimento do sistema de software a ser produzido,
e apresente qualificao para gerenciar, tais como, estimativa de custo, gerenciamento
de qualidade de software, aprimoramento do processo de desenvolvimento e que
19
apresente grande capacidade de estabelecer uma comunicao eficiente entre os

membros da equipe.
O desenvolvimento de software no uma tarefa simplificada, pois o mesmo
problema pode apresentar inmeras solues. Alm da efetivao do desenvolvimento do
software depender unicamente da competncia de um bom relacionamento entre os membros
da equipe (AVILA, 2008).
20
2.2 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAL
A atividade de desenvolvimento de software na dcada de 70 era executada de

forma desorganizada, e sem planejamento, gerando um produto final de software de m
qualidade, que no correspondia com as reais necessidades abordadas inicialmente pelo
cliente, a partir desta problemtica torna-se indispensvel efetivar o desenvolvimento de
software de forma estruturada, planejada e padronizada (PRESSMAN, 2001).
O Modelo em Cascata (ver Figura 01) surgido na dcada de 1970, tem como foco de
desenvolvimento realizar uma sequncia de atividades uma nica vez, estruturadas como uma
cascata, onde a sada de uma atividade um produto para a entrada da atividade subseqente
(WILEY, 2002).
Figura 01: Modelo em Cascata
Fonte: Adaptado (WILEY, 2002).
O Modelo em Espiral (ver Figura 02) apresenta um conjunto de atividades de forma

no seqencial, onde cada loop na espiral cria uma nova verso de software. E em cada volta,
21
todas as atividades de anlises, teste, projeto, planejamento e construo so repetidas e

entregues ao cliente como nova verso, a maior vantagem desse modelo em relao a outros
modelos tradicionais, a sua capacidade de anlise de risco no incio do desenvolvimento
(SOMMERVILLE, 2007).
Figura 02: Modelo em Espiral
Fonte: Adaptado ( SOMMERVILLE, 2007).
Quando nos referimos a projetos de pequenas e mdias empresas, e principalmente em

um mercado altamente competitivo, ou em crise econmica, esses tipos de modelos so
considerados desnecessrios, o problema que, dependendo do projeto, as metodologias
tradicionais podem deixar os desenvolvedores amarrados a requisitos desatualizados, fazendo
com que os sistemas em desenvolvimento sejam entregues aps o tempo especificado pelo o
cliente, ou at mesmo no concludos (CAETANO, 2009).
22
2.3 METODOLOGIA DE DESENVOLVIMENTO GIL
Esse modelo de desenvolvimento foi criado especificamente para apoiar a efetivao

de aplicaes de negcio, onde os requisitos de sistema so encontrados em uma constante
modificao.
(...) eles so mais adequados para o desenvolvimento de sistemas de
pequenas e mdias empresas e produtos para computadores pessoas. Eles
no so to adequados para o desenvolvimento de sistema de larga escala
com as equipes de desenvolvimento em lugares diferente e onde possa haver
interaes complexas com outros sistemas de hardware e software
(SOMMERVILLE, 2007).
Existe uma quantidade significativa de metodologias geis baseadas unicamente

em desenvolvimento incremental e interativo, contudo apresentam e compartilham um mesmo
conjunto de princpios (SOMMERVILLE, 2007):
Envolvimento do Cliente: O cliente tem uma participao ativa no processo de
desenvolvimento, tendo como papel fornecer e priorizar novos requisitos para
implementao do sistema;
Entrega Incremental: O software desenvolvido em incrementos, cada incremento
resultado de um conjunto de requisitos atribudos e priorizados pelo cliente;
Pessoas, no processos: Cada membro da equipe pode apresentar habilidades
diferentes que devem ser reconhecidas e exploradas de forma saudvel, fazendo os
mesmos trabalharem produtivamente e de forma confortvel;
Aceite as Mudanas: Projetar o sistema de software para possveis mudanas, j que
requisitos de sistema de software e principalmente de negcio esto numa constante
variao;
Manter Simplicidade: Procurar manter a concentrao no desenvolvimento de um
sistema de software simples, e trabalhar proativamente para eliminar s complexidades
que podem aparecer no processo de desenvolvimento.
23
2.4
MODELOS
DE DESENVOLVIMENTO APOIADORES DO
YP
(easyProcess)
2.4.1 Extreme Programming (XP)
2.4.1.1 Definio
O Extreme Programming (XP) um modelo de desenvolvimento gil de software

desenvolvido por Kent Back (Engenheiro de Software americano formado em M. S.
Licenciatura em Cincia da computao pela Universidade de Oregon) (GERVAZONI,
2005). Essa forma de construir software permite um grupo entre 2 a 10 programadores,
projetos de 1 36 meses de durao, de 1000 250 000 linhas de cdigo (FREIRE, 2003).
2.4.1.2 Princpio
O XP aborda os requisitos do sistema em cartes de histria, que por sua vez sero
subdivididos em tarefas menores para facilitao do desenvolvimento (MONTEIRO, 2009). O
desenvolvimento com XP leva em considerao alguns princpios bsicos ou prticas que
devem ser seguidos, a saber (KUHN e PALOMA, 2009):
Planejamento: O desenvolvimento realizado por semana o cliente juntamente com
os desenvolvedores se renem semanalmente para que sejam definidos os requisitos de
maior prioridade;
Pequenas Liberaes: As funcionalidades de maior prioridades so implementadas,
fazendo essas prioridades serem atribudas ao sistema como incrementos, sendo assim,
pequenas releases so atribudas constantemente ao sistema;
24
Metfora: Uma problemtica encontrada na aquisio de requisitos unicamente

entender o problema do cliente para ento se atribuir uma soluo, pensando nisso
apoiado o uso de metforas para que os membros da equipe possam compartilhar a
mesma linguagem tcnica;
Projeto Simples: Fazer a equipe de desenvolvimento manter o foto no
desenvolvimento de um sistema simples, por exemplo, se dado a um programador
para codificar um meio de acesso ao sistema com a senha 123456, desnecessrio o
programador elaborar um meio sofisticado, como acesso biomtrico;
Testes de Aceitao: So particularmente definidos pelo cliente juntamente com os
testadores, so essenciais para comprovar as funcionalidades de uma determinada
parte do sistema;
Ritmo Sustentvel: A equipe tem que procurar uma forma saudvel de trabalho, sem
exceder hora normal, o XP recomenda uma quantidade mxima de 40 horas
semanais, por exemplo, de segunda a sexta-feira com oito (8) horas por dia, voltando o
funcionrio na prxima segunda-feira, cheio de novas idias e muita motivao;
Posse Coletiva: O sistema visto como propriedade coletiva de cdigo, ou seja, todos
os membros da equipe podem fazer possveis mudanas ou incrementos no cdigo
produzido pelo um membro da equipe sem muitas dificuldades;
Programao em Pares: A programao de um cdigo realizado por duas pessoas
no mesmo computador enquanto uma pessoa digita o cdigo a outra vai instruindo,
essa tcnica ajuda a produzir cdigo sem ou com o mnimo de erros possveis, por
causa do refatoramento constante;
Padres de Codificao: Os cdigos devem ser redigidos seguindo a mesma
padronizao, isso permite aos programadores entender bem o que eles produzem;
Refatorao: Realizar um refinamento no sistema, eliminar cdigos e fontes repetidas,
deixando mais claro, enxutos, coesos e com a mesma funcionalidade;
Integrao Contnua: Como a programao realizada de forma incremental, tornase essencial adicionar uma nova funcionalidade a cada verso atribuda de forma
contnua at a finalizao do projeto.
25
2.4.2 Rational Unified Process (RUP)
2.4.2.1 Definio
O RUP (processo unificado racional) um modelo proprietrio de desenvolvimento de

software desenvolvido pela Rational Software Corporation e adquirido em fevereiro de 2003
pela atual pertencente IBM, apesar de ser considerada uma maneira de produzir software
pesada por algumas organizaes, uma das formas mais disciplinadas e usadas por grandes
equipes de desenvolvimento, considerada um modelo customizvel por causa de sua
adaptabilidade projetos de qualquer escala (MARTINESES, 2010).
2.4.2.2 Principio
A filosofia RUP pode ser melhor esclarecida ao analisarmos alguns de seus princpios
clssicos, a saber (TANAKA e BANKI, 2008):
Desenvolvimento iterativo: Intuitivamente no se d para desenvolver um software
em um nico passo, pois o sistema pode passar por constantes alteraes, questes
relacionadas a arquitetura, usurio, e at mesmo um maior entendimento do problema,
tudo isso amarrado a uma ou a conjunto de iteraes, que tem como principal foco
fazer refinamentos no projeto;
Gerenciamento de requisitos: Na prtica todo modelo de desenvolvimento de
software passa pelo levantamento de requisitos, no RUP no muito diferente,
entretanto, ele faz todo um gerenciamento de requisitos, tais como: anlise do
problema, definio problema, mudana de requisitos, escopo do problema, entre
outros;
Arquitetura baseada em componentes: Componentes so basicamente bibliotecas de
software j prontas, onde os desenvolvedores tm a nica funo de us-las e retirar o
26
maior aproveitamento possvel, promovendo de forma contnua a reusabilidade de

software;
Modelagem visual de software: O uso de UML (linguagem de modelagem unificada)
apoiada pelo RUP, definir toda a lgica de um problema em diagramas facilita muito
o seu entendimento, uma forma intuitiva de analisar o funcionamento do sistema,
abstraindo de forma simplificada o entendimento de um projeto complexo;
Qualidade de software: Foco na qualidade uma tarefa indispensvel para qualquer
modelo de desenvolvimento, no RUP no seria diferente, entretanto ele garante
qualidade em todo processo de desenvolvimento, fazendo com que as fases do ciclo de
vida sejam todas observadas por cada membro da equipe;
Alteraes no software: Em qualquer projeto mudanas so imprevisveis, vendo esse
tipo de problemtica o RUP apia o processo de planejamento direcionado a
mudanas, como: espao de trabalho seguro (forma de garantir a confiabilidade de um
sistema).
2.4.3 Agile Modeling (AM)
2.4.3.1 Definio
A princpio o Agile Modeling no uma metodologia de desenvolvimento como XP,

RUP, mas uma forma de modelagem que pode ser usada paralelamente a uma metodologia de
desenvolvimento tanto em carter gil como prescritiva. Caracteristicamente no definida
uma forma de modelagem especfica, apresenta como funo orientaes aos membros da
equipe para que sejam mais efetivos ao projeto.
(...) um conjunto de valores, princpios e prticas de modelagem de

software que pode ser aplicado em um projeto de desenvolvimento de
software em uma forma leve de peso eficaz (...) (AMBLER, 2009).
27
2.4.3.2 Princpios
Agile Modeling define uma coleo de princpios que devem ser levados em
considerao durante o processo desenvolvimento de software, logo abaixo alguns princpios:
(AMBLER, 2009):
Maximizar Stakeholder: uma abordagem que deve ser usada para manter os
investidores do projeto informados sobre o processo de construo do software, pois
os interessados no desenvolvimento investem muitos recursos, como: tempo, dinheiro,
entre outras questes relacionadas;
Comentrios rpidos: Cada ao atribuda a modelagem deve ser constituda
unicamente por intervalo de tempo mnimo destinados a possveis comentrios que
ajudam a produzir um feedback necessrio entre os membros da equipe;
Suponha simplicidade: No apresentar termos adicionais em seu sistema uma
questo importantssima, manter sempre simplicidade essencial no processo de
modelagem para uma maior coerncia do sistema;
Trabalho de Qualidade: As pessoas quando gostam do que fazem tendem a produzir
o melhor trabalho possvel, os membros da equipe tm que produzir modelos com
foco na qualidade que possam ser facilmente analisados e modificados por outras
pessoas.
2.4.3.3 Prticas
Agile Modeling define uma coleo de prticas que devem ser adotadas no processo
de desenvolvimento de software, a seguir algumas prticas (AMBLER, 2009):
Participao ativa dos interessados: Nesta categoria a construo de um site onde os
membros da equipe possam ver todo o andamento do projeto, como tambm
apresentar uma participao bem mais significativa;
Uso de ferramentas simples: Evitar o uso de ferramentas complexas o objetivo
principal desta categoria, boa parte dos modelos podem ser projetados at mesmo em
28
um pedao de papel, ento para qu desperdiar tempo em uma ferramenta

complicada;
Modelo em pequenos incrementos: Todo o problema de modelagem no
necessariamente resolvido de uma s vez, ento em um determinado perodo toda a
modelagem pode ser resolvida com a definio de incrementos;
Criar contedo simples: Torna-se essencial para os membros da equipe criarem seus
contedos o mais simples possvel, evitar incrementos desnecessrios, uma virtude
que a equipe deve seguir.
Sendo o easYProcess foco deste trabalho de concluso de curso (TCC), o mesmo ser
apresentado na prxima seo, onde abordado todos os processos de forma simples e
intuitiva, e que so consideradas indispensveis para efetivao de um componente de
software de qualidade.
29
3 EASY PROCESS (YP)
O easYProcess uma metodologia de desenvolvimento de software gil criada pelo

grupo PET2 da Universidade Federal de Campina Grande (UFCG), sendo idealizada pela
Professora Dr Francilene Procpio Garcia (SILVA, 2010). Est metodologia foi criada com o
intuito de auxiliar os alunos do curso de Cincia da Computao no desenvolvimento e
efetivao de seus projetos de software ofertados pelas disciplinas no decorre do ano letivo
(GARCIA, 2007).
O fluxo de trabalho do easYProcess, segundo Garcia (2007), so descritas logo
abaixo, (ver Figura 03).
Figura 03: Sntese do Fluxo do Processo YP
Fonte: Adaptado (GARCIA, 2007).

2
O Grupo PET (Programa de Educao Tutorial) do Curso de Graduao em Cincia da Computao da

Universidade Federal de Campina Grande (UFCG) foi criado em 1992. [Disponvel em:
<http://www.dsc.ufcg.edu.br/~pet/>. Acesso : 13/05/11]
30
3.1 DEFINIO DE PAPIS
O processo iniciado com a definio de papis (funo de uma pessoa no processo

de desenvolvimento), neste momento os participantes da equipe de desenvolvimento so
listados em uma tabela juntamente com suas habilidades que ajudaram no desenvolvimento
do projeto.
Segundo Garcia (2007) dependendo da quantidade de pessoas na equipe, ou
habilidades pertencentes a uma mesma pessoa, um nico membro poder desempenhar mais
de um papel paralelamente, e desta forma estruturando a melhor equipe possvel para se obter
uma maior produtividade no processo.
Segue a baixo os papis adotados pelo YP:
Gerente: Membro da equipe que gerencia o processo de desenvolvimento, analisa e
toma decises referentes ao andamento do projeto. Segundo Garcia (2007) as
competncias do Gerente so: conduzir os planejamentos e as aes dos
desenvolvedores, elaborar o plano de desenvolvimento, avaliar sistematicamente os
riscos descobertos, coletar e analisar mtricas, alocar testadores, presidir as reunies
de acompanhamento, resolver conflitos internos, tornar a documentao do projeto
sempre acessvel e atualizada;
Desenvolvedor: Membro da equipe responsvel pela efetivao dos requisitos em
cdigos executveis. De acordo com Garcia (2007) as competncias do Desenvolvedor
so: levantar os requisitos funcionais e no-funcionais, auxiliar o gerente na
elaborao de um plano de desenvolvimento, analisar e modelar a tarefa, gerar um
prottipo de interface, elaborar o projeto arquitetural, construir um modelo lgico de
dados;
Testador: Membro da equipe que efetiva a maioria dos testes do projeto, alm de
defini-los juntamente com o cliente. Afirma Garcia (2007), competncias do Testador
so: revisar o cdigo de outras pessoas, elaborar testes sobre o cdigo de outros
desenvolvedores, refatoramento de cdigo, gerar teste de aceitao e elaborar o
material para realizao dos testes de usabilidade;
31
Cliente: considerado membro da equipe por causa de sua participao efetiva no

projeto, quem adquire o sistema de software para solucionar um determinado
problema. Constata Garcia (2007) as competncias do Cliente so: definir os
requisitos do sistema, priorizar as funcionalidades, ajudar no plano de release,
identificar o perfil do usurio, identificar os objetivos de usabilidade, validar o
prottipo da interface, validar o projeto arquitetural, ser ativo no processo de
desenvolvimento;
Usurio(s): Tm participaes significativas no processo de desenvolvimento,
basicamente a pessoa para quem se destinar o produto de software. Segundo Garcia
(2007), competncias do Usurio so: ajudar a definir os testes de aceitao, ajudar a
identificar os objetivos de usabilidade, validar o prottipo da interface, avaliar a
interface do sistema.
32
3.2 CONVERSA COM O CLIENTE
Em seguida vem a conversa com o cliente, neste momento os desenvolvedores devem

extrair o mximo de informaes do cliente para que sejam produzidos todos os artefatos
necessrios e indispensveis a efetivao do projeto.
Afirma Garcia (2007), antes da conversa os desenvolvedores devem ter um
entendimento breve do problema para que possam elaborar um roteiro de perguntas eficientes
ao cliente. Durante a conversa deve-se usar termos simples para evitar complicaes, usar o
mximo de analogias quando necessrio, de forma a exemplificar o problema, deve-se
tambm deixar bem claro ao cliente a sua funo no processo.
3.2.1 Documento de viso
De acordo com Garcia (2007), os desenvolvedores elaboram um documento

especificando a descrio do sistema que ser produzido, esse documento deve apresentar de
forma geral e objetiva, o que o sistema se prope a fazer para solucionar o problema do
cliente.
3.2.2 Requisitos
Os requisitos um conjunto de especificaes referentes ao projeto a ser

desenvolvido, ou seja, so todas as funes e caractersticas que o sistema dever apresentar
depois de finalizado. Destacando basicamente duas categorias de requisitos, os funcionais que
so responsveis por todas as funes que sistema dever apresentar para efetivao das
atividades administrativas, e no funcionais que so responsveis por todas as caractersticas
que o sistema dever apresentar (GARCIA, 2007).
33
3.2.3 Perfil do Usurio
Trata-se de uma lista de informaes provenientes das caractersticas do usurio, essas

informaes so consideradas indispensveis para elaborao do projeto. Segundo Garcia
(2007), o YP afirma as seguintes caractersticas:
Sexo;
Se canhoto, destro ou ambidestro;
Faixa etria;
Experincia prvia no uso de sistemas computacionais;
Etc.
3.2.4 Objetivos de Usabilidade
De acordo com Garcia (2007), o sistema depois de finalizado deve apresentar as

especificaes, a saber:
Eficcia;
Eficincia;
Segurana;
Memorizao.
34
3.3
INICIALIZAO
Este processo permite que os membros da equipe possam ver o futuro sistema em
diversos aspectos, a saber: Modelo de tarefa, Prottipo de interface, User Stories e Testes de
aceitao, Projeto arquitetural, Modelo lgico de dados. De acordo com Garcia (2007):
investir tempo aqui muito importante, pois quanto maior for o entendimento do sistema,
menos problema se ter na etapa de implementao.
3.3.1 Modelo de Tarefa
uma representao grfica de como as tarefa sero realizadas, a anlise da tarefa

permite aos desenvolvedores terem maior compreenso de como o usurio ir interagir com a
interface do sistema, ajudar tambm na elaborao do prottipo da interface. Afirma Garcia
(2007): O modelo de tarefa pode ser construdo de acordo com vrios formalismos, no
entanto, o YP sugere o uso do TAOS3.
3.3.2 User Stories e Teste de Aceitao
So os requisitos do cliente definidos de forma mais especifica, a cada User Story

alocado pelo menos um Teste de Aceitao (condio mnima da funcionalidade definida pelo
cliente), so listadas pelo cliente com orientao dos desenvolvedores, e estruturadas na tabela
em ordem de priorizao, quando uma User Story muito grande dividida em partes
menores para facilitar o processo de implementao (GARCIA, 2007).
3.3.3 Prottipo da Interface

3
Task and Action Oriented System uma ferramenta CASE para ajudar na arquitetura do sistema.
35
uma representao grfica da interface do sistema que permite aos membros da

equipe se comunicarem em uma linguagem comum, nesta etapa a interface no precisa ser
funcional. Especifica Garcia (2007): a construo de um esboo de interfaces simples que
possam ser produzidas com baixo custo de investimento, facilita maior entendimento entre a
interao de sistema e usurio.
3.3.4 Projeto Arquitetural
De acordo com Garcia (2007), a forma de visualizar o sistema em um alto nvel de

abstrao sendo til quando se deseja explicar o funcionamento entre as partes do sistema,
essencial que esse artefato seja gerado em forma de diagrama para facilitar o entendimento
dos membros da equipe, ao se concluir o artefato ele deve mostrar a estrutura do sistema e
relacionamento existente entre seus mdulos.
3.3.5 Modelo Lgico de Dados
Trata-se unicamente da modelagem de entidades referentes ao problema especfico,

caso o sistema a ser desenvolvido necessite de uma forma de guardar e manipular
informaes.
36
3.4 PLANEJAMENTO
o cronograma de todas as atividades que sero realizadas no processo de

implementao, sabendo-se da estimativa de tempo necessria para a concluso do projeto, os
nmeros de Releases e Iteraes devem ser especificados pelos membros da equipe. Segundo
Garcia (2007): A fase de planejamento composta por dois planejamentos, o de Release e o
de Iterao, no qual existem 3 releases, cada qual contendo 2 iteraes de 2 semanas cada.
No planejamento, o plano de release formado basicamente por iteraes, onde cada
iterao constituda por um conjunto de User Stories priorizadas pelo cliente na fase de
inicializao; no plano de iterao as User Stories se necessria so divididas em atividades
menores para facilitar o processo de implementao, e alocadas a cada membro da equipe de
acordo com suas habilidades para efetivao da mesma (GARCIA, 2007).
37
3.5 IMPLEMENTAO
a codificao das atividades presentes na iterao, para se ter um bom processo de

implementao os desenvolvedores devem seguir algumas prticas, a saber: Integrao
contnua, Boas prticas de codificao, Propriedade coletiva de cdigo, Testes e Pequenos
releases (GARCIA, 2007).
3.5.1 Integrao continua
Tem como objetivo facilitar o gerenciamento do projeto e o trabalho dos

desenvolvedores, em relao ao gerenciamento do projeto essa prtica auxilia na coleta de
mtricas, como tambm na elaborao do Big Chart (tabela de informaes sobre o processo
de desenvolvimento, em relao aos desenvolvedores essa prtica bem observada quando os
mesmos no possuem horrios de trabalho em comum.
Cada cdigo produzido e testado deve ser integrado continuamente ao sistema como
parte de um todo, o easYProcess recomenda o uso de algumas ferramentas no auxilio da
integrao contnua, a saber: CruiseControl4, Apache Gump5.
3.5.2 Boas Prticas de Codificao
De acordo com Garcia (2007), os membros da equipe de desenvolvimento devem ter

em mente a idia de cdigo limpo e principalmente de fcil entendimento, para tal o YP adota
o seguinte conjunto de prticas, a saber:
4
tanto uma ferramenta de integrao contnua e um framework extensvel para a criao de um contnuo
processo de compilao personalizada. [CruiseControl]
5
Constri e compila software contra as ltimas verses de desenvolvimento desses projetos. [Apache Gump]
38
Design Simples: O cdigo deve apresentar um fcil entendimento, ser alto-explicativo,

com uso de comentrios apenas essenciais;
Padres de Codificao: Ajudam na estruturao do cdigo de forma visual
possibilitando um maior entendimento por parte dos desenvolvedores. Por exemplo: a
forma de posicionamento dos parnteses, o meio de nomear variveis e mtodos,
formam um padro de codificao aceitvel entre os membros da equipe;
Padres de Projeto: Consiste no uso de solues computacionais previamente
elaboradas e testadas por grande projetistas, o uso de padres faz com que os membros
da equipe ganhem tempo no desenvolvimento, e consequentemente eficincia e
qualidade no projeto;
Refatoramento: basicamente uma modificao em determinada parte do cdigo do
sistema, essa modificao no pode alterar o comportamento funcional, entretanto so
apresentadas modificaes significativas em termos no funcionais, a saber:
simplicidade, flexibilidade, clareza do cdigo.
3.5.3 Propriedade Coletiva de Cdigo
Essa prtica uma forma de melhoramento contnuo de cdigo, que visto como uma
propriedade coletiva, ou seja, de todos os membros da equipe, isso significa que um membro
da equipe de desenvolvimento pode alterar e acrescentar o cdigo produzido por outro
membro sem muitas dificuldades.
3.5.4 Testes
De acordo com Garcia (2007), o YP recomenda o uso de trs tipos de testes, a saber:
Testes de Unidade: uma categoria de teste indispensvel para um bom
funcionamento do cdigo interno, esse tipo de teste analisa a estrutura interna do
cdigo, ou seja, tanto a parte lgica e o fluxo de dados;
39
Testes de Aceitao: So indispensveis no processo de elaborao das User Stories, o

YP recomenda pelo menos um teste de aceitao para cada User Story, a principal
caracterstica desse tipo de teste ele ser atribudo pelo cliente, que por sua vez
orientado pela equipe de desenvolvimento;
Teste de Usabilidade: Essa categoria de teste executada em duas etapas, na primeira
o usurio submetido ao sistema produzido com um questionrio de atividades
referentes s funes que o sistema deve cumprir, na segunda etapa aplicado outro
questionrio, sendo este referente satisfao subjetiva do usurio.
3.5.5 Pequenos Releases
O YP recomenda a alocao dos requisitos em pequenos releases para que se tenha uma
maior facilidade no processo de implementao, o ideal que cada release seja constituda de
duas iteraes e estas com conjunto de User Stories (GARCIA, 2007).
40
3.6 REUNIO DE ACOMPANHAMENTO
Sendo organizadas uma vez por semana pelo gerente as reunies de acompanhamento
tem como objetivo analisar sistematicamente o andamento do projeto. Um gerente
comprometido com o projeto nessas reunies pode identificar previamente falhas no processo
de desenvolvimento e promover junto equipe possveis solues. Segundo o Garcia (2007),
toda equipe de desenvolvimento deve participar das reunies semanais, pois a mesma se dar
em torno do material produzido no processo de desenvolvimento, assegurando as atividades a
seguir:
Big Chart: Constitui em uma tabela com informaes para anlise quantitativa do
projeto;
Tabela de Alocao de Atividade (TAA): Constitui em uma tabela com informaes
referentes s atividades realizadas pelos membros da equipe;
Anlise de Risco: Consiste em todos os empecilhos encontrados no processo de
desenvolvimento que podem prejudicar significativamente o produto final de software;
Mudana: So possveis alteraes, existe vrios tipos: as que exigem modificaes de
implementaes, no modelo de tarefa, no projeto arquitetural, no modelo lgico de
dados, nas User Stories, na Interface, na modificao de membros da equipe, at
mesmo no documento de viso.
Esta seo apresentou uma abordagem metodologia referente ao modelo de
desenvolvimento gil em questo, visando ao leitor conhecimento especifico para prxima
seo, onde usado na prtica o uso dessa metodologia.
41
4 SYS VENDA E YP (easYProcess)
Nesta seo abordado o desenvolvimento de um sistema para controle de vendas de

produtos (SysVenda), com auxilio de um modelo de desenvolvimento gil (easYProcess).
4.1 DEFINIO DE PAPIS
Lembrando que este projeto trata-se de um trabalho de concluso de curso (TCC), um

nico membro desempenha os papis referentes a uma equipe de desenvolvimento, (ver
Quadro 01).
Quadro 01: Definio de papis
Equipe
Elder G. Pereira
Papis
Gerente, desenvolvedor, testador, cliente e
usurio.
Fonte: Autor da Pesquisa, 2011
O prprio YP afirma que um mesmo integrante da equipe pode desempenhar mais de

um papel (funo) simultaneamente, mas que tambm no abre mo de uma boa equipe no
processo de desenvolvimento.
42
4.2 CONVERSA COM O CLIENTE
Depois da primeira conversa com o cliente os desenvolvedores elaboram uma srie de

artefatos essenciais para o andamento do projeto, a saber: Documento de viso (descrio do
sistema a ser produzido); Requisitos funcionais e no funcionais; Perfil do usurio e Objetivos
de usabilidade.
4.2.1 Documento de viso
A proposta o desenvolvimento de um sistema para a manipulao de informaes de

uma determinada empresa de vendas de produtos, o SysVenda ser um sistema de informao
desenvolvido para funes especificas e indispensveis na manipulao de funcionrios,
clientes, fornecedores, vendas, produtos, entre outros recursos auxiliares no processo
administrativo.
Para a efetivao do funcionamento do SysVenda, torna-se necessrio que o mesmo
seja projetado em arquitetura WEB, onde funcionrios da empresa podero desempenhar
funes administrativas sem necessariamente ter o sistema instalado nas suas maquinas.
4.2.2 Requisitos
Depois da conversa com o cliente os desenvolvedores j devem ter em mente uma

idia inicial sobre o sistema que ser produzido, neste momento gerado os requisitos
funcionais e no funcionais do sistema.
Requisitos Funcionais:
Controle de venda;
Cadastro de cliente, fornecedor, funcionrio e produto;
43
Editar cliente, fornecedor, funcionrio e produto;

Listar cliente, fornecedor, funcionrio e produto;
Confirmao de venda;
Grfico para controle de venda.
Requisitos no-funcionais
Interface WEB (JSP + JSF + HTML);
Tratando-se de sistema de informao torna-se indispensvel, segurana com LOGIN;
Confiabilidade;
Integridade;
Componentes RichFaces;
Componente para persistncia de dados usando o HIBERNATE;
Padres de projeto (DAO e MVC).
4.2.3 Perfil do Usurio
Usurios de baixo nvel de conhecimento em informtica, mas que podem demonstrar

muita capacidade de aprendizagem no uso do sistema, visto que a interface (interao homem
maquina) ser projetada de forma intuitiva, analisando essa perspectiva disponibilizao de
um treinamento torna-se indispensvel para os usurios se familiarizarem com as funes do
SysVenda.
4.2.4 Objetivo de Usabilidade

A seguir so apresentados os objetivos usuais que o sistema deve alcanar, (ver
Quadro 02).
Quadro 02: Objetivo de usabilidade
OBJETIVO
Aumentar nvel de segurana.
MENSURAO
Tornar as informaes
do
processo
44
administrativo longe de pessoas no

autorizadas.
Eficincia para controle de informaes.
Processo administrativo amigvel, para o
cadastro,
listagem
e
edio
de
informaes.
Aumento de produtividade das vendas.
Realizao e confirmao de venda, de
forma intuitiva.
Possuir uma Interface simples.
Assegurar ao usurio maior compreenso
na identificao de componentes na
interface.
Garantir a validao dos campos da Fazer as informaes na interface ter um
Interface.
valor significativo.
Manter a estrutura do sistema de forma Usar termos referentes ao tipo de processo
clara.
administrativo da equipe de usurios.
Este item importante para todos os membros da equipe de desenvolvimento

tentarem manter a fidelidade na construo do sistema, e para que no percam o foco no que o
sistema deve apresentar na sua fase final.
45
4.3 INICIALIZAO
4.3.1 USER STORIES (histrias de usurio) e TESTE DE ACEITAO
A seguir ser mostrado todos os requisitos funcionais de forma mais especifica a

serem implementados, so listados e especificados com uma estimativa de tempo inicial para
cada User Store (histria de usurio), e estruturados no quadro em ordem de priorizao de
implementao, indispensvel frisar que para cada histria de usurio definido pelo menos
um teste de aceitao que devem ser todos indicados, analisados e aprovados pelo cliente,
com orientao dos desenvolvedores e testadores (ver Quadro 03).
Quadro 03: User Stories
US01
TA1.1
US02
TA2.1
TA2.2
TA2.3
TA2.4
US03
TA3.1
TA3.2
TA3.3
TA3.4
TA3.5
TA3.6
TA3.7
US04
Ampliar conhecimento nas seguintes tecnologias, a saber: JSF, Rich Faces,

MySql, JFreeChart, HIBERNATE, MVC, DAO Genrico.
Estimativa Inicial: 20 h
Elaborar exemplos referentes s tecnologias citadas, efetivando maior
conhecimento prtico.
Implementar os modelos de classes referentes as entidades do sistema, e a classe
DAOGenerica responsvel para operaes CRUD do sistema.
Configurao da plataforma de desenvolvimento, com todos os plugins
indispensveis para a efetivao do sistema.
Confirmar as classes necessrias na camada de modelo.
Confirma classe responsvel pelas operaes CRUD.
Verificao de todas as bibliotecas necessrias, para uso das tecnologias.
Implementar modulo de venda.
Verificar se o cliente est sendo disponibilizado como opo.
Verificar se funcionrio estar sendo disponibilizado como opo.
Verificar se o produto est sendo disponibilizado como opo.
Realizar venda com todos os campos (operao com sucesso).
Realizar venda sem todos os campos (operao no realizada).
Testar o campo Unidade para que liste a quantidade de produto em estoque.
Verificar se o produto selecionado est disponibilizando a quantidade certa em
estoque, e realizando o clculo correto.
Implementar listas de todas as vendas no pagas, com aes para confirmar ,
desfazer venda.
46
TA4.1
TA4.2
TA4.3
TA4.4
US05
Verificar se est listando todas as vendas no pagas.

Testar opo de confirmao de vendas (confirmao em nova janela).
Testar o desfazer de venda (ao realizada com sucesso)
Verificar se o grfico gerado est de acordo com as vendas pagas e pendentes.
Implementar o cadastro de fornecedor.
TA5.1 Cadastro de um fornecedor com todos os campos (operao com sucesso).
TA5.2 Cadastro de fornecedor apenas com os campos obrigatrios (operao com
sucesso).
TA5.3 Cadastro de fornecedor faltando um campo obrigatrio (operao no realizada).
TA5.4 Cadastro de fornecedor faltando todos os campos obrigatrios (operao no
realizada).
US06 Implementar o cadastro de produto.
TA6.1
TA6.2
TA6.3
TA6.4
US07
TA7.1
TA7.2
TA7.3
TA7.4
US08
TA8.1
TA8.2
TA8.3
TA8.4
US09
TA9.1
TA9.2
TA9.3
US10
Verificar se o fornecedor est sendo disponibilizado como opo.
Cadastro de um produto com todos os campos (operao com sucesso).
Cadastro de um produto com campos obrigatrios (operao com sucesso).
Cadastro de um produto sem os campos obrigatrios (operao no realizada).
Implementar o cadastro de cliente.
Cadastro de um cliente com todos os campos (operao com sucesso).
Cadastro de cliente apenas com os campos obrigatrios (operao com sucesso).
Cadastro de cliente faltando um campo obrigatrio (operao no realizada).
Cadastro de cliente faltando todos os campos obrigatrios (operao no
realizada).
Implementar o cadastro de funcionrio.
Cadastro de um funcionrio com todos os campos (operao com sucesso).
Cadastro de funcionrio apenas com os campos obrigatrios (operao com
sucesso).
Cadastro de funcionrio faltando um campo obrigatrio (operao no realizada).
Cadastro de funcionrio faltando todos os campos obrigatrios (operao no
realizada).
Implementar funcionalidade para listas de: cliente, funcionrio, fornecedor e
produto.
No mdulo busca de cliente por nome (cliente retornado com sucesso).
No mdulo busca de funcionrio por nome (funcionrio retornado com sucesso).
No mdulo busca de fornecedor por nome (fornecedor retornado com sucesso).
Implementar funcionalidade de alterao, nos tipos de lista.
47
TA10.1
TA10.2
TA10.3
TA10.4
US11
Editar cadastro com todos os campos (cadastro realizado com sucesso).

Editar cadastro faltando os campos obrigatrios (cadastro no realizado).
Editar cadastro faltando qualquer campo obrigatrio (cadastro no realizado).
Verificar modificao do boto confirmar para o boto voltar.
Implementar funcionalidade para autenticao de usurios.
TA11.1 Entrar no sistema a partir de login valido (autenticao realizada).
TA11.2 Entrar no sistema a partir de login invalido (autenticao no realizada).
4.3.2 PROTTIPO DA INTERFACE
O easYProcess recomenda um prottipo inicial das interfaces do sistema a ser

desenvolvido para que os membros da equipe tenha um maior entendimento de como se dar
a interao entre usurio e sistema, e tambm abordar umas idias de design antes de gerar as
interfaces executveis, logo abaixo so apresentadas as telas iniciais do sistema a ser
desenvolvido (ver Figura 04, Figura 05, ver Figura 06 e Figura 07).
Figura 04: Cadastro de Produto
48
Figura 05: Venda de Produto
Figura 06: Lista de Produto
Figura 07: Confirmao de Venda
49
O YP que as interfaces devem ser geradas da forma mais simples possvel, ou seja,
sem uso de ferramentas complexas.
4.3.3 PROJETO ARQUITETURAL
Figura 08: Modelo Arquitetural
50
O software ser produzido a partir de tecnologias WEB Abertas (Open Source), onde
os desenvolvedores podem consegui l sem nenhum custo. A arquitetura baseada com
componentes JSF que por padronizao apia o padro de projeto MVC (model, view and
controller), o cliente ao fazer suas requisies ao servidor, induz a camada de controle
redirecionar uma chamada para a camada de modelo que, por sua vez envia uma resposta ao
cliente na camada de apresentao com intermdio da camada de controle (ver Figura 08).
Para SGBD (sistema de gerenciamento de banco de dados) foi escolhido o MySQL,
um dos mais usados banco de dados na WEB, isso devido: desempenho, portabilidade,
facilidade de uso, exige pouco recurso de hardware, segurana, entre outros requisitos
necessrios para um padro de usabilidade.
4.3.4 MODELO RELACIONAL
Figura 09: Modelo Relacional
51
Ao se tratar de manipulao de registros referentes a uma boa administrao da

empresa do cliente, torna-se indispensvel um modelo relacional, ento para o problema do
cliente definido uma base de dados com seis (6) entidades: temos a tabela Pessoa que
extensvel para as tabelas Cliente, Funcionrio e Fornecedor; tem a tabela Produto atribuda
pelos fornecedores; tem tabela Vendas que faz uma venda para um Cliente de um conjunto de
produto por um determinado Funcionrio do plano de negocio do cliente (ver Figura 09).
52
4.4
PLANEJAMENTO
Depois do artefato de Inicializao ter sido finalizado e aprovado pelo cliente com as
especificaes necessrias para o andamento do projeto, parte-se para as fases seguintes, o
Plano de Releases e Iterao. relevante salientar que os perodos definidos nestes so de
tempo fixo, ou seja, o projeto pode passar por grandes modificaes, mas os tempos definidos
nos mesmos devem permanecer constantes, isso ajuda a manter credibilidade com cliente.
4.4.1 MATRIZ DE COMPETNCIA

Na elaborao das Iteraes recomendado uso da Matriz de Competncia (quadro
para especificar as capacidades profissionais dos membros da equipe), para alocar os
membros da equipe nas atividades que requerem especificaes profissionais adequadas em
uma determinada atividade (ver Quadro 04).
Quadro 04: Matriz de Competncia
Equipe
Elder G. Pereira
Competncia
Java, JSP, JSF, PHP, HTML, MySQL, JavaScript,
Hibernate Annotation.
4.4.2 PLANO DE RELEASES
As Releases so preenchidas a partir de uma subseo do artefato de Inicializao

(User Story), um conjunto destas so alocadas dentro das Iteraes, e estas dentro de uma
Release, o YP recomenda nas Releases duas Iteraes de duas semanas cada, isso levando em
considerao uma disciplina de perodo letivo de um curso, mas que no precisa

53
necessariamente seguir essa recomendao quando adotado no ramo comercial, a seguir so

apresentadas as Releases (ver Quadro 05, Quadro 06, Quadro 07).
Quadro 05: Plano de Release 01
Release 01:
01/03/11 20/03/11
Iterao
Iterao 01
Iterao 02
Gerente Elder Gonalves Pereira

User Story
US01
US02, US03
Perodo
01/03/11 15/03/11
16/03/11 30/03/11
Release 02:
21/03/11 12/04/11
Iterao
Iterao 03
Iterao 04
User Story
US04, US05
US06, US07
Perodo
01/04/11 15/04/11
16/04/11 30/04/11
Release 03:
13/04/11 20/05/11
Iterao
Iterao 05
Iterao 06
User Story
US08, US09
US10, US11
Perodo
01/05/11 15/05/11
16/05/11 30/05/11
4.4.3 PLANO DE ITERAO
Cada User Story alocada em uma Iterao apresenta uma definio de problema a ser
solucionada, so listadas em um plano de Iterao e divididas em um conjunto de atividades,
54
estas so direcionadas a cada desenvolvedor para solucionar o problema, especificado uma

Estimativa de Tempo para o termino da atividade, ao termino da atividade o desenvolvedor
conclui o Tempo Real gasto, e o STATUS (se a atividade foi ou no concluda).
Quadro 08: Plano de Iterao 02
Iterao 02 - 16/03/11 30/03/11

US02 - Implementar os modelos de classe referente as entidades do sistema, e a
classe DAOGenerica responsvel para operaes CRUD do sistema.
Testes de Aceitao
TA2.1
Configurao da plataforma de desenvolvimento, com todos os
TA2.2
TA2.3
TA2.4
TAA 01
A2.1
A2.2
A2.3
A2.4
A2.5
plugins indispensveis para a efetivao do sistema.

Verificao de todas as bibliotecas necessrias, para uso das
tecnologias.
Descrio
Responsvel
Configurao das
bibliotecas necessrias
no Eclipse.
Gerar as classes
entidades com
tecnologia Hibernate,
indispensveis para
mapeamento com o
banco.
Criar classe geradora
de tabela.
Criao de DAO
Genrico para
operaes CRUD, com
tecnologia Hibernate.
Criar classe teste para
por em prova o DAO
Genrio.
ELDER
Estimativa
de Tempo
(Horas)
1
ELDER
ELDER
ELDER
ELDER
Tempo
Real
(Horas)
US03 - Implementar modulo de venda.

Teste de Aceitao
TA3.1
TA3.2
Verificar se funcionrio estar sendo disponibilizado como
TA3.3
TA3.4
TA3.5
TA3.6
STATUS
STATUS
STATUS
opo.
Testar o campo Unidade para que liste a quantidade de produto
em estoque.
55
Verificar se o produto selecionado est disponibilizando a

quantidade certa em estoque, e realizando o clculo correto.
TA3.7
Atividade
A3.1
A3.2
A3.3
A3.4
A3.5
A3.6
A3.7
Descrio
Responsvel
Criao da interface
do mdulo de venda.
Criar os Beans
responsveis pelo
mapeamento das
informaes.
Criar mtodo para
listar os clientes na
interface.
Criar mtodo para
listar os funcionrios
na interface.
Criar mtodo para
listar os produtos na
interface.
Criar mtodo para
fazer o calculo do
valor da venda, aps
selecionar o produto
e unidades.
Mtodo para realizar
a efetivao do
cadastro, e o
cancelamento do
mesmo.
ELDER
Estimativa
de Tempo
(Horas)
1
ELDER
ELDER
ELDER
ELDER
ELDER
ELDER
Tempo
Real
(Horas)
STATUS
Percebe-se que nesse momento o Tempo Real gasto no desenvolvimento e STUTUS

(se atividade foi ou no concluda), ainda permanecem sem preenchimento, isso devido no
ter ocorrido implementao de cdigo (ver Quadro 08).
56
4.5 IMPLEMENTAO
Depois da Iterao ter sido definida parte-se para o processo de implementao, neste
momento a codificao iniciada, lembrando que para tal o YP recomenda o uso de
Integrao Contnua, Boas Prticas de Codificao, Propriedade coletiva de Cdigo (se existe
mais de um membro na equipe).
Segue-se o Plano de Iterao 02, as atividades referentes US02 geram a estrutura
base do sistema (ver Apndice A), depois as atividades referentes US03 geram o modulo de
venda do sistema (ver Apndice B). Com base no cdigo produzido, o mesmo submetido a
uma maratona de testes, primeiro Testes de Unidade (referentes estrutura interna do cdigo),
depois Testes de Aceitado (definidos pelo cliente), e Testes de Usabilidade (ver Apndice C).
4.5.1 FERRAMENTAS E TECNOLOGIAS
4.5.1.1 Java
Java uma linguagem de programao orientada a objetos criada pela Sun

Microsystems que atualmente foi incorporada pela Oracle Corporation. Sendo uma
linguagem de programao de referencia no mundo, devido sua: versatilidade, eficincia,
segurana, robusta e, o mais importante dos fatores, a portabilidade entre plataformas. Muito
diferentemente das linguagens convencionais, que so compiladas para cdigo nativo,
enquanto a linguagem Java compilada para um bytecode e executada por uma mquina
virtual.
4.5.1.2 Apache Tomcat
57
Apache
Tomcat
um
servidor
web desenvolvido
pela Apache
Software
Foundation (ASF), essa tecnologia implementa cmo JavaServer Pages (JSP) e Java Servlet
que atualmente so especificaes da Oracle Corporation, tendo como finalidade fornecer
um servidor web para aplicaes Java.
4.5.1.3 JSF
JavaServer Faces (JSF) uma tecnologia para desenvolvimento web baseada em

linguagem de programao Java, sendo um padro de desenvolvimento para fornecedores de
ferramentas criarem produtos que valorizem a produtividade no desenvolvimento de
interfaces visuais. JSF baseado no padro de projeto MVC (modelo, viso e controle), com
separao bem definida entre as camadas e regras de negcio.
4.5.1.4 Framework RichFaces
RichFaces uma biblioteca de componentes JSF open source (gratuita), que

disponibiliza uma variedade de componentes visuais e, sendo tambm um framework capaz
de tornar aplicaes web capazes de trabalhar com AJAX (Asynchronous Java Script and
XML) tcnica essa usada para criar aplicaes web mais interativas.
4.5.1.5 MySQL
O MySQL atualmente um dos SGBD (sistema de gerenciamento de banco de dados)
mais populares na WEB, apresenta algumas caractersticas importantssimas, como:
portabilidade, compatibilidade com drivers externos (JDBC uma API JAVA responsvel
pela comunicao entre MySQL e linguagem JAVA), suporte a controle transacionais, dentre
outras funcionalidades.
58
4.5.1.6 Hirbernate
O Hibernate um framework para o mapeamento objeto-relacional, esta tecnologia
facilita o mapeamento dos atributos de uma Classe Java em tabelas numa base de dados, a
partir de arquivos XML.
4.5.1.7 DAO
O DAO (data acess objecto) foi projetado para persistncia de dados em aplicaes
que utilizem banco de dados relacional, no desenvolvimento do SysVenda foi implementado
esse padro, sendo o principal papel do DAO no software consultar, alterar, inserir e excluir
dados, operaes estas indispensveis para manipulao dos registros.
4.5.1.8 MVC
Model, view and controller (modelo, viso e controle) um padro arquitetural para
criao de software que tem como objetivo a separao das camadas de controle, apresentao
e modelo. Por exemplo: um cliente faz uma requisio na camada de apresentao, que
conseqentemente faz a camada de controle direcionar essa requisio a camada de modelo, e
depois o acontecimento inverso deste processo at apresentao dos dados ao cliente.
59
4.6 REUNIO DE ACOMPANHAMENTO
As reunies segundo o YP devem acontecer uma vez a cada semana, neste momento
se a finalizao de uma iterao coincidir junto a reunio os mdulos do sistema produzidos
devem ser integrados, deve ocorrer tambm a coleta de mtricas por parte do Gerente para
atualizao do Big Chart, a finalizao do preenchimento da TAA (tabela de alocao de
atividades) e a indicao de possveis riscos no projeto se existir.
4.6.1 BIG CHART

A seguir o gerente faz a coleta de mtricas para possibilitar uma maior compreenso
no andamento do projeto, tais como: Classes Criadas, Teste de Aceitao realizados, Teste de
Unidade, entre outras, (ver Quadro 09).
Quadro 09: Big Chat
Perodo de Iterao
CC
TA
TU
PJ
US
01/03/11 15/03/11
16/03/11 30/03/11
10
24
Observao
Sem implementao de cdigo,
devido estudo das tecnologias.
Prxima Iterao Aqui

CC => Classes Criadas; TA => Teste de Aceitao; TU=> Teste de Unidade

PJ => Pginas JSF; US => User Story
4.6.2 TAA (tabela de alocao de atividades)
60
Ao fazer a coleta de mtricas (informaes) o campo de STATUS referentes as

atividades so preenchidas, nesta Iterao todas as atividades foram finalizadas como
concludas, mas em outros casos elas poderiam ter sido finalizadas como: em
desenvolvimento (neste caso as atividades seriam alocadas para prxima iterao) ou
abortadas. O Tempo Real do desenvolvimento das atividades atualizado, e por ltimo o
STATUS do Teste de Aceitao (ver Quadro 10).
Quadro 10: Plano de Iterao 02
Iterao 02 - 16/03/11 30/03/11

US02 - Implementar os modelos de classe referente as entidades do sistema, e a
classe DAOGenerica responssvel para operaes CRUD do sistema.
Testes de Aceitao
TA2.1
Configurao da plataforma de desenvolvimento, com todos os
TA2.2
TA2.3
TA2.4
TAA 01
A2.1
A2.2
A2.3
A2.4
A2.5
plugins indispensveis para a efetivao do sistema.

Verificao de todas as bibliotecas necessrias, para uso das
tecnologias.
Descrio
Responsvel
Configurao das
bibliotecas necessrias no
Eclipse.
Gerar as classes entidades
com tecnologia Hibernate,
indispensveis para
mapeamento com o banco.
Criar classe geradora de
tabela.
Criao de DAO Genrico
para operaes CRUD, com
tecnologia Hibernate.
Criar classe teste para por
em prova o DAO Genrio.
C
C
C
C
Tempo
Real
(Horas)
1
STATUS
ELDER
Estimativa
de Tempo
(Horas)
1
ELDER
ELDER
ELDER
4,5
ELDER
US03 - Implementao do modulo de venda.

Testes de Aceitao
TA3.1
TA3.2
TA3.3
TA3.4
TA3.5
TA3.6
STATUS

Verificar se funcionrio estar sendo disponibilizado como opo.
Testar o campo Unidade para que liste a quantidade de produto em
estoque.
STAT
US
C
C
C
C
C
C
61
Verificar se o produto selecionado est disponibilizando a

quantidade certa em estoque, e realizando o clculo correto.
TA3.7
Atividad
e
A3.1
A3.2
A3.3
A3.4
A3.5
A3.6
A3.7
Descrio
Responsvel
Tempo
Real
(Horas)
1
STAT
US
ELDER
Estimativa
de Tempo
(Horas)
1
Criao da interface do
mdulo de venda.
Criar os Beans responsvel
pelo mapeamento das
informaes.
Criar mtodo para listar os
cliente na interface.
funcionrios na interface.
produtos na interface.
Criar mtodo para fazer o
calculo do valor da venda ao
selecionar o produto e
unidades.
Implementar forma de
efetivar o cadastro, e
cancelar o cadastro.
ELDER
ELDER
1,5
ELDER
1,5
ELDER
1,5
ELDER
ELDER
Status: C = concludo, D = desenvolvimento, A = abortado.
indispensvel presena do cliente na reunio e demais membros, pois o primeiro

responsvel pela aprovao das atividades finalizadas pelos desenvolvedores, e segundo pelas
informaes referentes sobre suas produes durante a semana.
4.6.3 ANALISE DE RISCO
Lembrando-se que riscos so empecilhos na efetivao do desenvolvimento do

projeto, e que estes devem ser identificados, analisados e superados o mais rpido possvel.
Quadro 11: Risco

Data
16/03/11
30/03/11
Risco
Tecnologia
desconhecida
Prioridade
Alta
Responsvel
Elder
Status
Superado
Providencia/Soluo
Adquirir
conhecimento bsico
62
16/03/11
30/03/11
16/03/11
30/03/11
RichFaces
Tecnologia
desconhecida
Hibernate
Tecnologia
desconhecida
JFreeChar
Alta
Elder
Vigente
Baixa
Elder
Abortado
no assunto.
Adquirir
conhecimento mais
abrangente.
Adquirir
conhecimento bsico
no assunto, se o
projeto requerer
grficos.
Prioridade: Alta, Mdia e Baixa.

Status: Vigente, Superado e Abortado.
Ao inicio do projeto foram previamente identificados alguns riscos, o primeiro foi

superado, no segundo o desenvolvedor conseguiu abstrair conhecimento necessrio para
finalizar o projeto, e o terceiro foi considerado aquisio de conhecimento desnecessrio,
sendo ento abortado. Mas que ainda pode ser levando em considerao dependendo da
necessidade do cliente (ver Quadro 11).
A partir desse ponto os processos referentes s sees 4.4 4.6 so repetidas at a
finalizao de todas as Iteraes alocadas nas Releases. Dependendo do encaminhamento do
projeto se o mesmo necessitar de modificaes outras sesses podero ser alteradas, o projeto
ser dito finalizado depois da aprovao e satisfao do cliente.
63
5 CONSIDERAES FINAIS
Nesta seo, ser apresentado o processo conclusivo desta pesquisa, identificando

todos os passos do trabalho, anlise, relacionamento e prova de finalizao dos objetivos.
O TCC em questo propiciou uma viso geral da Engenharia de Software segundo
alguns autores renomados no assunto, e tambm uma anlise significativa dos processos de
um modelo de desenvolvimento de software genericamente que podem ser direcionados tanto
a modelos tradicionais quanto geis e, que essa significncia se direciona a escolha da
metodologia mais adequada ao problema.
Aqui, tambm foram mostradas algumas definies e princpios de XP, RUP e Agile
Modeling, modelos estes usados como base para a especificao e definio do easYProcess,
atribuindo a este s melhores prticas e valores dos modelos apoiadores, integrando
produo, rapidez com qualidade.
Quanto ao desenvolvimento do software anteriormente mencionado, por meio das
especificaes do YP, trouxe como experincia pessoal e profissional a definio de papis, o
dilogo com o cliente, e a cultura do planejamento, implementao e reunies de
acompanhamento. Sem contar, a elaborao de artefatos especficos.
Com a modelagem do sistema de software, pde facilmente ser observado que YP gera
muitos artefatos antes de implementar o software, isso devido ao fato de o modelo de
desenvolvimento estar disponvel em verso original, considerando artefatos essenciais para
um bom andamento do projeto.
Portanto, uma boa atualizao e refinamento se fazem necessrios para que a
metodologia de desenvolvimento easYProcess produza menos artefatos, e desta forma, possa
tambm atuar mais e competir com outras metodologias de desenvolvimento geis no
mercado atual, garantindo sucesso do binmio problema-soluo.
64
5.1 TRABALHOS FUTUROS
Este trabalho serve como base para mostrar que o easYProcess apesar de ser uma
metodologia de desenvolvimento gil, deve passar por um processo de atualizao, no pelo
fato de ainda est disponvel na verso original (2007), mas que tambm tenha finalidade de
produzir menos artefatos, j que o mercado bem competitivo e tempo um bem precioso, e
desta forma competir com outras metodologias de desenvolvimento geis atualmente no
mercado.
Em relao ao sistema produzido (SysVenda), previsto que o mesmo em trabalhos
futuros seja submetido a um processo de atualizao (upgrade) para possveis melhoramentos
de suas funcionalidades e incrementos de outras pendncias, como a opo para visualizao
de grficos onde os administradores do SysVenda podero ter melhores anlises das
informaes na tela do sistema.
65
REFERNCIAS
AVILA, Ana Luiza. Introduo Engenharia de Requisitos. 2008. Disponvel

em:<http://www.devmedia.com. br/articles/ viewcomp.asp? comp=8034>. Acesso:
03/06/2011.
AURLIO, Holanda B. Ferreira. Mini Aurlio O minidicionrio da lngua portuguesa. 5

Ed. Rio de Janeiro : FNDE, 2004.
AMBLER, Scott W. Uma Introduo Modelagem gil. 2009. Disponvel em:

<http://translate.googleusercontent.com/translate_c?hl=ptBR&prev=/search%3Fq%3Dwww.a
gilemodeling.com%26hl%3DptR%26biw%3D836%26bih%3D478%26prmd%3Divns&rurl=t
ranslate.google.com.br&sl=en&twu=1&u=http://www.agilemodeling.com/essays/introduction
ToAM.htm&usg=ALkJrhhq6njJCXCJbNICGODJSqxp94z87Q>. Acesso: 22 de Abril de
2011
CAETANO, Rodrigo. Metodologias de desenvolvimento: qual a mais adequada?.
Computerwordl,
2009.
Disponvel
em:
<
http://computerworld.uol.com.br/gestao/2009/08/05/metodologias-de-desenvolvimento-quala-mais-adequada/>. Acesso: 01 de Julho de 2011
FREIRE, Alexandre. Programao eXtrema Desenvolvendo Software com Qualidade e
Agilidade. 2003.
GARCIA, Francile Procpio; LIMA, Aliandro Higino Guedes; FERREIRA, Danilo de Sousa;
JNIOR, Fbio Luiz Leite; ROCHA, Giselle Regina Chaves da; MENDES, Gustavo Wagner
Diniz; PONTES, Renata Frana de; ROCHA, Verlaynne Kelley da Hora; DANTAS, Vinicius
Farias. easYProcess Um Processo de Desenvolvimento de Software. Universidade Federal
de Campina Grande. Campina Grande: 2007.
GERVAZONI, Thiago Pastorello. XP Extreme Programming. 2005.Disponvel em:

<http://www.linhadecodigo.com.br/artigo/764/XP-%E2%80%93-Extreme-Programming%E2%80%93-Parte-1.aspx>. Acesso: 18 de Abril de 2011.
MOLINARI, Leonardo. Gerncia de Configurao - Tcnicas e Prticas no

Desenvolvimento do Software. Florianpolis: Visual Books, 2007.
66
MONTEIRO, Guilherme Alexandre Reinaldo. Extreme Programming (XP). 2009.

Disponivel em: <http://www.cin.ufpe.br/~gamr/FAFICA/ Desenvo lvimento %
20de%20sistemas/XP.pdf>. Acesso: 15 de Abril de 2011.
MARTINES, Marina. RUP. 2010. Disponvel em: <http://www.infoescola.com/engenhariade-software/rup/>. Acesso: 19 de Abril de 2011.
KUHN, Giovane Roslindo. PAMPLONA, Vitor Fernando. Apresentando XP. Encante seus
clientes
com
Extreme
Programming.
2009.
Disponvel
em:
<http://
javafree.uol.com.br/artigo/871447/#equipe>. Acesso: 18 de Abril de 2011.
PRESSMAN, Roger. Software Engineering A Pratitictioners Approach. McGraw-Hill,
5th Edition, 2001.
MANSUR, Ricardo. Governana de TI: Metodologias, Frameworks e Melhores Prticas.
Rio
de
Janeiro:
BRASPORT,
2007,
pg.
167.
Disponvel
em:
<
http://www.livrariaresposta.com.br /v2/produto.php?id=30722&sp=0>. Acesso: 29 de Abril
de 2011.
SILVA, F. A. M; LIMA, F. A. Analisando e Utilizando o easYProcess. 2010
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. So Paulo: Addison Wesley, 2007.

TANAKA, Sergio Akio. BANKI, Andr. ALINHAMENTO DO RUP 7.0 AOS VALORES
DO
MOVIMENTO
GIL.
2008.
Disponvel
em:
<
http://revista.ctai.senai.br/index.php/edicao01/article/download/19/17>. Acesso: 27 de Junho
de 2011.
WILEY, John e Sons. Design de Interao. So Paulo: Bookman, 2002. P. 207 - 208.
67
APNDICES
68
Apndice A: Estrutura Base do Sistema

Classe Entidade Venda
package br.systemVenda.entidade;
import java.io.Serializable;
import java.util.Date;
import javax.persistence.*;
import br.systemVenda.util.*;
@Entity
@Table(name="vendas")
public class Vendas implements Serializable{
private static Vendas instance = new Vendas();
public static Vendas getInstance(){
return instance;
}
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private Integer codigo;
@ManyToOne
@JoinColumn(name="fk_cliente_id", nullable=false)
private Cliente cliente;
@ManyToOne
@JoinColumn(name="fk_funcionario_id", nullable=false)
private Funcionario funcionario;
@ManyToOne
@JoinColumn(name="fk_produto_id", nullable=false)
private Produto produto;
@Column(scale=10, precision=2, nullable=false)
private float valorVendaCliente;
@Column(scale=10, precision=2, nullable=false)
private int unidadeProduto;
@Temporal(TemporalType.DATE)
private Date dataVenda;
@Temporal(TemporalType.DATE)
private Date dataConfirmaVenda;
69
@Enumerated(EnumType.STRING)
@Column(length=10)
private TipoVenda tipo;
//temos gets e set no fim do codigo
} // fim do cdigo acima
Classe para operaes CRUD

package br.systemVenda.DAOeBusca;
import java.util.*;
import org.hibernate.*;
import org.hibernate.criterion.Restrictions;
import br.systemVenda.entidade.Vendas;
public class GenericoDAO<Tipo> implements InterfaceDAO<Tipo>{
private Session session;
private Transaction transaction;
private Tipo tipo;
private List<Tipo> lista;
public GenericoDAO(Tipo tipo) {
super();
this.session = HibernateUtil.getSession();
this.transaction = session.beginTransaction();
this.tipo = tipo; }
public void daoClose(){
session.close(); }
public boolean insert() {
boolean condicao=true;
try{
session.save(tipo);
transaction.commit();
}catch(HibernateException hibernateException){
if(transaction.isActive()){
transaction.rollback();
}
hibernateException.printStackTrace();
condicao=false;
}
return condicao;
}
public boolean update(){
70
try{
session.update(tipo);
}
condicao=false;
}
return condicao;
}
public boolean delete() {
try{
session.delete(tipo);
}
condicao=false;
}
return condicao;
}
public List<Tipo> getAll(){
lista = new LinkedList<Tipo>();
try{
lista = session.createCriteria(tipo.getClass()).list();
lista =null;
}
return lista;
}
public Tipo getId(int id){
Tipo type;
try{
type = (Tipo)session.get(tipo.getClass(), id);
}catch(HibernateException erro){
type = null;
}
return type; }
Apndice B: Modulo de venda

71
Classe vendasBean responsvel pela ligao das camadas: controle e viso

package br.systemVenda.bean;
//import java.util.*;
import javax.faces.event.*;
import javax.faces.model.SelectItem;
import br.systemVenda.DAOeBusca.*;
import br.systemVenda.entidade.*;
public class vendasBean {
private FactoryObject factory = new FactoryObject(); // fabrica
private List<ProdutoUnidade> listaProdutos;
private ProdutoUnidade deleteProduto;
private List<SelectItem> clientes;
private List<SelectItem> funcionarios;
private List<SelectItem> produtos;
private List<SelectItem> numeros;
private Vendas selectedVenda;
private Produto selectProduto;
private Produto produtoTemporario;
private float totalSoma=0.f;
private int unidadeProduto;
public vendasBean() {
selectedVenda = new Vendas();
produtoTemporario = factory.getProduto();
}
public List<SelectItem> getClientes() {
if(clientes == null) {
clientes = new LinkedList<SelectItem>();
Cliente cliente = factory.getCliente(); // usado para referenceia
cliente.setCodigo(-1);
cliente.setNome("--selecione--");
clientes.add(new SelectItem(cliente, cliente.getNome()));
for(Cliente c : new GenericoDAO<Cliente>(cliente).getAll()){
clientes.add(new SelectItem(c, c.getNome()));
//System.out.println("Nome: "+c.getNome());
}
}
72
return clientes;
}
// gets e sets
}
Cdigo JSF para Modulo Venda de Produto(s)

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<%@ taglib prefix="a4j" uri="http://richfaces.org/a4j"%>
<%@ taglib prefix="rich" uri="http://richfaces.org/rich"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Venda Produto</title>
<link rel="stylesheet" type="text/css" href="css/estilo.css" />
</head>
<body>
<f:view>
<h2><h:outputText value="Venda de Produto(s)"/></h2>
<br>
<rich:messages id="message" layout="table" errorClass="msgErro"
infoClass="msgInfo"
showSummary="true" showDetail="true">
<f:facet name="infoMarker">
<h:graphicImage value="imagens/sucesso.gif"/>
</f:facet>
<f:facet name="errorMarker">
<h:graphicImage value="imagens/erro.gif"/>
</f:facet>
</rich:messages>
<br/>
<a4j:form id="frm_venda" >
<rich:panel id="rich_panel_selecionar" style="width: 400px;"
header="Selecione os Dados...">
<h:panelGrid columns="3" >

<h:panelGroup>
<h:outputLabel value="Cliente: "/><h:outputLabel
value="*" style="color: red;"/>
</h:panelGroup>
<h:selectOneMenu id="id_cliente"
value="#{vendasBean.selectedVenda.cliente}">
<a4j:support event="onchange"/>
<f:converter converterId="ClienteConverter"/>
<f:selectItems value="#{vendasBean.clientes}"/>
</h:selectOneMenu>
<h:message for="id_cliente" showDetail="true"
showSummary="false" styleClass="msgErro"/>
73


<h:panelGroup>
<h:outputLabel value="Funcionrio: "/><h:outputLabel
</h:panelGroup>
<h:selectOneMenu id="id_funcionario"
value="#{vendasBean.selectedVenda.funcionario}">
<a4j:support event="onchange"/>
<f:converter converterId="FuncionarioConverter"/>
<f:selectItems value="#{vendasBean.funcionarios}"/>
</h:selectOneMenu>
<h:message for="id_funcionario" showDetail="true"

<h:panelGroup>
<h:outputLabel value="Data Venda: "/><h:outputLabel
</h:panelGroup>
<rich:calendar id="id_data_venda"
value="#{vendasBean.selectedVenda.dataVenda}" datePattern="dd/MM/yyyy"
inputSize="12"/>
<h:message for="data_venda" showDetail="true"

<h:panelGroup>
<h:outputLabel value="Produto: "/><h:outputLabel
</h:panelGroup>
<h:panelGroup>
<h:selectOneMenu id="id_produto"
value="#{vendasBean.selectProduto}"
valueChangeListener="#{vendasBean.getValueProdutoChange}"
onchange="submit();">
<f:converter converterId="ProdutoConverter"/>
<f:selectItems value="#{vendasBean.produtos}" />
</h:selectOneMenu>
<h:outputText value=" - "/>
<h:selectOneMenu id="id_unidade"
value="#{vendasBean.unidadeProduto}"
valueChangeListener="#{vendasBean.getValorUnidadeChange}"
onchange="submit();">
<f:converter converterId="NumeroConverter" />
<f:selectItems value="#{vendasBean.numeros}"/>
</h:selectOneMenu>
</h:panelGroup>
<h:message for="id_produto" showDetail="true"
</h:panelGrid>
</rich:panel>
<rich:panel id="rich_panel_informacao" style="width: 400px;"
header="Produto(s) e subtotal...">
<rich:dataTable id="tabela" border="1" var="item"
value="#{vendasBean.listaProdutos}"
74
rows="5" rowClasses="linha1Tabela,
linha2Tabela">
<rich:column>
<f:facet name="header">
<h:outputText value="Produto(s)"/>
</f:facet>
<h:outputText value="#{item.produto.descricao}"/>
</rich:column>
<rich:column>
<f:facet name="header">
<h:outputText value="Valor/Produto"/
Interface do Modulo Venda de Produto(s)

Figura 10: Interface de Venda
Sem dados selecionados
Com dados selecionados
Apndice C: Teste de Usabilidade

Atividades referentes ao teste de usabilidade
75
Atividade 01- Realizao de Venda de Produto.

Roteiro: Nesta atividade o usurio ter que realizar uma seqncia de vendas, usando a
interface de vendas de produtos
Instrues:
a) Abra a interface Venda de Produto(s), e verifique se todos os campos necessrios para
venda esto disponibilizados;
b) Tente confirmar um venda com pelo menos um campo de informao em branco, o
resultado dever ser uma venda no confirmada;
c) Liste vrios produtos na tabela e verifique se o valor total da venda estar resultando
corretamente;
d) Depois de selecionado um produto relacione uma quantidade para o produto;
e) Cancele um produto da tabela, e verifique se o valor total de venda est sendo
decrementado corretamente;
f) Faa a venda de pelo menos um produto, no esquecer de preencher todos os campos da
venda, a venda deve ser realizada com sucesso;
g) Faa uma nova venda com no mnimo 3 produtos listados na tabela, no esquecer de
preencher todos os campos da venda, realizada com sucesso.
76

YP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

YP

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL DA PARABA

CAMPUS GOVERNADOR ANTONIO MARIZ

ELDER GONALVES PEREIRA

Implementando um Componente de Software com o Auxlio da Metodologia

ELDER GONALVES PEREIRA

Implementando um Componente de Software com o Auxlio da Metodologia

Monografia apresentada ao Curso de Graduao

Universidade Estadual da Paraba, em cumprimento

Orientador: Prof. Esp. Vitor Ablio Sobral Dias Afonso

ELDER GONALVES PEREIRA

Implementando um Componente de Software com o Auxlio da Metodologia

Monografia apresentada ao Curso de Graduao

Universidade Estadual da Paraba, em cumprimento

O presente Trabalho de Concluso de Curso objetiva apresentar a metodologia gil de

Palavras chaves: Engenharia de Software, desenvolvimento gil, easYProcess.

keyword: Software engineering, agile development, easYProcess.

Figura 01: Modelo em Cascata ----------------------------------------------------------------- 20

Quadro 01: Definio de papis --------------------------------------------------------------- 41

PROBLEMTICA ------------------------------------------- -------------------- 13

JUSTIFICATIVA ----------------------------------- ----------------------------- 14

DELIMITAO --------------------------------------- -------------------------- 15

OBJETIVOS ----------------------------------------- ----------------------------- 16

1.4.1 Geral ------------------------------------------- ------------------------------------ 16

ESTRUTURA DO TRABALHO ----------------------------------------------- 16

ENGENHARIA DE SOFTWARE ------------------------- --------------------------- 17

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ---- --------- 18

METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAL ------- 20

METODOLOGIA DE DESENVOLVIMENTO GIL -----------------------22

MODELOS DE DESENVOLVIMENTO APOIADORES DO YP -------- 23

2.4.1 Extreme Programming - XP (programao extrema) -------------------- 23

EASY PROCESS ................................................................................................... 29

DEFINIO DE PAPIS ........................................................................... 30

CONVERSA COM O CLIENTE ................................................................ 32

3.2.1 Descrio ..................................................................................................... 32

3.3.1 Modelo de Tarefa ........................................................................................ 34

3.5.1 Integrao continua .................................................................................... 37

REUNIO DE ACOMPANHAMENTO ..................................................... 40

SYS VENDA E YP .................................................................................................. 41

DEFINIO DE PAPIS ............................................................................. 41

CONVERSA COM O CLIENTE .................................................................. 42

REUNIO DE ACOMPANHAMENTO ...................................................... 59

CONSIDERAES FINAIS ............................................................................... 63

TRABALHOS FUTUROS .......................................................................... 64

Em algumas equipes de desenvolvimento de software um dos problemas encontrados

Apesar do curso de Licenciatura em Computao da Universidade Estadual da Paraba

A presente pesquisa aborda o processo de implementao de um componente de

Realizar, na prtica, um estudo referente a uma metodologia de desenvolvimento gil,

Apresentar as caractersticas das metodologias de desenvolvimento geis e

Analisar as principais caractersticas das metodologias de desenvolvimento apoiadoras

Especificar detalhadamente a metodologia de desenvolvimento gil easYProcess;

Modelar e implementar um componente de software com auxlio da metodologia de

Avaliar a aderncia do YP no desenvolvimento de um Sistema.

O restante do trabalho est dividido em quatro captulos:

Engenharia a aplicao de conhecimentos cientficos, empricos e certas habilitaes

Manoel Silva e Thaissa Rocha 1

2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Processos de Desenvolvimento de Software so um conjunto de atividades requeridas

apresente grande capacidade de estabelecer uma comunicao eficiente entre os

2.2 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAL

A atividade de desenvolvimento de software na dcada de 70 era executada de

Figura 01: Modelo em Cascata

Fonte: Adaptado (WILEY, 2002).

O Modelo em Espiral (ver Figura 02) apresenta um conjunto de atividades de forma

todas as atividades de anlises, teste, projeto, planejamento e construo so repetidas e