355lia Machado de ) - projetos.inf.ufsc.br · PDF file• Contribuição para a...
90
Universidade Federal de Santa Catarina Departamento de Informática e Estatística Curso de Sistemas de Informação Aplicação de Metodologia Ágil no Desenvolvimento de um Componente de Software para Prefeituras CECÍLIA MACHADO DE FELIPPE Florianópolis – SC Ano 2007 / 1
Transcript of 355lia Machado de ) - projetos.inf.ufsc.br · PDF file• Contribuição para a...
Universidade Federal de Santa Catarina
Departamento de Informática e Estatística
Curso de Sistemas de Informação
Aplicação de Metodologia Ágil no Desenvolvimento de um
Componente de Software para Prefeituras
CECÍLIA MACHADO DE FELIPPE
Florianópolis – SC
Ano 2007 / 1
CECÍLIA MACHADO DE FELIPPE
Aplicação de Metodologia Ágil no Desenvolvimento de um
Componente de Software para Prefeituras
Trabalho de conclusão de curso apresentado como parte dos requisitos para
obtenção do grau de Bacharel em Sistemas de Informação
Orientadora: Profa. Maria Marta Leite, Dra.
Coorientador: Prof. José Eduardo De Lucca, Msc.
Banca Examinadora
Prof. Leandro José Komosinski, Dr.
Ao meu pai, à minha mãe
e à minha dinda.
AGRADECIMENTOS
Agradeço primeiramente à minha família querida, meus pais Nelson e
Canda, à minha madrinha Carla e aos meus irmãos Natália e Rodrigo, pela palavra,
incentivo e confiança.
À minha grande professora, orientadora e amiga tia Marta, pela
dedicação, atenção, oportunidade de aprendizado e principalmente por ter
acreditado em mim.
Aos professores José Eduardo De Lucca e Leandro José Komosinski pela
avaliação deste trabalho.
Aos amigos Ju, Carol, Adriano, Renata e Chiqueti, pelo companheirismo,
paciência e pelos momentos de descontração tão importantes.
À Universidade Federal de Santa Catarina.
A todos que direta ou indiretamente contribuíram para a realização deste
trabalho.
E finalmente a Deus, por me trilhar no melhor caminho e me dar forças
para seguir adiante e alcançar meus objetivos.
Resumo
A Engenharia de Software sempre contou com metodologias cujo
processo de desenvolvimento é totalmente planejado, baseado na produção de uma
grande quantidade de documentação. Ao mesmo temo que proporcionam um
grande controle do processo, não oferecem meios de tratar as mudanças
decorrentes do desenvolvimento, tornando-se muitas vezes pesadas e não flexíveis.
Neste sentido, surgiram as metodologias ágeis, com enfoque maior nas pessoas do
que no processo de desenvolvimento, procurando desenvolver o mínimo
indispensável de documentação.
Este trabalho apresenta as diferenças da abordagem ágil de
desenvolvimento de software em relação à abordagem tradicional. Também
apresenta o estudo e aplicação da metodologia ágil EasYProcess, proposta pela
Universidade Federal de Campina Grande, na construção de um componente de
software para prefeituras.
Palavras-chave: Metodologias Tradicionais, Metodologias Ágeis, EasYProcess.
Abstract
Software Engineering has always counted on methodologies whose
development process is completely planned, based on the production of a large
quantity of documentation. At the same time that they provide a great process
control, they do not offer means of treating changes from development, and they
frequently become heavy and inflexible. Therefore, new methodologies have
appeared with a greater focus on people than on the development process, seeking
to develop a minimum, indispensable documentation.
This study presents the differences between the agile software
development approach and the traditional approach. It also presents a study and
application of the agile methodology EasYProcess, proposed by the Federal
University of Campina Grande when building software components for city halls.
Keywords: Traditional Methodologies, Agile Methodologies, EasYProcess.
Sumário
1 INTRODUÇÃO ................................................................................................................. 12 1.1 APRESENTAÇÃO........................................................................................................... 13 1.2 FORMULAÇÃO DO PROBLEMA........................................................................................ 14 1.3 JUSTIFICATIVAS ........................................................................................................... 14 1.4 OBJETIVOS .................................................................................................................. 15
1.4.1 Objetivo Geral .........................................................................................................15 1.4.2 Objetivos Específicos...............................................................................................15
1.5 DELIMITAÇÃO DO ESCOPO ............................................................................................ 15 1.6 METODOLOGIA DE DESENVOLVIMENTO.......................................................................... 16 1.7 ORGANIZAÇÃO DO TRABALHO ....................................................................................... 16
2 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE....................................... 17 2.1 INTRODUÇÃO ............................................................................................................... 17 2.2 METODOLOGIAS TRADICIONAIS ..................................................................................... 18 2.3 METODOLOGIAS ÁGEIS................................................................................................. 23
2.3.1 XP ............................................................................................................................26 2.4 COMPARAÇÃO ENTRE METODOLOGIAS .......................................................................... 30
3 EASYPROCESS – YP...................................................................................................... 34 3.1 INTRODUÇÃO ............................................................................................................... 34
3.1.1 Identificação do Escopo do Problema ....................................................................34 3.1.2 Especificação de Papéis ..........................................................................................35 3.1.3 Conversa com o Cliente...........................................................................................36 3.1.4 Inicialização ............................................................................................................38 3.1.5 Planejamento ...........................................................................................................41 3.1.6 Implementação ........................................................................................................42 3.1.7 Finalização da Iteração...........................................................................................45 3.1.8 Versão do Produto...................................................................................................47
4 PROPOSTA DO COMPONENTE DE SOFTWARE.......................................................... 48 4.1 INTRODUÇÃO ............................................................................................................... 48 4.2 COMPONENTE.............................................................................................................. 48 4.3 DESENVOLVIMENTO DO COMPONENTE .......................................................................... 49
4.3.1 Identificação do Escopo do Problema ....................................................................49 4.3.2 Especificação de Papéis ..........................................................................................49 4.3.3 Conversa com o Cliente...........................................................................................50 4.3.4 Inicialização ............................................................................................................50 4.3.5 Planejamento ...........................................................................................................52 4.3.6 Implementação ........................................................................................................53 4.3.7 Finalização da Iteração...........................................................................................55 4.3.8 Versão do Produto...................................................................................................56
4.4 FERRAMENTAS............................................................................................................. 56
5 CONCLUSÕES ................................................................................................................ 57
5.1 QUANTO AOS OBJETIVOS ............................................................................................. 57 5.1.1 Objetivo Específico I ...............................................................................................57 5.1.2 Objetivo Específico II ..............................................................................................57 5.1.3 Objetivo Específico III.............................................................................................59
5.2 QUANTO ÀS PERSPECTIVAS DE CONTINUIDADE .............................................................. 59
6 REFERÊNCIAS ................................................................................................................ 61
APÊNDICE A....................................................................................................................... 64
APÊNDICE B....................................................................................................................... 66
APÊNDICE C....................................................................................................................... 69
APÊNDICE D....................................................................................................................... 74
APÊNDICE E....................................................................................................................... 77
APÊNDICE F....................................................................................................................... 81
APÊNDICE G ...................................................................................................................... 83
APÊNDICE H....................................................................................................................... 85
7 GLOSSÁRIO .................................................................................................................... 89
Índice de Figuras
FIGURA 2.1 – MODELO EM CASCATA.........................................................................................19 FIGURA 3.1 – MODELO DA TAREFA ...........................................................................................39 FIGURA 4.1 – ESTRUTURA DE DIRETÓRIOS ................................................................................54
Índice de Gráficos e Tabelas
GRÁFICO 2.1 – GRÁFICO DO PREÇO DE UMA ALTERAÇÃO NO DECORRER DO PROJETO ...............31 TABELA 2.1 – COMPARAÇÃO ENTRE A ABORDAGEM TRADICIONAL E A ABORDAGEM ÁGIL......33 TABELA 3.1 – TABELA DE USER STORIES ...................................................................................40 TABELA 4.1 – DEFINIÇÃO DE PAPÉIS .........................................................................................50 TABELA 4.2 – PLANO DE RELEASE .............................................................................................53
Lista de Abreviaturas e Siglas
CGC – Componente para Gerência de Cemitérios
CVS – Current Version System
DAO – Data Access Object
IDE – Integrated Development Environment
HTML – Hype Text Markup Language
JEE – Java Platform Enterprise Edition
JSP – JavaServer Page
RUP – Rational Unified Process
SVN – Subversion
TA – Teste de Aceitação
TAA – Tabela de Alocação de Atividades
UFCG – Universidade Federal de Campina Grande
US – User Story
VO – Value Object
XP – Extreme Programming
YP – EasYProcess
12
1 INTRODUÇÃO
A preocupação com a qualidade deixou de ser um diferencial competitivo
e passou a ser um pré-requisito básico para a participação no mercado (ZANATTA,
2004). Para alcançar a qualidade desejada, a Engenharia de Software dedica
esforços na tentativa de melhorar os processos de desenvolvimento de software. A
melhoria destes processos implica em compreendê-los a fim de modificá-los, de
forma a aumentar a qualidade do produto desenvolvido.
Sommerville (2004) define “processo de software” como um conjunto de
atividades cujo objetivo é o desenvolvimento ou a evolução de um software. Estas
atividades precisam estar coordenadas e todas as pessoas envolvidas precisam
estar cientes de seus papéis no processo para garantir o seu sucesso. Logo, existem
metodologias que definem uma série de passos para que o processo de
desenvolvimento siga um padrão e assim atinja bons níveis de qualidade. A
avaliação de um processo de software torna-se inviável sem um padrão de
desenvolvimento.
Segundo a modelagem tradicional, um software deve ser planejado e
documentado antes de ser implementado, desde a sua concepção até a sua
entrega. O Modelo em Cascata, por exemplo, apresenta fases distintas de
especificação de software e somente quando estas são concluídas, a geração de
código é realizada (LARMAN, 2002). A abordagem tradicional coloca grande ênfase
em projetar antes de construir.
Apesar da padronização e formalização de processos proposta pelos
modelos tradicionais, a entrega de softwares conforme o planejado nem sempre é
garantida. Todas as pesquisas do Standish Group (THE STANDISH GROUP) dos
últimos 15 anos apresentam números que demonstram poucos sucessos e um alto
número de fracassos tratando-se de projetos de desenvolvimento de software. Neste
sentido, qual é a dose certa de métodos, formalidades e documentação que um
processo de desenvolvimento de software deve ter para se ter um produto final com
qualidade?
13
Como resposta às chamadas metodologias tradicionais, surgiram as
metodologias ágeis, propondo meios de desenvolver software de forma mais direta e
menos burocrática. Este trabalho apresenta as vantagens e desvantagens do uso de
metodologias ágeis em relação a metodologias tradicionais para especificação de
software. Também apresenta o estudo e aplicação de uma metodologia ágil, em
particular a metodologia EasYProcess (EASYPROCESS).
Para este estudo o cenário de desenvolvimento escolhido foi a área de
Governo Eletrônico (e-Gov), mais especificamente o Projeto Via Digital (PORTAL
VIA DIGITAL). O projeto busca atender às necessidades mais comuns de pequenas
prefeituras através da criação de softwares open source.
1.1 APRESENTAÇÃO
A Engenharia de Software define vários processos de desenvolvimento de
software. Dentre esses processos, existem as metodologias tradicionais, que têm
como uma de suas características a grande quantidade de documentos gerados, e
as metodologias ágeis, focada mais nas pessoas do que na documentação. Os
métodos1 tradicionais de desenvolvimento de software, tendo como foco a
documentação, necessitam de requerimentos completos e fixos, tornando-os por
vezes “pesados” e não flexíveis (SEGUNDO e MOURA, 2004).
As metodologias ágeis têm sido apontadas como alternativa às
metodologias tradicionais de desenvolvimento de software. Estas metodologias
abordam o desenvolvimento de software de forma diferente dos modelos
preconizados anteriormente pela Engenharia de Software, que tinham forte ênfase
na documentação e no processo (COSTA et alii, 2005). Visam um desenvolvimento
rápido, permitindo modificações à medida que novas funcionalidades apareçam e
um grande e contínuo envolvimento do cliente antes e durante o desenvolvimento do
software.
1 O termo “método” será utilizado ao longo deste trabalho equivalente ao termo “metodologia”.
14
1.2 FORMULAÇÃO DO PROBLEMA
Conforme Camara (2005), o que motiva o estudo de metodologias ágeis é
o cenário atual dos resultados de desenvolvimento de software, em que
normalmente são entregues fora do prazo e com o orçamento estourado.
Processos orientados a documentação são de certa forma fatores
limitadores aos desenvolvedores. As pequenas empresas muitas vezes não
possuem recursos ou inclinação para processos pesados de produção de software.
Além disso, o processo de desenvolvimento de software envolve riscos, como
substituição de membros da equipe de desenvolvimento, mudança de requisitos,
atrasos no cronograma, projetos cancelados, dentre outros (SEGUNDO e MOURA,
2004). Devido a estes problemas muitas organizações, em particular as
consideradas de menor porte, acabam por não adotar nenhum processo de
desenvolvimento (SOARES, 2004). Os processos tradicionais tornam-se pouco
adequados à realidade das organizações, principalmente as pequenas. O ambiente
dessas organizações é dinâmico, não permitindo que os requisitos sejam estáticos.
Levando-se em consideração que o processo de desenvolvimento é
mutável, é conveniente o uso de uma metodologia de desenvolvimento que permita
alteração de requisitos a baixo custo, sem comprometer a qualidade do produto final.
Por este motivo, existe uma grande demanda pelas empresas da introdução de
práticas de desenvolvimento ágeis (SEGUNDO e MOURA, 2004).
As metodologias ágeis surgiram como alternativa ao processo de
desenvolvimento de software dirigido a pequenas organizações, abdicando muitas
vezes de controles tais como padronização dos processos, documentação excessiva
e gerenciamento dos requisitos, como destaca Zanatta (2004). A proposta das
metodologias ágeis é o desenvolvimento de sistemas de uma maneira mais rápida,
eficiente e que atenda as reais necessidades dos clientes.
1.3 JUSTIFICATIVAS
Como justificativas para elaboração deste trabalho podem ser citadas:
15
• O estudo e aprendizado de metodologias ágeis de desenvolvimento de
software, uma vez que práticas ágeis de desenvolvimento são de
grande interesse no mercado e pouco exploradas no meio acadêmico;
• Avaliação da aplicabilidade de metodologias ágeis através da
construção de um componente de software simples;
• Contribuição para a iniciativa do projeto Via Digital através da criação
de uma solução livre, visando abastecer uma necessidade de
pequenas prefeituras.
1.4 OBJETIVOS
Este trabalho está baseado nos objetivos descritos a seguir.
1.4.1 OBJETIVO GERAL
O objetivo geral do trabalho é estudar e aplicar uma metodologia ágil na
construção de um componente de software utilizando tecnologias open-source.
1.4.2 OBJETIVOS ESPECÍFICOS
I – Realizar estudo comparativo entre metodologias ágeis e metodologias
tradicionais de desenvolvimento de software.
II – Estudar o processo da modelagem ágil de software através do uso da
metodologia YP.
III – Aplicar a metodologia YP em uma solução de software simples.
1.5 DELIMITAÇÃO DO ESCOPO
Durante a realização do trabalho será estudada a metodologia ágil
EasYProcess (YP) proposta pela Universidade Federal de Campina Grande.
EasYProcess é apoiada em práticas do Extreme Programming (EXTREME
PROGRAMMING), Rational Unified Process (RATIONAL UNIFIED PROCESS) e
16 Agile Modeling (AGILE MODELING). Esta metodologia será aplicada no
desenvolvimento de um componente de software dentro do contexto do projeto Via
Digital. O projeto visa a criação de componentes de software voltados para a área de
governo eletrônico (e-Gov), utilizando a idéia de software livre.
Não é intenção deste trabalho a integração do componente desenvolvido
com sistemas já existentes em prefeituras que se beneficiariam de seu uso, bem
como a criação da infra-estrutura necessária para a utilização do mesmo.
1.6 METODOLOGIA DE DESENVOLVIMENTO
Este trabalho é caracterizado como uma pesquisa aplicada, visto que todo
o conhecimento adquirido será utilizado para um objetivo específico, o estudo da
metodologia ágil EasYProcess através da criação de um componente de software.
Como metodologia de pesquisa para reunir informações foi utilizada a
pesquisa bibliográfica, praticamente ao longo de todo o trabalho, a fim de obter
conhecimento sobre o assunto abordado.
1.7 ORGANIZAÇÃO DO TRABALHO
O presente trabalho é composto por 5 capítulos e está organizado como
descrito a seguir. O primeiro capítulo apresenta esta Introdução, visando o
posicionamento do trabalho e a definição do seu escopo. O segundo capítulo
apresenta a revisão bibliográfica sobre metodologias de desenvolvimento de
software. O capítulo 3 apresenta o fluxo de trabalho da metodologia ágil
EasYProcess. No capítulo 4 a metodologia EasYProcess é aplicada na construção
de um componente de software para o Projeto Via Digital. As conclusões e trabalhos
futuros são apresentados no capítulo 5.
17
2 METODOLOGIAS DE DESENVOLVIMENTO DE
SOFTWARE
Este capítulo apresenta uma visão geral sobre as metodologias
tradicionais e metodologias ágeis de desenvolvimento de software. Ele também
apresenta uma comparação entre as duas abordagens, mostrando algumas
vantagens e desvantagens do uso de cada uma delas.
2.1 INTRODUÇÃO
Segundo Pressman (2001), processo de software é um conjunto de
tarefas necessárias para a produção de um software com alta qualidade. O resultado
do processo é um produto (software) que reflete a forma como o processo foi
realizado. Embora existam vários métodos de desenvolvimento de software existem
atividades genéricas comuns a todos eles (SOMMERVILLE, 2004):
• Especificação do Software: definição do que o sistema deve fazer,
definição dos requisitos e das restrições do software.
• Desenvolvimento do Software: projeto e implementação do software, o
sistema é desenvolvido conforme sua especificação.
• Validação do Software: o software é validado para garantir que as
funcionalidades implementadas estejam de acordo com o
especificado.
• Evolução do Software: evolução do software conforme a necessidade
dos clientes.
Visando a qualidade final do produto gerado são propostos métodos que
buscam padronizar as atividades e o ciclo de vida de um processo de software. Esta
padronização implica em criação de documentos, artefatos e marcos capazes de
representar o contexto do software (NETO, 2004).
18
Portanto, uma metodologia de desenvolvimento de software é a
representação simplificada do processo (SOMMERVILLE, 2004) que combina
descrição do trabalho, procedimentos e convenções utilizadas por seus membros
(COCKBURN, 2000). Ou ainda, uma metodologia de desenvolvimento de software é
um conjunto de práticas recomendadas para o desenvolvimento de software, sendo
que essas práticas geralmente passam por fases ou passos, que são subdivisões do
processo, para ordená-lo e melhor gerenciá-lo (SOMMERVILLE, 2004).
O desafio mais comum dentro do desenvolvimento de software é entregar
um produto que atenda as reais necessidades do cliente, dentro do prazo e
orçamento previstos (FAGUNDES, 2005). Como suporte a esta atividade, a
Engenharia de Software oferece metodologias que auxiliam os desenvolvedores
durante o processo de desenvolvimento, entre elas as metodologias tradicionais e as
metodologias ágeis.
2.2 METODOLOGIAS TRADICIONAIS
Na década de 70 a atividade de “desenvolvimento de software” era
executada de forma desorganizada, desestruturada e sem planejamento, gerando
um produto final de má qualidade, que não correspondia às reais necessidades do
cliente (PRESSMAN, 2001). A partir deste cenário surgiu a necessidade de tornar o
desenvolvimento de software como um processo estruturado, planejado e
padronizado (NETO, 2004).
Segundo Neto (2004), no início da padronização do processo foram
mantidos conceitos típicos da Engenharia Civil, que ajudaram a sistematizar o
processo de desenvolvimento de software. Conforme Fagundes (2005), o
desenvolvimento de software era caracterizado como um processo descritivo,
baseado em um conjunto de atividades predefinidas e detalhadamente planejadas
(LARMAN, 2002).
As metodologias consideradas tradicionais também são conhecidas como
orientadas a documentação. Têm como característica marcante dividir o processo de
19 desenvolvimento em etapas e/ou fases bem definidas. De acordo com Soares
(2004),
“essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe
2 e
terminais burros. Na época, o custo de fazer alterações era muito alto, uma vez que o acesso aos computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso, o software era todo planejado e documentado antes de ser implementado.”
Muitas metodologias foram desenvolvidas sobre o Modelo em Cascata
(SOMMERVILLE, 2004). Esse é um modelo em que as fases são seguidas de
maneira linear (LARMAN, 2002). Cada fase tem associada a seu término uma
documentação padrão que deve ser aprovada para que se inicie a etapa posterior.
Cada fase concluída gera um marco, que geralmente é um documento, protótipo do
software ou mesmo uma versão do sistema (NETO, 2004). De uma forma geral
fazem parte deste modelo as etapas de análise de requisitos, projeto do software,
geração de código e testes, como mostra a Figura 2.1.
Figura 2.1 – Modelo em Cascata (Adaptado de PRESSMAN, 2001)
Também chamado de Modelo Clássico ou Seqüencial, o Modelo em
Cascata sugere um desenvolvimento de software sistemático que engloba as
seguintes atividades (PRESSMAN, 2001):
2 Computador de grande porte, dedicado normalmente ao processamento de um volume grande de informações (WIKIPEDIA).
20
• Engenharia do Sistema/Informação e Modelagem: o trabalho começa
com o levantamento de requisitos para todos os elementos do sistema
e que serão pertinentes ao desenvolvimento do software. Esta visão
geral é essencial quando o sistema deve interagir com outros
elementos como hardware, pessoas e banco de dados.
• Análise de Requisitos: o processo de levantamento de requisitos é
intensificado e focado especificamente no desenvolvimento do
software. Nesta fase os requisitos são documentados e revisados junto
com o cliente.
• Projeto: o projeto do software é um processo que transforma os
requisitos em uma representação cuja informação pode ser acessada
com segurança e qualidade, antes da geração de código. Assim como
a análise de requisitos, o projeto é documentado e torna-se parte da
configuração do software.
• Geração de Código: caso o projeto tenha sido realizado de uma
maneira detalhada, a geração de código é executada mecanicamente.
• Testes: uma vez que o código foi gerado, inicia-se o processo de
testes. Os testes devem ser conduzidos para descobrir erros e garantir
que entradas definidas produzam resultados esperados.
• Manutenção: o software irá indubitavelmente sofrer mudanças após
ser entregue ao cliente. Mudanças vão ocorrer porque erros serão
encontrados, porque o software deve adaptar-se a um novo sistema
operacional, ou porque o cliente quer que o software tenha novas
funcionalidades. A manutenção do software reaplica cada uma das
fases anteriores em um sistema já existente muito mais que em um
novo sistema.
O ciclo de vida do modelo Clássico mostra uma visão seqüencial e linear
de tarefas. O processo de desenvolvimento é similar à abordagem utilizada na
Engenharia para construção de edificações (LARMAN, 2002).
21
Embora seja o modelo mais antigo e mais utilizado para a modelagem de
software (PRESSMAN, 2001), não é o mais eficaz (NETO, 2004). Dados do The
CHAOS Report (THE STANDISH GROUP) utilizando como base 8.380 projetos,
mostram que somente 16,2% dos projetos foram entregues respeitando prazos,
custos e todas as funcionalidades especificadas. Aproximadamente 31% dos
projetos foram cancelados antes de estarem completos. 52.7% foram entregues,
porém com prazos e custos maiores ou com menos funcionalidades que o
especificado no início do projeto. Dos projetos que não foram finalizados conforme
planejado, a média de atraso foi de 222% e a média de custo foi de 189% a mais
que o previsto. Considerando todos os projetos que foram entregues além do prazo
e custo estabelecidos, apenas 61% das funcionalidades originais foram finalizadas.
Mesmo os projetos cuja entrega foi feita respeitando os limites de prazo e custo
possuem qualidade suspeita. As principais razões das falhas encontradas estavam
relacionadas com o modelo Clássico.
Dentre os problemas encontrados quando este modelo é aplicado pode-
se citar (LARMAN, 2002; PRESSMAN, 2001; SOMMERVILLE, 2004):
• Divisão do projeto em fases distintas, uma vez que raros projetos
seguem o fluxo seqüencial que o modelo propõe. Como resultado,
tem-se a inflexibilidade do processo.
• Os requisitos são totalmente especificados e “congelados” na primeira
fase do projeto. Isto dificulta responder às mudanças nas fases mais
adiantadas do processo.
• Uma vez que os requisitos estão prontos, a arquitetura do projeto é
especificada e também “congelada” na segunda fase do projeto.
Assumindo que os requisitos sofrerão alterações, o projeto inicial da
arquitetura não deve ser confiável.
• O cliente deve ser paciente. Uma versão do sistema funcionando não
estará disponível antes do tempo estabelecido para o projeto. Caso
haja algum erro maior, não poderá ser detectado antes do
funcionamento do sistema.
22
• De uma maneira geral, não oferecer meios de alterar o projeto depois
que as decisões já foram tomadas.
A adoção do modelo Clássico é apropriada apenas quando os requisitos
forem bem compreendidos (SOMMERVILLE, 2004). Mesmo com todos estes
problemas, a adoção do modelo é bem melhor e mais eficiente que um projeto que
não segue nenhum padrão (NETO, 2004).
Portanto, uma metodologia de desenvolvimento baseada no modelo
Clássico está associada às seguintes premissas (LARMAN, 2002):
• definir cuidadosamente e detalhadamente um artefato antes de passar
à etapa seguinte;
• confinar o desenvolvimento a um conjunto estático de requisitos;
• alteração de requisitos indica uma falha de que o projeto não foi
devidamente detalhado.
Processos tradicionais são baseados na produção de uma grande
quantidade de documentação, conforme já citado anteriormente, e de modelos para
guiar a programação e que demandam muito tempo para serem gerados
(FAGUNDES, 2005). Isso dificulta o controle do projeto, pois a cada mudança de
requisitos será necessária uma volta ao início do mesmo para alteração de
documentação (PRESSMAN, 2001), implicando em re-trabalho.
O foco principal das metodologias tradicionais é a previsibilidade dos
requisitos do sistema, que traz grande vantagem de tornar os projetos
completamente planejados, facilitando a gerência do mesmo, mantendo sempre uma
linha, caracterizando o processo como bastante rigoroso (NETO, 2004). Entretanto,
estas metodologias são consideradas burocráticas e eficientes apenas para projetos
grandes e que não sofram muitas mudanças em seus requisitos (FAGUNDES,
2005).
23
2.3 METODOLOGIAS ÁGEIS
A partir da década de 90 começaram a surgir outros métodos sugerindo
uma nova abordagem de desenvolvimento, em que os processos adotados tentam
adaptar-se as mudanças, apoiando a equipe de desenvolvimento em seu trabalho
(FAGUNDES, 2005). As metodologias ágeis surgiram como uma reação às
metodologias tradicionais (FOWLER, 2005) e tiveram como principal motivação criar
alternativas para o Modelo em Cascata (HILMAN, 2004).
O termo “Metodologia Ágil” tornou-se popular em fevereiro de 2001,
quando um grupo de 17 especialistas, referências mundiais em desenvolvimento de
software, criou a Aliança Ágil e estabeleceu o Manifesto Ágil para o Desenvolvimento
de Software (HIGHSMITH, 2002). Conforme Highsmith (2002), os valores que
norteiam o Manifesto Ágil são:
• Indivíduos e iterações ao invés de processos e ferramentas.
• Um software funcionando ao invés de uma documentação extensa.
• A colaboração do cliente ao invés de negociação de contratos.
• Responder às mudanças ao invés de seguir um plano.
De acordo com Fagundes (2005), para auxiliar as pessoas a compreender
o enfoque do desenvolvimento ágil, os membros da Aliança Ágil refinaram a filosofia
contida em seu manifesto em uma coleção de doze princípios, aos quais os métodos
ágeis de desenvolvimento de software devem adequar-se. Estes princípios são
(COCKBURN, 2000):
1. A prioridade é satisfazer o cliente através de entregas de software de
valor contínuas e freqüentes.
2. Entregar softwares em funcionamento com freqüência de algumas
semanas ou meses, sempre na menor escala de tempo.
3. Ter o software funcionando é a melhor medida de progresso.
4. Receber bem as mudanças de requisitos, mesmo em uma fase
avançada, dando aos clientes vantagens competitivas.
24
5. As equipes de negócio e de desenvolvimento devem trabalhar juntas
diariamente durante todo o projeto.
6. Manter uma equipe motivada fornecendo ambiente, apoio e confiança
necessário para a realização do trabalho.
7. A maneira mais eficiente da informação circular dentro da equipe é
através de uma conversa face-a-face.
8. As melhores arquiteturas, requisitos e projetos provêm de equipes
organizadas.
9. Atenção contínua a excelência técnica e a um bom projeto aumentam
a agilidade.
10. Processos ágeis promovem o desenvolvimento sustentável. Todos os
envolvidos devem ser capazes de manter um ritmo de
desenvolvimento constante.
11. Simplicidade é essencial.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar
mais eficaz e então se ajustar e adaptar seu comportamento.
O Manifesto Ágil não é contra os modelos adotados pela abordagem
tradicional. Ele inclui técnicas utilizadas na Engenharia de Software3, porém não
segue o padrão proposto pelas metodologias tradicionais (HIGHSMITH, 2002).
Portanto, não rejeita os processos e ferramentas, a documentação, a negociação de
contratos ou o planejamento, apenas mostra que eles têm importância secundária se
comparado com os indivíduos e iterações, com o software estar executável e com a
colaboração e as respostas rápidas a mudanças e alterações.
Cockburn (2000) define desenvolvimento ágil de software como uma
abordagem de desenvolvimento que trata os problemas em ambientes aonde
ocorrem mudanças rápidas. Um processo ágil implica em um processo adaptativo e
leve, que facilmente responde a mudanças (LARMAN, 2002). As metodologias ágeis
3 Sommerville (2004) afirma que os métodos ágeis são fundamentados no Desenvolvimento Incremental.
25 adaptam-se a novos fatores decorrentes do desenvolvimento (FOWLER, 2005) ao
invés de procurar analisar previamente tudo o que pode acontecer no andamento do
projeto.
Nas metodologias ágeis o cliente faz parte da equipe de desenvolvimento
(HILMAN, 2004). Segundo Cockburn (2000), a colaboração do cliente faz com que
certos documentos tornem-se desnecessários. A documentação provê condições
limitadas acordadas pelas partes que pode até funcionar, mas apenas com a
colaboração do cliente a equipe de desenvolvimento poderá entender e entregar o
que o cliente realmente quer (HIGHSMITH, 2002).
Os métodos ágeis podem ser considerados como um meio termo entre a
ausência de processo e o processo exagerado (ZANATTA, 2004). Optam por uma
documentação apropriada evitando redundâncias e excessos, para que esta auxilie
efetivamente o desenvolvimento do software (COSTA et alii, 2005). Aconselha a
criação de documentos que têm valor (HILMAN, 2004), em que somente a
documentação necessária é gerada.
Segundo Costa et alii (2005), outra característica importante das
metodologias ágeis é que enfatizam os aspectos humanos de desenvolvimento de
software ao invés dos aspectos de Engenharia. As metodologias ágeis reconhecem
a importância de processos e ferramentas, mas enfatiza que a iteração entre os
indivíduos tem muito mais importância (HIGHSMITH, 2002). Como os indivíduos são
únicos e com diferentes talentos, o processo deve ser guiado pela equipe
(HIGHSMITH, 2002), não pelas etapas que o compõem.
Outro aspecto interessante é apresentado por Camara (2007), de que as
propostas ágeis baseiam-se na compreensão de que um projeto de software segue
orientação em um serviço único, exclusivo. Um projeto nunca é igual ao outro, por
mais que existam padrões e aplique-se “militarmente” uma metodologia (CAMARA,
2007). Desta forma, espera-se atender melhor às necessidades e aos requisitos do
cliente, que na maioria das vezes são mutáveis.
É importante entender que as metodologias ágeis são uma atitude, não
um processo descritivo (HILMAN, 2004). É uma forma efetiva de se trabalhar em
conjunto para atingir as necessidades das partes interessadas no projeto (HILMAN,
26 2004). Reúnem boas práticas de programação e de gerenciamento de projetos a fim
de produzir software com qualidade. Propõem uma alternativa que busca a melhoria
do processo, tornando-o mais ágil e menos burocrático.
Os métodos classificados como ágeis possuem em comum o fato de
serem aplicados em projetos não muito complexos, utilizando ciclos iterativos curtos,
planejamento guiado por funcionalidades, retro-alimentação constante, tolerância a
mudanças, proximidade da equipe, intimidade com o cliente e foco no ambiente
geral de trabalho da equipe (HIGHSMITH, 2002). Entre as metodologias ágeis a
mais conhecida é a Extreme Programming (XP), que será apresentada na próxima
seção.
2.3.1 XP
A Extreme Programming (Programação Extrema) é um método eficiente,
flexível e de baixo risco para equipes pequenas e médias que desenvolvem software
com requisitos dinâmicos ou em constante mudança (BECK, 1999), criado em 1996
por Kent Beck e Ward Cunningham. De acordo com Beck (1999), XP representa
uma disciplina e não uma metodologia de desenvolvimento de software, pois é
baseada em um conjunto bem definido de regras que devem ser utilizadas durante
todo o projeto e não em seqüência de etapas pré-definidas.
Por ser uma metodologia ágil, XP carrega consigo todas as características
descritas anteriormente, desde o foco principal na satisfação do cliente até o
pressuposto de que mudanças nos requisitos sempre vão ocorrer (NETO, 2004).
Nos itens 2.3.1.1 e 2.3.1.2 a seguir serão tratados os valores e as práticas que
conduzem o processo de XP.
2.3.1.1 Valores
Extreme Programming enfoca e prioriza a melhoria do projeto baseada
em quatro valores diferentes: comunicação, simplicidade, feedback e coragem,
detalhados a seguir conforme Beck (1999), Burke & Coyner (2003), Highsmith (2002)
e Hightower & Lesiecki (2002).
27
• Comunicação: o objetivo da comunicação é prover um meio rápido e
eficaz entre os stakeholders4. A comunicação é um dos pontos mais
fortes de XP, pois busca dinamismo em um ambiente que a mudança
de requisitos pode ser uma constante.
• Simplicidade: escolher os mais simples protótipos, tecnologia,
algoritmos e técnicas que efetivamente atendam à especificação do
cliente. Aplicando o princípio da simplicidade minimiza-se o risco de
gastar muito tempo desenvolvendo sistemas sofisticados demais
comparado com o que o cliente quer.
• Realimentação: o feedback é crucial e é obtido através de pequenas
iterações/entregas freqüentes, testes junto ao cliente, programação em
pares/constante revisão do código, entre outros. Todo problema é
evidenciado o mais cedo possível, tanto pelo cliente quanto pela
equipe de desenvolvimento, para que possa ser corrigido.
• Coragem: é preciso coragem para implantar os três valores anteriores.
Coragem para fazer a coisa certa, no sentido de estar convicto e
acreditar nos valores da equipe. Se os valores da equipe não estão
alinhados, seus membros não estarão convictos de que as práticas
realizadas estarão corretas.
2.3.1.2 Práticas
Para delinear o processo de desenvolvimento, a XP foi estruturada
baseada em algumas práticas de implementação e gerenciamento, acrescentando
as idéias de processo. Segundo Beck (1999), nenhuma prática consegue se manter
por si só: é a sinergia de seu conjunto de sustenta o processo de desenvolvimento
de XP. Logo, as práticas devem ser utilizadas em conjunto e todas devem ser
aplicadas para obter-se agilidade no processo.
4 Conjunto de partes interessadas em um processo (WIKIPEDIA).
28
As doze práticas adotadas pela Extreme Programming estão descritas a
seguir (BECK, 1999; EXTREME PROGRAMMING; HIGHSMITH, 2002;
HIGHTOWER & LESIECKI, 2002).
• Planejamento: programadores e clientes juntos determinam o escopo
das próximas versões, combinando prioridade de atividades e
estimativas técnicas. Consiste em decidir o que é necessário ser feito
e o que pode ser adiado no projeto.
• Pequenas Versões: visa a construção inicial de um software simples e,
conforme surjam os requisitos, entregar versões atualizadas do
mesmo. Cada versão entregue deve ter o menor tamanho possível,
respeitando os requisitos prioritários do sistema.
• Metáfora: descrição do sistema sem a utilização de termos técnicos. A
metáfora fornece uma visão comum do sistema e guia o seu
desenvolvimento.
• Projeto Simples: o sistema deve ser projetado o mais simples possível,
satisfazendo os requisitos atuais, preocupando-se com requisitos
futuros quando eles realmente existirem. A equipe não desenvolve um
grande projeto inicial, porém projeta continuamente durante todo o
processo de desenvolvimento.
• Testes: o projeto deve ser validado durante todo o desenvolvimento.
Os programadores escrevem testes de unidade continuamente. Esses
testes são criados anteriormente ao processo de codificação e só
depois são executados. Os clientes descrevem testes de aceitação,
para validar se as funcionalidades foram implementadas de acordo
com o especificado. Os resultados dos testes devem ser publicados
para toda a equipe.
• Refatoração: é a técnica empregada na estruturação do código, cujo
objetivo é fazer com que o mesmo fique mais reutilizável e
compreensível, sem modificar seu comportamento. A refatoração deve
ser feita sempre que um desenvolvedor perceba que é possível
simplificar o código sem perder nenhuma funcionalidade.
29
• Programação em Pares: todo código produzido é realizado em dupla,
ou seja, dois desenvolvedores trabalham em conjunto no mesmo
computador. A programação em pares é uma prática colaborativa de
revisão de código. Esta prática assegura que todo código produzido é
revisado por pelo menos outro programador.
• Propriedade Coletiva: o código do projeto pertence a todos os
membros da equipe. Qualquer um pode alterar qualquer código a
qualquer momento. Vale lembrar que para garantir a aplicação desta
prática é importante a adoção de um sistema de controle de versões.
• Integração Contínua: uma nova parte do código deve ser integrada
assim que estiver pronta. Logo, o sistema é integrado e construído
várias vezes ao dia. Nesta prática também é importante um bom
sistema de controle de versões.
• Semana de 40 horas: trabalho além do horário normal pode ser
necessário, mas fazer horas extras por períodos maiores que uma
semana é sintoma de sérios problemas no projeto. Se necessário,
deve-se alterar o planejamento do projeto e não sobrecarregar as
pessoas.
• Cliente junto aos Desenvolvedores: os desenvolvedores devem ter o
cliente disponível durante todo o desenvolvimento do projeto para que
ele possa fornecer detalhes do sistema quando surgirem dúvidas. Uma
idéia interessante é manter o cliente como parte integrante da equipe
de desenvolvimento.
• Padronização do Código: é importante que exista um padrão de
codificação comum a todos os membros, o que mantém o mesmo
consistente e de fácil entendimento para toda a equipe. Um
programador deve entender um código escrito por outro. A adoção de
um estilo comum e convenções é necessária para que o código possa
ser compartilhado por todos.
30
2.4 COMPARAÇÃO ENTRE METODOLOGIAS
A maioria das metodologias ágeis não possui nada de novo (COCKBURN,
2000). Segundo Highsmith (2002), o que existe de novo nos métodos ágeis não são
as práticas que eles usam, mas os enfoques e os valores. Basicamente os métodos
ágeis se diferem dos tradicionais em dois aspectos (FOWLER, 2005):
• são adaptativos ao invés de prescritivos;
• são orientados às pessoas ao invés dos processos.
De acordo com Soares (2006), para uma metodologia ser efetivamente
ágil ela deve aceitar mudanças ao invés de tentar prever o futuro. O problema não é
a mudança em si, uma vez que mudanças são um aspecto intrínseco na vida do
software (HILMAN, 2004). O problema é como receber, avaliar e responder às
mudanças.
“Os modelos de processo convencionais adotam a estratégia de previsibilidade. Eles utilizam técnicas para levantar todos os requisitos e compreender o domínio do problema antes de iniciar o desenvolvimento. Depois de levantados os requisitos, é feito um planejamento para que as mudanças possam ser controladas no decorrer do processo de desenvolvimento do software. Os métodos ágeis optam pela adaptabilidade. Os requisitos são levantados aos poucos e o planejamento é contínuo, para que a adaptação às mudanças possa ocorrer.” (COSTA et alii, 2005)
Portanto, a principal diferença está na forma como as mudanças são
tratadas durante o desenvolvimento do software. Os métodos tradicionais planejam
previamente o projeto buscando controlar as mudanças (COSTA, 2006), enquanto
os métodos ágeis incentivam a mudança nos requisitos (SOARES, 2006),
planejando o projeto continuamente.
Para ilustrar como alterações no projeto são tratadas, o Gráfico 2.1
apresenta o custo do esforço de modificações conforme a fase do projeto,
considerando as abordagens tradicional e ágil. O eixo horizontal apresenta as fases
do ciclo do projeto e o eixo vertical mostra o custo de investimento percentual da
alteração comparado ao que já foi feito.
31
Gráfico 2.1 – Gráfico do preço de uma alteração no decorrer do projeto
Fonte: CAMARA, 2007
Analisando o gráfico anterior, observa-se que uma mudança de escopo
de uma funcionalidade na fase de Planejamento custa um esforço de re-trabalho em
torno de 25% para ambas as abordagens. Porém, nas fases mais adiantadas, a
diferença de esforço e custo é considerável. A alteração de requisitos é muitas vezes
crítica nas metodologias tradicionais, pois estas não apresentam meios de se
adaptar às mudanças. A análise prévia dos requisitos apresenta alto custo e caso se
queira fazer alguma mudança no planejamento, a qualidade do software pode ser
comprometida (SOARES, 2004), além de alterar a documentação já gerada.
Assumindo que mudanças de especificação sempre vão ocorrer em todos
os projetos, é possível afirmar que melhor será o projeto que mais se adaptar a
estas mudanças. No entanto, segundo Zanatta (2004),
“Os métodos pesados são considerados eficientes para grandes projetos com grandes equipes, tendo a disposição todos recursos disponíveis, inclusive os humanos. Projetos menores em pequenas organizações não necessitam deste rigor e formalismo, podendo inclusive ter projetos mais simplificados, pois a adaptação e o custo destes métodos podem ser um entrave para os pequenos desenvolvedores.”
Enquanto o foco das metodologias tradicionais está nos grandes projetos,
que necessitam de especificações detalhadas do mesmo, as metodologias ágeis têm
32 seu foco nos pequenos projetos, totalmente adaptável a mudanças, porém fraco na
parte de documentos (NETO, 2004).
Nas metodologias ágeis, para cada documento gerado em um projeto
deve haver uma justificativa de sua importância no projeto (HIGHSMITH, 2002). Na
abordagem ágil a documentação continua fundamental, mas a preocupação deve
ser em não desperdiçar tempo com a criação de documentos que não serão úteis
(FAGUNDES, 2005).
Conversação e comunicação são valores básicos dos processos ágeis. A
maneira padrão de troca de informações é a conversação (COCKBURN, 2000).
Além disso, o cliente participa assiduamente do processo de desenvolvimento.
Cockburn (2000) destaca que tanto a colaboração do cliente quanto de quem
desenvolve o software é necessária para produzir um produto de qualidade. Logo,
nas metodologias ágeis as pessoas são os principais condutores do sucesso do
projeto (HIGHSMITH, 2002). Nas metodologias tradicionais a garantia da qualidade
está em seguir corretamente as etapas de um processo.
Por estes motivos, as metodologias tradicionais devem ser utilizadas
somente quando os requisitos do sistema são estáveis e situações futuras são
previsíveis. Já as metodologias ágeis devem ser utilizadas quando não se sabe
exatamente o que se quer no início do projeto, pois permite que o software evolua
no decorrer do desenvolvimento do projeto.
As abordagens tradicional e ágil possuem os mesmos fundamentos,
utilizam as mesmas práticas, porém as práticas ágeis são baseadas em valores e
princípios (HIGHSMITH, 2002). Ao longo do estudo deste trabalho não foram
encontradas na bibliografia um estudo comparativo aprofundado sobre as duas
abordagens.
Considerando as características apresentadas, alguns aspectos
significativos entre a abordagem tradicional e a abordagem ágil de desenvolvimento
de software são apresentados na Tabela 2.1 (MAGALHÃES, 2004).
33
Tabela 2.1 – Comparação entre a Abordagem Tradicional e a Abordagem Ágil
Abordagem Tradicional Abordagem Ágil
Preditivo: detalhar o que ainda não é bem conhecido
Adaptativo: conhecer o problema e resolver o crítico primeiro
Rígido: seguir especificação predefinida, a qualquer custo
Flexível: adaptar-se a requisitos atuais, que podem mudar
Burocrático: controlar sempre, para alcançar objetivo planejado
Simplista: fazer algo simples de imediato e alterar, se necessário
Orientado a processos: segui-los possibilita garantir a qualidade
Orientado a pessoas: motivadas, comprometidas e produtivas
Documentação gera confiança Comunicação gera confiança
Sucesso = entregar o planejado Sucesso = entregar o desejado
Gerência = “comando-e-controle” voltado para trabalho em massa, ênfase no papel do gerente, com forte planejamento e disciplina fortes
Gerência = liderança/orientação trabalhadores do conhecimento, ênfase na criatividade, flexibilidade, atenção às pessoas
Desenvolvedor hábil (variedade) Desenvolvedor ágil (colaborador)
Cliente pouco envolvido Cliente comprometido (autonomia)
Requisitos conhecidos, estáveis Requisitos emergentes, mutáveis
Retrabalho/reestruturação caro Retrabalho/reestruturação barato
Planejamento direciona os resultados (incentiva a controlar).
Resultado direciona o planejamento (incentiva a mudar)
Conjunto de processos, com metodologia definida
Conjunto de valores, com atitudes e princípios definidos
Premia a garantia da qualidade Premia o valor rápido obtido
Foco: grandes projetos ou os com restrições de confiabilidade, planejamento estratégico/priorização (exigem mais formalismo)
Foco: projetos de natureza exploratória e inovadores, com equipes pequenas e médias (exigem maior adaptação)
Objetivo: controlar, possibilitando alcançar o objetivo planejado (tempo, orçamento, escopo)
Objetivo: simplificar processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos
34
3 EASYPROCESS – YP
Este capítulo apresenta a metodologia ágil EasYProcess, que será
utilizada posteriormente para a modelagem do componente de software.
3.1 INTRODUÇÃO
EasyProcess (YP) é uma metodologia de desenvolvimento de software
para o desenvolvimento de projetos acadêmicos. Esta metodologia foi idealizada
pela Professora Drª Francilene Procópio Garcia, da Universidade Federal de
Campina Grande (UFCG), e foi concebida no ambiente do grupo PET Computação
desta mesma universidade, no ano de 2003.
YP foi moldado com base nas características de um projeto de
desenvolvimento de software acadêmico, como por exemplo, o escopo pequeno, em
virtude da duração de um semestre, e a utilização de tecnologias consideradas
estado da arte. Além disto, esta metodologia prima pela boa produtividade do
projeto, amparado pelo uso de boas ferramentas de apoio e pela geração mínima de
artefatos de software. EasyProcess é uma metodologia simples e de fácil
entendimento pelos integrantes da equipe, porém é completa e robusta a ponto de
gerar produtos de qualidade.
Esta metodologia está apoiada em práticas do XP, RUP e Agile Modeling,
utilizando o que foi considerado mais adequado em cada uma delas em relação ao
ambiente acadêmico. As fases do EasyProcess, conforme Garcia (GARCIA et alii,
2007), são descritas a seguir.
3.1.1 IDENTIFICAÇÃO DO ESCOPO DO PROBLEMA
Consiste no estudo inicial do escopo, a fim de obter-se conhecimento
prévio como a base para o entendimento e argumentação para a fase de conversa
com o cliente, a qual será descrita posteriormente.
35 3.1.2 ESPECIFICAÇÃO DE PAPÉIS
É esperado que a equipe que participa do desenvolvimento do software
seja dividida em papéis, os quais têm um conjunto de responsabilidades que
deverão ser desempenhadas durante as partes específicas do processo.
O EasyProcess recomenda a utilização de cinco papéis:
• Cliente: é a pessoa que solicitou o desenvolvimento do software. Suas
principais atividades são: definir os requisitos do sistema, priorizar as
funcionalidades, ajudar na elaboração do plano de releases5, explicitar
os testes de aceitação, identificar o perfil do usuário, identificar os
objetivos de usabilidade, validar o protótipo de interface, validar o
projeto arquitetural e ser ativo no processo de desenvolvimento do
sistema. O ideal seria que o cliente estive presente o máximo de
tempo possível com os desenvolvedores, seja na definição do sistema,
no refinamento do protótipo ou na implementação dos testes de
aceitação.
• Usuário: esta é a pessoa que irá utilizar o sistema produzido, assim o
desenvolvimento do software deve atentar para as características
desta pessoa. Logo, a presença do mesmo no desenvolvimento do
software seria de grande. Suas principais responsabilidades são:
ajudar na definição dos testes de aceitação, ajudar na identificação
dos objetivos de usabilidade, validar o protótipo de interface e avaliar
continuamente a interface do sistema.
• Gerente: é aquele que toma decisões referentes aos riscos e rumos do
projeto, sendo responsável por coordenar as atividades de todos os
outros membros do projeto. Suas competências abrangem: conduzir
os planejamentos e as ações dos desenvolvedores, elaborar o plano
de desenvolvimento, avaliar sistematicamente os riscos descobertos,
gerenciar configurações, coletar e analisar métricas, alocar testadores,
5 Criação e disponibilização de uma nova versão de um produto de software (WIKIPEDIA).
36
resolver conflitos internos, tornar a documentação do projeto sempre
atualizada e acessível.
• Desenvolvedor: é responsável por modelar os requisitos do sistema e
produzir a codificação eficiente e correta para tais requisitos. O
desenvolvedor deve utilizar-se de testes unitários a fim de encontrar
erros em seu código e corrigi-los. As principais responsabilidades da
pessoa que assume este papel são: levantar os requisitos funcionais e
não funcionais junto com o cliente, auxiliar o gerente na elaboração de
um plano de desenvolvimento, analisar e modelar cada tarefa, gerar
um protótipo da interface, identificar os objetivos de usabilidade, gerar
testes de unidade, elaborar o projeto arquitetural – o qual deve ser
validado pelo cliente –, construir o modelo lógico de dados e manter a
integração contínua de código.
• Testador: é responsável por realizar testes de integração do sistema,
por revisar os códigos dos desenvolvedores, refatorar se possível
àqueles códigos a fim de torná-lo mais simples, legível, flexível e claro.
Porém, caso haja um refatoramento de código, é necessário que o
código seja testado tanto antes quanto depois do refatoramento,
garantindo assim que as funcionalidades permaneçam intactas. Além
disso, o testador deve gerar os testes de aceitação e elaborar o
material para realização dos testes de usabilidade.
3.1.3 CONVERSA COM O CLIENTE
Trata-se da primeira conversa entre o cliente e os desenvolvedores do
sistema, tendo como objetivo fazer com que ambas as partes tenham uma idéia
comum a respeito do sistema em questão. Ao final desta fase o escopo do problema
deve estar bem definido, deve-se conhecer o perfil dos usuários e suas
necessidades. Além disso, deve-se saber quais os requisitos funcionais e não
funcionais do sistema e deve-se também listar os riscos do projeto. Para tal, o
EasyProcess utiliza-se de recursos tais como os enumerados a seguir.
37 3.1.3.1 Documento de Visão
Após a conversa inicial com o cliente, o documento de visão deve ser
criado utilizando-se uma linguagem de fácil entendimento para o cliente, visto que
este será um elo de comunicação entre o cliente e o desenvolver. O documento de
visão deverá conter as idéias gerais sobre o que o sistema se propõe a fazer. Depois
de concluído este documento pelos desenvolvedores, o mesmo deve ser validado
pelo cliente, a fim de verificar se aqueles compreenderam a visão do sistema. Este
documento é de suma importância pois serve como uma espécie de contrato entre
as partes envolvidas.
3.1.3.2 Requisitos
Dentro do Documento de Visão deve haver uma sessão onde são
descritos os requisitos funcionais e não funcionais do projeto. Os requisitos são
características e funções de um sistema. Os requisitos funcionais descrevem as
funções que o software deve possuir. Já os requisitos não funcionais descrevem as
propriedades e restrições do sistema. Os requisitos não funcionais podem ser, por
exemplo, usabilidade, manutenabilidade e desempenho. Estes requisitos devem ser
descritos pelos desenvolvedores em conjunto com o cliente.
3.1.3.3 Perfil do Usuário
São as descrições das características dos usuários reais do sistema que
são relevantes para o desenvolvimento do software. Estas descrições devem revelar
as habilidades, as preferências, as limitações, os interesses dos usuários e o
conhecimento prévio dos mesmos em relação às atividades que o sistema irá
desempenhar e ao uso do computador. A descrição do perfil dos usuários pode
aparecer no Documento de Visão. A seguir é apresentada uma lista de
características relevantes a serem observadas na primeira conversa com cliente,
segundo o documentação do EasyProcess:
• sexo;
• canhoto, destro ou ambidestro;
• uso de lentes corretivas;
• faixa etária;
38
• experiência prévia no uso de sistemas computacionais;
• tempo de uso de sistemas computacionais;
• freqüência de uso de sistemas computacionais;
• plataforma computacional que utiliza com maior freqüência;
• conhecimento prévio de uma outra versão do sistema que está sendo
desenvolvido (melhorado);
• freqüência de uso de tal versão;
• familiaridade com a língua inglesa.
3.1.3.4 Objetivos de Usabilidade
Define quais metas de usabilidade devem ser atingidas pelo software
desenvolvido. Servem para avaliar a usabilidade do sistema com base no
desempenho do usuário e deve ser desenvolvido pelo cliente e pelo usuário.
Geralmente estas metas referem-se à eficácia, eficiência, capacidade do
sistema de ser aprendido pelos usuários, e pela a segurança. A eficácia diz respeito
à forma com que as tarefas são realizadas e a disposição das informações
necessárias para que a tarefa seja realizada. A eficiência trata do auxílio prestado ao
usuário, pelo sistema, na realização de suas atividades.
3.1.4 INICIALIZAÇÃO
Após a fase de conversa com o cliente e de criação do Documento de
Visão, dá-se inicio a fase de Inicialização, a qual é composta por cinco atividades,
descritas a seguir.
3.1.4.1 Modelagem da Tarefa
Sua função é esclarecer os detalhes de cada tarefa do sistema. A
modelagem da tarefa auxilia na geração da interface do sistema, visto que a mesma
identifica as relações de hierarquias e dependência entre as sub-tarefas. Este
39 modelo pode ser realizado com a utilização da ferramenta iTAOS. Um exemplo de
modelagem pode ser observado na Figura 3.1.
Figura 3.1 – Modelo da Tarefa
O software iTAOS é uma ferramenta gráfica para análise e modelagem de
tarefas que utiliza o formalismo TAOS. Por sua vez, o TAOS é um formalismo que
inicialmente visava a construção de um Sistema Baseado em Conhecimento e foi
validado no ramo da biologia molecular. Também é usado para a modelagem de
tarefas, uma vez que o TAOS abrange todos os requisitos que a modelagem da
tarefa exige (GARCIA et alii, 2007).
3.1.4.2 Definição das User Stories
Esta é a fase do projeto em que são definidas as User Stories e estima-se
o tempo de desenvolvimento para cada uma delas. User Stories são funções que o
sistema deve desempenhar e que são definidas pelo cliente e pelo desenvolvedor.
Após a definição das User Stories envolvidas no projeto, e que pode sofrer
alterações no decorrer do tempo, é possível construir uma tabela com as User
Stories do sistema e suas respectivas estimativas, como observado na Tabela 3.1,
retirada do site oficial da metodologia YP.
40
Tabela 3.1 – Tabela de User Stories
User Stories Tempo Estimado (Horas)
US1 – Cadastro dos clientes, incluindo dados profissionais e pessoais. 8
US2 – Cadastro dos produtos que serão comercializados, descrevendo as particularidades de cada produto.
6
US3 – Cadastro de categorias. Estas categorias dizem respeito às possíveis classificações a que um cliente pode pertencer.
4
US4 – Fazer registro das vendas efetuadas, incluindo informações dos produtos vendidos e do cliente.
8
US5 – Implementar mecanismo de busca para produtos (por nome, por código, por preço) e clientes (por nome, por categoria, por CPF).
4
3.1.4.3 Protótipo de Interface
Permite visualizar como se dá a interação do usuário com o sistema. O
protótipo de interface pode ser construído com base no modelo de tarefas criado
anteriormente.
3.1.4.4 Modelo Lógico de Dados
Trata-se da modelagem das entidades de domínio em um banco de
dados, se houver a necessidade.
3.1.4.5 Projeto Arquitetural
O Projeto Arquitetural é um artefato que permite explicitar como as partes
do sistema interagem entre si ou com outros sistemas. Ele descreve o software com
um alto nível de abstração. Com este diagrama, o qual pode também apresentar
uma descrição do mesmo, é possível identificar os pontos críticos do sistema, as
dependências e os requisitos não funcionais levantados junto com o cliente.
A fim de tornar ciente a arquitetura geral do sistema é importante a
presença de todos os desenvolvedores na elaboração do mesmo, e para que haja a
validação do que foi elaborado, faz-se necessário a presença do cliente.
41 3.1.5 PLANEJAMENTO
Esta fase do processo é marcada pelo planejamento de como o projeto
será desenvolvido no tempo. Considerando que o YP foi elaborado com base em
projetos acadêmicos, tal metodologia aconselha a duração de três meses para o
desenvolvimento do software, sendo este tempo dividido em três partes,
denominadas releases, sendo estes releases divididos em duas partes, chamadas
de iterações. Logo, esta fase de planejamento divide-se em planejamento de release
e de iteração.
O planejamento de release diz respeito à alocação das User Stories nos
releases existentes, atentando sempre para as exigências do cliente em relação a
qual User Story deve ser realizada primeiramente, e para o fato de que se deve
primeiro alocar as User Stories que representam um maior risco para o projeto, pois
o risco do projeto ser abortado depois de muito tempo é minimizado. É notável
lembrar que todas as User Stories devem ter pelo menos um teste de aceitação.
Portanto, uma User Story somente poderá ser considerada finalizada após a
execução dos testes de aceitação. Uma vez que cada User Story alocada seja
finalizada após a aceitação do cliente, pode-se considerar que tudo o que foi
implementado funcione satisfazendo a especificação do projeto (GARCIA et alii,
2007).
Após a fase de planejamento de release dá-se a fase de planejamento de
iteração. O planejamento de iteração é a divisão das User Stories, as quais estavam
anteriormente englobadas em releases, em iterações. Cada User Story pode, se
preciso, ser dividida em atividades com o intuito de facilitar a implementação de tal
User Story e o gerenciamento da mesma. Portanto, cada iteração será um conjunto
de atividades a serem desenvolvidas e, por sua vez, cada release será um conjunto
de iterações.
Para auxiliar no planejamento das releases e das iterações é possível
construir uma matriz de competência, mapeando as habilidades de cada membro da
equipe e suas respectivas horas de dedicação semanal ao projeto.
As atividades oriundas das divisões das User Stories devem estar
explicitadas na Tabela de Alocação de Atividades (TAA) contendo, para cada
42 atividade, o tempo de desenvolvimento e o responsável pela mesma. Um detalhe
interessante a ressaltar é que o tempo de desenvolvimento de cada atividade é
estimado pelo próprio desenvolver responsável, respeitando o tempo estabelecido
pela iteração.
Por fim, o EasyProcess define que em hipótese nenhuma deve haver
alteração no tempo dos releases ou iterações, e que caso haja uma necessidade de
reajuste, o escopo é que deve ser alterado. Além disso, é de extrema importância a
disponibilização, por parte do gerente, de todo o planejamento realizado em um local
onde todos os membros da equipe possam acessar.
3.1.6 IMPLEMENTAÇÃO
As atividades definidas no plano de iteração são realizadas nesta fase. O
principal artefato construído é o código do sistema. Com o intuito de gerar uma boa
codificação, o EasyProcess apresenta algumas práticas a serem seguidas.
3.1.6.1 Propriedade Coletiva de Código
Toda a equipe é responsável por cada arquivo de código do sistema, não
necessitando assim que se peça autorização para o criador do arquivo para que se
possa fazer modificações no mesmo. Portanto, o código é propriedade coletiva e
conseqüentemente, toda a equipe é responsável por ele.
Com esta prática é possível atingir uma melhoria continua do software e
uma melhor recuperação de falhas, uma vez que trechos problemáticos de código
podem ser identificados e resolvidos com mais facilidade por determinados membros
da equipe, enquanto que outros não teriam a capacidade suficiente para realizar tal
tarefa. Porém, para que a propriedade coletiva do código seja efetuada com
sucesso, é preciso que os códigos desenvolvidos sejam limpos, claros e de fácil
entendimento, além de haver um controle de versão, a fim de saber quem está
alterando cada parte de código em determinado momento, evitando conflitos.
43 3.1.6.2 Boas Práticas de Codificação
Com o intuito de gerar um código limpo, o EasyProcess recomenda a
aplicação de práticas como: Design Simples, Refatoramento, Padrões de Projeto e
Padrões de Codificação. Estas práticas são descritas a seguir.
• Design Simples: o objetivo desta prática é atingir a geração do melhor
código possível, ou seja, um código de fácil entendimento, auto-
explicativo e de bom desempenho. Portanto, faz-se necessário atentar
para a utilização correta da flexibilização de código, uma vez que esta
prática, quando em excesso, pode levar a produção de código
desnecessário.
• Padrões de Codificação: com o objetivo de facilitar o entendimento do
código gerado por todos os membros da equipe, os mesmos devem
antes de começar o desenvolvimento do projeto, acordar questões
relativas ao padrão do código a ser desenvolvido. Nomenclatura de
variáveis e métodos, tamanho da identação utilizada, posição dos
parênteses e chaves, são exemplos de questões a serem acordadas.
• Padrões de Projeto: a fim de ganhar tempo, garantindo eficiência, e
fazer com que o produto final se aproxime de um produto de
qualidade, faz-se importante a utilização de padrões de projeto, os
quais são soluções previamente pensadas e testadas, de qualidade
assegurada, para a solução de diversos problemas comuns ao
desenvolvimento de software.
• Refatoramento: são pequenas modificações sobre o código
considerado completamente testado e aceito como funcionando 100%,
que visam melhorar algumas qualidades não funcionais, como por
exemplo: simplicidade, flexibilidade, desempenho e clareza do código.
Para tanto, é preciso que o tempo necessário para a execução do
refatoramento seja previsto no planejamento da iteração. Além disso, o
EasyProcess recomenda utilizar o controle de versão para dar suporte
a esta prática.
44 3.1.6.3 Integração Contínua
Como forma de melhorar o gerenciamento do projeto e o trabalho dos
desenvolvedores, caso estes não possuam horários em comum, o EasyProcess
utiliza-se da integração contínua de código.
Na medida em que o código é produzido e testado é importante que o
mesmo seja integrado continuamente ao sistema como um todo, e para isso faz-se
necessário a utilização de ferramentas com tal funcionalidade como, por exemplo, o
CVS (Current Version System) e o SVN (Subversion).
Com a utilização desta prática, a coleta de métricas por parte do gerente
do projeto fica mais consistente, facilitando a análise real do desenvolvimento, uma
vez que o produto do desenvolvimento está todo centralizado.
3.1.6.4 Testes
Para assegurar, na medida do possível, a qualidade e corretude do
sistema, e conseqüentemente a satisfação do cliente e do usuário, o YP recomenda
principalmente três tipos de testes:
• Teste de Unidade: testa a estrutura interna do código, ou seja, a lógica
e o fluxo de dados. Recomenda-se que os testes de unidade sejam
realizados antes da codificação, pois esta é uma conduta que ajuda na
solução do problema e melhora a qualidade do código desenvolvido.
Devem ser validados aspectos como: condições de limite, tratamento
de erros, manipulação de dados inconsistentes e impróprios.
• Teste de Aceitação: são situações definidas pelo cliente sobre como
medir o sucesso do projeto. Usuários finais podem ser ouvidos
também na definição destes testes para reforçar aspectos levantados
pelo cliente. A elaboração destes testes é feita durante o levantamento
das User Stories, porém a realização dos mesmos é feita após a
finalização da User Story.
• Teste de Usabilidade: Serve para verificar se os testes de usabilidade
definidos pelo cliente e pelos usuários foram satisfeitos, servindo
também como forma de verificar o grau de iteração dos usuários com
45
o sistema. Para tal, o EasYProcess utiliza-se do roteiro de atividades e
do questionário pós-teste. Este último tem por objetivo identificar o
grau de satisfação do usuário ao utilizar o sistema e deve ser
executado após a elaboração do roteiro de atividades. Durante a
execução do roteiro de atividades deve-se atentar ao levantamento de
indicadores quantitativos, como por exemplo: número de erros
repetidos, número de acessos à área de ajuda do software e tempo
para realização das tarefas. Portanto, o YP recomenda a seguinte
seqüência de passos para a execução dos testes de usabilidade:
elaborar o roteiro de atividades; recrutar os usuários para teste;
observar os usuários executando as atividades do roteiro; colher os
indicativos quantitativos para análise; aplicar questionários pós-teste;
analisar os resultados obtidos e sanar as falhas detectadas.
3.1.7 FINALIZAÇÃO DA ITERAÇÃO
Ao final da implementação e teste de uma iteração, deve-se preencher os
campos de status e tempo real de desenvolvimento de cada atividade da iteração na
Tabela de Alocação de Atividades (TAA). Caso haja mais alguma iteração ou release
a ser desenvolvida, deve-se voltar para a fase de planejamento de release e seguir
toda a seqüência de passos seguintes.
3.1.7.1 Reuniões de Acompanhamento
Esta fase do processo deve ocorrer semanalmente em reuniões que
visam recolher e analisar métricas, utilizando-se do Big Chart – explicado a seguir –
e da Tabela de Alocação de Atividades.
Com as reuniões de acompanhamento, o gerente do projeto tem uma
visão dos resultados obtidos pela equipe em uma semana de trabalho. A partir daí o
gerente é capaz de identificar os pontos fortes e fracos do projeto, podendo então
tomar as atitudes cabíveis a fim de melhorar o andamento e o sucesso do mesmo.
O Big Chart pode ser visto como a análise quantitativa do andamento do
projeto. As métricas são definidas pelo gerente do projeto de acordo com os pontos
46 a serem analisados, como por exemplo: número de classes existentes, número de
linhas de código, número de testes de aceitação prontos, testes de unidades que
estão rodando perfeitamente, dentre outros. Com este gráfico é possível identificar
se o projeto apresentou mudanças no decorrer da semana em questão, ou se
ocorreu algo inesperado, como exemplo, o aumento do número de classes e a
manutenção no número de testes de unidade.
Durantes estas reuniões os desenvolvedores podem solicitar que os seus
códigos sejam refatorados quando percebem que os mesmos não foram gerados da
melhor forma possível. Esta é a chamada necessidade de refatoramento explicito.
Porém esta prática deve acontecer com pouca freqüência, visto que é
responsabilidade do desenvolvedor criar o seu melhor código.
Além disso, a gerência de risco deve estar sempre em pauta nestas
reuniões, uma vez que essa metodologia foi proposta para diminuir os riscos através
da verificação constante da situação do projeto. Riscos são situações indesejáveis
que ocorrem durante o processo de desenvolvimento. Alguns exemplos comuns são:
custo do projeto, prazo determinado para o desenvolvimento do projeto e uso de
tecnologias desconhecidas por parte da equipe. Para realizar a gerência de riscos, o
EasyProcess utiliza-se da tabela de riscos, uma tabela contendo o risco identificado,
a data de identificação, o responsável pela solução, o grau de prioridade e a solução
encontrada. Com a tabela de risco é possível manter um histórico dos riscos
encontrados e suas respectivas soluções a fim de agilizar a solução dos riscos
futuramente identificados.
Outro fator que deve ser considerado em reuniões de acompanhamento é
a necessidade de mudanças. Existem vários tipos de mudanças e cada uma tem o
seu grau de impacto no andamento do projeto. Algumas implicam apenas em
modificações de implementação, outras em alocações de tarefas, outras em
alterações no planejamento ou ainda do modelo lógico e projeto da arquitetura.
Logo, cada mudança identificada deve ser analisada cuidadosamente pelo gerente
do projeto, o qual tomará as atitudes cabíveis em resposta ao acontecimento. Cabe
lembrar que o tempo determinado para as iterações e releases não deve ser
47 alterado, mesmo em decorrência destas mudanças, restando a alteração do escopo
do prometido, uma vez acordado com o cliente anteriormente.
3.1.8 VERSÃO DO PRODUTO
Após a finalização do sistema, realizam-se os testes de usabilidades
sobre o mesmo, feito pelos usuários, e, caso o resultado seja positivo, gera-se a
versão final do produto.
48
4 PROPOSTA DO COMPONENTE DE SOFTWARE
Este capítulo apresenta a aplicação da metodologia EasYProcess na
construção de um componente de software open source, que será disponibilizado no
Repositório do Projeto Via Digital.
4.1 INTRODUÇÃO
Governo Eletrônico é uma tendência global (WIKIPEDIA). Com o advento
da internet, governos de todo o mundo têm concentrado esforços no
desenvolvimento de políticas e definições de padrões visando construir uma
arquitetura interoperável a fim de melhorar as relações do governo com os cidadãos
(GOVERNO ELETRÔNICO). O desenvolvimento de programas de e-Gov tem como
princípio a utilização de tecnologias de informação e comunicação para democratizar
o acesso à informação e dinamizar a prestação de serviços públicos com foco na
eficiência das funções governamentais (GOVERNO ELETRÔNICO).
Como exemplo de iniciativa nesta área existe o Projeto Via Digital. A
proposta do Projeto Via Digital é a criação de um serviço que integre um repositório
de componentes open source, propiciando a construção de um acervo público de
soluções com foco na realidade de pequenas prefeituras.
A opção pelo software livre não pode ser entendida somente como
motivada por aspectos econômicos, mas também na preocupação em garantir ao
cidadão o direito de acesso aos serviços públicos sem obrigá-lo a usar plataformas
específicas (GOVERNO ELETRÔNICO).
4.2 COMPONENTE
Dentro do contexto do Projeto Via Digital pretende-se construir o CGC –
Componente para Gerência de Cemitérios. A escolha pelo módulo de Cemitérios
foi baseada no fato de que para este módulo há nenhum software publicado no
repositório do projeto. Além disso, a simplicidade do desenvolvimento deste tipo de
aplicação facilitará o estudo da metodologia ágil EasYProcess.
49
Durante o desenvolvimento de um projeto é fundamental a presença de
uma pessoa que tenha o conhecimento sobre o problema, que esteja familiarizada
com o cenário da aplicação e que possa estar disponível durante o processo. Para o
desenvolvimento do componente pôde-se contar com a ajuda de Renata Susan da
Silva. Renata é administradora do Cemitério São Cristóvão da Prefeitura Municipal
de Florianópolis. Logo, a equipe de desenvolvimento será formada pela autora do
trabalho e pela administradora do cemitério.
4.3 DESENVOLVIMENTO DO COMPONENTE
Conforme já mencionado, o desenvolvimento do componente será
baseado no fluxo de trabalho da metodologia ágil EasYProcess.
4.3.1 IDENTIFICAÇÃO DO ESCOPO DO PROBLEMA
O Cemitério fisicamente está dividido em quadras. Uma quadra é uma
zona do cemitério. Nas quadras, encontram-se as sepulturas. Cada sepultura tem
um dono e um enterro associada a ela.
Existem basicamente dois fluxos de controle para a gerência de um
cemitério. O primeiro, o controle de posse dos terrenos. O outro, o controle dos
sepultamentos. Portanto, é necessária a implementação do cadastro de compra dos
terrenos e dos sepultamentos.
4.3.2 ESPECIFICAÇÃO DE PAPÉIS
O YP recomenda a divisão da equipe em cinco papéis, cada papel
responsável por um conjunto de tarefas. É essencial que todos os papéis estejam na
equipe, porém um papel não corresponde necessariamente a uma pessoa da
equipe, podendo uma pessoa desempenhar vários papéis simultaneamente
(GARCIA et alii, 2007).
Para o desenvolvimento desta aplicação têm-se apenas duas pessoas na
equipe de desenvolvimento. Considerando o escopo do projeto e as habilidades dos
integrantes da equipe a definição de papéis foi realizada conforme a Tabela 4.1.
50
Tabela 4.1 – Definição de Papéis
Equipe Papéis
Renata Cliente, Usuário
Cecília Gerente, Desenvolvedor, Testador
4.3.3 CONVERSA COM O CLIENTE
A coleta inicial de informações sobre o sistema foi feita na primeira
conversa com o cliente. Para essa conversa foi elaborado um roteiro de perguntas
buscando extrair as informações mais importantes sobre o software, que está no
Apêndice A. O objetivo é fazer com que o cliente e o desenvolvedor tenham uma
idéia comum a respeito do funcionamento do sistema.
Segundo a documentação do EasYProcess, concluída a conversa com o
cliente a primeira tarefa passa a ser a elaboração de um documento de visão, que
deve conter as características gerais do sistema. Para o problema em questão foi
gerado um documento de visão contendo as seguintes informações: descrição do
sistema, definição do escopo, requisitos funcionais, requisitos não-funcionais, perfil
do usuário e objetivos de usabilidade. O documento encontra-se no Apêndice B. As
informações contidas no documento gerado foram baseadas em conversas com o
cliente sobre o domínio do problema, salvo os requisitos não-funcionais, que foram
definidos a partir das exigências do Projeto Via Digital e das aptidões do
desenvolvedor.
4.3.4 INICIALIZAÇÃO
Logo após a equipe de desenvolvimento ter uma idéia geral sobre o
problema a ser resolvido, devem ser iniciadas algumas atividades de análise do
sistema. O objetivo é fazer um Modelo da Tarefa para que sirva de base para a
construção do Protótipo da Interface, que tem a função de receber o feedback do
cliente para listar todas as User Stories do sistema a fim de desenvolver uma
Arquitetura e um Modelo Lógico de Dados. De acordo com Garcia et alii (2007),
51 vale a pena investir tempo nesta etapa, pois com um bom entendimento do sistema
sob diversos aspectos, a fase de implementação apresenta menos problemas.
A primeira atividade realizada foi a análise da tarefa, a fim de melhorar a
compreensão do desenvolvedor com relação às partes que compõem a tarefa e a
ordem com que devem ser executadas. O estudo da tarefa foi baseado em
conversas entre cliente e desenvolvedor. A partir desta análise foi construído o
Modelo da Tarefa, dividindo a tarefa em sub-tarefas e definindo a seqüência de
realização das mesmas. O Modelo da Tarefa gerado foi construído utilizando o
formalismo iTAOS, conforme a sugestão da documentação do EasYProcess, e está
disponível no Apêndice C.
O próximo passo foi a elaboração das User Stories do sistema, aonde o
cliente define o que o sistema deve ter e fazer. É com base nas User Stories que as
funções do sistema são implementadas. A lista de User Stories encontra-se no
Apêndice D, lembrando que os testes de aceitação foram definidos na fase de
planejamento.
A partir do Modelo da Tarefa e dos requisitos do cliente foi construído o
Protótipo da Interface. Embora o YP preconize a construção de protótipos simples,
com o uso da ferramenta Dreamweaver foi possível gerar protótipos em formato
HTML, que posteriormente foram utilizados na implementação. Os protótipos
gerados podem ser visualizados no Apêndice E.
Como o sistema envolve um banco de dados, nesta fase também deve
ser construído um Modelo Lógico de Dados, capaz de representar a estrutura lógica
do banco. Uma vez que o banco de dados utilizado é o MySQL Server, para a
criação deste modelo foi utilizado o editor visual para criação de banco de dados
MySQL DBDesigner. O modelo encontra-se no Apêndice F.
A última atividade da fase de inicialização é a construção do Projeto
Arquitetural. Este projeto deve ser construído com base nos requisitos não-
funcionais do sistema. O YP sugere que o Projeto Arquitetural contenha um
diagrama com a estrutura da arquitetura e, se necessário, um texto que explique de
forma objetiva os aspectos de maior relevância no sistema, conforme apresentado
no Apêndice G.
52 4.3.5 PLANEJAMENTO
No EasYProcess a fase de planejamento é composta por duas etapas, o
planejamento de release e o de iteração. Nesta etapa a equipe deve definir junto
com o cliente o número de releases e iterações necessárias para a conclusão do
projeto.
Depois que todas as User Stories foram definidas deve ser iniciado o
planejamento de release. O plano de release consiste em definir o período dos
releases e a partir de então dividi-los em iterações. O YP propõe que o planejamento
seja focado em pequenos releases, garantindo uma maior iteração com o cliente
(GARCIA et alii, 2007). Considerando o tempo de desenvolvimento e a
complexidade do sistema, o projeto foi dividido em duas releases de 6 dias, que por
sua vez, foi dividida em duas iterações de 3 dias.
Nesta etapa também o cliente define os testes de aceitação, que
descrevem cenários que devem ser suportados pelo sistema. Os testes foram
anexados à lista de User Stories apresentada no Apêndice D. Cada User Story deve
estar associada a pelo menos um teste de aceitação.
Depois, as User Stories com seus respectivos testes de aceitação devem
ser distribuídas nas iterações do release em questão. A alocação das User Stories
deve levar em consideração a priorização e a complexidade das atividades. Vale
lembrar que a alocação das mesmas deve ser feita para o próximo release, pois
planejar releases a frente significa que mudanças ou aparecimento de novos
requisitos podem vir a invalidar um planejamento de atividades ainda distantes
(GARCIA et alii, 2007). Logo, o planejamento do segundo release só foi realizado ao
final do primeiro. O plano de release é apresentado na Tabela 4.2, a seguir.
53
Tabela 4.2 – Plano de Release
Release 01 (06/06/2007 – 13/06/2007) Gerente – Cecília
Iteração User Stories Período Iteração 01 US01 06/06/2007 a 08/06/2007 Iteração 02 US02 11/06/2007 a 13/06/2007
Release 02 (27/06/2007 a 04/07/2007) Gerente – Cecília
Iteração User Stories Período Iteração 03 US03 27/06/2007 a 29/06/2007 Iteração 04 US04 02/07/2007 a 04/07/2007
Após o planejamento de release dá-se início ao planejamento de iteração.
Nesta etapa as Users Stories da iteração foram quebradas em atividades menores e
depois documentadas na Tabela de Alocação de Atividades (TAA). Nesta tabela há
informações sobre estimativa de tempo, tempo real, responsável e status do
desenvolvimento para cada uma das atividades.
Assim como no planejamento de release, o planejamento da próxima
iteração é realizado somente ao término da anterior. Portanto, nota-se que neste
momento a TAA não é completamente construída, pois campos como tempo real
para a conclusão da atividade e status só serão preenchidos no final da iteração. A
versão final deste documento está disponível do Apêndice H.
Pelo fato da equipe de desenvolvimento ser composta por um membro,
não houve necessidade da construção da Matriz de Competência.
4.3.6 IMPLEMENTAÇÃO
Nesta fase foram realizadas as atividades estabelecidas no plano de
iteração. O objetivo desta etapa é obter uma versão codificada do sistema.
Primeiramente foi gerado o banco de dados da aplicação. O editor visual
DBDesigner também gera scripts para criação de banco de dados. Logo, a partir do
Modelo Lógico de Dados apresentado no Apêndice F foram gerados scripts para a
criação do banco.
O próximo passo foi a configuração do ambiente de programação. A
linguagem de programação utilizada no projeto foi Java, versão Enterprise (JEE). A
IDE de programação na qual a aplicação foi desenvolvida é o MyEclipse. A
54 arquitetura do sistema foi construída de acordo com o Projeto Arquitetural,
explicitado no Apêndice G. As páginas HTML do Protótipo da Interface apresentado
no Apêndice E foram renomeadas para JSP e colocadas no diretório WebRoot. A
estrutura de diretórios do sistema é apresentada na Figura 4.1.
Figura 4.1 – Estrutura de Diretórios
Antes da construção do código devem ser elaborados os testes de
unidade (GARCIA et alii, 2007), para avaliar a conexão com o banco e o fluxo dos
dados. Uma vez que o sistema utiliza operações simples e sem restrições, os testes
de unidade foram realizados manualmente.
Depois, foi iniciada a geração de código. Segundo a documentação do
EasYProcess, para que a implementação do sistema resulte em uma boa
codificação é necessário que a equipe de desenvolvimento considere algumas
práticas, descritas anteriormente na seção 3.6.1.
Na tentativa de gerar um código limpo, de fácil entendimento e com
qualidade, foi utilizada uma nomenclatura para nome de classes, métodos, variáveis,
para que o código seguisse um padrão. Na comunicação e persistência de objetos
55 foram adotados os padrões de projeto VO6 e DAO7, respectivamente. Como a
equipe de desenvolvimento é composta por um membro, as práticas de propriedade
coletiva de código e integração contínua estiveram automaticamente embutidas
durante o processo de geração de código. Pelo mesmo motivo, não foi necessária a
utilização de ferramentas para controle de versão. A prática de refatoramento foi
realizada poucas vezes, após uma revisão geral no código da aplicação ao final de
cada iteração.
As User Stories alocadas em cada iteração só podem ser consideradas
como finalizadas após a realização dos testes de aceitação (GARCIA et alii, 2007).
Portanto, sempre que uma User Story foi implementada, os seus respectivos testes
de aceitação foram executados pelo testador.
4.3.7 FINALIZAÇÃO DA ITERAÇÃO
Ao final dos testes de uma iteração deve-se atualizar a Tabela de
Alocação de Atividades presente no Apêndice H.
Uma vez que os papéis de gerente, desenvolvedor e testador são
desempenhados pela mesma pessoa, as reuniões de acompanhamento foram
substituídas por uma análise do projeto, a fim de avaliar sistematicamente os
resultados obtidos. Nesta análise o gerente fez uso da TAA como referência para
examinar o andamento do projeto. Assim como nas reuniões de acompanhamento,
foi dada atenção para os riscos e possíveis mudanças, assim como a necessidade
explícita de refatoramento. Segundo Garcia et alii (2007), a dedicação e o
compromisso do gerente é uma questão decisiva para o andamento do projeto, pois
seu empenho pode identificar prematuramente suas falhas.
No decorrer do trabalho não foram identificados riscos a ponto de impedir
o fluxo normal do desenvolvimento do software. Devido à baixa complexidade do
sistema, não foi necessária a definição de métricas de qualidade para o projeto.
Logo, durante as análises do projeto não foram adotados o uso do Big Chart e da
6 http://www.mundooo.com.br/php/modules.php?name=News&file=print&sid=483 7 http://www.java.sun.com/blueprints/patterns/DAO.html
56 Tabela de Riscos. Entretanto, a cada finalização de iteração, foi utilizada a revisão
de código, visto que tal prática auxilia na melhoria da qualidade e da funcionalidade
do código através de revisões internas (GARCIA et alii, 2007).
Todas as atividades estabelecidas no plano de iteração foram executadas
dentro do tempo planejado. As mudanças que surgiram implicaram apenas em
modificação de implementação e de algumas atividades da TAA, não causando
grande impacto em artefatos já gerados. Vale lembrar que a TAA não representa
todo processo de geração de código, ela é mais um artefato para o auxílio do
gerenciamento do projeto.
4.3.8 VERSÃO DO PRODUTO
Quando o sistema for finalizado o usuário deve realizar os testes de
usabilidade. Os cenários dos testes de usabilidade devem buscar avaliar o
desempenho de usuários típicos na realização de tarefas comuns (GARCIA et alii,
2007). Visto que o sistema é composto basicamente por dois cadastros, estes testes
foram realizados de maneira informal. Após a realização destes testes, foi gerada a
versão final do CGC.
4.4 FERRAMENTAS
Para o desenvolvimento do componente foram utilizadas as seguintes
ferramentas:
• IDE de Programação: MyEclipse 5.5 GA.
• Servidor Web: Tomcat 6.0.
• Banco de Dados: MySQL Server 5.0.
• Ferramenta de gerência de banco de dados: MySQL Administrator 1.2.
• Ferramenta para construção do Modelo da Tarefa: iTAOS.
• Editor de HTML: Macromedia Dreamweaver 8.0.
• Editor para modelagem de banco de dados: DBDesigner 4.0.
57
5 CONCLUSÕES
Este capítulo apresenta as conclusões do desenvolvimento do trabalho,
assim como as perspectivas de continuidade.
5.1 QUANTO AOS OBJETIVOS
5.1.1 OBJETIVO ESPECÍFICO I
I – Realizar estudo comparativo entre metodologias ágeis e metodologias tradicionais de desenvolvimento de software.
No capítulo 2 deste trabalho foram apresentadas as metodologias
tradicionais (seção 2.2) e metodologias ágeis (seção 2.3) de desenvolvimento de
software. O estudo comparativo entre ambas as abordagens foi explicitado na seção
2.4.
5.1.2 OBJETIVO ESPECÍFICO II
II – Estudar o processo da modelagem ágil de software através do uso da metodologia YP.
Durante a aplicação do EasYProcess várias características da
modelagem ágil de software ficaram evidentes.
Na definição de papéis, na qual cada membro da equipe representa uma
peça no processo, o cliente faz parte da equipe de desenvolvimento e participa das
decisões do projeto. É importante entender que desempenhar um papel significa ser
responsável por um conjunto de tarefas e estar ciente da importância do seu papel
no processo de desenvolvimento. No decorrer do trabalho, o cliente esteve
comprometido durante todo o processo, refletindo nas decisões mais críticas
relativas ao andamento do projeto.
58
O planejamento do projeto foi contínuo, iteração a iteração, sem se
preocupar com requisitos que ainda não existem. Primeiramente houve a
preocupação com o funcionamento de ações simples do sistema. Depois, novas
funcionalidades foram anexadas à lista de User Stories e o sistema foi refinado nos
pontos requeridos pelo cliente. A cada análise do projeto, quando o gerente julgou
adequado, algumas atividades da TAA foram re-planejadas. Cabe ao gerente avaliar
continuamente o projeto e assim decidir como será o planejamento da próxima
iteração. Percebe-se claramente que o andamento do projeto é guiado pelo feeling
do gerente. Este ponto ratifica o valor maior nas pessoas que no processo de
desenvolvimento.
O número de integrantes da equipe de desenvolvimento (uma pessoa)
refletiu em alguns aspectos em relação ao processo. Detalhar certos documentos
mostrou-se desnecessário. Algumas das práticas propostas não puderam ser
aplicadas. Reuniões de acompanhamento de projeto não têm sentido neste cenário.
Com isso, documentos relativos à comunicação entre a equipe de desenvolvimento
também não foram gerados. Sem a iteração entre as pessoas responsáveis pelo
desenvolvimento, toda e qualquer dúvida foi esclarecida junto ao cliente. Pode-se
afirmar que o desenvolvimento da aplicação foi embasado principalmente pelo
contato com o cliente no processo.
A simplicidade do sistema também afetou o grau de detalhamento da
documentação. Não houve necessidade de gerar artefatos com todos os itens
propostos pela metodologia. A geração de documentos foi totalmente flexível, tanto
na escolha das ferramentas quanto na elaboração do artefato, o que efetivamente
auxiliou no desenvolvimento do componente. Não foi gerado nenhum documento
que não tenha sido utilizado.
Ao longo do trabalho percebeu-se que as práticas adotadas pela
metodologia YP são conhecidas da abordagem tradicional. A diferença está nos
princípios e nos valores onde são apoiadas. Portanto, as metodologias ágeis apenas
aplicam uma coleção de práticas que podem ser utilizadas por profissionais de
software no dia-a-dia.
59 5.1.3 OBJETIVO ESPECÍFICO III
III – Aplicar a metodologia YP em uma solução de software simples.
Para avaliar a aplicabilidade da metodologia YP alguns aspectos sobre o
desenvolvimento do sistema devem ser revisados. A aplicação desenvolvida é de
baixa complexidade, basicamente é um sistema de cadastros e consultas, sem
muitas regras de negócio, ou seja, um sistema com escopo pequeno. O tempo de
desenvolvimento também foi pequeno. O cliente esteve comprometido durante todo
o desenvolvimento. Também, a equipe de desenvolvimento foi composta por um
membro.
Considerando a situação em questão, caso fosse escolhida uma
metodologia tradicional para modelagem deste componente, seriam aplicados uma
série de passos redundantes no processo. Por exemplo, como o cliente pôde estar
sempre presente nas decisões do projeto, não teria porque analisar todas as
situações possíveis no início, pois o cliente estaria sempre disponível para
esclarecer dúvidas que surgissem. Outro ponto a considerar seria o excesso de
documentos gerados. Como a documentação serve para formalizar a comunicação
entre as pessoas da equipe e a equipe de desenvolvimento foi composta por um
membro, certamente seriam gerados documentos desnecessários.
O cenário da aplicação em questão é propício para a modelagem ágil de
software. Tempo e escopo pequenos, equipe de desenvolvimento pequena, cliente
disponível. Logo, a adoção de uma metodologia simples ofereceu o suporte
necessário para a solução de um problema simples. Por este motivo, a construção
do componente de software modelado pelo EasYProcess foi considerada
satisfatória.
5.2 QUANTO ÀS PERSPECTIVAS DE CONTINUIDADE
Considerando o estudo apresentado neste trabalho percebe-se que
ambas as abordagens oferecem vantagens e desvantagens em sua utilização. Não
existe uma metodologia ideal para se produzir software: existem metodologias que
60 são adequadas a certas situações, focadas em resolver determinado tipo de
problemas. Portanto, uma sugestão seria a proposta, avaliação e aplicação de uma
metodologia de desenvolvimento de software que carregasse consigo pontos fortes
das duas abordagens.
61
6 REFERÊNCIAS
_____. Agile Modelling. Disponível em: <http://www.agilemodeling.com/> . Acessado em: 11 dez 2006. _____. Apache Tomcat. Disponível em: <http://tomcat.apache.org/>. Acessado em: 27 mai 2007. BECK, Kent. Extreme Programming Explained: Embracing Change. 1st Edition, Adisson-Wesley, 1999. BURKE, Eric M.; COYNER, Brian M. Java Extreme Programming Cookbook. O’Reilly & Associates, Inc., 2003. CAMARA, Fabio. Experimente um Projeto Ágil. 2007. Disponível em: <http://www.linhadecodigo.com.br/artigos_impressao.asp?id_ac=1285>. Acessado em: 30 mar 2007. CAMARA, Fabio. Processos Ágeis e MSF. 2005. Disponível em: <http://www.linhadecodigo.com.br/artigos.asp?id_ac=833>. Acessado em: 12 nov 2006. COCKBURN, Alistair. Agile Software Development. Adisson-Wesley, 2001. COSTA, Edes Garcia da. Métodos Ágeis. 2006. Disponível em: <http://www.dc.ufscar.br/~junia/MetAgEds.pdf>. Acessado em: 30 mar 2007. COSTA, Edes Garcia da; PENTEADO, Rosângela; SILVA, Júnia Coutinho Anacleto; BRAGA, Rosana Teresinha Vaccare. Padrões e Métodos Ágeis: Agilidade no Processo de Desenvolvimento de Software. 2005. Disponível em: <http://sugarloafplop2005.icmc.usp.br/papers/9673.pdf>. Acessado em: 25 mar 2007. _____. DBDesigner 4. Disponível em: <http://www.fabforce.net/dbdesigner4/>. Acessado em: 11 jun 2007. _____. easYProcess. Disponível em: <http://www.dsc.ufcg.edu.br/~yp/>. Acessado em: 11 dez 2006. _____. Extreme Programming. Disponível em: <http://www.extremeprogramming.org/>. Acessado em: 11 abr 2007. FAGUNDES, Priscila Bastos. Framework para Comparação e Análise de Métodos Ágeis. Dissertação de Mestrado. Universidade Federal de Santa Catarina. Florianópolis: 2005. FOWLER, Martin. The New Methodology. 2005. Disponível em: <http://www.martinfowler.com/articles/newMethodology.html>. Acessado em: 15 abr 2007. GARCIA, Francile Procópio; LIMA, Aliandro Higino Guedes; FERREIRA, Danilo de Sousa; JÚNIOR, Fábio Luiz Leite; ROCHA, Giselle Regina Chaves da; MENDES, Gustavo Wagner Diniz; PONTES, Renata França de; ROCHA, Verlaynne Kelley da Hora; DANTAS, Vinicius Farias. easYProcess – Um Processo de Desenvolvimento de Software. Universidade Federal de Campina Grande. Campina Grande: 2007.
62 _____. Governo Eletrônico. Diponível em: <https://www.governoeletronico.gov.br/>. Acessado em: 23 mai 2007. HIGHSMITH, Jim. Agile Software Development Ecosystems. Adisson-Wesley, 2002. HIGHTOWER, Richard; LESIECKI, Nicholas. Java Tools for eXtreme Programming – Mastering Open Source Including Ant, JUnit, and Cactus. John Wiley & Sons, Inc., 2002. HILMAN. Metodologias Ágeis. 2004. Disponível em: <http://www.redes.unb.br/material/ESOO/Metodologias%20%c1geis.pdf>. Acessado em: 20 abr 2007. LARMAN, Craig. Applying UML And Patterns. 2nd Edition, 2002. MAGALHÃES, Ana Liddy C. C. O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias Ágeis. 2004. Disponível em: <http://ftp.mct.gov.br/Temas/info/Dsi/PBQP/EQPS_Campinas_2004/Projeto%202_10.pdf>. Acessado em: 25 mar 2007. _____. MyEclipse. Disponível em: <http://www.myeclipseide.com/>. Acessado em: 19 mai 2007. _____. MySQL. Disponível em: <http://www.mysql.com/>. Acessado em: 10 jun 2007. NETO, Oscar Nogueira de Souza. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Trabalho de Conclusão de Curso. Universidade da Amazônia. Belém: 2004. _____. Portal Via Digital. Disponível em: <http://www.viadigital.ufsc.br/>. Acessado em: 15 abr 2007. PRESSMAN, Roger. Software Engineering – A Pratitictioner’s Approach. McGraw-Hill, 5th Edition, 2001. _____. Rational Unified Process. Disponível em: <http://www.wthreex.com/rup/>. Acessado em: 11 dez 2006. _____. Repositório Via Digital. Disponível em: <http://repositorio.viadigital.org.br/>. Acessado em: 11 abr 2006. SEGUNDO, Volmar P.; MOURA, Alexandre M. Introdução de Metodologias Ágeis de Desenvolvimento de Software nos Currículos de Referência do Ensino Universitário. 2004. Disponível em: <http://www.frb.br/ciente/Impressa/Info/2004.2/Introducao%20de%20metodologias.pdf >. Acessado em: 24 fev 2007. SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2004. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf> . Acessado em: 11 jan 2007. SOMMERVILLE, Ian. Software Engineering. 7th Edition, 2004.
63 _____. The Standish Group. Disponível em: <http://www.standishgroup.com/>. Acessado em: 12 dez 2006. _____. Wikipedia. Disponível em: <http://en.wikipedia.org/wiki/Main_Page>. Acessado em: 20 fev 2007. ZANATTA, Alexandre. xScrum: Uma Proposta de Extensão do xScrum para Adequação ao CMMI. Dissertação de Mestrado. Universidade Federal de Santa Catarina. Florianópolis: 2004.
64
APÊNDICE A
Roteiro de perguntas
65 Roteiro de perguntas para a primeira conversa com o cliente:
1. Quais são as principais características de um cemitério? 2. Quais os principais termos envolvidos na administração de um cemitério?
3. Como é o funcionamento de um cemitério?
4. Quais os procedimentos existentes no dia-a-dia de um cemitério?
5. Quais são os documentos presentes na administração de um cemitério?
6. Quem vai utilizar este sistema?
7. Quantas pessoas vão utilizar o sistema?
8. O que um sistema de controle de cemitérios deve ter para atender às
necessidades de quem vai utilizá-lo?
9. Quais as funcionalidades básicas que um sistema deve ter para que se consiga administrar um cemitério?
10. Como essas funcionalidades devem se relacionar para uma melhor
administração do cemitério?
11. Quais funcionalidades são mais importantes?
12. Quais os passos de cada funcionalidade?
66
APÊNDICE B
Documento de Visão
67
CGC – Componente para Gerência de Cemitérios Descrição do sistema
O cemitério fisicamente é dividido em quadras e estas estão divididas em sepulturas. Uma quadra é uma zona do cemitério. Cada sepultura tem um dono e um enterro associada a ela. Existem basicamente dois procedimentos no cemitério. O primeiro é o controle de compra dos terrenos do cemitério. Este procedimento gera um documento chamado de título de aforamento. Aforamento é o ato de compra do terreno aonde ocorre o sepultamento. O título de aforamento contém informações do terreno e dono do terreno.
O segundo é o controle dos sepultamentos. Para solicitação de abertura de jazigo para sepultamento faz-se necessária a apresentação de declaração de óbito e título de aforamento ou identidade do dono do terreno. Depois, preenche-se um documento chamado solicitação de abertura de jazigo. Após a realização do enterro, este é registrado em um livro. Definição do escopo É necessária a implementação do cadastro de compra dos terrenos e dos sepultamentos. Requisitos Funcionais
Componente 01 – Cadastramento de sepulturas.
1) Cadastro de sepulturas (inserção, edição, alteração e exclusão);
2) Busca pelos campos de cadastro;
Componente 02 – Cadastramento de sepultamento.
1) Cadastro do sepultamento (inserção, edição, alteração e exclusão);
2) Busca pelos campos de cadastro;
Requisitos Não Funcionais
1) Interface Web (JSP + STRUTS);
2) Banco de dados MySQL;
3) Arquitetura em camadas.
4) Utilização de padrões de projeto (VO e DAO).
68 Perfil do Usuário Administrador do cemitério, possui pouco conhecimento de informática. Porém, não é necessário treinamento para a utilização do sistema. Objetivos de Usabilidade
Objetivo Mensuração Ser de fácil aprendizado Uso de recursos avançados. Possuir telas simples Observar dificuldades de navegação.
69
APÊNDICE C
Modelo da Tarefa
70 CGC
Cadastro de Sepulturas
Dados do Aforamento
71
Dados do Proprietário
Consulta de Sepulturas
72 Cadastro de Sepultamentos
Dados do Sepultamento
Dados do Cartório
Dados do Sepultado
73
Outras Informações
Consulta de Sepultamentos
74
APÊNDICE D
User Stories
75
Lista de User Stories Programar funcionalidade de cadastro de sepulturas.
• TA1.1 - Cadastrar sepulturas informando todos os campos obrigatórios (Cadastro efetuado com sucesso);
• TA1.2 - Cadastrar sepulturas sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado);
• TA1.3 - Cadastrar sepulturas informando um número de aforamento já cadastrado no sistema (Mensagem de erro deve ser retornada).
US01
Estimativa Inicial: 8 horas Programar funcionalidade de pesquisa de sepulturas.
• TA2.1 - Recuperar dados gerais da sepultura sem informar campos (Dados devem ser retornados com sucesso);
• TA2.2 - Recuperar dados gerais da sepultura a partir de um número de aforamento existente (Dados devem ser retornados com sucesso);
• TA2.3 - Recuperar dados gerais da sepultura a partir de uma quadra (Dados devem ser retornados com sucesso);
• TA2.4 - Recuperar dados gerais da sepultura a partir de uma sepultura (Dados devem ser retornados com sucesso);
• TA2.5 - Recuperar dados gerais da sepultura a partir do nome do comprador ou nome do responsável existente (Dados devem ser retornados com sucesso);
• TA2.6 - Recuperar dados gerais da sepultura a partir de algum campo inexistente na base de dados do sistema (Mensagem de nenhum registro encontrado deve ser retornada);
• TA2.7 - Permitir alteração e exclusão de registros a partir de uma lista de dados retornados (Operação deve ser executada com sucesso).
US02
Estimativa Inicial: 6 horas Programar funcionalidades de cadastro de sepultamentos.
• TA3.1 - Verificar se ao informar o número de aforamento ou selecionar um aforamento existente o sistema recupera os dados de quadra e sepultura do mesmo (Dados devem ser retornados com sucesso);
• TA3.2 - Cadastrar sepultamentos informando todos os campos obrigatórios (Cadastro efetuado com sucesso);
• TA3.3 - Cadastrar sepulturas sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado);
• TA3.4 - Cadastrar sepultamentos informando um número de sepultamento já cadastrado no sistema (Mensagem de erro deve ser retornada).
US03
Estimativa Inicial: 8 horas
76
Programar funcionalidade de pesquisa de sepultamentos. • TA4.1 - Recuperar dados gerais do sepultamento sem informar
campos (Dados devem ser retornados com sucesso);
• TA4.2 - Recuperar dados gerais do sepultamento a partir de um número de sepultamento existente (Dados devem ser retornados com sucesso);
• TA4.3 - Recuperar dados gerais do sepultamento vinculado a um número de aforamento existente (Dados devem ser retornados com sucesso).
• TA4.4 - Recuperar dados gerais do sepultamento a partir de um intervalo de data (Dados devem ser retornados com sucesso);
• TA4.5 - Recuperar dados gerais do sepultamento a partir de um nome do sepultado existente (Dados devem ser retornados com sucesso);
• TA4.6 - Recuperar dados gerais do sepultamento a partir de algum campo inexistente na base de dados do sistema (Mensagem de nenhum registro encontrado deve ser retornada);
• TA4.7 - Permitir alteração e exclusão de registros a partir de uma lista de dados retornados (Operação deve ser executada com sucesso).
US04
Estimativa Inicial: 4 horas
77
APÊNDICE E
Protótipo da Interface
78
79
80
81
APÊNDICE F
Modelo Lógico de Dados
82 Cadastro de Sepulturas e Sepultamentos
83
APÊNDICE G
Projeto Arquitetural
84
Projeto Arquitetural
Descrição A arquitetura utilizada segue o padrão n-camadas, separando a apresentação, as camadas de negócio e a camada de persistência de dados. De acordo com o padrão definido, as camadas serão implementadas em tecnologias Web, abertas e open source. Na interface serão utilizadas páginas JSP com inserção de tags do framework Struts para operações de validação de entrada e para direcionar as ações implementadas. A arquitetura utiliza tecnologia Web, sendo portanto aplicável em ambientes intranet/internet. A seguir estão descritas características do serviço de hospedagem de páginas:
• Servidor Web e servidor java pages: Tomcat. • Páginas JSP: as requisições do browser se destinarão a páginas JSP, que obedecerão a
algumas restrições de conteúdo. o Nenhuma regra de negócio ou acesso a dados será realizado em código dentro das
páginas JSP bem como nas classes do Struts. Toda lógica da aplicação, bem como acesso a dados, deve ser implementada em componentes JavaBeans a serem referenciados nas páginas JSP;
o A persistência dos objetos deve ser implementada sob o padrão de projeto DAO (http://www.java.sun.com/blueprints/patterns/DAO.html);
o A comunicação entre as camadas deve ser implementada sob o padrão de projeto VO (http://www.mundooo.com.br/php/modules.php?name=News&file=print&sid=483);
Será adotado como padrão o SGBD relacional MySQL (http://dev.mysql.com/downlodas/mysql/5.0.html), por ser um software open source e por suportar os requisitos existentes no desenvolvimento da aplicação.
85
APÊNDICE H
Tabela de Alocação de Atividades
86
Iteração 01 – (06/06/2007 – 08/06/2007) US01 - Programar funcionalidade de cadastro de sepulturas Testes de Aceitação Status
TA1.1 Cadastrar sepulturas informando todos os campos obrigatórios (Cadastro efetuado com sucesso) C
TA1.2 Cadastrar sepulturas sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado) C
TA1.3 Cadastrar sepulturas informando um número de aforamento já cadastrado no sistema (Mensagem de erro deve ser retornada) C
Ativi-dade
Descrição Responsável Estimativa de tempo (horas)
Tempo real
(horas) Status
A1.1 Gerar script para configuração do MySQL Cecília 2 1 C
A1.2 Adaptar JSP do cadastro de sepulturas Cecília 2 1 C
A1.3 Implementar funcionalidade de cadastro de sepulturas Cecília 3 2 C
A1.4 Realizar os testes de aceitação Cecília 1 1 C
Iteração 02 – (11/06/2007 – 13/06/2007) US02 - Programar funcionalidade de pesquisa de sepulturas Testes de Aceitação Status
TA2.1 Recuperar dados gerais da sepultura sem informar campos (Dados devem ser retornados com sucesso)
C
TA2.2 Recuperar dados gerais da sepultura a partir de um número de aforamento existente (Dados devem ser retornados com sucesso)
C
TA2.3 Recuperar dados gerais da sepultura a partir de uma quadra (Dados devem ser retornados com sucesso)
C
TA2.4 Recuperar dados gerais da sepultura a partir de uma sepultura (Dados devem ser retornados com sucesso)
C
TA2.5 Recuperar dados gerais da sepultura a partir do nome do comprador ou nome do responsável existente (Dados devem ser retornados com sucesso)
C
TA2.6 Recuperar dados gerais da sepultura a partir de algum campo inexistente na base de dados do sistema (Mensagem de nenhum registro encontrado deve ser retornada)
C
TA2.7 Recuperar dados gerais da sepultura a partir de algum campo inexistente na base de dados do sistema (Mensagem de nenhum registro encontrado deve ser retornada)
C
Ativi-dade
Descrição Responsável Estimativa de tempo (horas)
Tempo real
(horas) Status
A2.1 Adaptar JSP da consulta de sepulturas Cecília 1 1 C
A2.2 Implementar funcionalidade de consulta de sepulturas Cecília 2 1 C
A2.3 Implementar funcionalidade de alteração e exclusão de registros
Cecília 2 1 C
87
A2.4 Realizar os testes de aceitação Cecília 1 1 C
Iteração 03 – (27/06/2007 – 29/06/2007) US03 - Programar funcionalidade de cadastro de sepultamentos Testes de Aceitação Status
TA3.1
Verificar se ao informar o número de aforamento ou selecionar um aforamento existente o sistema recupera os dados de quadra e sepultura do mesmo (Dados devem ser retornados com sucesso)
C
TA3.2 Cadastrar sepultamentos informando todos os campos obrigatórios (Cadastro efetuado com sucesso)
C
TA3.3 Cadastrar sepulturas sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado)
C
TA3.4 Cadastrar sepultamentos informando um número de sepultamento já cadastrado no sistema (Mensagem de erro deve ser retornada)
C
Ativi-dade
Descrição Responsável Estimativa de tempo (horas)
Tempo real
(horas) Status
A3.1 Adaptar JSP do cadastro de sepulturas Cecília 1 1 C
A3.2 Adaptar JSP da busca de aforamento Cecília 1 1 C
A3.3 Implementar funcionalidade de busca quadra/sepultura a partir de um nro. Afor.
Cecília 1 1 C
A3.4 Implementar funcionalidade de cadastro de sepultamentos
Cecília 3 3 C
A3.5 Realizar os testes de aceitação Cecília 1 1 C
Iteração 04 – (02/07/2007 – 04/07/2007) US04 - Programar funcionalidade de pesquisa de sepultamentos
Testes de Aceitação Status
TA4.1 Recuperar dados gerais do sepultamento sem informar campos (Dados devem ser retornados com sucesso) C
TA4.2 Recuperar dados gerais do sepultamento a partir de um número de sepultamento existente (Dados devem ser retornados com sucesso) C
TA4.3 Recuperar dados gerais do sepultamento vinculado a um número de aforamento existente (Dados devem ser retornados com sucesso) C
TA4.4 Recuperar dados gerais do sepultamento a partir de um intervalo de data (Dados devem ser retornados com sucesso) C
TA4.5 Recuperar dados gerais do sepultamento a partir de um nome do sepultado existente (Dados devem ser retornados com sucesso) C
TA4.6 Recuperar dados gerais do sepultamento a partir de algum campo inexistente na base de dados do sistema (Mensagem de nenhum registro encontrado deve ser retornada)
C
TA4.7 Permitir alteração e exclusão de registros a partir de uma lista de dados retornados (Operação deve ser executada com sucesso). C
Ativi-dade
Descrição Responsável Estimativa de tempo (horas)
Tempo real
(horas) Status
A4.1 Adaptar JSP da consulta de sepulturas Cecília 1 1 C
88
A4.2 Implementar funcionalidade de consulta de sepultamentos
Cecília 1 1 C
A4.3 Implementar funcionalidade de alteração e exclusão de registros
Cecília 1 1 C
A4.4 Realizar os testes de aceitação Cecília 1 1 C
89
7 GLOSSÁRIO
Algoritmo Conjunto de regras e operações bem definidas e ordenadas, destinadas à solução de um problema, ou de uma classe de problemas, em um número finito de etapas.
e-Gov Prestação de serviços públicos por meio eletrônico, utilizando-se de recursos de tecnologia da informação em caráter remoto, disponível no sistema vinte e quatro horas por dia, sete dias por semana.
Feedback Procedimento através do qual parte do sinal de saída de um sistema é transferida para a entrada deste mesmo sistema, com o objetivo de diminuir, amplificar ou controlar a saída do sistema.
Framework Definição ampla que encapsula o conceito de uma estrutura sobre a qual se pode construir algo, principalmente como a base para algo ser construído.
Open source Software cujo código fonte pode ser usado, copiado, estudado, modificado e redistribuído sem nenhuma restrição.
Scripts Instruções formais geradas a partir de ferramentas, interpretadas comando a comando cada vez que são executadas.
Stakeholder Qualquer organização, parte dela, grupo ou pessoa interessada ou envolvida em um projeto, seja por ser responsável, financiadora, executora, beneficiária ou afetada. Também chamados de: parte interessada, envolvido ou ator.
User story Requisito de software formulado com o linguajar do dia-a-dia do usuário, sem a utilização de termos técnicos.
Website Um conjunto de páginas da Web (documentos contendo texto, elementos gráficos e fotos que são carregados na tela de um computador) interligadas segundo uma estrutura organizada. A maioria dos Websites contém uma página
90
inicial (home page) que o usuário de um computador vê quando visita o site.
![355lia em tempos de crise [Modo de Compatibilidade])juliofurtado.com.br/papel_familia_tempos_crise.pdf · valores inclusivos e combater os valores excludentes. Ensine a adiar o prazer](https://static.fdocumentos.tips/doc/165x107/5e584461466e22056635e068/355lia-em-tempos-de-crise-modo-de-compatibilidade-valores-inclusivos-e-combater.jpg)
