Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de...
106
UNIVERSIDADE DE PASSO FUNDO Diego Antonio Lusa DESENVOLVIMENTO DO PROTÓTIPO DE UMA FERRAMENTA PARA ENGENHARIA DE REQUISITOS VOLTADA AO MODELO DE PROCESSO DE SOFTWARE XP Passo Fundo 2009
-
Upload
diego-lusa -
Category
Software
-
view
308 -
download
2
Transcript of Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de...
UNIVERSIDADE DE PASSO FUNDO
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITOS
VOLTADA AO MODELO DE PROCESSO DE SOFTWARE
XP
Passo Fundo
2009
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITOS
VOLTADA AO MODELO DE PROCESSO DE SOFTWARE
XP
Monografia apresentada ao curso de Ciência da
Computação, do Instituto de Ciências Exatas e
Geociências, da Universidade de Passo Fundo, como
requisito parcial para a obtenção de grau de Bacharel
em Ciência da Computação, sob orientação da Profa.
Ms. Jane Colossi Grazziotin.
Passo Fundo
2009
Diego Antonio Lusa
Desenvolvimento do protótipo de uma ferramenta para engenharia de requisitos
voltada ao modelo de processo de software XP
Monografia apresentada ao curso de Ciência da
Computação, do Instituto de Ciências Exatas e
Geociências, da Universidade de Passo Fundo, como
requisito parcial para obtenção do grau de Bacharel
em Ciência da Computação, sob a orientação da
Profa. Ms. Jane Colossi Grazziotin.
Aprovada em __ de __________________ de __________.
BANCA EXAMINADORA
_____________________________________
Profa. Ms. Jane Colossi Grazziotin – UPF
____________________________________
Profª. Ms. Lis Ângela De Bortoli – UPF
Apesar de todas as pedras encontradas pelo
caminho, os sonhos se realizam. Apesar de
todo o cansaço, tristeza, dúvida ou medo, o
caminho foi trilhado. E a chegada aproxima-
se, como o clarão de uma vela iluminando a
escuridão.
Nesta caminhada nunca estive só. Estive
sempre amparado por grandes pessoas, de
valor inestimável e é a elas que dedico este
trabalho.
A meus pais, além de todo meu amor, os
agradeço de todo meu coração. Vocês são
minha força e inspiração.
A meus professores, em especial minha
orientadora Jane Colossi, pela amizade, pelos
ensinamentos, pelas cobranças e pelos
conselhos. A vocês, minha eterna gratidão.
A meus amigos, pelas críticas, pela amizade,
pelos bons conselhos e pelas bobagens que
tantas alegrias me trouxeram. Obrigado a
todos.
Minha conquista é também a conquista de
todos aqueles que de alguma forma estiveram
comigo nesta caminhada. A todos, meu muito
obrigado.
“A persistência é o caminho do êxito.”
Charles Chaplin
RESUMO
Desenvolver software é uma atividade complexa. Muitos problemas podem ocorrer
durante o desenvolvimento e vir a comprometer todo o projeto. Dentre os mais comuns pode-
se citar atrasos na entrega do software e a incapacidade de manter-se dentro dos custos
previstos, problemas estes oriundos grande parte das vezes de falhas na especificação do
software. Em vista disso, é necessário que o desenvolvimento se dê embasado por um
processo bem definido que forneça uma sustentação gerencial às atividades necessárias, ou
seja, por um modelo de processo de software. Neste aspecto, grande enfoque deve ser dado à
atividade de elicitação de requisitos, que é a base fundamental de qualquer modelo de
processo de software e também a área mais crítica do desenvolvimento.
Existem na literatura dois grandes grupos de modelos de processo de software: ágeis e
prescritivos. Os modelos ditos ágeis caracterizam-se por enfatizarem a simplicidade e a
desburocratização do desenvolvimento de software, enquanto que os modelos prescritivos
enfatizam um desenvolvimento orientado por atividades rigidamente definidas e que
normalmente atravancam o processo pela grande necessidade de documentação durante o
desenvolvimento.
Dentre os modelos ágeis, a Extreme Programming destaca-se como um dos mais
conhecidos. Entre suas principais características destaca-se o desenvolvimento incremental,
programação em par, participação do cliente na equipe e o refactoring.
No que concerne a elicitação de requisitos, observou-se que a Extreme Programming
apresenta algumas falhas, que podem comprometer a qualidade da especificação de requisitos
por ela mantida. Observou-se também que tais falhas poderiam ser suprimidas com o uso de
uma ferramenta informatizada de auxílio ao processo de gerência de requisitos (ferramenta
CASE – Computer Aided Software Engineering).
Dado que as ferramentas avaliadas não contemplam as necessidades elencadas, este
trabalho objetiva propor um protótipo de ferramenta CASE, voltada a gerência de requisitos
na Extreme Programming, que forneça todas as características necessárias para manter uma
especificação de requisitos guarnecida por todos os atributos de qualidade necessários.
Palavras-chave: especificação de requisitos, CASE, protótipo, Engenharia de
Requisitos, Extreme Programming.
LISTA DE FIGURAS
Figura 1: Tipos de requisitos não funcionais ................................................................ 26
Figura 2: Especificação de um requisito de domínio .................................................... 27
Figura 3: Especificação de requisitos utilizando um formulário padrão ....................... 31
Figura 4: Exemplo de um Diagrama de Fluxo de Dados (DFD) ................................. 32
Figura 5: Diagrama de Casos de Uso ............................................................................ 32
Figura 6: Dificuldades de compreensão ........................................................................ 37
Figura 7: Processo de Engenharia de Requisitos .......................................................... 38
Figura 8: Custos de erros nos requisitos ....................................................................... 43
Figura 9: Modelo Cascata ............................................................................................. 45
Figura 10: Diagrama esquemático da metodologia XP ................................................. 49
Figura 11: Diagrama de casos de uso da visão técnica ................................................. 86
Figura 12: Diagrama de casos de uso da visão gerencial .............................................. 87
Figura 13: Diagrama de Classes DAO .......................................................................... 90
Figura 14: Diagrama de classes DTO ........................................................................... 91
Figura 15: Diagrama Entidade Relacionamento ........................................................... 92
Figura 16: Tela de login do protótipo ........................................................................... 93
Figura 17: Tela principal do protótipo .......................................................................... 94
Figura 18: Tela de listagem de estórias ......................................................................... 95
Figura 19: Tela de manutenção de estórias ................................................................... 95
Figura 20: Tela de listagem com a nova estória cadastrada .......................................... 96
Figura 21: Operações necessárias a uma manutenção de dados ................................... 96
Figura 22: Hierarquia dos dados mantidos pelo protótipo ............................................ 97
LISTA DE TABELAS
Tabela 1: Project Planning & Tracking System v. 1.6.6 ............................................... 61
Tabela 2: Trackit ........................................................................................................... 62
Tabela 3: XPWEB ......................................................................................................... 63
Tabela 4: BABAXP ....................................................................................................... 64
Tabela 5: Relação ferramenta X Grau de atendimento ................................................. 67
Tabela 6: Atores do protótipo ....................................................................................... 70
Tabela 7: UC Manter estórias........................................................................................ 72
Tabela 8: UC Manter Tarefas ........................................................................................ 73
Tabela 9: UC Manter bugs ............................................................................................ 74
Tabela 10: UC Manter Versões ..................................................................................... 74
Tabela 11: UC Estimar tempo de desenvolvimento para uma estória .......................... 75
Tabela 12: UC Buscar estórias semelhantes ................................................................. 76
Tabela 13: UC Manter casos de teste ............................................................................ 77
Tabela 14: UC Manter iterações.................................................................................... 78
Tabela 15: UC Gerar matriz de rastreabilidade dos requisitos ...................................... 78
Tabela 16: UC Manter releases ..................................................................................... 79
Tabela 17: UC Exportar projeto em XML .................................................................... 80
Tabela 18: UC Buscar projeto ....................................................................................... 80
Tabela 19: UC Buscar release ....................................................................................... 81
Tabela 20: UC Buscar iteração ...................................................................................... 81
Tabela 21: UC Recuperar o número de bugs encontrados por iteração e estórias
relacionadas .............................................................................................................................. 82
Tabela 22: UC Recuperar o número de bugs encontrados por release ......................... 83
Tabela 23: UC Recuperar o número de bugs encontrados por projeto ......................... 84
Tabela 24: UC Manter projetos ..................................................................................... 84
Tabela 25: UC Manter usuários .................................................................................... 85
Tabela 26: UC Manter equipe ....................................................................................... 85
LISTA DE ABREVIATURAS
CASE Computer- Aided Software Engineering
CMMI Capability Maturity Model Integration
CVS Concurrent Version System
D Deslocamento
DAO Data Access Object
DFD Diagrama de Fluxo de Dados
DTO Data Transactional Object
ER Engenharia de Requisitos
FDD Feature Driven Development
GNU Acrônimo Recursivo de “GNU`s Not Unix!”
IDE Integrated Development Environment
PHP Hypertext Preprocessor
PPTS Project Planning & Tracking System v. 1.6.6
REQM Requirements Management
RUP Rational Unified Process
Sf Posição Final
SGBD Sistema Gerenciador de Banco de Dados
Si Posição Inicial
T Tempo
TDD Test-Driven Development
UC Use Case
UP Unified Process
URL Uniform Resource Locator
UML Unified Modeling Language
VM Velocidade Média
XML Extensible Markup Language
XP Extreme Programming
SUMÁRIO
INTRODUÇÃO ............................................................................................................ 12
1. ENGENHARIA DE SOFTWARE ......................................................................... 15
1.1. Histórico .......................................................................................................... 15
1.2. Processo de Software ...................................................................................... 18
1.3. Modelo de ciclo de vida .................................................................................. 19
2. REQUISITOS......................................................................................................... 23
2.1. Requisitos de usuário ...................................................................................... 24
2.2. Requisitos de sistema ...................................................................................... 24
2.2.1. Requisitos Funcionais ............................................................................... 25
2.2.2. Requisitos não-funcionais ........................................................................ 25
2.2.3. Requisitos de domínio .............................................................................. 26
2.3. Especificação de requisitos e os problemas relacionados ............................... 27
2.3.1. Elaboração ................................................................................................ 28
2.3.2. Ambiente .................................................................................................. 28
2.3.3. Evolução ................................................................................................... 29
2.3.4. Limites ...................................................................................................... 29
2.3.5. A problemática relacionada ...................................................................... 30
2.4. Qualidade dos Requisitos ................................................................................ 33
2.4.1. Correção.................................................................................................... 33
2.4.2. Precisão ..................................................................................................... 33
2.4.3. Completeza ............................................................................................... 34
2.4.4. Consistência .............................................................................................. 34
2.4.5. Priorização ................................................................................................ 34
2.4.6. Verificabilidade ........................................................................................ 35
2.4.7. Modificabilidade ....................................................................................... 35
2.4.8. Rastreabilidade ......................................................................................... 35
3. ENGENHARIA DE REQUISITOS ....................................................................... 37
3.1. Estudo da Viabilidade ..................................................................................... 39
3.2. Elicitação e análise dos requisitos .................................................................. 40
3.3. Especificação dos Requisitos .......................................................................... 42
3.4. Validação dos Requisitos ................................................................................ 42
3.5. Gerenciamento de Requisitos ......................................................................... 43
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS ................... 45
4.1. Valores ............................................................................................................ 47
4.1.1. Comunicação ............................................................................................ 47
4.1.2. Simplicidade ............................................................................................. 48
4.1.3. Coragem ................................................................................................... 48
4.1.4. Feedback ................................................................................................... 49
4.2. Ciclo de Vida XP ............................................................................................ 49
4.2.1. Fase de Exploração ................................................................................... 50
4.2.2. Fase de Planejamento ............................................................................... 50
4.2.3. Fase de iterações para entrega .................................................................. 51
4.2.4. Fase de produção ...................................................................................... 52
4.2.5. Manutenção .............................................................................................. 53
4.3. Engenharia de Requisitos aplicada a Extreme Programming ......................... 53
5. TECNOLOGIA CASE ........................................................................................... 57
5.1. Estudo de ferramentas CASE existentes de apoio ao processo de Engenharia
de Requisitos voltado a Extreme Programming ................................................................... 59
5.1.1. Ferramentas CASE analisadas .................................................................. 61
5.1.2. Formalização das características desejáveis a uma ferramenta de gerência
de requisitos para XP ........................................................................................................ 64
6. PROJETO DO PROTÓTIPO ................................................................................. 68
6.1. Casos de uso do protótipo ............................................................................... 69
6.1.1. Casos de uso da visão técnica ................................................................... 71
6.1.2. Casos de uso da visão gerencial ............................................................... 82
6.2. Diagrama de Classes do Protótipo .................................................................. 88
6.3. Interface gráfica .............................................................................................. 93
CONCLUSÃO .............................................................................................................. 98
TRABALHOS FUTUROS .......................................................................................... 100
REFERÊNCIAS .......................................................................................................... 101
ANEXO A – DICIONÁRIO DE DADOS .................................................................. 103
12
INTRODUÇÃO
O desenvolvimento de software é uma atividade de engenharia (PRESSMAN, 2002).
Diferentemente de uma linha de produção industrial, onde manufaturam-se milhares de
produtos de características iguais diariamente, o processo de desenvolvimento de software
segue linhas distintas. Não há como manufaturar software, pois ele é elemento de um sistema
lógico e não físico. Desta forma, cada software que é desenvolvido origina-se de um projeto
distinto, mesmo o produto final servindo ao mesmo fim.
Para orientar as atividades necessárias ao desenvolvimento de software, criaram-se
diferentes abstrações de processos de software, denominadas modelos de ciclo de vida
(SOMMERVILLE, 2007), com vistas a definir um arcabouço unívoco que facilitasse a
gerência e as atividades de desenvolvimento propriamente ditas. Inicialmente, os modelos
propostos tinham por principal meta definir rigidamente a sequência de atividades a ser
realizada durante o projeto, exigindo disciplina e comprometimento na execução do modelo
por parte da equipe. Por este fato, tais modelos receberam a denominação de modelos
prescritivos de desenvolvimento.
Todavia, o uso dos modelos prescritivos mostrou-se inconveniente em determinados
casos justamente pela burocracia que impunham ao desenvolvimento. Em vista disso, teóricos
da Engenharia de Software reuniram-se e propuseram formas mais eficientes de
desenvolvimento, defendendo que a satisfação do cliente com entregas rápidas e funcionais do
software era muito mais importante que seguir um protocolo extremamente formal de
desenvolvimento. Desta forma, os modelos de desenvolvimento que abarcaram tais idéias
ficaram conhecidos como modelos ágeis de desenvolvimento.
Embora as diferenças entre metodologias ágeis e prescritivas sejam consideráveis,
muitas atividades em comum podem ser observadas. Dentre elas, a descoberta de requisitos
13
(elicitação) merece destaque. Segundo Sommerville (2007), “os requisitos de um sistema são
descrições dos serviços fornecidos pelo sistema e suas restrições operacionais”. De acordo
com esta definição, um requisito pode representar uma necessidade funcional do sistema, ou
também, uma característica não-funcional inerente ao software, como um nível de
confiabilidade mínimo, por exemplo.
A atividade de descoberta de requisitos, num olhar superficial, parece ser
extremamente simples de ser realizada. Todavia, observa-se que ela é rodeada de
complexidade, sendo a etapa mais crítica de um projeto de software. Tal é a importância desta
atividade que existe uma subárea da Engenharia de Software, denominada Engenharia de
Requisitos que se atém exclusivamente às atividades de descoberta, organização, validação e
gerenciamento dos requisitos.
Basicamente, o objetivo da Engenharia de Requisitos é criar e manter a especificação
de requisitos de um software. Uma especificação define um software em termos de seus
requisitos e necessita apresentar um conjunto mínimo de atributos de qualidade para de fato
apresentar um valor concreto durante um projeto de software. Manter uma especificação de
requisitos, se mal planejada, pode tornar-se oneroso e incômodo. Outro agravante é o uso de
ferramentas inadequadas para a geração e manutenção de uma especificação, que de certa
forma impõe mais dificuldades do que benefícios à disciplina de ER.
Em um contexto ágil de desenvolvimento de software, uma importante questão que se
levanta quanto à manutenção de uma especificação de requisitos é: será possível manter uma
especificação de requisitos de qualidade em uma metodologia ágil sem “engessar” o processo
de descoberta de requisitos e, por conseguinte, atravancar toda a metodologia?
Visando responder esta importante pergunta, este trabalho sugere o desenvolvimento
de um protótipo de ferramenta CASE para gerência de requisitos voltado à metodologia ágil
Extreme Programming (XP). Desta forma, quando aplicado ao modelo de desenvolvimento
XP, o protótipo propõe-se a manter uma especificação de requisitos alicerçada em todos os
atributos de qualidade necessários sem impor qualquer restrição à metodologia para tanto.
A fim de atingir o objetivo proposto, este trabalho está organizado em um conjunto de
seis capítulos, os quais seguem o protocolo apresentado nos próximos parágrafos deste texto.
O capítulo 1 trata de introduzir os conceitos referentes à Engenharia de Software, que
compreendem os requisitos básicos necessários aos conceitos que se seguem. Aspectos
históricos, características do software e conceito de ciclo de vida são alguns dos assuntos
tratados neste capítulo.
14
O capítulo 2 aborda o conceito de requisito, fundamental à definição do protótipo
proposto e essencial ao desenvolvimento de software e a Engenharia de Software; a
classificação dos requisitos, os atributos de qualidade de requisitos e os problemas
relacionados são também amplamente discutidos neste tópico.
O capítulo 3, por sua vez, se atém a disciplina de Engenharia de Requisitos, uma
importante subárea da Engenharia de Software que trata exclusivamente da definição do
processo de descoberta, classificação, priorização, validação e gerência dos requisitos de um
software.
No capítulo 4 apresenta-se a metodologia ágil Extreme Programming, enfatizando suas
principais características e valores, ressaltando como ela trata os requisitos durante o processo
de desenvolvimento e avaliando-se qual é o grau de atendimento da especificação de
requisitos gerada quanto aos atributos de qualidade necessários.
O capítulo 5 apresenta o conceito de ferramenta de apoio ao processo de
desenvolvimento de software. Neste capítulo são apresentadas quatro ferramentas de gerência
de requisitos para a metodologia Extreme Programming oferecidas gratuitamente na grande
rede, a partir das quais é feita uma análise comparativa. Com base nos resultados obtidos com
a análise, conjuntamente com os critérios de seleção definidos para as ferramentas e os
atributos de qualidade, apresenta-se no capítulo 6 a modelagem do protótipo em termos de
casos de uso, diagramas de classe e interface com o usuário.
15
1. ENGENHARIA DE SOFTWARE
Neste capítulo são abordados aspectos históricos que deram origem a Engenharia de
Software, uma importante área da Engenharia que visa a melhoria constante do processo de
desenvolvimento de software, com a finalidade de garantir qualidade e cumprimento de
prazos e custos. Conceitos como software, processo de software e modelo de processo de
software compreendem o universo de trabalho das técnicas de Engenharia de Software
existentes.
1.1. Histórico
O software é indispensável ao funcionamento da sociedade contemporânea. Ele
controla infra-estruturas e serviços essenciais a nossa vida. Redes de água, eletricidade, redes
bancárias, bolsa de valores, telefonia, entre outros, têm suas atividades controladas por
sistemas de informação em computador. O software está incorporado à rotina de qualquer
pessoa, direta ou indiretamente.
Mas afinal, o que realmente é software? Segundo Pressman (2002) por software
entende-se os programas, estruturas de dados e a documentação de operação e uso que,
quando executados, fornecem a função e o desempenho desejados.
O software apresenta características peculiares em relação aos demais produtos
produzidos pelos seres humanos. O software é elemento de um sistema lógico e não físico
(PRESSMAN, 2002). Para Sommerville (2007), ele [o software] é abstrato e intangível, não
limitado por materiais e leis físicas ou processos de manufatura.
16
As características do software residem, segundo Pressman (2002), em três importantes
itens, a saber:
a) O software é desenvolvido, ou passa por um processo de engenharia, não é
manufaturado.
No desenvolvimento de software a relação entre as pessoas envolvidas na
atividade e o trabalho a ser realizado é diferente de um processo de manufatura
convencional. Além disso, os custos de desenvolvimento do software estão
concentrados na engenharia, o que pressupõem que a gerência de projetos de
software deva ser diferente da gerência de projetos de fabricação.
b) Software não se desgasta.
O software não é suscetível às adversidades físicas que afetam praticamente todos
os outros produtos feitos pelo homem. Quando, por exemplo, é necessário trocar
uma peça do motor de um automóvel o processo é relativamente simples, pois
existem peças de reposição. Todavia, quando o software falha não existem peças
de reposição, o custo de manutenção pode ser elevado em razão da complexidade
do processo e, de quebra, pode indicar que houve um erro no projeto do mesmo.
c) A maior parte do software continua a ser construída sob encomenda.
Diferentemente de outras áreas da engenharia, como a mecânica e a elétrica, por
exemplo, o conceito de reuso de componentes de software ainda é incipiente.
Embora já esteja bem difundido este conceito em função das linguagens
orientadas a objetos, por exemplo, muito é feito do princípio (sob encomenda) em
um software.
Em vista das características atípicas que o produto de software possui, o seu
desenvolvimento apresenta grande complexidade. Existem inúmeros problemas que podem
surgir no decorrer do desenvolvimento que podem vir a comprometer o produto final. O
grande dilema vivenciado pelos desenvolvedores desde os primórdios da indústria do software
é como desenvolver um produto confiável e de qualidade que respeite os custos e os prazos de
entrega previamente estipulados.
17
Na década de 60, os problemas com desenvolvimento de software atingiram níveis
críticos. As causas para este estresse na indústria do software, segundo Vergílio (2009), se
baseavam basicamente nos seguintes problemas:
a) Cronogramas e custos imprecisos;
b) Inexistência de dados históricos sobre o processo de desenvolvimento;
c) Comunicação deficiente com o usuário;
d) Carência de conceitos quantitativos sobre confiabilidade, qualidade e
reusabilidade;
e) Manutenção difícil.
A evolução do hardware também representava um agravante ao desenvolvimento de
software. Projetos até então tidos como não realizáveis tornaram-se possíveis em função do
novo hardware permitir a sua execução. Com isso o software a ser produzido apresentava-se
maior e mais complexo do que os sistemas anteriormente desenvolvidos (SOMMERVILLE,
2007).
Em função dos problemas encontrados, os desenvolvedores observaram que o
desenvolvimento informal de software, feito até então, não mais suportava as necessidades de
projeto apresentadas. Era necessária alguma mudança para reverter o quadro crítico que
estava instaurado na indústria do software.
A resposta a então denominada “crise do software” veio em 1968, com a organização
de uma conferência para discutir a turbulência que a indústria do software estava enfrentando.
Dentre as discussões feitas na busca por soluções foi proposto o conceito inicial de
“Engenharia de Software”, como um conjunto de técnicas e métodos formais de
desenvolvimento, na intenção de eliminar o amadorismo e formalizar todo o processo de
desenvolvimento de software (SOMMERVILLE, 2007).
Ainda segundo Sommerville (2007), a Engenharia de Software é uma disciplina de
engenharia relacionada com todos os aspectos de produção de software, desde os estágios
iniciais de especificação do sistema até sua manutenção, depois de entrar em operação. Ela se
preocupa com o software como produto (PAULA FILHO, 2001), utilizando sólidos princípios
18
de engenharia com o intuito de obter o software de maneira econômica, com características de
confiabilidade e eficiência no uso em máquinas reais (PRESSMAN, 2002).
1.2. Processo de Software
A engenharia de software se fundamenta no processo (PRESSMAN, 2002). O
processo, portanto, é o que garante que as metodologias e ferramentas usadas pela Engenharia
de Software tenham o efeito esperado.
Segundo Campos (1999), processo é um conjunto de causas que provoca um ou mais
efeitos. Sempre que algo ocorre (efeito, fim, resultado) existe um conjunto de causas que
podem ter influenciado a sua ocorrência. A saída de qualquer processo, portanto, é um efeito
de sua execução.
Segundo Rabello (2006), os processos são importantes porque imprimem consistência
e estrutura a um conjunto de atividades. Um processo institucionalizado garante um padrão e,
por conseguinte, ajuda a manter as características de qualidade do produto final, mesmo sendo
este produzido por indivíduos diferentes.
Para Sommerville (2007), um processo de software é um conjunto de atividades que
leva a produção de um software. Pressman (2002) afirma que o processo define uma estrutura
para um conjunto de áreas-chave de processo que deve ser estabelecida para a efetiva
utilização da tecnologia de Engenharia de Software. Tais áreas formam a base para o controle
gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são
aplicados, os produtos de trabalho produzidos, os marcos estabelecidos, a qualidade
assegurada e as modificações geridas.
Todo o processo possui atividades que devem ser executadas no seu decorrer. Existem
diferentes processos de software na literatura. Segundo Sommerville (2007), dentre todos os
processos, as atividades que lhes são comuns compreendem:
a) Especificação de software: definição das funcionalidades e restrições do software;
b) Projeto e implementação do software: produção do software que atenda as
especificações;
c) Validação do software: validação do software com o cliente a fim de garantir que
ele esteja de acordo com as especificações;
19
d) Evolução do software: evolução do software durante seu ciclo de vida para
acompanhar as necessidades dos clientes.
Pressman (2002) entende, por sua vez, que todo o processo de software pode ser
composto por três fases, a saber:
a) Definição: definição dos requisitos. O foco da fase é descobrir “o quê” o software
deve fazer;
b) Desenvolvimento: O foco da fase é o “como”. Esta fase engloba o projeto, a
codificação e os testes do software;
c) Manutenção: O foco desta fase são as mudanças, sejam elas para corrigir erros,
adaptar, melhorar ou inserir novas funcionalidades no software.
1.3. Modelo de ciclo de vida
A aplicação de um processo de software não se dá diretamente no desenvolvimento de
um software. A utilização de um modelo de processo de software permite focalizar aspectos
diferenciados de um mesmo processo de software. Há modelos que enfocam a entrega rápida
de um protótipo inicial do sistema ao usuário. Outros, por sua vez, orientam a total
especificação do sistema e uma única entrega ao cliente.
Um modelo de processo de software, segundo Sommerville (2007), é uma abstração de
um processo de software. Cada modelo representa um processo sob determinada perspectiva.
Ou seja, o modelo representa parcialmente um processo de software e não a sua totalidade.
É possível também entender modelo de processo de software (ou paradigma de
engenharia de software) como uma estratégia de desenvolvimento que abrange camadas de
processos, métodos e ferramentas na resolução de problemas. (PRESSMAN, 2002)
Existem na literatura inúmeros modelos de processos de software. O exemplo mais
clássico é o modelo em Cascata, proposto por Royce em 1970. Além dele, pode-se citar o
Desenvolvimento Evolucionário, o Desenvolvimento Orientado ao Reuso, o Desenvolvimento
Incremental, o Desenvolvimento Formal de Sistemas e os modelos ágeis, como SCRUM, a
Extreme Programming, o Feature Driven Development (FDD), entre outros.
20
Embora cada modelo apresente suas particularidades, é possível agrupá-los em dois
grandes grupos. O primeiro grupo engloba os modelos ditos tradicionais, e o segundo, os
modelos ditos ágeis.
Os modelos tradicionais caracterizam-se por serem baseados no modelo Cascata. A
principal característica do modelo Cascata é o seu enfoque linear e sequencial ao processo de
software. No Cascata, as fases que compõe o modelo devem ser executadas na ordem correta,
iniciando pela primeira e seguindo seqüencialmente até a última. O Cascata foi concebido de
outros processos de engenharia predecessores com a finalidade de orientar o desenvolvimento
de grandes produtos de software. Embora seja eficaz no desenvolvimento, é um modelo
burocrático e rígido que dá ao cliente pouca visibilidade do andamento do projeto. No grupo
dos métodos tradicionais encontram-se modelos como a Prototipação e suas variações, o
Desenvolvimento Incremental, o Espiral, o Processo Unificado (UP) e o Rational Unified
Process (RUP), entre outros.
Em suma, os modelos de desenvolvimento de software tradicionais orientam o
desenvolvimento de software por meio de uma estrutura bem definida de desenvolvimento,
cobrando disciplina e comprometimento com a metodologia por parte da equipe de
desenvolvimento. (RABELLO, 2006).
Já os modelos ágeis apresentam características consideravelmente diferentes em
relação aos tradicionais. A origem destes modelos baseia-se na crítica, por parte de
programadores e consultores, à burocracia que os modelos tradicionais impõem ao projeto de
desenvolvimento de um software.
Mais precisamente, o desenvolvimento ágil de software surgiu em fevereiro de 2001
com a formação da Agile Software Development Alliance (conhecida também como Agile
Alliance). Os fundadores foram 17 metodologistas que propuseram um manifesto com o
objetivo de encorajar a adoção de melhores meios de desenvolver software. Basicamente, o
manifesto é composto por quatro declarações de valores, que são:
a) Indivíduos e interações valem mais que processos e ferramentas.
b) Um software funcionando vale mais que documentação extensa.
c) A colaboração do cliente vale mais que a negociação do contrato.
d) Responder a mudanças vale mais do que seguir um plano.
21
Outra importante produção da equipe da Agile Alliance foi um conjunto de 12
princípios fundamentais que devem ser seguidos por qualquer metodologia ágil. A seguir está
sendo listado este conjunto de princípios segundo Ambler (2004).
1. A maior prioridade é satisfazer ao cliente mediante entregas de software de
valor em tempo hábil e continuamente.
2. Receber bem as mudanças de requisitos, mesmo em uma fase mais avançada
no desenvolvimento. Os processos ágeis direcionam as mudanças para obter vantagens
competitivas para o cliente.
3. Entregar software em funcionamento com frequência de algumas semanas a
alguns meses, de preferência na menor escala de tempo.
4. As equipes de negócio e de desenvolvimento devem trabalhar juntas
diariamente durante todo o projeto.
5. Construir projetos ao redor de indivíduos motivados. Dar-lhes o ambiente e o
apoio de que eles precisam e confiar neles para realizar o trabalho.
6. O método mais eficiente de levar informação a uma equipe de
desenvolvimento e fazê-la circular é a conversa cara a cara.
7. Ter o software funcionando é a principal medida de progresso.
8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários deveriam ser capazes de manter um ritmo constante
indefinidamente.
9. Atenção contínua a excelência técnica e a um bom projeto aumentam a
agilidade.
10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é
essencial.
11. As melhores arquiteturas, requisitos, projetos provêm de equipes organizadas.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz
e então se ajustar e adaptar seu comportamento.
Observa-se desta forma que a Engenharia de Software surgiu com a finalidade de
orientar e definir um processo de desenvolvimento de software bem estruturado com vistas a
controlar os problemas relacionados ao não cumprimento de prazos e aos custos, dentre
outros. Desta forma, o processo define um conjunto básico de atividades que levam a
construção de um produto de software. A execução de um processo de software não se da
nativamente, mas sim através de um modelo de processo, que nada mais é que uma abstração
22
particular do próprio processo. No âmbito de modelos de processos de software, existem os
modelos prescritivos, oriundos do Cascata, que implementam um conjunto de atividades
rigidamente definidas e burocráticas, e os ágeis, originados de uma oposição aos métodos
prescritivos, que enfatizam o desenvolvimento rápido, a simplicidade, a presença constante do
cliente e uma boa comunicação.
23
2. REQUISITOS
Para iniciar-se o desenvolvimento de um software, utilizando um modelo qualquer de
processo de software, uma das primeiras atividades a ser realizada é compreender quais são as
necessidades e expectativas do cliente em relação ao produto a ser desenvolvido. As
informações recolhidas neste processo representam os requisitos que o software deve atender.
Especifica-se um software em termos de seus requisitos. Segundo Sommerville
(2007), “os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e
suas restrições operacionais”. Os requisitos representam necessidades que os clientes
apresentam e buscam sanar através do sistema a ser desenvolvido ou modificado.
Os requisitos de um sistema, como explica Sommerville (2007), podem ser
apresentados em diferentes níveis de abstração. Ou seja, em um extremo, um requisito
expressa simplesmente um serviço ou uma restrição que o sistema deve apresentar de forma
abstrata. Em outro extremo, um requisito define de forma detalhada e específica uma função
do sistema.
Os diferentes níveis de abstração dos requisitos de um sistema, desde o mais abstrato
até o mais específico, são de fundamental importância ao processo de desenvolvimento de
software. Jacobson, Booch e Rumbaugh (1999), em seu livro The Unified Software
Development Process afirmam que a coleta de requisitos possui dois objetivos: encontrar os
verdadeiros requisitos e representar estes requisitos de modo satisfatório para os usuários,
clientes e desenvolvedores. Ainda segundo os autores, os verdadeiros requisitos são aqueles
que quando implementados trarão o valor esperado para os usuários. Já a representação dos
requisitos visa descrevê-los de uma forma que estes possam ser entendidos por usuários e
clientes, além dos desenvolvedores.
24
No desenvolvimento de um sistema, os requisitos podem surgir de várias fontes. A
principal delas, de fato, é o cliente. Mas também é possível extrair requisitos do domínio,
como por exemplo, as leis fiscais no caso do desenvolvimento de um sistema contábil. Outro
exemplo seria uma restrição de projeto que afirma que o software deva apresentar um taxa de
erros menor que 0,001%. Todas as situações apresentadas representam necessidades que o
sistema deve atender. Todavia, cada um dos requisitos acima especificados aponta
características essencialmente distintas (de diferente enfoque). Em vista dessa separação, é
possível classificar os requisitos em grupos distintos.
Segundo Sommerville (2007), os requisitos podem ser classificados como requisitos
de usuário e requisitos de sistema.
2.1. Requisitos de usuário
Os requisitos de usuário são declarações em linguagem natural e/ou em diagramas
acerca de serviços e restrições que o sistema deve atender. O objetivo é oferecer aos usuários
uma descrição compreensível e não técnica dos requisitos funcionais e não-funcionais do
sistema, de modo que haja compreensão dos mesmos.
Um grande problema encontrado em expressar requisitos em linguagem natural é a
dificuldade em se garantir precisão na descrição do requisito de modo a evitar ambiguidades.
Também é comum a ocorrência de confusão na descrição dos requisitos em razão da
condensação de vários requisitos em um texto único, ou mesmo, quando falta compreensão
dos requisitos por parte dos responsáveis pela criação do documento de requisitos a ser
apresentado ao usuário.
2.2. Requisitos de sistema
Os requisitos de sistema definem detalhadamente as funções, os serviços e as restrições
operacionais do sistema. Normalmente os requisitos de sistema são escritos na forma de um
contrato entre o cliente e a equipe de desenvolvimento.
Resumidamente, os requisitos de sistema são versões estendidas dos requisitos de
usuário que são utilizados pelos engenheiros de software como ponto de partida para o projeto
25
do sistema. Contudo, os requisitos de sistema não devem descrever como o sistema pode ser
implementado e projetado. Devem apenas detalhar e explicar como os requisitos de usuário
serão fornecidos pelo sistema.
Sommerville (2007) classifica os requisitos de sistema em três classes distintas:
requisitos funcionais, requisitos não funcionais e requisitos de domínio.
2.2.1. Requisitos Funcionais
“Os requisitos funcionais de um sistema descrevem o que o sistema deve fazer”
(SOMMERVILLE, 2007). A principal característica que os requisitos funcionais apresentam
é o alto grau de detalhamento, especificando cada função que o sistema deve implementar em
termos de entrada, saída, exceções, etc.
A especificação de requisitos funcionais deve abranger todos os serviços exigidos pelo
usuário (completeza) de forma não contraditória. Todavia, teoria e prática neste caso
mostram-se ligeiramente distantes. Ao especificar requisitos funcionais de um sistema com
dimensões consideravelmente grandes e de domínio complexo é praticamente impossível
atingir, de fato, consistência e completeza. A origem dessa dificuldade recai nos aspectos
humanos do processo. Uma explicação é a ocorrência de erros e omissões ao se redigir o
requisito, mediante dificuldades de entendimento que o escopo do sistema a ser desenvolvido
apresenta. Outro caso, mais convencional, é a falta de unanimidade entre os próprios
envolvidos (stakeholders) na descrição de suas necessidades.
2.2.2. Requisitos não-funcionais
Os requisitos não funcionais são aqueles requisitos que não apresentam ligação com
funcionalidades que o sistema precisa apresentar. Eles relacionam-se com propriedades
emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento.
Uma falha na especificação de um requisito não funcional pode afetar o sistema de forma
acentuada, podendo causar até o seu descarte. Um exemplo de tal afirmação é um requisito de
confiabilidade de um sistema crítico de controle de uma usina nuclear, que não é atingido pelo
sistema em simulações de operação feitas. Devido ao alto grau de exigência de confiabilidade
26
requisitado, o sistema não poderá entrar em operação existindo grande probabilidade de
descarte do mesmo.
Sommerville (2007) divide os requisitos não-funcionais em três grupos, a saber,
requisitos de produto, requisitos organizacionais e requisitos externos.
a) Requisitos de produto: especificam o comportamento do produto. Desempenho,
rapidez de execução e requisitos de confiabilidade fazem parte deste grupo.
b) Requisitos organizacionais: requisitos advindos de políticas e procedimentos
organizacionais tanto do cliente quanto do desenvolvedor.
c) Requisitos externos: Requisitos de interoperabilidade entre sistemas, requisitos
referentes às leis e a questões de caráter ético.
A figura 1 apresenta os tipos de requisitos não-funcionais segundo Sommerville
(2007).
Figura 1: Tipos de requisitos não funcionais
Fonte: Sommerville(2007), pg. 82.
2.2.3. Requisitos de domínio
Os requisitos de domínio fazem referência ao domínio da aplicação. O domínio, em
suma, representa a esfera de ação, o âmbito dentro do qual o sistema atua e é influenciado.
27
Segundo Sommerville (2007), “os requisitos de domínio podem ser novos requisitos,
podem restringir requisitos funcionais já existentes ou estabelecer a forma como cálculos
específicos devem ser gerados”.
Um exemplo básico de requisito de domínio pode ser o cálculo da velocidade média
que o software de controle de um trem deve fazer. Tal cálculo faz parte do domínio da Física.
É possível especificá-lo conforme mostra a figura 2:
Figura 2: Especificação de um requisito de domínio
Fonte: Primária
2.3. Especificação de requisitos e os problemas relacionados
Segundo Paula Filho (2001), “a Especificação dos Requisitos do Software é o
documento oficial de descrição dos requisitos de um projeto de software”. A especificação,
também conhecida como Documento de Requisitos, pode fazer referência a um módulo do
sistema ou a todo ele. Toda a especificação deve, segundo o mesmo autor, apresentar as
seguintes características:
a) Funcionalidade: descrição do software em termos de função. A pergunta chave é
“O que o software deve fazer?”.
b) Interfaces externas: maneira pela qual o software interage com as pessoas, com o
hardware, com outros sistemas e produtos.
c) Desempenho: especificação da velocidade de processamento, o tempo de resposta
e outros parâmetros requeridos pela aplicação.
28
d) Restrições impostas pela aplicação: restrições de padrões, linguagem de
programação, ambientes de operação, limites de recurso, etc.
e) Outros atributos: aqui são abordados aspectos de portabilidade, manutenibilidade
e confiabilidade.
Toda especificação de requisitos passa por uma etapa de elaboração onde, de fato, é
feita a formalização de todas as considerações acerca das necessidades do software, tomando
o ambiente de operação como base de análise. Uma boa especificação deve ser adaptável o
suficiente para atender a evolução dos requisitos no decorrer do tempo, bem como limitar-se a
descrever apenas os requisitos que o software deve atender (salvo exceções onde se faça
necessário especificar aspectos de desenvolvimento).
A seguir, cada um dos itens levantados acima são abordados e contextualizados
segundo as concepções de Paula Filho (2001).
2.3.1. Elaboração
Toda a especificação de requisitos (ou documento de requisitos) passa pela fase de
elaboração. Os membros da equipe do projeto do software são responsáveis pelo
desenvolvimento da elaboração com a indispensável participação de um ou mais usuários
chaves (ou clientes). Estes usuários ficam responsáveis, juntamente com a equipe do projeto,
pela correta especificação das necessidades que o software deve atender.
2.3.2. Ambiente
Quando o software fizer parte de um sistema mais amplo, os requisitos do software
estão contidos dentro de uma especificação mais ampla, normalmente uma Especificação dos
Requisitos do Sistema. Nessa situação o software é apenas um dos componentes do sistema e
não todo ele. Os requisitos do sistema se estendem a todas as necessidades dos componentes e
das interfaces que devem ser implementadas entre os mesmos.
Assim, todas as características requeridas para o ambiente considerado devem ser
especificadas a fim de assegurar o sucesso do projeto.
29
2.3.3. Evolução
A natureza dos requisitos é mutável. A mudança dos requisitos deve ser algo esperado
em qualquer projeto de software. Grande parte dos modelos de processo de software tem sua
estrutura moldada em favor da adaptação às mudanças nos requisitos, principalmente os
modelos ágeis. Nos modelos tradicionais, como o Cascata, uma mudança nos requisitos em
fases de desenvolvimento mais avançadas pode resultar em grandes problemas de ordem
financeira e de cronograma.
A evolução dos requisitos deve ser gerenciada, de modo que a alteração dos requisitos
seja controlada, minimizando qualquer problema decorrente.
O modelo CMMI (Capability Maturity Model Integration), um dos modelos de
melhoria de qualidade de processo mais reconhecidos no mundo, recomenda uma área de
processo voltada especificamente para gerenciamento de requisitos (Requirements
Management - REQM). Segundo Ahern (2006), para gerenciar requisitos, os profissionais
precisam desenvolver e entender o que estes requisitos significam antes de fazer qualquer
coisa com os mesmos. Depois de entendidas e confirmadas, todas as mudanças devem ser
gerenciadas, incluindo a manutenção de um histórico de mudanças e a evolução dos impactos
destas mudanças.
O gerenciamento de requisitos permite identificar inconsistências entre os requisitos e
os planos de projeto e trabalho dos produtos (software), dando condições para a execução de
ações corretivas na intenção de eliminá-las.
2.3.4. Limites
A Especificação dos Requisitos não deve incluir decisões de projeto e de desenho do
sistema, desde que estes não figurem como requisições explícitas que o cliente faz à equipe de
projeto. Para Paula Filho (2001), uma especificação deve se ater a três elementos
fundamentais:
a) Definir de forma completa e correta os requisitos do produto a ser desenvolvido.
b) Não descrever qualquer detalhe de desenho interno do sistema.
30
c) Não descrever aspectos gerenciais do projeto.
2.3.5. A problemática relacionada
Especificar requisitos utilizando linguagem natural pode trazer sérios problemas de
interpretação. A multiplicidade de interpretações possíveis para um mesmo enunciado
corroboram para erros de projeto. Sommerville (2007) aponta três agravantes do uso da
linguagem natural na especificação de requisitos de sistema:
a) A compreensão da linguagem natural depende do uso das mesmas palavras
buscando o mesmo significado tanto para leitores quanto para os elaboradores da
especificação.
b) A flexibilidade dada pela linguagem natural permite que seja escrito a mesma
coisa de várias formas distintas.
c) Difícil padronização.
Mesmo na especificação de requisitos de usuário, para os quais o uso da linguagem
natural aparentemente seria apropriado, deve-se ter cuidados especiais. Sommerville (2007)
recomenda o uso consistente da linguagem natural, utilizando ressaltos no texto e evitando ao
máximo o uso de jargões de informática.
Como forma de amenizar os problemas referentes à utilização da linguagem natural na
especificação de requisitos, principalmente os requisitos de sistema que necessitam de um
maior nível de padronização, pode-se utilizar um esquema padronizado de especificação.
Através da padronização da especificação reduz-se consideravelmente o escopo de
interpretações possíveis a um mesmo requisito. Quando fala-se em requisitos de sistema, esta
propriedade mostra-se de extrema valia, já que normalmente requisitos de sistema apresentam
um nível de detalhamento consideravelmente alto.
Sommerville (2007) apresenta uma solução de padronização de especificação de
requisitos utilizando um formulário padrão. Soluções como a criação de um glossário de
termos suscetíveis a mais de uma interpretação também são funcionais e recomendadas. A
figura 3 apresenta um exemplo de especificação de requisitos.
31
Figura 3: Especificação de requisitos utilizando um formulário padrão
Fonte: Sommerville (2007), pag. 89.
Também é possível especificar requisitos utilizando-se de linguagens gráficas. Os
diagramas auxiliam na compreensão dos requisitos e na redução de ambigüidades. O
diagrama de fluxo de dados, por exemplo, é uma ferramenta gráfica que dá aos
desenvolvedores condições de avaliar o fluxo das informações em relação às funções
implementadas e às entradas informadas. A figura 4 apresenta um Diagrama de Fluxo de
Dados, contendo a entidade externa Farmacêutico, os processos “Manter dados de
medicamentos”, “Manter dados de diagnósticos”, “Manter dados de materiais”, “Manter
dados de recomendações” e os depósitos de dados associados (Medicamentos, Diagnósticos,
Materiais, Recomendações).
32
6
Manter dados de medicamentos
Farmaceutico
5 Medicamentos
6 Diagnósticos
7
Manter dados de diagnósticos
7 Materias
10
Manter dados de materiais
8 Recomendações
9
Manter dados de recomendações
Figura 4: Exemplo de um Diagrama de Fluxo de Dados (DFD)
Fonte: Primária
A Unified Modeling Language (UML) é uma metodologia gráfica desenvolvida, dentre
outras coisas, para especificar requisitos de software. Os diagramas de casos de uso permitem
descrever funcionalidades do sistema a ser desenvolvido de forma clara e específica,
apresentando as relações estabelecidas entre os atores (entidades que atuam sobre o sistema) e
as funcionalidades do software (seus casos de uso).
A figura 5 apresenta os casos de uso para o responsável pelo almoxarifado (ator) em um
sistema de controle de estoque.
Figura 5: Diagrama de Casos de Uso
Fonte: Primária
33
2.4. Qualidade dos Requisitos
A qualidade dos requisitos elicitados determina profundamente a qualidade do produto
de software desenvolvido. Requisitos incompletos e inconsistentes comprometem o
entendimento do problema, podendo causar desvios custosos durante o desenvolvimento do
software.
Paula Filho (2001) apresenta oito características necessárias a uma Especificação de
Requisitos para que a mesma apresente qualidade. Segundo o autor é necessário que uma
especificação seja correta, precisa, completa, consistente, priorizada, verificável, modificável
e rastreável para apresentar de fato qualidade. A seguir, cada um destes atributos de qualidade
é abordado separadamente.
2.4.1. Correção
“Uma Especificação dos Requisitos está correta se todo requisito presente nela
realmente é um requisito do produto a ser construído” (PAULA FILHO, 2001). Os requisitos
devem expressar de forma correta as necessidades do cliente, de modo que recebam a
aprovação formal do mesmo.
2.4.2. Precisão
A precisão na Especificação dos Requisitos é obtida se cada requisito apresentar
apenas uma única interpretação, tanto pelo cliente quanto pelos desenvolvedores. Para obter a
precisão pode-se utilizar técnicas, como as apresentadas na seção 2.3.5, que trata de
problemas relacionadas à especificação de requisitos.
34
2.4.3. Completeza
Uma Especificação dos Requisitos não pode conter pendências. Ela deve possuir, para
ser considerada completa, todos os requisitos significativos referentes à funcionalidade,
desempenho, restrições de desenvolvimento, atributos e interface. Deve também definir todas
as respostas do software para todas as entradas possíveis, válidas e inválidas, em todas as
situações possíveis.
Vale ressaltar que, dificilmente em um sistema complexo, consegue-se atingir total
completeza nos requisitos. O escopo do software muitas vezes impossibilita o total
conhecimento e especificação de todas as necessidades, eventos e entradas possíveis e
necessárias.
2.4.4. Consistência
A consistência em uma especificação é obtida quando não existem conflitos entre os
requisitos.
Os conflitos podem ser basicamente de três tipos:
a) Conflitos entre características do mundo real: são exemplos deste tipo de conflito
formatos de relatórios, cores, etc.
b) Conflitos de ordem lógica ou temporal: quando dois ou mais requisitos se
contradizem na especificação da ordem de ocorrência de determinada ação.
c) Conflitos de definição: quando um ou mais verbetes são utilizados para designar
um mesmo objeto do mundo real.
2.4.5. Priorização
A priorização dos requisitos se dá em duas perspectivas: importância e estabilidade.
A estabilidade estima a probabilidade de um requisito mudar no decorrer do projeto.
Quanto à importância, pode-se ter requisitos essenciais, cuja necessidade de atendimento é
crítica; requisitos desejáveis, cujo atendimento aumenta o valor do produto e requisitos
opcionais, que podem ser atendidos se houver tempo hábil e recursos disponíveis.
35
2.4.6. Verificabilidade
Para uma Especificação de Requisitos ser verificável é necessário que:
a) Todos os requisitos nela contidos sejam verificáveis.
b) Exista um processo para verificar requisitos que seja finito, que tenha custo
compensador, que possa ser executado por pessoas ou máquinas, e que mostre a
conformidade final do requisito.
2.4.7. Modificabilidade
Uma especificação é modificável se a sua estrutura for maleável o suficiente para que
uma alteração seja executada de forma fácil, completa e consistente. Para alcançar a
modificabilidade, uma especificação requer uma organização coerente, feita através de índices
e referências cruzadas, ausência de redundância entre os requisitos e definição separada dos
mesmos no texto.
2.4.8. Rastreabilidade
A rastreabilidade de um requisito pressupõe que seja possível determinar seus
antecedentes e conseqüentes de maneira simples, ou seja, que se possa determinar, em relação
a um dado requisito, quais são os requisitos afetados por ele e quais o afetam dentro da
Especificação de Requisitos. A rastreabilidade dos requisitos permite, segundo Rational
Unified Process (2009), que seja possível:
a) Compreender a origem dos requisitos.
b) Gerenciar o escopo do projeto.
c) Gerenciar mudanças nos requisitos.
d) Avaliar o impacto no projeto da mudança em um requisito.
e) Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar,
talvez o requisito não seja atendido).
36
f) Verificar se todos os requisitos do sistema são desempenhados pela
implementação.
g) Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.
Paula Filho (2001) apresenta dois tipos distintos de rastreabilidade, um denominado
rastreabilidade para trás e outro chamado de rastreabilidade para frente. A rastreabilidade para
frente permite localizar quais os resultados do desenvolvimento são afetados pelo requisito
considerado. Já a rastreabilidade para trás permite encontrar a origem de cada requisito.
Conhecer as necessidades do cliente e desenvolver um software que realmente as atenda
é o principal ingrediente para o sucesso de um projeto de desenvolvimento. De fato, o
processo de extração dos requisitos é complexo e sujeito a inúmeros percalços, uma vez que é
uma atividade extremamente centrada na interação com pessoas. Sabe-se que pessoas distintas
apresentam uma visão diferenciada sobre um mesmo aspecto do ambiente e cabe ao analista
encontrar um ponto em comum. É muito importante que este processo de descoberta dos
requisitos gere uma especificação de requisitos de qualidade, que de fato reflita as reais
necessidades do cliente.
Tanto a rastreabilidade quanto os demais itens que definem teoricamente a qualidade
dos requisitos são preocupações de uma importante subárea da Engenharia de Software
denominada Engenharia de Requisitos. A ER engloba um conjunto de técnicas formais de
coleta, análise, documentação e gerência de requisitos de software que visa criar e manter um
documento de requisitos. O capítulo 3, que segue, aborda especificamente a Engenharia de
Requisitos e suas diversas atividades.
37
3. ENGENHARIA DE REQUISITOS
Erros na especificação de requisitos são muito custosos na indústria do software.
Segundo a Borland®
Software Corporation (2009), em média 40% do esforço durante um
projeto de software deve-se a retrabalho. Quem mais contribui para este valor são os erros de
requisitos, representando mais da metade do total. Mas qual é a explicação para tal fato? A
figura 6 faz uma representação clássica da dificuldade de entendimento entre as partes
envolvidas em um projeto de um software.
Figura 6: Dificuldades de compreensão
Fonte: http://wagnergomes.files.wordpress.com/2008/05/levantamentorequisitos.jpg
A Engenharia de Requisitos surgiu para tentar contornar problemas relacionados com a
especificação de requisitos de um software como os apresentados na figura 6. Ela se apresenta
como uma disciplina da Engenharia de Software que se preocupa com a elicitação dos
38
requisitos das fontes de informação disponíveis, e posterior análise, verificação,
documentação e gerenciamento dos mesmos. A ER fornece um mecanismo adequado para
atender o que o cliente deseja. O processo de engenharia de requisitos visa criar e manter uma
especificação dos requisitos com todos os atributos de qualidade (correteza, precisão,
completeza, consistência, priorização, verificabilidade, modificabilidade e rastreabilidade).
Pressman (2002) define a Engenharia de Requisitos como
“O uso sistemático de princípios, técnicas, linguagens e ferramentas comprovadas
para a análise, documentação, evolução continuada das necessidades do usuário e
especificação do comportamento externo de um sistema para satisfazer as
necessidades do usuário, que sejam efetivas em termos de custo”.
Sommerville (2007) divide o processo de Engenharia de Requisitos em quatro
subprocessos. Estes subprocessos relacionam-se com a avaliação da real utilidade do sistema
para o cliente (estudo da viabilidade), obtenção dos requisitos (elicitação e análise), conversão
destes requisitos em alguma forma padrão (especificação) e a averiguação de se os requisitos
especificados de fato definem o sistema desejado pelo cliente (verificação).
A figura 7 apresenta o processo de Engenharia de Requisitos proposto por Sommerville
(2007).
Figura 7: Processo de Engenharia de Requisitos
Fonte: Sommerville (2007), pg. 50.
39
Pressman (2002), por sua vez, entende que a engenharia de requisitos é um conjunto de
seis passos distintos, que são a elicitação dos requisitos, análise e negociação de requisitos,
especificação de requisitos, modelagem do sistema, validação de requisitos e gestão de
requisitos.
Embora Sommerville (2007) e Pressman (2002) apresentem um número distinto de
etapas para definir a Engenharia de Software, pode-se observar que é meramente uma questão
de agrupamento. O processo de Engenharia de Requisitos é de consenso.
A seguir serão apresentadas as etapas da Engenharia de Requisitos mesclando-se os
conceitos apresentados por ambos os autores.
3.1. Estudo da Viabilidade
O estudo da viabilidade visa, ao final do processo, elaborar um relatório que informa ao
cliente se é ou não é viável prosseguir com as próximas etapas da Engenharia de Requisitos.
Para iniciar-se o estudo da viabilidade é necessário compreender os requisitos preliminares do
negócio, ter uma descrição (esboço) superficial do sistema e também entender como o sistema
proposto irá apoiar os processos de negócio da empresa.
Para Sommerville (2007), o estudo de viabilidade deve responder três questões
importantes:
a) O sistema contribui para os objetivos da organização?
O sistema deve ter sua utilidade vista de forma clara e o seu uso deve contribuir
para os objetivos da organização. Do contrário, o software nasce sem nenhuma
utilidade.
b) O sistema pode ser implantado com a tecnologia atual e dentro das restrições
definidas de custo e prazo?
Verifica-se se a tecnologia disponibilizada pela organização, os recursos
financeiros a serem despendidos e o tempo estipulado para o desenvolvimento do
software permitem de fato o seu desenvolvimento.
40
c) O sistema pode ser integrado a outros sistemas já implantados?
Normalmente o novo software precisa comunicar-se com os sistemas legados
(sistemas já existentes e em funcionamento). Verifica-se, portanto, se a
comunicação entre os sistemas legados e o novo é possível.
É de vital importância que as fontes selecionadas para extração de informações, tanto no
estudo de viabilidade, quanto nos demais subprocessos da Engenharia de Requisitos, sejam
fidedignas. Do contrário, omissões e/ou erros podem se propagar para etapas mais adiantadas
do desenvolvimento, podendo comprometer seriamente todo o projeto.
Pressman (2002) coloca o estudo da viabilidade dentro da etapa de Elicitação de
Requisitos, sendo um dos produtos de trabalho da mesma a declaração de viabilidade para o
sistema em questão.
3.2. Elicitação e análise dos requisitos
Tendo o relatório de viabilidade do sistema homologado a real utilidade e
possibilidade de desenvolvimento do sistema, segue-se para a etapa de elicitação e análise dos
requisitos.
Nesta etapa, os engenheiros trabalham junto aos stakeholders (envolvidos) do sistema
a fim de aprender o que o sistema deve fazer, como deve fazer e quais são as restrições
impostas a ele.
Aparentemente, a elicitação de requisitos apresenta-se como uma atividade simples de
ser realizada. Basta que o analista peça ao cliente o que ele deseja que o software faça e está
feito. Certo? Não, totalmente errado!
A elicitação é um processo complicado, que impõe dificuldade aos profissionais que a
executam. Inúmeras situações problemáticas podem ocorrer durante a elicitação.
As maiores dificuldades encontradas envolvem aspectos de comunicação. Sommerville
(2007) elenca cinco itens que normalmente originam problemas durante a elicitação, enquanto
que Pressman (2002) os divide em três grupos distintos, a saber, problemas de escopo,
problemas de entendimento e problemas de volatilidade. A seguir serão apresentados os
principais problemas encontrados durante esta etapa segundo os atores citados:
41
a) Stakeholders não sabem o que querem do sistema computacional especificamente,
tendo dificuldade de articular seus pedidos ou mesmo fazendo pedidos
demasiadamente custosos de serem desenvolvidos. Neste caso, se tem um problema
de entendimento e de escopo, pois além de não ser sabido quais as funções que o
sistema deve executar, existe dificuldade na identificação das necessidades.
b) Os stakeholders expressam os requisitos em seus próprios termos, deixando
muitas vezes implícitos termos técnicos de sua rotina. Um típico problema de
entendimento.
c) Diferentes stakeholders possuem diferentes requisitos, cada qual expresso de uma
forma distinta. O analista precisa encontrar e gerenciar pontos comuns e conflitos
existentes nos requisitos. Apresenta-se como um problema de entendimento.
d) Fatores políticos da organização podem ter forte influência nos requisitos
elicitados. Normalmente, quando problemas como estes ocorrem o escopo do
sistema tenta ser manipulado para beneficiar pessoas específicas, ou seja, os
envolvidos tentam criar um sistema que os favoreça.
e) O ambiente do sistema é naturalmente mutável. Em decorrência, os requisitos do
sistema também tendem a se modificar no tempo. Resumindo, os requisitos são
voláteis.
A análise e elicitação é um subprocesso composto por várias atividades. Sommerville
(2007) a divide em quatro atividades distintas que são: a obtenção de requisitos, classificação
e organização de requisitos, priorização de requisitos e documentação de requisitos.
Na atividade de Obtenção de Requisitos o objetivo é reunir informações sobre o
sistema a ser desenvolvido e os sistemas já existentes das diferentes fontes de informação
existentes, tais como documentos, stakeholders, aspectos de domínio, etc. Esta atividade
possui forte interação entre os analistas e os stakeholders do sistema. Pontos de vista do
sistema são definidos. Ou seja, a visão apresentada por cada fonte de informação acerca do
sistema representa um ponto de vista específico. Um ponto de vista é olhar o sistema sob
determinada perspectiva. Embora eles sendo distintos, muitos dos requisitos apresentados por
pontos de vista distintos tendem a apresentar características comuns.
Na obtenção dos requisitos são empregadas técnicas que visam diminuir os problemas
de escopo e de entendimento durante a etapa. Exemplos de técnicas de elicitação são
etnografia, casos de uso (UML), entrevista, questionário, etc.
Na Classificação e Organização de Requisitos os requisitos recolhidos são organizados
em conjuntos coerentes, considerando-se a relação existente entre os mesmos.
42
Na Priorização e Negociação de Requisitos os requisitos são priorizados, ou seja, são
postos numa listagem por ordem de prioridade, os conflitos entre requisitos são buscados e
uma resolução aos mesmos é aplicada. Pressman (2002) sugere uma abordagem interativa
para resolver conflitos, onde os clientes, usuários e analistas expõem suas considerações a fim
de encontram um ponto de acordo comum, de modo que cada um alcance certo grau de
satisfação.
Na Documentação de Requisitos são produzidos documentos de requisitos, tanto
formais quanto informais.
3.3. Especificação dos Requisitos
Pode-se especificar os requisitos de diferentes maneiras. É possível fazê-la através de
um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de
cenários de uso, um protótipo ou qualquer combinação dos anteriores (PRESSMAN, 2002).
A especificação adapta-se ao tipo de sistema a ser desenvolvido. Para sistemas grandes,
de difícil entendimento, pode ser necessário utilizar mais de uma forma de especificação,
enquanto que para um sistema de domínio conhecido, e de pequeno porte, uma coleção de
cenários de uso é suficiente.
A especificação de um sistema tem a finalidade de “descrever a função e o desempenho
de um sistema baseado em computador e as restrições que vão governar o seu
desenvolvimento” (PRESSMAN, 2002).
3.4. Validação dos Requisitos
“A validação dos requisitos dedica-se a mostrar que os requisitos realmente definem o
sistema que o usuário deseja” (SOMMERVILLE, 2007). Na validação examina-se a
especificação dos requisitos previamente criada a fim de encontrar ambiguidades,
inconsistências, omissões e erros, fazendo as correções necessárias. Também é avaliada a
conformidade entre as normas de projeto, processo e produto previamente estabelecidos e os
produtos de trabalho obtidos.
43
A validação é importante porque desenvolver um requisito incorreto pode levar a
custos excessivos no contexto de um projeto de desenvolvimento de software. Estes custos
aumentam quase que exponencialmente à medida que o desenvolvimento do sistema avança,
como pode ser observado na figura 8.
Figura 8: Custos de erros nos requisitos
Fonte: Adaptação do vídeo disponível em
http://www.borland.com/media/en/edm/rdm_solution_demo/rdm.html
Os requisitos devem ser validados tomando por base os aspectos de qualidade de
requisitos conforme apresentado na seção 2.4.
3.5. Gerenciamento de Requisitos
O gerenciamento de requisitos é uma atividade que visa controlar o problema da
volatilidade dos requisitos. Ou seja, a necessidade de mudança em um software persiste
durante todo o seu ciclo de vida.
A mudança nos requisitos não pode ser vista como um problema, mas sim como uma
característica inerente ao próprio software. Os requisitos mudam porque a evolução natural
também se aplica a eles. Muito mais o software deve se adaptar ao meio do que o inverso.
44
O objetivo do gerenciamento de requisitos é compreender e controlar as mudanças dos
requisitos de sistema. É necessário ter condições de acompanhar os requisitos
individualmente, manter as ligações entre os requisitos dependentes e quando necessário
permitir determinar o impacto de uma mudança de um requisito em relação aos demais.
(SOMMERVILLE, 2007).
Muito embora os objetivos do gerenciamento de requisitos sejam os mesmos, cada
metodologia de desenvolvimento de software o realiza de maneira particular, o que é uma
característica aplicável à Engenharia de Requisitos como um todo.
O que deve ser respeitado, contudo, em qualquer abordagem dada ao processo de ER é
o seu objetivo fundamental: gerar e manter uma especificação de requisitos de qualidade.
Desta forma, seja em uma metodologia ágil ou seja em uma metodologia prescritiva, o
processo de Engenharia de Requisitos deve focar a construção de um documento de requisitos
que defina realmente o software que o cliente necessita. A forma de construir a especificação
de requisitos também não segue um padrão. Em alguns modelos, por exemplo, a especificação
de requisitos é feita através de um documento detalhado e formal (Cascata), enquanto em
outros como a Extreme Programming, a especificação dos requisitos é feita através de
estórias, escritas pelo próprio cliente e destituídas de qualquer regra formal para a escrita. O
próximo capítulo trata exatamente da relação entre a formalidade teórica pregada pela
Engenharia de Requisitos, fortemente presente nos métodos prescritivos, e a “liberdade”
apregoada pela Extreme Programming.
45
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS
Os modelos de desenvolvimento de software estão classificados em dois grandes
grupos, conforme descrito na seção 1.3, que são os modelos prescritivos ou tradicionais e os
modelos ágeis.
Modelos prescritivos seguem uma linha pouco flexível no desenvolvimento do
software. Tomando por exemplo o modelo Cascata, que foi o primeiro modelo desenvolvido,
observa-se uma clara sequência inflexível de atividades que são executadas ao longo do
tempo. A figura 9 apresenta a estrutura do Cascata segundo Sommerville (2007).
Figura 9: Modelo Cascata
Fonte: Sommerville (2007)
Basicamente, os modelos prescritivos se valem de três premissas básicas (FREIRE,
2009), que são:
46
a) É necessário realizar uma análise detalhada dos requisitos antes de projetar a
arquitetura de um sistema.
b) É necessário realizar um estudo detalhado da arquitetura do sistema antes de
iniciar a implementação.
c) É necessário testar completamente o sistema antes de colocar em produção o
software.
Desenvolver software seguindo estas premissas é perfeitamente possível. É tão
possível que muitos projetos de desenvolvimento de software utilizam ainda hoje modelos
prescritivos. Todavia, o desenvolvimento tradicional apresenta alguns problemas conforme
explica Freire (2009). Segundo o autor, os métodos tradicionais supõem que seja possível
prever o futuro, dada a grande quantidade de estudos e documentações realizadas antes da
realização de qualquer implementação. Outro ponto negativo é a pouca participação do cliente
no projeto, que muitas vezes participa apenas nas etapas de elicitação dos requisitos e de
implantação do software. O terceiro problema apontado refere-se à burocracia que tais
modelos impõem ao projeto. Um grande número de documentos é gerado a cada etapa, sendo
que os mesmos identificam o grau de avanço do projeto. Trocando em miúdos, o progresso é
indicado pela burocracia!
As metodologias ágeis surgiram então como uma nova forma de desenvolver software
de maneira mais eficiente e menos burocrática. Tendo como marco o manifesto ágil de 2001,
os métodos ágeis orientam-se por um conjunto de princípios, conforme apresentados na seção
1.3 que tratam aspectos tanto humanos quanto técnicos do desenvolvimento de software.
Dentre as metodologias ágeis existentes merece destaque a Extreme Programming,
como sendo umas das principais representantes desta nova filosofia.
A Extreme Programming foi desenvolvida por Kent Beck em um projeto sitiado na
DaimlerChrysler, no qual ele utilizou novos conceitos idealizados sobre o desenvolvimento
de software para dar forma ao novo modelo de desenvolvimento.
Beck (2004) define a Extreme Programming como “uma metodologia leve para times
de tamanho pequeno á médio, que desenvolvem software em face a requisitos vagos que se
modificam rapidamente” . Ainda segundo o autor, o que diferencia a XP das demais
metodologias refere-se aos seguintes pontos:
a) Feedback antecipado, concreto e contínuo derivado dos ciclos curtos de
desenvolvimento.
47
b) Abordagem incremental do projeto, que gera um plano geral que pode evoluir
com o passar do tempo.
c) Confiança nos testes automatizados escritos por programadores e clientes.
d) Confiança na comunicação oral, teste e código-fonte como formas de comunicar a
estrutura e o objetivo do sistema.
e) Confiança em um processo evolutivo que perdura tanto quanto o sistema em si.
f) Confiança na intensa colaboração de programadores com habilidades comuns.
g) Confiança em práticas que combinam tanto com os instintos a curto prazo dos
programadores quanto com os interesses de longo prazo do projeto.
A XP aponta quatro dimensões que podem ser melhoradas em qualquer projeto de
software. São elas a comunicação, a simplicidade, a coragem e o feedback. Estas quatro
dimensões são conhecidas como valores e são essenciais a qualquer projeto que venha a
utilizar a metodologia. Observa-se que os valores da XP têm grande enfoque nas pessoas, na
equipe de desenvolvimento, visto que é muito importante ter-se de fato uma equipe de
desenvolvimento e não apenas um grupo.
4.1. Valores
Os quatro valores fundamentais da XP representam o pilar sobre o qual toda a
metodologia sustenta-se. Todos eles, igualmente, apresentam-se como indispensáveis à
execução do modelo. A seguir é apresentado cada um deles, ressaltando-se a sua importância.
4.1.1. Comunicação
A comunicação é um requisito para o sucesso do desenvolvimento de software
(AMBLER, 2004). Comunicar é executar um processo no qual são trocadas informações
usando-se de algum recurso, como a fala, a escrita, os gestos, etc. Quando uma comunicação é
estabelecida, cria-se um canal por onde trafegam informações nos dois sentidos. Ou seja,
quem informa recebe informação também pelo mesmo caminho.
48
É importante ter comunicação em um projeto de software porque simplesmente a sua
falta é catastrófica. Desenvolvedores devem trocar informações entre si para resolver
problemas, propor melhorias, organizar o trabalho e também devem trocar informações com
os clientes de modo que ambos estejam de comum acordo sobre o que o software a ser
desenvolvido deve fazer.
4.1.2. Simplicidade
Simplicidade significa fazer de forma simples. A engenharia de software recomenda a
criação e manutenção de modelos, arquiteturas teóricas do funcionamento do software. Muitas
vezes, os desenvolvedores buscam desenvolver arquiteturas que predigam necessidades
futuras, ainda não citadas pelo cliente na esperança de tornar a manutenção um processo
menos “azedo”. Todavia, conforme Ambler (2004) coloca, ao tentar predizer necessidades
futuras, a probabilidade de ser uma decisão acertada é praticamente a mesma de ser uma
decisão errada. Em vista disso, desenvolver o software priorizando apenas as necessidades
expressas e necessárias da melhor forma possível é uma decisão melhor do que predizer o
futuro. Quanto à modelagem, o fato de ser simples não implica que ela é incompleta ou
inexistente. É perfeitamente possível ler um resumo de um livro e ter uma ótima idéia da obra
original, não é? É o mesmo que ocorre com os modelos. Eles existem na XP em virtude da
necessidade, e os mesmos são simplesmente simples.
4.1.3. Coragem
A coragem é o aspecto humano do desenvolvimento ágil. É necessário ter coragem
para manter-se firme na metodologia, quebrar dogmas antigos acerca do desenvolvimento. É
necessário ter coragem para acreditar nas pessoas, para admitir que as pessoas podem falhar e
que os problemas futuros serão resolvidos no futuro. A coragem é o tempero que dá sabor às
metodologias ágeis, em especial a XP.
49
4.1.4. Feedback
A única maneira de se obter a garantia de que o trabalho desenvolvido está correto é
recebendo feedback (retorno) do mesmo (AMBLER, 2004). O retorno, em um projeto de
software, pode ser a opinião de um cliente ao trabalhar com um novo release (entrega) do
software ou a opinião de um colega de equipe de desenvolvimento, por exemplo. É
importante ter retorno sobre os modelos abstratos do software, afinal eles orientam o
desenvolvimento. E a melhor maneira de obter retorno de um modelo é implementar o modelo
e fazer o cliente testá-lo.
4.2. Ciclo de Vida XP
O ciclo de vida de um projeto na Extreme Programming, segundo Ambler (2004),
pode ser definido conforme mostra a figura 10.
Figura 10: Diagrama esquemático da metodologia XP
Fonte: Ambler (2004), pg. 185
Conforme observa-se na modelo acima, o ciclo de vida de um projeto na metodologia
XP está dividido em cinco etapas (fases) distintas: exploração, planejamento, iterações para
entrega, produção e manutenção.
50
4.2.1. Fase de Exploração
A fase de exploração é a primeira fase do desenvolvimento XP. Nesta etapa são
coletadas as primeiras estórias de usuário e é definida uma base arquitetural para o sistema. É
importante ressaltar que o cliente é parte integrante da equipe XP durante todo o projeto,
sendo indispensável ao sucesso do mesmo.
As estórias de usuário desempenham um papel fundamental na metodologia XP, tal
qual a participação do cliente no projeto o é. Elas são escritas pelo cliente, usando linguagem
natural, nos termos que ele deseja utilizar. Não há qualquer restrição ou obrigatoriedade de
formalismos nas estórias de usuário. Elas são simplesmente escritas em cartões (story cards),
usando-se as ferramentas mais simples (papel e lápis).
As estórias de usuários representam os requisitos do sistema. Elas são utilizadas em
substituição a uma vasta documentação normalmente gerada pelo processo de especificação
de requisitos explicado na seção 3 (Engenharia de Requisitos). Apresentam um baixo
detalhamento, mas tem o foco voltado estritamente no que o cliente necessita.
Outras importantes utilidades que as estórias de usuário têm dentro metodologia XP
estão na estimativa de tempo do release e nos testes de aceitação, como será visto nas
próximas seções.
4.2.2. Fase de Planejamento
Nesta fase é realizado o trabalho de planejamento da versão. Juntamente com o cliente
é selecionado o menor e melhor conjunto de estórias de usuário que fará parte da versão
(AMBLER, 2004). Na filosofia XP existe o conceito de tempo ideal de desenvolvimento, que
nada mais é do que o tempo que será empregado para desenvolver uma estória de usuário se
não existirem distrações, adição de novas estórias, e, é claro, se o desenvolvedor souber
exatamente o que deve fazer. Em relação ao tempo ideal de desenvolvimento são feitas as
seguintes considerações:
a) O tempo de desenvolvimento estimado para a estória não alcança uma semana:
Deve-se combinar algumas estórias de modo a alcançar um tempo mínimo de uma
semana.
51
b) O tempo de desenvolvimento estimado para a estória excede três semanas: Deve-
se quebrar a estória em partes menores.
c) O tempo ideal de desenvolvimento de uma estória é de uma a três semanas.
Para cada estória de usuário é feito um cartão de tarefas, onde são descritas as
atividades necessárias para desenvolvê-la. A descrição pode ser feita de várias formas, desde
textualmente até utilizando-se desenhos esquemáticos, ficando a cargo do profissional a
escolha do modo de descrição.
Tendo em mãos as estórias de usuário conjuntamente com os cartões de tarefas é
possível estimar o trabalho necessário para implementá-las com maior precisão.
4.2.3. Fase de iterações para entrega
A fase de iterações para entrega é o momento, dentro de um projeto XP, em que é
despendido o maior esforço em termos de desenvolvimento (modelagem, programação, teste e
integração).
Inicialmente é feito um planejamento da iteração levando-se em conta as estórias de
usuário selecionadas para serem desenvolvidas na fase corrente. A estimativa de tempo se dá
pela divisão de cada estória de usuário em tarefas. Inicialmente, o cliente prioriza quais são as
estórias de usuário que podem ser imediatamente implementadas para fornecer suporte útil ao
negócio (SOMMERVILLE, 2007). Feito isso, segue-se com o desenvolvimento das estórias
de usuário. O desenvolvimento apresenta particularidades interessantes na filosofia XP. A
primeira delas é que grande parte da modelagem ocorre em curtas reuniões realizadas em pé
(stand-up meeting), onde os desenvolvedores trocam idéias entre si sobre o trabalho que está
sendo desenvolvido no momento (AMBLER, 2004). A stand-up meeting tem por objetivo
comunicar problemas, soluções e manter o foco da equipe no que está trabalhando
(EXTREME PROGRAMMING, 2009).
A segunda particularidade diz respeito à forma com que os programadores
desenvolvem o código. Na XP, a programação é feita aos pares (pair programming). Ou seja,
cada dupla senta-se em frente a um computador e desenvolve conjuntamente. Sommerville
(2007) aponta as seguintes vantagens da programação em par:
52
a) Apóia a ideia de propriedade e responsabilidade comuns para o software.
b) Atua como um processo informal de revisão porque cada linha de código é vista
por mais de uma pessoa.
4.2.4. Fase de produção
A fase de produção focaliza-se na garantia de que o software esteja pronto para entrar
em produção (AMBLER, 2004). São executados testes como o de sistema, de carga e
instalação. O software, portanto, deixa o ambiente de desenvolvimento e passa a operar no
ambiente real, de produção.
Segundo Ambler (2004), na fase de produção o ritmo de desenvolvimento diminui e
aspectos como documentação e correção de defeitos recebem o foco do trabalho.
Quando os testes demonstrarem a existência de algum defeito no sistema é necessário,
obviamente, realizar atividades que visem corrigi-los o mais rápido possível.
Já a documentação deve ser desenvolvida e otimizada, desde que a sua existência
justifique-se por uma necessidade e não de uma imposição burocrática. Diferentes
documentos podem ser desenvolvidos: Dentre eles, pode-se citar:
a) Documentação do Sistema: É o tipo de documentação mais importante
(AMBLER, 2004). Oferece aos desenvolvedores e profissionais responsáveis pela
manutenção uma visão geral do sistema, através de visões gerais da arquitetura
técnica e de negócios, requisitos de alto nível do sistema, resumo das decisões
importantes de projeto, diagramas e modelos. O objetivo é ser uma ferramenta que
permita o entendimento do sistema desenvolvido.
b) Documentação de Operações: Descreve dependências do sistema para com
outros, como sistemas gerenciadores de banco de dados (SGBD), por exemplo;
descrições de rotinas de backup, resumo dos requisitos de disponibilidade e
confiabilidade, perfil de carga de trabalho esperado e procedimentos de resolução de
problemas que por ventura ocorram.
c) Documentação de Suporte: Contém um conjunto de informações voltadas a quem
irá prestar suporte ao sistema.
d) Documentação de Usuário: Inclui guias de uso do software, guia de suporte e
materiais de treinamento.
53
4.2.5. Manutenção
A fase de manutenção é o estado normal dos projetos XP (AMBLER, 2004),
englobando as fases de Planejamento, Iterações para Entrega e Produção para Entrega 2 até N
do sistema. Isso se explica pelo fato de a XP utilizar uma abordagem de desenvolvimento em
iterações. Na primeira iteração, portanto, a manutenção não existe, porque o software está
“nascendo” naquele momento. A partir da segunda, parte-se de um primeiro release já
existente e prossegue-se com o seu desenvolvimento, seguindo assim sucessivamente.
4.3. Engenharia de Requisitos aplicada a Extreme Programming
A Engenharia de Requisitos se faz necessária tanto nas metodologias ágeis quanto nas
metodologias tradicionais. Certamente, a forma de emprego das técnicas de ER é adaptada a
filosofia do modelo de software aplicado. Seja ágil ou tradicional, o fato é que se faz
necessário, em um processo de desenvolvimento de software, despender esforços para a
descoberta e gerência dos requisitos do software a ser construído.
Na Extreme Programming, os requisitos são elicitados do cliente na forma de estórias
de usuário, escritas em cartões pelo próprio cliente em linguagem natural. Como o cliente é
parte integrante da equipe XP, sendo sua presença fundamental ao funcionamento da
metodologia, pode-se concluir que o processo de obtenção dos requisitos e de validação é
otimizado consideravelmente.
Beck (2004) apresenta três razões que justificam a escrita de estórias de usuário.
Segundo o autor, para o cliente, a escrita de estórias:
a) Força uma melhor análise da funcionalidade, pois no momento da escrita da
estória ele formaliza o pensamento e busca compreender melhor o assunto sobre o
qual irá tratar.
b) Cria um vínculo psicológico, ficando sob sua responsabilidade o que está sendo
escrito.
c) Ajuda a compreender que existe um custo sobre tudo aquilo que é pedido.
54
O processo de descoberta de requisitos gera um conjunto de requisitos que de alguma
forma precisa ser documentado para posterior consulta. Documentar os requisitos é outra
atividade que cabe ao processo de engenharia de requisitos, o qual visa gerar um documento
que contenha a descrição verídica do sistema a ser desenvolvido. Esta documentação pode ser
formal, utilizando-se templates predefinidos de documentos ou pode ser feita de forma mais
informal. Na Extreme Programming, o conjunto de estórias de usuário pode ser considerado
o documento de requisitos de um projeto.
Recolher os requisitos do software e documentá-los não é garantia de que eles de fato
reflitam as necessidades do cliente. Grande parte dos problemas enfrentados no
desenvolvimento de software reside na falta de qualidade dos requisitos elicitados. Em vista
disso, é fundamental a qualquer metodologia de desenvolvimento gerir os requisitos de forma
a alcançar alto grau de excelência na suas especificações. Conforme descrito na seção 2.4, é
possível avaliar a qualidade dos requisitos contidos em uma especificação de requisitos
tomando por parâmetro oito características de qualidade, a saber, correção, precisão,
completeza, consistência, priorização, verificabilidade, modificabilidade e rastreabilidade.
Sendo a Extreme Programming uma metodologia de desenvolvimento de software,
convém neste momento submetê-la a uma avaliação segundo os critérios de qualidade de
requisitos apresentados. Para cada critério, serão descritas as características da XP que o
sustentam e/ou as deficiências enfrentadas pela metodologia no atendimento ao mesmo.
Segue a análise:
a) Quanto à correção: A correção dos requisitos refere-se à qualidade do requisito
de expressar de fato a necessidade do cliente, da forma como ele imagina. Na
Extreme Programming, o cliente é parte integrante da equipe, ele próprio escreve o
que necessita e recebe constante feedback do que está sendo desenvolvido, o que
garante a correteza da especificação dos requisitos.
b) Quanto à precisão: Precisão é a característica que um requisito tem de não
apresentar ambiguidade em seu sentido. Cliente e desenvolvedor devem lê-lo e obter
o mesmo significado. Como na XP a presença do cliente se dá em todo o
desenvolvimento, requisitos ambíguos são imediatamente mais bem especificados e,
por conseguinte, é obtida precisão em sua descrição.
c) Quanto à Completeza: A completeza refere-se à propriedade de uma
especificação de requisitos de conter todos os requisitos significativos. A
completeza pressupõe que grande parte dos requisitos sejam recolhidos
previamente, o que, em teoria, contradiz o que acontece em um projeto que utiliza
desenvolvimento incremental e ágil. A XP recolhe os requisitos à medida que o
projeto evolui diferentemente de métodos tradicionais que buscam elicitar todos os
55
requisitos antes de propriamente projetar e desenvolver o software. Todavia, pode-
se afirmar que na XP existe “completeza temporal”, ou seja, a cada iteração se tem
uma especificação dos requisitos que apresenta completeza em sua definição para
aquele dado momento do desenvolvimento.
d) Quanto à Consistência: A consistência dos requisitos é a condição de inexistência
de conflitos entre os mesmos. Tais conflitos podem ser de ordem lógica ou
temporal, de definição e de características do mundo real. Novamente a XP
consegue obter consistência nos seus requisitos pelo fato de o cliente estar presente
durante o desenvolvimento. O feedback do que foi desenvolvido se dá em um
intervalo de tempo curto, o que permite que todos os conflitos possam ser corrigidos
com rapidez e sem maiores complicações ao projeto.
e) Quanto à priorização: A priorização é a atividade onde se atribui ao requisito
uma escala qualitativa ou quantitativa de prioridade. Na XP, a priorização dos
requisitos é natural. O cliente determina quais são os requisitos que são essenciais
ao seu negócio e que, em vista disso, devem ser os primeiros a serem desenvolvidos.
A cada nova versão do sistema, o cliente prioriza as estórias que devem ser
entregues e isto se repete durante todo o projeto.
f) Quanto à verificabilidade: A verificabilidade dos requisitos diz respeito à
propriedade de um requisito de ser verificável por um processo finito, viável e
eficaz. Ela é obtida na XP através da presença constante do cliente, dos casos de
teste escritos para verificar se de fato o que foi desenvolvido comporta-se conforme
o especificado e do feedback constante obtido do cliente no projeto. Desta forma, na
XP todos os requisitos são verificáveis através de um processo finito, pouco oneroso
e eficaz.
g) Quanto à modificabilidade: A modificabilidade de uma especificação de
requisitos diz respeito à maleabilidade que a mesma possui de ser modificável,
mantendo a sua consistência e completeza. A XP tem como um de seus
“mandamentos” a simplicidade, ou seja, fazer as coisas da forma mais simples. As
estórias de usuário são escritas em cartões de papel, e não existem documentos
fortemente amarrados formando uma especificação complexa, o que permite que
modificações sejam realizadas sem maiores problemas. Além disso, toda a
metodologia foi desenvolvida para trabalhar com requisitos pouco estáveis,
devendo, portanto, a modificabilidade ser uma característica inerente ao modelo.
h) Quanto à rastreabilidade: A rastreabilidade nos requisitos é a propriedade que
permite determinar a relação de dependência entre os mesmos. A rastreabilidade é
de grande valia para uma especificação de requisitos. Para obtê-la, é necessária a
utilização de ferramentas automatizadas, denominadas ferramentas CASE
(Computer-Aided Software Engineering), que serão explicadas no próximo capítulo.
Valendo-se de uma ferramenta CASE, a XP consegue alcançar a rastreabilidade nos
requisitos sem maiores problemas.
56
Com base na avaliação proposta acima, é possível extrair dois elementos fundamentais
para que a XP obtenha todos os requisitos de qualidade: cliente sempre presente e uso de uma
ferramenta CASE.
O primeiro elemento, que diz respeito ao cliente estar sempre presente, é uma das
premissas básicas da metodologia XP. Sem o cliente presente durante todo o
desenvolvimento, a XP simplesmente não funciona, não fazendo sentido utilizar a
metodologia em projetos onde este requisito não possa ser atendido. O segundo elemento, o
uso de uma ferramenta CASE, será amplamente discutido nas próximas seções deste trabalho,
onde serão descritas as características de algumas ferramentas CASE disponíveis e, a partir do
estudo das mesmas, será proposto um protótipo de ferramenta CASE com vistas a gerenciar
requisitos em projetos baseados na metodologia XP.
Observa-se que a XP é uma das metodologias mais puristas no que diz respeito a
filosofia ágil. É de grande aplicabilidade, uma vez que enfatiza a satisfação rápida do cliente
mediante entregas funcionais em um curto espaço de tempo. Dado que a necessidade pelo
desenvolvimento rápido de software é evidente no cenário atual, a XP apresenta-se como uma
ótima opção às equipes de desenvolvimento. Contudo, a sua execução requer organização e
coragem no cumprimento das atividades e dos valores por ela apregoados; é fato que a XP
não funciona num ambiente desordenado.
No que tange à Engenharia de Requisitos, a XP utiliza uma forma particular de
execução do processo que é fortemente ligado à presença do cliente. Dentre os atributos de
qualidade de requisitos citados, a avaliação da metodologia mostrou que a grande maioria tem
forte ligação com a constante participação do cliente no projeto. A rastreabilidade, por sua
vez, mostrou ser um ponto fraco da metodologia, mas que com o auxílio de uma ferramenta
CASE pode ser facilmente contornado.
57
5. TECNOLOGIA CASE
Organizar e gerir os requisitos de um software torna-se uma atividade onerosa de ser
feita com ferramentas simples, como papel e caneta, à medida que o conjunto de requisitos
obtidos cresce. Aliado a isso, a necessidade cada vez maior de otimização do tempo utilizado
na realização de qualquer atividade torna visível a necessidade de uso de ferramentas
automatizadas de apoio a estas atividades. Otimizar o uso do tempo em um processo de
software pode ser o diferencial entre o sucesso e o fracasso de um projeto. Conforme já
exposto anteriormente, dentre os motivos que levaram a idealização da Engenharia de
Software, os atrasos meteóricos nos projetos de desenvolvimento ocupavam o topo da lista.
Uma das formas de otimizar o uso do tempo e de aumentar a qualidade da gerência de
projetos de software é utilizar ferramentas (softwares) que automatizem importantes tarefas
comuns a qualquer ambiente de desenvolvimento de software. Quando uma ferramenta de
software apóia atividades de um processo de software, como engenharia de requisitos, projeto,
desenvolvimento, teste, etc. esta recebe o nome de ferramenta CASE, do inglês Computer-
Aided Software Enginneering, em português, Engenharia de Software Auxiliada por
Computador (SOMMERVILLE, 2007).
A tecnologia CASE foi concebida, portanto, com o intuito de aprimorar o processo de
desenvolvimento de software, através da automação e integração das atividades desenvolvidas
na construção de um software. Todavia, a expectativa inicial de êxito da aplicação de
ferramentas CASE foi, de certa forma, podada segundo Sommerville (2007) pelos seguintes
motivos:
a) A Engenharia de Software é uma atividade de projeto, que baseia-se na
criatividade. As ferramentas CASE automatizam atividades, mas são incapazes de
criar por si soluções;
58
b) A Engenharia de Software é uma atividade baseada em equipe, fortemente
baseada no diálogo entre os integrantes. As ferramentas CASE não teriam
aplicabilidade neste sentido.
Embora as previsões iniciais de sucesso no uso de ferramentas CASE tenham apontado
resultados acima dos realmente obtidos, o seu uso no apoio ao processo de desenvolvimento
de software mostra-se ainda extremamente benéfico. Segundo Huff apud Sommerville (2007),
os aprimoramentos com a aplicação de ferramentas CASE no processo de desenvolvimento de
software atingiram 40% nas primeiras experiências. Isso demonstrou que o uso de uma
ferramenta adequada incrementa positivamente o processo de desenvolvimento e, por
conseguinte, aumenta as chances de o produto final apresentar qualidade. Um exemplo
simples de tal efeito pode ser um trabalho de marcenaria. Basta pensar que, por exemplo, a
qualidade de uma cadeira depende fortemente das ferramentas de que o marceneiro dispõe no
momento de sua confecção e da perícia que o mesmo possui no manejo destas ferramentas.
Trazendo o exemplo do marceneiro ao desenvolvimento de software é possível criar
uma forte ligação entre os conceitos. Primeiramente, o uso de ferramentas inadequadas, ou
mesmo, o não uso de ferramentas pode comprometer o resultado final do projeto. Com
ferramentas mais apuradas é possível trabalhar melhor a madeira e, em decorrência, obter
ângulos mais suaves, cantos mais arredondados resultando em um produto final de traços
mais finos. Analogamente, o desenvolvimento de software apoiado por boas ferramentas
CASE tem maiores chances de resultar em um produto de software mais aprimorado.
Todavia, dispor de ótimas ferramentas não é indicador de que o produto final tenha
qualidade (nas dimensões de quem faz e de quem compra). É fundamental que haja
profissionais habilitados a usá-las, a explorar os seus recursos e obter resultados com ela. De
nada adianta dar uma motocicleta a quem sequer sabe andar de bicicleta! Disso é possível
deduzir que as ferramentas CASE não trabalham pelo programador, analista ou gerente de
projetos. Na verdade, elas trabalham conjuntamente com os profissionais no apoio a suas
atividades.
É importante ter em mente também, quando fala-se em ferramentas CASE, que a
melhor ferramenta é aquela que atende as necessidades de forma satisfatória e eficaz. Via de
regra julga-se a qualidade de uma ferramenta normalmente pela quantidade de recursos que
ela oferece. Todavia, nem sempre isso é determinante no dia a dia. O objetivo da ferramenta
CASE é dar auxílio e não impor mais complexidade ao processo. Por exemplo, a Extreme
59
Programming prega o uso das ferramentas mais simples no desenvolvimento de um produto
de software e que de fato auxiliem e não burocratizem o processo.
As ferramentas CASE são classificadas em grandes grupos ou classes, os quais levam
em conta a função exercida pela mesma, bem como a sua abrangência no apoio ao processo
de software. Sommerville (2007) apresenta três classes distintas de sistemas CASE, a saber:
a) Ferramentas: apóiam tarefas individuais de processo.
b) Workbenches: apóiam fases ou atividades de processo, como especificação,
projeto, etc. Consistem geralmente em um conjunto de ferramentas integradas entre
si.
c) Ambientes: Apóiam todo ou quase totalmente um processo de software. Incluem
normalmente vários workbenches integrados.
O termo ferramenta utilizado durante todo este trabalho não se refere a classificação
apresentada acima. Seu sentido é genérico, podendo ser aplicado a qualquer um dos três
grupos supra citados.
5.1. Estudo de ferramentas CASE existentes de apoio ao processo de Engenharia de
Requisitos voltado a Extreme Programming
As ferramentas de apoio ao processo de software, como já enfatizado, apresentam um
impacto positivo no mesmo. Existem inúmeras ferramentas CASE voltadas ao apoio de
praticamente todos os modelos de processo de software existentes.
Para o estudo que se segue, optou-se por utilizar os seguintes critérios para a seleção
das ferramentas CASE analisadas:
a) Critério 1: A ferramenta deve ser gratuita
Nenhuma ferramenta analisada deve apresentar qualquer custo para sua aquisição e
uso. A escolha por tal critério justifica-se pelo fato de o custo de ferramentas CASE
proprietárias ser um forte inibidor a sua utilização. Muitas empresas de software, que não
dispõem de recursos para adquirir uma ferramenta proprietária, acabam utilizando recursos
60
muitas vezes inadequados para apoiar seu processo de software, como documentos
manuscritos e quando muito editores de texto.
b) Critério 2: A ferramenta deve ser de código aberto (Open Source)
Toda a ferramenta analisada deve ter seu código-fonte disponível para análise e
modificação. As ferramentas Open Source permitem a customização de suas funcionalidades
de acordo com os critérios de quem a está utilizando. Para uma empresa, dispor de uma
ferramenta que permita alteração é extremamente útil, uma vez que a empresa adapta a
ferramenta ao seu processo, e não a empresa se adapta a ferramenta.
c) Critério 3: A ferramenta deve apresentar interface WEB.
Toda a ferramenta analisada deve apresentar interface WEB. A justificativa por este
critério está nas vantagens que a Internet oferece, em especial a portabilidade natural entre
diferentes plataformas computacionais. Com isso, os usuários da ferramenta ficam
desobrigados do uso da plataforma X ou Y para usufruírem dos recursos da ferramenta. Além
disso, a tecnologia Cloud Computing tornará a Internet a mesa de trabalho do mundo virtual
em pouco tempo.
d) Critério 4: A ferramenta deve apoiar o processo de descoberta e gerência de
requisitos do modelo XP
As metodologias ágeis apresentam-se como uma filosofia de desenvolvimento
contemporânea, que enfoca entregas funcionais em curto prazo em oposição à geração prévia
de extensa documentação. Os modelos ágeis oferecem a flexibilidade que se encaixa às
necessidades dos clientes que necessitam de projetos rápidos, entregas funcionais em curto
prazo e com qualidade.
Dentre os modelos ágeis existentes, a Extreme Programming representa de forma
impecável toda a filosofia proposta para o desenvolvimento ágil de software. Unindo
flexibilidade e engenharia de software, o modelo mostra-se extremamente funcional e com
aplicabilidade comprovada. O uso de uma ferramenta CASE com vistas a auxiliar a gerência
de requisitos, traz maior eficiência à XP no trato aos requisitos, aumentando o controle sobre
61
os mesmos, e por conseguinte tornando o processo de Engenharia de Requisitos incluso mais
eficiente.
5.1.1. Ferramentas CASE analisadas
De acordo com os critérios anteriormente apresentados, foram encontradas na grande
rede e posteriormente analisadas as ferramentas Project Planning and Tracking System
v.1.6.6, Trackit, XPWeb e BabaXP :
1 - Project Planning & Tracking System v. 1.6.6
Project Planning & Tracking System v. 1.6.6
Linguagem Utilizada: PHP
Onde obter: http://ses-ppts.sourceforge.net/
Idioma: Suporte a múltiplos idiomas
Desenvolvedor (es): Koninklijke Philips Electronics N.V.
Banco de Dados: Mysql
Licença: GNU General Public Licence
Principais características:
Administração de projeto
Controle de alocação de recursos
Controle de pessoas
Visão do andamento do projeto
Manutenção de estórias
Manutenção de tarefas relacionadas a uma estória
Manutenção de releases e iterações
Geração de relatórios gráficos
Suporte ao modelo SCRUM e XP de desenvolvimento de software
Gráfico de Gantt, Custos, Métricas
Tabela 1: Project Planning & Tracking System v. 1.6.6
Fonte: PPTS (2009)
62
2- Trackit
TRACKIT
Linguagem Utilizada: Java
Onde obter: http://trackit.sourceforge.net/
Idioma: Inglês
Desenvolvedor (es): Não encontrado
Banco de Dados: HSQLDB
Licença: GNU Lesser General Public Licence
Principais características:
Criação de relatórios customizados
Visão do andamento do projeto
Barra de status com informações acerca do projeto
Manutenção de estórias mantendo-se o histórico das mudanças
Manutenção de relacionamento entre as estórias
Gerenciamento de testes
Manutenção de bugs encontrados no projeto.
Apresenta suporte ao desenvolvimento TDD (Test Driven Development)
CVS (Concurrent Version System)
Permite customização do próprio software
Tabela 2: Trackit
Fonte:Trackit (2009)
63
3 – XPWEB
XPWEB
Linguagem Utilizada: PHP
Onde obter: http://xpweb.sourceforge.net/index.php
http://www.sigg100.com/XPWeb/Help/Planning_help.php
Idioma: Disponível em vários idiomas, dentre eles o Português
Desenvolvedor (es): Olivier Chirouze
Banco de Dados: Oferece suporte a PostgreSQL, Mysql e Access
Licença: GNU General Public Licence
Principais características:
Manutenção de Projetos
Manutenção de Iterações
Manutenção de Estórias
Manutenção de Tarefas
Visão do andamento do projeto
CVS integrado
Exportação em XML
OBS: Não foi possível testar os recursos desta ferramenta, uma vez que foram encontrados erros de
execução que impossibilitaram o seu uso.
Tabela 3: XPWEB
Fonte: XPWeb (2009)
Utilizando-se os critérios de seleção previamente definidos observou-se que o número
de ferramentas disponíveis com tais características é um tanto reduzido. O custo e a
característica de execução na web foram os dois critérios mais seletivos.
Optou-se assim por apresentar uma ferramenta que não contempla totalmente os
critérios definidos, mas que apresenta recursos interessantes que contribuem com os objetivos
deste trabalho. Convém mencionar esta ferramenta apenas não contempla o critério 3, que diz
respeito à ferramenta apresentar interface web. A seguir apresenta-se a ferramenta
mencionada.
64
4- BABAXP
BABAXP
Linguagem Utilizada: Java
Onde obter: https://babaxp.dev.java.net/
Idioma: Português
Desenvolvedor (es): Vítor Pamplona
Giovane Roslindo Kuhn
José Ronaldo Henriques Da Silva
Banco de Dados: Prevayler (Biblioteca de persistência de dados)
Licença: GNU General Public Licence
Principais características:
Manutenção de Clientes
Manutenção de Desenvolvedores
Manutenção de Estórias
Manutenção de Casos de Teste
Relatório de Produtividade dos Desenvolvedores
Manutenção de dependência entre estórias
OBS: Este software não contempla o critério 3, que diz respeito à ferramenta apresentar interface web.
Tabela 4: BABAXP
Fonte: BabaXp (2009)
5.1.2. Formalização das características desejáveis a uma ferramenta de gerência de
requisitos para XP
Com base em uma análise prévia das ferramentas acima apresentadas, elencou-se um
conjunto de cinco características, entendidas por este autor como essenciais a uma ferramenta
que se propõe a gerenciar os requisitos na metodologia XP. Tais características são,
concomitantemente, os objetivos gerais da nova ferramenta proposta no capítulo seguinte.
Segue abaixo a descrição explicativa de cada uma das características elencadas.
a) Manter cadastro de estórias com retrospectiva histórica de alterações, bugs e casos
de teste relacionados.
Cada estória representa um requisito do software que o cliente define durante o
projeto. Mantê-las registradas garante que se tenha sempre em mãos o documento de
requisitos do software, permitindo consultas rápidas e dinâmicas a qualquer instante.
65
Bem, mas as estórias são escritas em cartões de papel, certo? Não seria suficiente
guardá-las em uma caixa? A resposta é simples: guardar os cartões em uma caixa é uma
solução de fato, mas não é a mais eficaz. O papel está sujeito ao desgaste pelo tempo
enquanto que a informação em meio digital não enfrenta este problema. Além disso, o tempo
de procura e a qualidade das informações recuperadas através de um meio digital são
consideravelmente otimizados pelo uso de uma ferramenta CASE de gerência de requisitos.
Obter dados históricos então, é algo extremamente difícil de ser implementado usando apenas
papel. “Se ser ágil é bom, que sejamos ao extremo!”.
b) Gerar e manter a matriz de rastreabilidade dos requisitos
Normalmente no desenvolvimento de um software, um grande conjunto de requisitos
deve ser manipulado pelos profissionais da equipe de desenvolvimento. Tais requisitos
apresentam ligações (dependências) entre si, de modo que é muito importante saber a
implicação de uma mudança em um dado requisito sobre os demais. Na fase de manutenção,
acentua-se vertiginosamente esta necessidade, pois nesta etapa é necessário dar prioridade a
um controle mais rígido sobre os impactos. O software já está em ambiente de produção e
qualquer falha pode causar problemas sérios ao cliente. A matriz de rastreabilidade apresenta-
se como uma ferramenta muito útil à equipe de desenvolvimento, facilitando o processo de
entendimento do software, de avaliação de impactos, previsão de tempo de manutenção,
contribuindo em última instância com a garantia da qualidade do produto.
c) Proporcionar uma sólida visão do progresso do projeto à equipe
A agilidade na gerência é necessária a qualquer projeto e a qualquer gerente de
projetos. Em projetos de desenvolvimento de software, este panorama se acentua devido às
especificidades que os mesmos apresentam. É necessário que a ferramenta CASE que
gerencie os requisitos ofereça conjuntamente com uma visão técnica do desenvolvimento,
uma visão gerencial que permita ao gerente de projetos e outros responsáveis avaliar e extrair
informações que os ajude a tomar melhores decisões durante o projeto.
d) Utilizar feedback de estórias em projetos futuros
Passado, presente e futuro, embora indiquem momentos diferentes em uma
representação temporal, possuem uma forte interligação, principalmente no que tange ao
conhecimento empírico. Desta forma, o passado, ou o conhecimento do passado, muitas vezes
66
oferece suporte a decisões imediatas ou futuras. Na XP não é diferente. Quando os
desenvolvedores estimam o tempo de desenvolvimento de determinada estória, na grande
maioria das vezes utilizam-se de experiências passadas para gerar um valor. Esta busca de
informações apenas na memória dos desenvolvedores leva a resultados do tipo “cerca de ....”,
ou seja, não precisos. Tendo em mãos uma ferramenta que recupere estórias já desenvolvidas
sob determinadas regras de busca, cria-se uma base de informação mais sólida que permite ao
desenvolvedor estimar o tempo de desenvolvimento com maior precisão. Considera-se, neste
caso, que toda a estória desenvolvida contenha em si a informação do tempo gasto em seu
desenvolvimento.
e) Permitir portabilidade de dados
A exportação de dados em um padrão amplamente utilizado aumenta consideravelmente
o potencial da ferramenta, uma vez que permite que os dados sejam trabalhados de diferentes
formas e por diferentes ferramentas. Além de contribuir em funcionalidade, a exportação dos
dados dá maior liberdade à equipe, dando condições a mesma de lapidar os dados de acordo
com as suas necessidades.
Com base nas cinco características desejáveis a uma ferramenta CASE de gerência de
requisitos na filosofia XP acima descritas, elaborou-se uma tabela relacionando-as com as
ferramentas avaliadas, de modo a demonstrar o grau de atendimento de cada característica
pelas ferramentas. Para determiná-lo, foi estabelecida uma escala qualitativa composta pelos
valores plenamente (PL), parcialmente (PA) e não atende (NA), representando
respectivamente, o atendimento total, parcial ou o não atendimento da característica
considerada.
A tabela 5 apresenta a análise relacional entre as ferramentas CASE e as cinco
características elencadas como essenciais. Cada característica está sendo referenciada na
tabela através da seguinte legenda:
1 – Manter um cadastro de estórias com retrospectiva histórica de alterações, bugs e
casos de teste relacionados.
2 – Gerar e manter a matriz de rastreabilidade dos requisitos.
3 – Proporcionar sólida visão do progresso do projeto à equipe.
4 – Utilizar feedback de estórias em projetos futuros.
5 – Permitir portabilidade de dados.
67
Ferramenta/Característica 1 2 3 4 5 %PL %PA %NA
PPTS PA NA PL NA NA 20% 20% 60%
TRACKIT PL NA PL NA NA 40% 0% 60%
XPWEB PA NA PA NA PL 20% 40% 40%
BABAXP PA NA PA NA NA 0% 40% 60%
Tabela 5: Relação ferramenta X Grau de atendimento
Fonte: Primária
Fazendo uma análise sobre os dados da tabela 5 é possível observar que as
características 2 e 4 não foram contempladas por nenhuma das ferramentas analisadas e a
característica 5 foi contemplada apenas por uma das ferramentas. Já as características 1 e 3
obtiveram algum grau de atendimento por todas as ferramentas, mas isso já era esperado,
afinal são duas características fundamentais à qualquer ferramenta nos moldes das analisadas
neste trabalho.
Observa-se, portanto, que há uma deficiência por parte das ferramentas CASE
analisadas neste trabalho no atendimento às características especificadas. Talvez um dos
motivos da inexistência de algumas funcionalidades esteja no fato da Extreme Programming
não apresentar regras formais de gerência de requisitos. Não há, por exemplo, menção a
matriz de rastreabilidade no modelo. Todavia isso não significa que ela não deva existir. O
mesmo se aplica na busca por estórias já desenvolvidas para estimar o tempo de
desenvolvimento de novas estórias, que é uma atividade realizada em muitas equipes XP e
que, na maioria das vezes, não tem suporte automatizado. Em vista disso, no capítulo 6 deste
trabalho está sendo proposto um protótipo de uma ferramenta CASE, cujo foco é atender de
forma unânime todas as cinco características apresentadas. Também é objetivo do protótipo
respeitar todos os critérios definidos na seção 5.1 definidos para uma ferramenta CASE
voltada a XP.
68
6. PROJETO DO PROTÓTIPO
Este capítulo compreende a modelagem física e lógica do protótipo de ferramenta
CASE de gerenciamento de requisitos proposta. No texto que se segue, faz-se referência ao
protótipo sem qualquer designação de nome. Todavia, batizou-se este com o nome de
SimpleXP, buscando criar uma referência à simplicidade, tão necessária à metodologia.
Optou-se por utilizar a técnica de modelagem de sistemas orientada a objetos, utilizando
para tanto a linguagem UML, que é mundialmente utilizada para este fim. Para dar suporte ao
processo de modelagem em UML, foi utilizada a ferramenta gratuita JUDE Community na
sua versão 5.5b1.
Como plataforma de desenvolvimento do protótipo optou-se por utilizar a IDE Eclipse,
na sua versão 3.4.2. A escolha pelo Eclipse fundamentou-se na grande quantidade de recursos
que a IDE apresenta, pela sua versatilidade (no que tange à instalação de plugins) e pelo fato
de ser software livre. Desta forma, o Eclipse mostrou-se como a melhor plataforma de
desenvolvimento para o protótipo proposto.
Toda a codificação do protótipo foi feita utilizando-se a linguagem de programação
PHP, versão 5.2.8. O PHP é uma linguagem muito poderosa para o desenvolvimento de
aplicações Web. Oferece recursos aprimorados de orientação a objetos, os quais se mostraram
de extrema valia para a implementação do protótipo da ferramenta. Da mesma forma que a
IDE Eclipse, o PHP é oriundo de um projeto de software livre, o que também contribuiu para
a sua escolha.
Para a base de dados, foi escolhido o SGBD Mysql, versão 5.1.3. Já para criação e
documentação do esquema lógico e físico da base de dados, foi empregado o software Mysql
Workbench 5.1.18. Ambos os softwares também são de uso livre.
69
Em nível de projeto, toda a modelagem do protótipo apresentada a seguir visa atingir as
cinco características elencadas na seção 5.1.2 deste trabalho. Estas características, portanto,
constituem os objetivos gerais do protótipo. Espera-se que, ao alcançar os objetivos gerais,
seja possível atingir todos os itens necessários à qualidade dos requisitos, previamente
explicados na seção 2.4, referentes à correção, completeza, precisão, consistência, priorização,
verificabilidade, modificabilidade e rastreabilidade dos requisitos. Estes, portanto, constituem
os objetivos específicos do protótipo proposto.
A especificação do protótipo se dará da seguinte forma:
a) Especificação de cada caso de uso
b) Esboço do diagrama de casos de uso do protótipo
c) Esboço do diagrama de classes
6.1. Casos de uso do protótipo
Os casos de uso do protótipo referem-se à visão superficial das funcionalidades que um
sistema fornece e as interações entre tais funcionalidades com os atores do sistema, abstraindo
qualquer detalhe de implementação. Segundo Lima (2005), um caso de uso pode ser definido
ainda como “sentenças escritas em passos de ação simples, em que um ator alcança um
resultado ou transmite informação ao sistema”.
É muito importante definir antes de qualquer caso de uso, quais são os atores do
sistema. Um ator representa qualquer entidade externa ao sistema, mas que interage com ele.
Atores podem representar papéis executados por pessoas, máquinas ou outros sistemas. Para o
protótipo proposto, os atores envolvidos representam papéis comuns dentro de uma equipe
XP. No uso da ferramenta, os atores envolvidos representam os papéis de desenvolvedor,
cliente, redator técnico e gerente de projetos. A seguir, na tabela 6 são especificados os atores
do protótipo e uma breve descrição de suas funções, com base em Rabello (2006).
70
Ator Funções exercidas
Cliente O cliente é a pessoa que orienta o trabalho da equipe. É ele quem tem
conhecimento sobre o negócio a ser modelado pelo software e, por conseguinte
representa a maior fonte de informações dentro do projeto. Em simples palavras, o
cliente diz o que o desenvolvedor deve projetar e implementar.
Desenvolvedor Os desenvolvedores analisam, projetam e implementam o software. O cliente diz O
QUE deve ser feito, o desenvolvedor FAZ.
Gerente de Projetos Administra o projeto e a comunicação com o cliente e fornece informações
essenciais ao projeto
Redator Técnico Auxilia a equipe na tarefa de documentação do software
Analista de Testes Auxilia o cliente a escrever casos de teste para o software. Seu objetivo é buscar
defeitos no software e fornecer feedback a equipe de desenvolvimento sobre seus
resultados.
Tabela 6: Atores do protótipo
Fonte: Adaptação de Rabello (2006)
Uma vez definidos os atores, já é possível definir o sistema em termos de casos de uso.
Os documentos gerados na modelagem de casos de uso são dois: o diagrama de casos de uso e
a documentação expandida.
No diagrama de casos de uso, apresenta-se de forma gráfica a interação existente entre
os elementos que compõem ou atuam sobre o sistema. A documentação expandida
complementa a visão do sistema apresentada pelo diagrama de casos de uso, adicionando
aspectos que não podem ser demonstrados através dos estereótipos da UML. Desta forma a
documentação dos casos de uso tem por objetivo retratar as reais tarefas que compõem
determinada atividade (MEDEIROS, 2004), além de, é claro, salvaguardar informações
importantes para consulta futura.
Para realizar a documentação expandida dos casos de uso não há um consenso quanto a
um padrão a ser seguido. Existem apenas estruturas que alguns autores apresentam como
sugestão para realizar tal tarefa. Além da forma, o nível de abstração também não é definido.
Isso significa que a documentação expandida pode tanto descrever os casos de uso
aproximando-se da visão técnica do sistema ou descrevê-los ignorando totalmente a
implementação. Um terceiro caso compreende uma mescla dos dois anteriores, onde o nível
de abstração é intermediário. Neste caso, aspectos de implementação misturam-se a
descrições mais superficiais das tarefas.
71
Optou-se por descrever os casos de uso do protótipo proposto utilizando-se um esquema
tabular de descrição, que tem por principal objetivo traçar um paralelo entre as ações do ator e
as respostas do sistema. Quanto ao nível de abstração, convencionou-se usar um nível
mediano, mesclando-se em certas situações aspectos menos abstratos que aproximam-se da
implementação propriamente dita do protótipo.
O diagrama de casos de uso do protótipo está dividido em duas visões distintas: a visão
técnica e a visão gerencial. O motivo da existência de tais visões é organizar e facilitar a
compreensão global do protótipo. Não caberia misturar os casos de uso das duas visões, uma
vez que estão em níveis de detalhamento diferentes, apresentando cada qual atores distintos e
objetivos distintos.
Na visão técnica concentram-se os casos de uso referentes aos aspectos de
desenvolvimento como manutenção de estórias, releases, iterações, geração de matriz de
rastreabilidade, etc. Na visão técnica atuam mais intensamente os atores redator técnico,
desenvolvedor e cliente. Engloba-se, portanto, os procedimentos ditos operacionais, que
compõem a rotina da metodologia XP.
A visão gerencial apresenta os casos de uso que dão suporte a decisões estratégicas
durante e posteriormente ao desenvolvimento do projeto. O gerente de projetos é o ator que
atua mais fortemente nesta visão extraindo informações estatísticas acerca do projeto
considerado. Também é de competência do gerente de projetos manter o cadastro de usuários,
equipes e de projetos.
A seguir segue a documentação expandida da visão técnica e da visão gerencial dos
casos de uso do protótipo.
6.1.1. Casos de uso da visão técnica
Conforme mencionado, os casos de uso da visão técnica compreendem o mapeamento
das rotinas operacionais do protótipo. Praticamente todas as manutenções de dados são
tratadas nesta visão, merecendo especial consideração a de estórias (Tabela 7), por ser esta a
mais importante. Relacionados à manutenção de estórias encontram-se anexados os casos de
uso referentes à manutenção de tarefas de uma estória (Tabela 8), de bugs (Tabela 9), de
versões da estória (Tabela 10) e de casos de teste (Tabela 13).
72
A visão técnica também contempla os casos de uso de manutenção de releases de um
projeto (Tabela 16), de iterações de um release (Tabela 14), de exportação de dados, de
geração da matriz de rastreabilidade dos requisitos (Tabela 15) e da recuperação de projetos,
releases e iterações cadastradas (Tabelas 18,19 e 20, respectivamente).
A recuperação de estórias semelhantes (Tabela 12) merece especial destaque. O seu
objetivo é fornecer informações que auxiliem os desenvolvedores a estabelecer, de forma
mais precisa, o tempo de desenvolvimento de uma estória. A técnica é simples: cada estória
contém um conjunto de tags (palavras chaves), que funcionam como chaves de busca e
determinam o grau de similaridade das estórias. Somente estórias que possuam tempo de
desenvolvimento realmente obtido (aquele contabilizado após o desenvolvimento) são
retornadas na execução deste caso de uso, fornecendo assim uma base fidedigna de decisão.
UC 001 Manter estórias
Atores Principal(is) Secundário(s)
Desenvolvedor Redator Técnico
Resumo Este caso de uso tem por objetivo manter os dados referentes às estórias de usuário
Pré-Condições Desenvolvedor acessar o menu “Estórias”
Pós-Condições Uma nova estória é cadastrada na base de dados ou uma estória existente é alterada ou
excluída
Fluxo Principal
Ação do Ator Resposta do Sistema
Desenvolvedor acessa o menu “Estórias”
Desenvolvedor executa uma operação de edição,
inclusão ou exclusão. Quando a operação for de inserção
de uma nova estória, o desenvolvedor informa o cliente,
descrição, duração estimada, tempo gasto no
desenvolvimento, prioridade, volatilidade, tags, estórias
relacionadas e anexa algum documento, se necessário.
Sistema lista as estórias já cadastradas (se houver).
Sistema valida operação. Se for inválida, retorna mensagem de
erro.
Validações/Restrições
Sistema não permite excluir uma estória já atribuída a algum release.
Sistema não permite alteração de estórias de projetos já finalizados.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 7: UC Manter estórias
73
UC 002 Manter tarefas
Atores Principal(is) Secundário(s)
Desenvolvedor Redator Técnico
Resumo Este caso de uso tem por objetivo manter os dados referentes à tarefas de uma estória.
Pré-Condições Desenvolvedor acessa o menu “Estórias” do sistema e posteriormente acessa a opção
“Tarefas”
Pós-Condições Uma nova tarefa é cadastrada, ou uma tarefa existente é alterada ou excluída
Fluxo Principal
Ação do Ator Resposta do Sistema
Desenvolvedor acessa o menu “Estórias” do sistema.
Desenvolvedor seleciona uma estória dentre as listadas
para atribuir uma ou mais tarefas.
Desenvolvedor executa uma operação de inserção,
edição ou exclusão. Quando a operação for de inserção, o
desenvolvedor informa uma descrição, estimativa de
tempo de realização da tarefa, data de início e data de
término.
Sistema lista as estórias já cadastradas.
Sistema lista as tarefas já cadastradas à tarefa.
Sistema valida a operação. Se inválida, retorna uma mensagem
de erro.
Validações/Restrições
Sistema não permite alteração, exclusão ou inclusão de tarefas pertencentes a estórias
de projetos já finalizados.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 8: UC Manter Tarefas
UC 003 Manter bugs
Atores
Principal(is) Secundário(s)
Desenvolvedor Redator técnico
Analista de testes
Cliente
Resumo Este caso de uso tem por objetivo manter os dados referentes a bugs encontrados
durante um projeto.
Pré-Condições Existência de um projeto cadastrado.
Pós-Condições Novo bug é cadastrado, ou um bug existente é alterado ou excluído.
Fluxo Principal
Ação do Ator Resposta do Sistema
Desenvolvedor acessa o menu “Bugs”.
Sistema lista os bugs cadastrados para o projeto.
74
Desenvolver executa uma operação de inserção, edição
ou exclusão. Quando a operação for de inserção, o
desenvolvedor informa a descrição, a gravidade, o
release e a iteração quando o bug foi encontrado. Se
necessário, o desenvolvedor pode também informar quais
foram as estórias envolvidas no problema (UC Buscar
estória)
Sistema valida a operação. Se inválida, retorna uma mensagem
de erro para o usuário.
Validações/Restrições Sistema não permite alteração ou exclusão de bugs de projetos já finalizados.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 9: UC Manter bugs
UC 004 Manter Versões
Atores Principal(is) Secundário(s)
Desenvolvedor Redator técnico
Resumo Este caso de uso tem por objetivo manter os dados referentes a uma nova versão de
uma estória de usuário
Pré-Condições Uma estória de usuário deve existir na base de dados e ser selecionada
Pós-Condições Nova versão da estória é criada
Fluxo Principal
Ação do Ator Resposta do Sistema
Desenvolvedor acessa o menu “Estórias”.
Desenvolvedor seleciona uma estória dentre as listadas,
para a qual deseja criar uma nova versão.
Desenvolvedor executa uma operação de inclusão. Para a
operação de inclusão, o desenvolvedor informa os dados
referentes a nova versão da estória ( ver UC Manter
estórias)
Sistema lista todas as estórias cadastradas.
Sistema lista as versões anteriores cadastradas para a estória
selecionada.
Sistema valida a operação. Se inválida, retorna uma mensagem
de erro para o usuário.
Validações/Restrições Sistema não permite alteração ou exclusão de versões de uma estória.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 10: UC Manter Versões
75
UC 005 Estimar tempo de desenvolvimento para uma estória
Atores Principal(is) Secundário(s)
Desenvolvedor Redator técnico
Resumo Este caso de uso tem por objetivo atribuir uma estimativa de tempo para uma estória.
Pré-Condições A estória de usuário deve existir na base de dados.
Pós-Condições Estória recebe uma estimativa de tempo.
Fluxo Principal
Ação do Ator Resposta do Sistema
Equipe estima tempo de desenvolvimento para as
estórias da nova iteração.
Desenvolvedor informa o número de horas estimadas
para o desenvolvimento da estória.
Sistema persiste a informação
Fluxo Alternativo I
Ação do Ator Resposta do Sistema
Equipe estima tempo de desenvolvimento para as
estórias da nova iteração.
Desenvolvedor procura por estórias semelhantes (UC
Buscar estórias semelhantes) de outros projetos.
Desenvolvedor informa o número de horas estimadas
para o desenvolvimento da estória.
Sistema persiste a informação.
Validações/Restrições
Sistema não permite alteração de estimativa de tempo de estórias pertencentes a
projetos já finalizados.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema não permite números negativos como estimativa de tempo.
Tabela 11: UC Estimar tempo de desenvolvimento para uma estória
UC 006 Buscar estórias semelhantes
Atores Principal(is) Secundário(s)
Desenvolvedor Redator técnico
Resumo
Este caso de uso tem por objetivo auxiliar o ator na previsão de tempo de
desenvolvimento da estória, utilizando uma técnica de busca de estórias por palavras
chaves, de modo a oferecer aporte de informação para uma previsão mais próxima da
ideal.
Pré-Condições Um conjunto de palavras chaves (tags) deve ser informado.
Pós-Condições Listagem de estórias
Fluxo Principal
76
Ação do Ator Resposta do Sistema
Desenvolvedor informa um conjunto de palavras de
busca.
Desenvolvedor define um critério de busca (parcial ou
total). No critério de parcialidade, o desenvolvedor
deseja buscar estórias que contenham uma ou mais das
tags informadas. Já no de totalidade, o desenvolvedor
deseja receber apenas as estórias que possuem todas as
tags informadas.
Sistema processa a base de estórias e retorna uma listagem de
todas as estórias que se encaixam no critério de busca definido.
Sistema apresenta a média aritmética do tempo de
desenvolvimento estimado e do tempo de desenvolvimento
realmente gasto.
Validações/Restrições
Sistema lista apenas estórias já implementadas, ou seja, que possuem um tempo de
desenvolvimento realmente obtido informado.
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 12: UC Buscar estórias semelhantes
77
UC 007 Manter casos de teste
Atores
Principal(is) Secundário(s)
Analista de testes Redator técnico
Cliente
Desenvolvedor
Resumo Este caso de teste tem por objetivo manter os dados referentes aos casos de testes
definidos para uma estória.
Pré-Condições Uma estória deve ter sido previamente selecionada.
Pós-Condições Um novo caso de teste é criado ou um caso de teste existente é alterado ou excluído.
Fluxo Principal
Ação do Ator Resposta do Sistema
Analista de testes define junto ao cliente os casos de
teste.
Analista de teste realiza uma operação de inserção,
edição ou exclusão de um caso de teste. Para a operação
de inserção, o analista de testes informa a sequência de
passos textualmente do teste, o status (realizado ou não),
o resultado do teste e, se necessário, anexa um
documento.
Sistema valida a operação. Se inválida, retorna uma mensagem
de erro ao usuário.
Validações/Restrições
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema não permite incluir, atualizar ou excluir casos de teste de estórias de projetos já
finalizados.
Tabela 13: UC Manter casos de teste
UC 008 Manter iterações
Atores Principal(is) Secundário(s)
Redator técnico
Resumo Este caso de uso tem por objetivo manter os dados referentes às iterações de um
projeto.
Pré-Condições Deve existir um projeto e ao menos um release cadastrado na base de dados.
Pós-Condições Uma nova iteração é cadastrada ou uma iteração existente é alterada ou excluída.
Fluxo Principal
Ação do Ator Resposta do Sistema
Redator acessa o menu “Iterações”.
Redator executa uma operação de inserção, edição ou
alteração. Quando a operação for de inserção, o redator
informa uma data de início, data de término e um
78
comentário.
Sistema valida a operação. Se inválida, retorna uma mensagem
de erro ao usuário.
Validações/Restrições
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema não permite excluir iterações que possuam estórias atribuídas.
Sistema não permite incluir, atualizar ou excluir iterações de projetos já finalizados.
Tabela 14: UC Manter iterações
UC 009 Gerar matriz de rastreabilidade dos requisitos
Atores Principal(is) Secundário(s)
Desenvolvedor Redator técnico
Resumo Este caso de uso tem por objetivo gerar uma matriz de rastreabilidade dos requisitos, de
modo a demonstrar as inter-relações entre as estórias de usuário.
Pré-Condições Deve existir um projeto cadastrado.
Pós-Condições Sistema apresenta a matriz de rastreabilidade dos requisitos na tela.
Fluxo Principal
Ação do Ator Resposta do Sistema
Desenvolvedor escolhe um projeto dentre os cadastrados.
Por padrão, o projeto default está selecionado.
Sistema gera a matriz de rastreabilidade dos requisitos do projeto
(estórias de usuário), apresentando o tipo de relação de
dependência existente entre cada uma das estórias do projeto.
Validações/Restrições
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema gera matriz de rastreabilidade apenas dos projetos para o qual o desenvolvedor
faça parte da equipe.
Observações
A matriz gerada apresenta-se como uma tabela, onde as n estórias cadastradas para o
projeto devidamente ligadas a uma iteração são dispostas na vertical e na horizontal, de
modo a formar o cabeçalho das linhas e colunas. No caso de existência de uma
dependência entre duas estórias, a região da tabela que representa a interseção da linha
da estória principal com a estória dependente é realçada, usando-se para tanto uma cor
diferenciada para cada escala de dependência, a qual configura-se como baixa, média e
alta.
Nesta região de interseção são apresentadas importantes informações acerca das
estórias, como grau de volatilidade, prioridade, release e iteração de ambas as estórias
relacionadas.
Desta forma, cria-se um esquema de rastreabilidade para frente, a partir do qual é
possível determinar os impactos da alteração de determinada estória sobre as demais.
Tabela 15: UC Gerar matriz de rastreabilidade dos requisitos
79
UC 010 Manter releases
Atores Principal(is) Secundário(s)
Redator técnico
Resumo Este caso de uso tem por objetivo manter os dados referentes aos releases de um
determinado projeto.
Pré-Condições Deve existir um projeto cadastrado na base de dados.
Pós-Condições Um novo release é cadastrado ou um release existente é alterado ou excluído.
Fluxo Principal
Ação do Ator Resposta do Sistema
Redator acessa o menu “Releases”.
Redator executa uma operação de inclusão, alteração ou
edição. Quando a operação for de inserção, o redator
informa a data de início, a duração em horas, a data de
término.
Sistema lista todos os releases cadastrados para o projeto.
Sistema valida a operação. Se inválida, retorna um mensagem de
erro.
Fluxo Alternativo I
Ação do Ator Resposta do Sistema
Redator acessa o menu “Releases”.
Redator executa uma operação de inclusão, alteração ou
edição. Quando a operação for de inserção, o redator
informa a data de início, a duração em horas, a data de
término.
Redator mantém iterações para o release corrente. (UC
Manter iterações.)
Sistema lista todos os releases cadastrados para o projeto.
Sistema valida a operação. Se inválida, retorna um mensagem de
erro.
Validações/Restrições
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema não permite excluir releases que possuam iterações atribuídas.
Sistema não permite incluir, atualizar ou excluir releases de projetos já finalizados.
Observações
O sistema lista automaticamente todos os releases de um projeto configurado como
default no protótipo. A partir da seleção do projeto default, todas as funcionalidades do
protótipo passam a representar os dados referentes a este projeto.
O projeto default pode ser alterado em qualquer momento da execução.
Apenas são listados os projetos, na caixa de seleção de projetos default, cujo usuário
integra a equipe para o mesmo.
Tabela 16: UC Manter releases
80
UC 011 Exportar projeto em XML
Atores Principal(is) Secundário(s)
Redator técnico Gerente de projetos
Resumo Este caso de uso tem por objetivo exportar todos os dados referentes a um determinado
projeto em um arquivo XML, para fins de portabilidade de dados.
Pré-Condições Deve existir um projeto cadastrado na base de dados.
Pós-Condições Um arquivo XML contendo todos os dados do projeto é criado.
Fluxo Principal
Ação do Ator Resposta do Sistema
Redator acessa o menu Exportação.
Redator informa os dados referentes às opções de
exportação como caminho do arquivo de destino.
Sistema lista as opções de exportação.
Sistema executa a operação
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 17: UC Exportar projeto em XML
UC 012 Buscar projeto
Atores
Principal(is) Secundário(s)
Gerente de projetos
Redator técnico
Resumo Este caso de uso tem por objetivo selecionar, dentre os projetos cadastrados, um que é
o intencionado pelo ator.
Pré-Condições Deve existir pelo menos um projeto cadastrado na base.
Pós-Condições O projeto selecionado é retornado.
Fluxo Principal
Ação do Ator Resposta do Sistema
Ator seleciona um projeto dentre os listados
Sistema lista os projetos cadastrados.
Sistema “retorna” o projeto selecionado.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 18: UC Buscar projeto
81
UC 013 Buscar release
Atores Principal(is) Secundário(s)
Gerente de projetos
Resumo Este caso de uso tem por objetivo listar todos os releases existentes em um dado projeto
de modo a permitir a escolha de um release dentre todos.
Pré-Condições Deve existir um projeto cadastrado na base de dados e ao menos um release para o
projeto.
Pós-Condições Sistema retorna o release selecionado.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos escolhe um projeto dentre os
listados.
Gerente de projetos escolhe o release desejado.
Sistema lista os projetos cadastrados.
Sistema lista os releases para o projeto selecionado
Sistema “retorna” o release desejado.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 19: UC Buscar release
UC 014 Buscar iteração
Atores Principal(is) Secundário(s)
Gerente de Projetos
Resumo Este caso de uso tem por objetivo selecionar, dentre as iterações cadastradas, uma que é
a intencionada pelo ator.
Pré-Condições Deve existir um projeto cadastrado com, no mínimo, um release atribuído ao mesmo.
Pós-Condições O sistema retorna a iteração selecionada.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos executa caso de uso UC Buscar
release.
Gerente de projetos seleciona um release dentre os
cadastrados.
Sistema lista as iterações do release selecionado.
Sistema retorna a iteração selecionada.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 20: UC Buscar iteração
82
6.1.2. Casos de uso da visão gerencial
Os casos de uso da visão gerencial têm a função de fornecer ao ator informações que
sustentem decisões de projeto. Aspectos de tempo de desenvolvimento e número de bugs, na
perspectiva de uma estória, iteração, release ou projeto, são tratados nesta visão. Algumas
manutenções de dados também são realizadas, como por exemplo, a de equipes, projetos e de
usuários. A participação do ator gerente de projetos é intensa nesta visão.
As tabelas 21, 22, 23, 24, 25 e 26 descrevem os casos de uso da visão gerencial do
protótipo.
UC 015 Recuperar o número de bugs encontrados por iteração
Atores Principal(is) Secundário(s)
Gerente de projetos
Resumo
Este caso de uso tem por objetivo manter informado o gerente de projetos acerca do
número de bugs encontrados em uma determinada iteração de um projeto de
desenvolvimento de software.
Pré-Condições Gerente de projetos acessa o menu “Estatísticas”.
Pós-Condições Listagem de bugs encontrados.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Estatísticas”
.
Gerente de projetos seleciona uma iteração
Gerente de projetos acessa a opção “Bugs”
Sistema executa caso de uso UC Buscar Iteração.
Sistema apresenta o conjunto de opções referentes à iteração.
Sistema gera uma listagem dos bugs encontrados, quantificando o
número total encontrado na iteração, com opção de visualizar
características específicas de cada bug listado.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Deve existir ao menos uma iteração cadastrada na base de dados.
Casos de uso
relacionados
16 - Recuperar o percentual de estórias com mais de uma versão na iteração.
17 - Recuperar as estórias implementadas durante uma iteração.
18 - Recuperar o tempo de desenvolvimento consumido em uma iteração.
Tabela 21: UC Recuperar o número de bugs encontrados por iteração e estórias relacionadas
83
UC 019 Recuperar o número de bugs encontrados por release
Atores Principal(is) Secundário(s)
Gerente de projetos
Resumo
Este caso de uso tem por objetivo manter informado o gerente de projetos acerca do
número de bugs encontrados durante release de um projeto de desenvolvimento de
software.
Pré-Condições Gerente de projetos acessa o menu “Estatísticas”
Pós-Condições Listagem de bugs encontrados.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Estatísticas”
.
Gerente de projetos seleciona um release
Gerente de projetos acessa a opção “Bugs”
Sistema executa caso de uso UC Buscar Release.
Sistema apresenta o conjunto de opções referentes ao release.
Sistema gera uma listagem dos bugs encontrados, quantificando o
número total encontrado no release, com opção de visualizar
características específicas de cada bug listado.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Deve existir ao menos um release cadastrado na base de dados.
Casos de uso
relacionados
20 - Recuperar o tempo de desenvolvimento consumido por um release.
21 - Recuperar as estórias implementadas durante um release.
22 - Recuperar o percentual de estórias com mais de uma versão no release.
Tabela 22: UC Recuperar o número de bugs encontrados por release
UC 023 Recuperar o número de bugs encontrados por projeto
Atores Principal(is) Secundário(s)
Gerente de projetos
Resumo Este caso de uso tem por objetivo manter informado o gerente de projetos acerca do
número de bugs encontrados em um projeto de desenvolvimento de software.
Pré-Condições Gerente de projetos acessa o menu “Estatísticas”.
Pós-Condições Listagem de bugs encontrados.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Estatísticas”
.
Gerente de projetos seleciona um projeto.
Gerente de projetos acessa a opção “Bugs”
Sistema executa caso de uso UC Buscar projeto.
Sistema apresenta o conjunto de opções referentes ao projeto.
84
Sistema gera uma listagem dos bugs encontrados, quantificando o
número total encontrado no projeto, com opção de visualizar
características específicas de cada bug listado.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Deve existir ao menos um projeto cadastrado na base de dados.
Casos de uso
relacionados
24 - Recuperar o tempo de desenvolvimento consumido por um projeto.
25 - Recuperar as estórias implementadas durante um projeto.
26 - Recuperar o percentual de estórias com mais de uma versão no projeto.
Tabela 23: UC Recuperar o número de bugs encontrados por projeto
UC 027 Manter projetos
Atores Principal(is) Secundário(s)
Gerente de projetos
Resumo Este caso de uso tem por objetivo manter dados referentes a um projeto de
desenvolvimento de software.
Pré-Condições Gerente de projetos acessa o menu “Projeto”.
Pós-Condições Um novo projeto é cadastrado, ou um projeto existente é alterado ou excluído.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Projeto”.
Gerente de projetos pode executar uma operação de
inserção, exclusão ou alteração. Para um novo projeto, o
gerente de projetos informa o titulo, a empresa para a
qual o projeto está sendo desenvolvido e uma descrição
sobre o mesmo.
Sistema lista todos os projetos existentes.
Sistema valida a operação. Se inválida, retorna mensagem de
erro. Caso contrário persiste a operação.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 24: UC Manter projetos
UC 028 Manter Usuários
Atores Principal(is) Secundário(s)
Gerente de Projetos
Resumo Este caso de uso visa manter dados referentes a usuários do sistema e clientes de
projetos.
Pré-Condições Gerente de projetos acessa o menu “Usuários”
Pós-Condições Um novo usuário é cadastrado ou o registro de um usuário existente é alterado ou
excluído.
85
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Usuários” do
sistema.
Gerente de projetos pode executar uma operação de
exclusão, inclusão ou alteração. Quando a operação for
de inserção, o gerente de projetos irá informar o login, o
nome, a senha e o e-mail do novo usuário.
Sistema lista todos os usuários cadastrados no sistema.
Sistema valida a operação. Se for válida, persiste a operação,
caso contrário retorna uma mensagem de erro.
Validações/Restrições
Sistema não permite acesso a usuários sem validação prévia de login/senha.
Sistema não permite exclusão de usuários, quando estes estiverem ligados a algum
projeto existente.
Tabela 25: UC Manter usuários
UC 029 Manter equipe
Atores Principal(is) Secundário(s)
Gerente de Projetos
Resumo Este caso de uso tem por objetivo montar equipes de desenvolvimento para um projeto.
Pré-Condições Gerente de projetos acessa o menu “Equipes”.
Pós-Condições Uma nova equipe é criada ou uma equipe existente é modificada.
Fluxo Principal
Ação do Ator Resposta do Sistema
Gerente de projetos acessa o menu “Equipes” do sistema
Gerente de projetos pode executar uma operação de
inserção, exclusão ou alteração. Quando a operação for
de inserção, o gerente de projetos informa qual é o
projeto, o nome da equipe e os integrantes com seus
respectivos papéis (gerente de projetos, redator técnico,
cliente, analista de testes ou desenvolvedor).
Sistema lista as equipes já cadastradas.
Sistema valida a operação. Se for válida, persiste a operação,
caso contrário retorna uma mensagem de erro.
Validações/Restrições Sistema não permite acesso a usuários sem validação prévia de login/senha.
Tabela 26: UC Manter equipe
A fim de melhorar a compreensão acerca das relações existentes entre os casos de uso e
as interação existentes entre os mesmos com os atores do protótipo, as figuras 11 e 12
apresentam o diagrama de casos de uso das duas visões (técnica e gerencial) citadas.
86
Figura 11: Diagrama de casos de uso da visão técnica
Fonte: Primária
87
Figura 12: Diagrama de casos de uso da visão gerencial
Fonte: Primária
88
6.2. Diagrama de Classes do Protótipo
O projeto do protótipo foi idealizado baseando-se na técnica de orientação a objetos.
Desta forma, as unidades funcionais e lógicas do software foram definidas através de classes,
de modo que as funcionalidades são executadas através da troca de mensagens entre os
diversos objetos que compõem o software no momento de sua execução.
Segundo Sommerville (2007), um objeto define-se como sendo:
“[..] uma entidade que possui um estado e um conjunto definido de operações
definidas para funcionar neste estado. O estado é representado como um conjunto
de atributos de objeto. As operações associadas ao objeto fornecem serviços a
outros objetos (clientes) que solicitam esses serviços quando alguma computação é
necessária”.
Todo o objeto é uma instância de uma classe. A classe define quais são os atributos e
quais são os métodos que o objeto possui. Desta forma, pode-se entender a classe como uma
fôrma que serve de modelo a criação de novos objetos. Ela contém em si toda a especificação
da unidade do universo real mapeado.
Uma das grandes vantagens em se desenvolver um software orientado a objetos é criar
estruturas suficientemente genéricas e consistentes com objetos do mundo real. Isso torna o
código produzido mais sucinto, compreensível, manutenível e reusável. A adoção de design
patterns é uma estratégia de projeto que vai ao encontro de tais objetivos, uma vez que
enfatiza a adoção de padrões durante o desenvolvimento que levam ao reuso de software e a
aplicação de melhores práticas, com eficácia já comprovada (SOMMERVILLE, 2007).
Em vista disso, a estrutura de objetos referentes à persistência de dados do protótipo
utiliza dois patterns definidos pela Sun MicroSystems®, um denominado Data Access Object
(DAO) e outro denominado Data Transactional Object (SUN MICROSYSTEMS, 2009), que
embora tenham sido idealizados para programação com linguagem Java mostram-se
totalmente aplicáveis a linguagem PHP (linguagem escolhida para o desenvolvimento do
protótipo).
O pattern DAO objetiva criar um conjunto de classes que forneçam uma interface
comum de persistência, escondendo qualquer detalhe desta aos objetos que acessam seus
89
métodos. Isso permite que a aplicação seja facilmente portada entre mecanismos de
persistência de dados distintos, sem maiores implicações ao restante do código.
O diagrama de classes DAO do protótipo tem como estrutura central a interface
DAO_Class. Toda a classe DAO criada deve implementar esta interface, obrigatoriamente,
além dos métodos particulares que lhe compete. É importante ressaltar que todos os métodos
de todas as classes DAO devem ser estáticos, podendo estes serem invocados através da
própria classe, sem necessidade de instanciação de um objeto para tanto.
A interface DAO_Class define quatro métodos estáticos fundamentais, que são:
a) list: retorna um vetor de objetos da tabela do banco de dados mapeada pela classe
que o implementa.
b) add (obj): insere o objeto recebido por parâmetro na tabela do banco de dados
mapeada pela classe que o implementa.
c) remove (obj): exclui o objeto recebido por parâmetro da tabela do banco de dados
mapeada pela classe que o implementa.
d) edit (obj): atualiza o objeto recebido por parâmetro da tabela do banco de dados
mapeada pela classe que o implementa.
A figura 13 apresenta o diagrama de classes DAO do protótipo.
90
Figura 13: Diagrama de Classes DAO
Fonte: Primária
Os objetos retornados ou recebidos por parâmetro pelas classes DAO são objetos
denominados Data Transactional Objects (DTO). Um objeto DTO encapsula uma unidade de
dado do negócio, isto é, mapeia os atributos de uma tabela de modo que sua instância
represente uma tupla da mesma. O seu uso se dá na transferência dos dados entre a camada de
dados e a interface com o usuário. Quando recupera-se informações da base, através de
método list de uma classe DAO, é retornado um conjunto de objetos DTO. Da mesma forma,
quando um conjunto de dados parte da interface do usuário para a base de dados, são os
objetos DTO que fazem o transporte das informações entre as camadas.
A figura 14 apresenta o diagrama das classes DTO definidas para o protótipo da
ferramenta.
91
Figura 14: Diagrama de classes DTO
Fonte: Primária
O diagrama acima não apresenta os métodos referentes a cada classe. A explicação para
isto é que dois tipos de métodos se repetem em todas as classes: os setters e os getters. Os
métodos setters recebem como parâmetro um valor que é atribuído a um atributo da classe por
ele tratado. Por exemplo, o método de assinatura void setId(long id) atribui o valor do
parâmetro id ao atributo id de um objeto da classe Projeto. Já os métodos getters têm a função
de retornar o valor que um determinado atributo contém. Como exemplo, pode-se definir um
método de assinatura string getTitulo() para a classe Estoria, o qual retornaria em sua
chamada o valor contido no atributo título de um objeto desta classe.
Os diagramas de classe apresentados permitem abstrair qual é a estrutura lógica da
base de dados. Todavia, a fim de definir claramente qual é a estrutura relacional, a seguir é
apresentado o modelo entidade-relacionamento da base de dados criada para o protótipo.
Convém apresentá-lo como artefato de suporte à definição do modelo de dados, pois
apresentou grande utilidade como documento de consulta, contribuindo fortemente para a
definição das classes do protótipo. A figura 15 apresenta o modelo entidade-relacionamento
da ferramenta, usando a sintaxe dos tipos de dados do banco de dados MySQL. O dicionário
de dados correspondente ao modelo encontra-se no Anexo A.
92
Figura 15: Diagrama Entidade Relacionamento
Fonte: Primária
93
6.3. Interface gráfica
A interface gráfica é o meio pelo qual o usuário tem acesso às funcionalidades do
software. Conforme explica Sommerville (2007), o projeto de interface com o usuário é parte
indispensável de um projeto de software, e um bom projeto da mesma aumenta
consideravelmente as chances de o software atingir todo o seu potencial, e é claro, agradar o
cliente.
Para o protótipo proposto, a interface com o usuário será web, mantendo-se desta
forma concernente a um dos critérios definidos que se refere à necessidade de a ferramenta
apresentar interface web. Desta forma, o acesso ao protótipo se dará através de um web-
browser, rodando sobre qualquer plataforma operacional gráfica existente, o que elimina
problemas de compatibilidade com sistemas operacionais e aumenta consideravelmente o
poder de adaptação do protótipo aos mais diversos ambientes existentes.
Informando a URL (Uniform Resource Locator) do protótipo, o usuário é direcionado
a tela de autenticação, onde deverá informar seu login e senha corretamente para obter acesso.
A figura 16 apresenta a tela de login do protótipo.
Figura 16: Tela de login do protótipo
Fonte: Primária
Uma vez estando corretamente autenticado, o usuário é redirecionado a tela central do
protótipo, a qual congrega todas as funcionalidades, tanto da visão técnica quanto da visão
gerencial. Para melhor atender às necessidades do usuário, o protótipo adapta-se entre as duas
visões tomando por base qual é o papel do usuário autenticado em relação ao projeto
selecionado. Isso é possível pelo fato de o protótipo apresentar as informações referentes a um
único projeto default. Desta forma, todos os cadastros referem-se a este projeto selecionado.
94
Durante o uso do protótipo é possível alterar a qualquer momento o projeto default, o que
pode repercutir em uma mudança de visão do sistema, caso o papel do usuário alterne entre as
visões. Assim, para o papel de gerente de projetos, o protótipo adapta a interface para a visão
gerencial, enquanto para os demais, configura-se na visão técnica.
Na figura 17 é apresentada a tela principal do protótipo, na visão técnica. Apenas a
barra de menus está sendo mostrada, uma vez que o conteúdo do corpo desta tela até o
momento deste trabalho não foi definido.
Figura 17: Tela principal do protótipo
Fonte: Primária
A barra de menus da tela principal sempre ficará ativa, independente da funcionalidade
acessada. Isso facilita a compreensão, além de melhorar a navegabilidade geral do protótipo.
Todas as outras páginas acessadas serão carregadas imediatamente abaixo da barra de menus.
Como estratégia de padronização, todas as telas de manutenção obedecem a um único
padrão. Neste, inicialmente, listam-se os registros de forma tabular, dando a opção do usuário
poder editá-los ou excluí-los através de botões anexados a cada registro. Logo abaixo da
listagem, é apresentado um botão à direita cuja função é adicionar um novo registro.
Medianamente, um botão de retorno, que volta a uma página pré-estabelecida. E, ao lado
esquerdo, um botão para atualizar o conjunto de registros listado.
Ao clicar sobre o botão de adição de registro ou sobre o botão de edição de registro, o
protótipo carrega a tela de manutenção propriamente dita, onde os dados de fato são
informados. Estas telas apresentam uma variação quanto aos botões dispostos na parte inferior
da página. Isso explica-se pelo fato de existir uma lógica implementada entre os cadastros, a
qual já pôde ser observada através do diagrama de classes DTO do protótipo (composições e
agregações).
A fim de melhor exemplificar a rotina de manutenção de dados, demonstrar-se-á a
seguir os passos necessários ao cadastramento de uma nova estória. Considerando-se que o
usuário tenha feito login corretamente no protótipo e que, para o projeto default o usuário
tenha um papel na equipe pertencente à visão técnica, o primeiro passo que se faz necessário
95
para cadastrar uma nova estória é clicar sobre o menu Estórias. Feito isso, o protótipo carrega
a página de listagem de estórias, na parte inferior da barra de menus. A figura 18 exemplifica
a situação descrita.
Figura 18: Tela de listagem de estórias
Fonte: Primária
A seguir, o usuário deve clicar sobre o botão “Nova Estória”, o qual irá direcioná-lo ao
formulário de manutenção dos dados da nova estória. Vale ressaltar que a presença dos botões
na parte inferior da tela de manutenção de estórias visa facilitar o processo de cadastramento
de informações, uma vez que relacionam as outras atividades que tem relação direta às
estórias de usuário.
Figura 19: Tela de manutenção de estórias
Fonte: Primária
96
Finalmente, tendo o usuário informado os dados requisitados, basta persistir de fato na
base. A forma de fazê-lo é clicando sobre o botão “Salvar”, que dispara uma rotina de
verificação de campos que visa encontrar algum problema com as informações. Caso não
encontre problemas, o protótipo persiste os dados e retorna à tela de listagem, já apresentando
a nova estória cadastrada.
Figura 20: Tela de listagem com a nova estória cadastrada
Fonte: Primária
O fluxo de operações mencionado acima é válido para toda a manutenção de dados
existente no protótipo. Diz-se, portanto, que são os passos mínimos necessários para executar
uma operação de cadastro. Este fluxo encontra-se melhor definido pela figura 21, onde
buscou-se demonstrar as operações que disparam a alternância entre as páginas envolvidas.
Figura 21: Operações necessárias a uma manutenção de dados
Fonte: Primária
97
A única regra que se aplica às manutenções refere-se a hierarquia das informações.
Todo o processo de inserção de dados, que se inicia com o cadastramento de um projeto, deve
respeitar uma sequência lógica. Não é permitido, por exemplo, cadastrar uma tarefa sem antes
ter cadastrado a estória a qual a tarefa pertence. Esta sequência é o reflexo das regras de
negócio implementadas pelo protótipo. A figura 22 demonstra a estrutura hierárquica dos
dados mantidos pelo protótipo.
Figura 22: Hierarquia dos dados mantidos pelo protótipo
Fonte: Primária
98
CONCLUSÃO
A partir do trabalho desenvolvido pôde-se observar que as metodologias ágeis, em
especial a Extreme Programming, apresentam-se em consonância com os princípios da
engenharia de software.
O que se observa, na realidade, é que uma metodologia ágil deve absorver a essência
das teorias apregoadas pela Engenharia de Software e aplicá-las de modo otimizado, a fim de
evitar qualquer situação de burocracia extrema. Este processo de otimização não representa
uma perda de informações, mas apenas uma interpretação ágil que utiliza uma perspectiva
diferenciada sobre tais teorias.
Dentre as diferentes etapas que o desenvolvimento de um software engloba, a elicitação
de requisitos certamente é uma das mais complexas. É nesta etapa que a equipe de
desenvolvimento deve extrair do cliente quais são suas necessidades, de forma a gerar uma
especificação do software desejado. Esta especificação deve apresentar-se de extrema
qualidade, uma vez que ela define o software que o cliente irá receber. Isso é válido tanto para
metodologias ágeis quanto prescritivas.
Uma especificação de requisitos falha é a responsável por muitos dos problemas
encontrados durante o desenvolvimento de um software, gerando altos custos de reparos e
atrasos nos cronogramas pré-estabelecidos. Por este fato, a aplicação das práticas
recomendadas pela Engenharia de Requisitos é de fundamental importância em qualquer
processo de desenvolvimento de software.
Inicialmente, as atividades que compreendem a Engenharia de Requisitos parecem
pouco adaptáveis à metodologias ágeis, uma vez que prescrevem a manutenção de uma
especificação de requisitos detalhada, bem documentada e com alto grau de qualidade.
Todavia, o velho provérbio que diz que as aparências enganam mais uma vez mostra seu
99
valor. Conforme foi possível observar, uma especificação de requisitos provida de todos os
atributos de qualidade é possível de ser gerada, mesmo em uma metodologia ágil como a
Extreme Programming.
Neste âmbito, destaca-se a aplicação de ferramentas CASE como instrumentos de
auxílio ao processo de Engenharia de Requisitos, através da automatização de importantes
rotinas do processo. Assim, uma ferramenta CASE que seja suficientemente maleável e
otimizada traz importantes benefícios ao processo de desenvolvimento, que vão desde maior
controle sobre as atividades até a diminuição considerável de tarefas manuais.
Em relação a uma ferramenta CASE voltada a gerência de requisitos na XP, observou-
se que algumas características devem ser levadas em conta no momento da escolha. Entre
elas, a interface web e o código-fonte aberto destacam-se como as mais importantes, uma vez
que enfatizam a portabilidade e a adaptabilidade, tão importantes a ambientes XP de
desenvolvimento.
Como visto no decorrer deste trabalho, as ferramentas CASE disponíveis para a XP são
poucas e incompletas. Muito deixam a desejar, principalmente no que diz respeito à
rastreabilidade dos requisitos, que é uma das deficiências que a XP apresenta em sua
especificação de requisitos.
O protótipo descrito neste trabalho apresenta características inovadoras, uma vez que
intenciona gerir os requisitos de modo a manter uma especificação com todos os requisitos de
qualidade necessários em uma metodologia ágil. Além disso, propõe a geração de uma matriz
de rastreabilidade, que é uma característica inexistente nas ferramentas estudadas.
Outra importante particularidade do protótipo é apresentar de forma distinta a visão
técnica da visão gerencial do projeto, o que torna a ferramenta mais simples de utilizar, uma
vez que apenas as funcionalidades coerentes com o papel do usuário são disponibilizadas na
tela principal.
Finalmente, pode-se concluir que o uso do protótipo em um projeto XP é perfeitamente
possível, não gerando qualquer sobrecarga ao processo. Além disso, muito se ganha em
controle sobre os requisitos, contribuindo desta forma para o aumento da qualidade final do
produto desenvolvido. Desta forma, demonstrou-se que a Engenharia de Requisitos é
totalmente aplicável a XP, não sendo impossível seguir suas recomendações em um processo
ágil de desenvolvimento.
100
TRABALHOS FUTUROS
Como trabalhos futuros buscar-se-á dar continuidade ao desenvolvimento do protótipo,
e uma vez pronto, disponibilizá-lo para download gratuito na WEB, juntamente com o
código-fonte e arquivos de especificação.
Pretende-se também testar a aplicabilidade do protótipo em um ambiente real de
desenvolvimento. Isto mostra-se como a melhor forma de submeter a ferramenta a uma
validação que venha expor os erros e acertos cometidos durante a sua especificação.
Outro grande intento tido é buscar hospedar o projeto junto ao site
www.sourceforge.net, um dois maiores portais de projetos OpenSource existentes. Desta
forma, todos aqueles que desejarem contribuir com o projeto de alguma forma terão a
possibilidade de fazê-lo, tornando-se um colaborador. Assim espera-se que a proposta contida
neste trabalho venha a tornar-se uma poderosa ferramenta de auxílio a equipes XP espalhadas
pelo mundo.
101
REFERÊNCIAS
AHERN, Dennis M.; CLOUSE, Aaron; TURNER, Richard. CMMI Distilled: A practical
Introduction to Integrated Process Improvement. Addison-Wesley, 2006.
AMBLER, Scott W.; PIMENTA, Marcelo Soares (Rev.) Modelagem ágil: práticas eficazes
para a programação extrema e o processo unificado. Porto Alegre: Bookman, 2004.
BABAXP. Disponível em <https://babaxp.dev.java.net/>. Acesso em: 20 de ago. de 2009.
BECK, KENT. Programação extrema explicada: Acolha as mudanças. Porto Alegre.
Artmed Editora S.A. 2004.
BORLAND SOFTWARE CORPORATION. Requeriments Definition and Management.
Disponível em <http://www.borland.com/media/en/edm/rdm_solution_demo/rdm.html>.
Acessado em: 13 maio 2009.
CAMPOS, Vicente Falconi. TQC: controle da qualidade total (no estilo japonês). 8.ed. Belo
Horizonte: EDG, 1999.
EXTREME Programming: A gentle introduction. Disponível em
<http://www.extremeprogramming.org>. Acessado em: 13 jun. 2009.
FREIRE, Alexandre; ASMUSSEM, Christian. Programação Extrema: Desenvolvendo
software com qualidade e agilidade. Disponível em < http://www.rau-tu.unicamp.br/nou-
rau/softwarelivre/document/?view=112>. Acessado em: 12 jun. 2009.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software develpment
Process. Editora Addison-Wesley. 1999.
LIMA, Adilson da Silva. UML 2.0: do requisito à solução. 1. ed. São Paulo: Érica, 2005
MEDEIROS, Ernani S.. Desenvolvendo software com UML 2.0 – Definitivo. São Paulo.
Editora Pearson Makron Books. 2004.
102
PAULA FILHO, Wilson de P.. Engenharia de Software: Fundamentos, Métodos e Padrões.
Rio de Janeiro. LTC. 2001.
PRESSMAN, Roger. S. Engenharia de Software. Rio de Janeiro. McGraw-Hill
Interamericana do Brasil, 2002.
RABELLO, Márcia Rodrigues; DE BORTOLI, Lis Ângela. Estrela: um modelo de processo
de desenvolvimento para aplicações de comércio eletrônico. Passo Fundo: Ed. Universidade
de Passo Fundo, 2006.
PPTS - Projetct Planning and Tracking System. Disponível em <http://ses-
ppts.sourceforge.net/>. Acesso em: 12 ago. 2009.
RATIONAL Unified Process: Visão Geral. Disponível em <
http://www.wthreex.com/rup/portugues/index.htm>. Acessado em: 20 abr. 2009.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison-Wesley, 2007.
SUN MICROSYSTEMS. Core J2EE Patterns – Data Acess Object. Disponível em <
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ >. Acessado em: 18 nov. 2009.
TRACKIT: Project Web Hosting - Open Source Software. Disponível em
<http://trackit.sourceforge.net/>. Acesso em: 8 ago. 2009.
VERGÍLIO, Silvia R.. Software e Engenharia de Software. Disponível em
<http://www.inf.ufpr.br/silvia/ES/SweES/SweESalunos.pdf>. Acessado em 26 mar. 2009.
XPWEB. Disponível em <http://xpweb.sourceforge.net/index.php>. Acesso em: 25 jul. 2009.
103
ANEXO A – DICIONÁRIO DE DADOS
104
105
106
