O uso de tecnologias de big data na concepção e execução de estratégias de en...
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
1. 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
2. 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
3. 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
4. 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.
6. 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.
7. 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
8. 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
9. 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
10. 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
11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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;