SlideShare uma empresa Scribd logo
1 de 106
Baixar para ler offline
UNIVERSIDADE DE PASSO FUNDO
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITOS
VOLTADA AO MODELO DE PROCESSO DE SOFTWARE
XP
Passo Fundo
2009
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITOS
VOLTADA AO MODELO DE PROCESSO DE SOFTWARE
XP
Monografia apresentada ao curso de Ciência da
Computação, do Instituto de Ciências Exatas e
Geociências, da Universidade de Passo Fundo, como
requisito parcial para a obtenção de grau de Bacharel
em Ciência da Computação, sob orientação da Profa
.
Ms. Jane Colossi Grazziotin.
Passo Fundo
2009
Diego Antonio Lusa
Desenvolvimento do protótipo de uma ferramenta para engenharia de requisitos
voltada ao modelo de processo de software XP
Monografia apresentada ao curso de Ciência da
Computação, do Instituto de Ciências Exatas e
Geociências, da Universidade de Passo Fundo, como
requisito parcial para obtenção do grau de Bacharel
em Ciência da Computação, sob a orientação da
Profa
. Ms. Jane Colossi Grazziotin.
Aprovada em __ de __________________ de __________.
BANCA EXAMINADORA
_____________________________________
Profa
. Ms. Jane Colossi Grazziotin – UPF
____________________________________
Profª. Ms. Lis Ângela De Bortoli – UPF
Apesar de todas as pedras encontradas pelo
caminho, os sonhos se realizam. Apesar de
todo o cansaço, tristeza, dúvida ou medo, o
caminho foi trilhado. E a chegada aproxima-
se, como o clarão de uma vela iluminando a
escuridão.
Nesta caminhada nunca estive só. Estive
sempre amparado por grandes pessoas, de
valor inestimável e é a elas que dedico este
trabalho.
A meus pais, além de todo meu amor, os
agradeço de todo meu coração. Vocês são
minha força e inspiração.
A meus professores, em especial minha
orientadora Jane Colossi, pela amizade, pelos
ensinamentos, pelas cobranças e pelos
conselhos. A vocês, minha eterna gratidão.
A meus amigos, pelas críticas, pela amizade,
pelos bons conselhos e pelas bobagens que
tantas alegrias me trouxeram. Obrigado a
todos.
Minha conquista é também a conquista de
todos aqueles que de alguma forma estiveram
comigo nesta caminhada. A todos, meu muito
obrigado.
“A persistência é o caminho do êxito.”
Charles Chaplin
RESUMO
Desenvolver software é uma atividade complexa. Muitos problemas podem ocorrer
durante o desenvolvimento e vir a comprometer todo o projeto. Dentre os mais comuns pode-
se citar atrasos na entrega do software e a incapacidade de manter-se dentro dos custos
previstos, problemas estes oriundos grande parte das vezes de falhas na especificação do
software. Em vista disso, é necessário que o desenvolvimento se dê embasado por um
processo bem definido que forneça uma sustentação gerencial às atividades necessárias, ou
seja, por um modelo de processo de software. Neste aspecto, grande enfoque deve ser dado à
atividade de elicitação de requisitos, que é a base fundamental de qualquer modelo de
processo de software e também a área mais crítica do desenvolvimento.
Existem na literatura dois grandes grupos de modelos de processo de software: ágeis e
prescritivos. Os modelos ditos ágeis caracterizam-se por enfatizarem a simplicidade e a
desburocratização do desenvolvimento de software, enquanto que os modelos prescritivos
enfatizam um desenvolvimento orientado por atividades rigidamente definidas e que
normalmente atravancam o processo pela grande necessidade de documentação durante o
desenvolvimento.
Dentre os modelos ágeis, a Extreme Programming destaca-se como um dos mais
conhecidos. Entre suas principais características destaca-se o desenvolvimento incremental,
programação em par, participação do cliente na equipe e o refactoring.
No que concerne a elicitação de requisitos, observou-se que a Extreme Programming
apresenta algumas falhas, que podem comprometer a qualidade da especificação de requisitos
por ela mantida. Observou-se também que tais falhas poderiam ser suprimidas com o uso de
uma ferramenta informatizada de auxílio ao processo de gerência de requisitos (ferramenta
CASE – Computer Aided Software Engineering).
Dado que as ferramentas avaliadas não contemplam as necessidades elencadas, este
trabalho objetiva propor um protótipo de ferramenta CASE, voltada a gerência de requisitos
na Extreme Programming, que forneça todas as características necessárias para manter uma
especificação de requisitos guarnecida por todos os atributos de qualidade necessários.
Palavras-chave: especificação de requisitos, CASE, protótipo, Engenharia de
Requisitos, Extreme Programming.
LISTA DE FIGURAS
Figura 1: Tipos de requisitos não funcionais ................................................................26
Figura 2: Especificação de um requisito de domínio....................................................27
Figura 3: Especificação de requisitos utilizando um formulário padrão.......................31
Figura 4: Exemplo de um Diagrama de Fluxo de Dados (DFD) .................................32
Figura 5: Diagrama de Casos de Uso............................................................................32
Figura 6: Dificuldades de compreensão........................................................................37
Figura 7: Processo de Engenharia de Requisitos ..........................................................38
Figura 8: Custos de erros nos requisitos .......................................................................43
Figura 9: Modelo Cascata .............................................................................................45
Figura 10: Diagrama esquemático da metodologia XP.................................................49
Figura 11: Diagrama de casos de uso da visão técnica .................................................86
Figura 12: Diagrama de casos de uso da visão gerencial..............................................87
Figura 13: Diagrama de Classes DAO..........................................................................90
Figura 14: Diagrama de classes DTO ...........................................................................91
Figura 15: Diagrama Entidade Relacionamento ...........................................................92
Figura 16: Tela de login do protótipo ...........................................................................93
Figura 17: Tela principal do protótipo ..........................................................................94
Figura 18: Tela de listagem de estórias.........................................................................95
Figura 19: Tela de manutenção de estórias ...................................................................95
Figura 20: Tela de listagem com a nova estória cadastrada..........................................96
Figura 21: Operações necessárias a uma manutenção de dados ...................................96
Figura 22: Hierarquia dos dados mantidos pelo protótipo ............................................97
LISTA DE TABELAS
Tabela 1: Project Planning & Tracking System v. 1.6.6...............................................61
Tabela 2: Trackit ...........................................................................................................62
Tabela 3: XPWEB.........................................................................................................63
Tabela 4: BABAXP.......................................................................................................64
Tabela 5: Relação ferramenta X Grau de atendimento .................................................67
Tabela 6: Atores do protótipo .......................................................................................70
Tabela 7: UC Manter estórias........................................................................................72
Tabela 8: UC Manter Tarefas........................................................................................73
Tabela 9: UC Manter bugs ............................................................................................74
Tabela 10: UC Manter Versões.....................................................................................74
Tabela 11: UC Estimar tempo de desenvolvimento para uma estória ..........................75
Tabela 12: UC Buscar estórias semelhantes .................................................................76
Tabela 13: UC Manter casos de teste............................................................................77
Tabela 14: UC Manter iterações....................................................................................78
Tabela 15: UC Gerar matriz de rastreabilidade dos requisitos......................................78
Tabela 16: UC Manter releases.....................................................................................79
Tabela 17: UC Exportar projeto em XML ....................................................................80
Tabela 18: UC Buscar projeto.......................................................................................80
Tabela 19: UC Buscar release.......................................................................................81
Tabela 20: UC Buscar iteração......................................................................................81
Tabela 21: UC Recuperar o número de bugs encontrados por iteração e estórias
relacionadas ..............................................................................................................................82
Tabela 22: UC Recuperar o número de bugs encontrados por release.........................83
Tabela 23: UC Recuperar o número de bugs encontrados por projeto .........................84
Tabela 24: UC Manter projetos.....................................................................................84
Tabela 25: UC Manter usuários ....................................................................................85
Tabela 26: UC Manter equipe.......................................................................................85
LISTA DE ABREVIATURAS
CASE Computer- Aided Software Engineering
CMMI Capability Maturity Model Integration
CVS Concurrent Version System
D Deslocamento
DAO Data Access Object
DFD Diagrama de Fluxo de Dados
DTO Data Transactional Object
ER Engenharia de Requisitos
FDD Feature Driven Development
GNU Acrônimo Recursivo de “GNU`s Not Unix!”
IDE Integrated Development Environment
PHP Hypertext Preprocessor
PPTS Project Planning & Tracking System v. 1.6.6
REQM Requirements Management
RUP Rational Unified Process
Sf Posição Final
SGBD Sistema Gerenciador de Banco de Dados
Si Posição Inicial
T Tempo
TDD Test-Driven Development
UC Use Case
UP Unified Process
URL Uniform Resource Locator
UML Unified Modeling Language
VM Velocidade Média
XML Extensible Markup Language
XP Extreme Programming
SUMÁRIO
INTRODUÇÃO ............................................................................................................12
1. ENGENHARIA DE SOFTWARE.........................................................................15
1.1. Histórico..........................................................................................................15
1.2. Processo de Software......................................................................................18
1.3. Modelo de ciclo de vida..................................................................................19
2. REQUISITOS.........................................................................................................23
2.1. Requisitos de usuário......................................................................................24
2.2. Requisitos de sistema......................................................................................24
2.2.1. Requisitos Funcionais...............................................................................25
2.2.2. Requisitos não-funcionais ........................................................................25
2.2.3. Requisitos de domínio ..............................................................................26
2.3. Especificação de requisitos e os problemas relacionados...............................27
2.3.1. Elaboração ................................................................................................28
2.3.2. Ambiente ..................................................................................................28
2.3.3. Evolução...................................................................................................29
2.3.4. Limites......................................................................................................29
2.3.5. A problemática relacionada......................................................................30
2.4. Qualidade dos Requisitos................................................................................33
2.4.1. Correção....................................................................................................33
2.4.2. Precisão.....................................................................................................33
2.4.3. Completeza...............................................................................................34
2.4.4. Consistência..............................................................................................34
2.4.5. Priorização................................................................................................34
2.4.6. Verificabilidade ........................................................................................35
2.4.7. Modificabilidade.......................................................................................35
2.4.8. Rastreabilidade .........................................................................................35
3. ENGENHARIA DE REQUISITOS.......................................................................37
3.1. Estudo da Viabilidade.....................................................................................39
3.2. Elicitação e análise dos requisitos ..................................................................40
3.3. Especificação dos Requisitos..........................................................................42
3.4. Validação dos Requisitos................................................................................42
3.5. Gerenciamento de Requisitos .........................................................................43
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS...................45
4.1. Valores............................................................................................................47
4.1.1. Comunicação ............................................................................................47
4.1.2. Simplicidade.............................................................................................48
4.1.3. Coragem ...................................................................................................48
4.1.4. Feedback...................................................................................................49
4.2. Ciclo de Vida XP ............................................................................................49
4.2.1. Fase de Exploração...................................................................................50
4.2.2. Fase de Planejamento ...............................................................................50
4.2.3. Fase de iterações para entrega ..................................................................51
4.2.4. Fase de produção ......................................................................................52
4.2.5. Manutenção ..............................................................................................53
4.3. Engenharia de Requisitos aplicada a Extreme Programming.........................53
5. TECNOLOGIA CASE...........................................................................................57
5.1. Estudo de ferramentas CASE existentes de apoio ao processo de Engenharia
de Requisitos voltado a Extreme Programming ...................................................................59
5.1.1. Ferramentas CASE analisadas..................................................................61
5.1.2. Formalização das características desejáveis a uma ferramenta de gerência
de requisitos para XP........................................................................................................64
6. PROJETO DO PROTÓTIPO.................................................................................68
6.1. Casos de uso do protótipo...............................................................................69
6.1.1. Casos de uso da visão técnica...................................................................71
6.1.2. Casos de uso da visão gerencial ...............................................................82
6.2. Diagrama de Classes do Protótipo..................................................................88
6.3. Interface gráfica ..............................................................................................93
CONCLUSÃO ..............................................................................................................98
TRABALHOS FUTUROS..........................................................................................100
REFERÊNCIAS..........................................................................................................101
ANEXO A – DICIONÁRIO DE DADOS ..................................................................103
12
INTRODUÇÃO
O desenvolvimento de software é uma atividade de engenharia (PRESSMAN, 2002).
Diferentemente de uma linha de produção industrial, onde manufaturam-se milhares de
produtos de características iguais diariamente, o processo de desenvolvimento de software
segue linhas distintas. Não há como manufaturar software, pois ele é elemento de um sistema
lógico e não físico. Desta forma, cada software que é desenvolvido origina-se de um projeto
distinto, mesmo o produto final servindo ao mesmo fim.
Para orientar as atividades necessárias ao desenvolvimento de software, criaram-se
diferentes abstrações de processos de software, denominadas modelos de ciclo de vida
(SOMMERVILLE, 2007), com vistas a definir um arcabouço unívoco que facilitasse a
gerência e as atividades de desenvolvimento propriamente ditas. Inicialmente, os modelos
propostos tinham por principal meta definir rigidamente a sequência de atividades a ser
realizada durante o projeto, exigindo disciplina e comprometimento na execução do modelo
por parte da equipe. Por este fato, tais modelos receberam a denominação de modelos
prescritivos de desenvolvimento.
Todavia, o uso dos modelos prescritivos mostrou-se inconveniente em determinados
casos justamente pela burocracia que impunham ao desenvolvimento. Em vista disso, teóricos
da Engenharia de Software reuniram-se e propuseram formas mais eficientes de
desenvolvimento, defendendo que a satisfação do cliente com entregas rápidas e funcionais do
software era muito mais importante que seguir um protocolo extremamente formal de
desenvolvimento. Desta forma, os modelos de desenvolvimento que abarcaram tais idéias
ficaram conhecidos como modelos ágeis de desenvolvimento.
Embora as diferenças entre metodologias ágeis e prescritivas sejam consideráveis,
muitas atividades em comum podem ser observadas. Dentre elas, a descoberta de requisitos
13
(elicitação) merece destaque. Segundo Sommerville (2007), “os requisitos de um sistema são
descrições dos serviços fornecidos pelo sistema e suas restrições operacionais”. De acordo
com esta definição, um requisito pode representar uma necessidade funcional do sistema, ou
também, uma característica não-funcional inerente ao software, como um nível de
confiabilidade mínimo, por exemplo.
A atividade de descoberta de requisitos, num olhar superficial, parece ser
extremamente simples de ser realizada. Todavia, observa-se que ela é rodeada de
complexidade, sendo a etapa mais crítica de um projeto de software. Tal é a importância desta
atividade que existe uma subárea da Engenharia de Software, denominada Engenharia de
Requisitos que se atém exclusivamente às atividades de descoberta, organização, validação e
gerenciamento dos requisitos.
Basicamente, o objetivo da Engenharia de Requisitos é criar e manter a especificação
de requisitos de um software. Uma especificação define um software em termos de seus
requisitos e necessita apresentar um conjunto mínimo de atributos de qualidade para de fato
apresentar um valor concreto durante um projeto de software. Manter uma especificação de
requisitos, se mal planejada, pode tornar-se oneroso e incômodo. Outro agravante é o uso de
ferramentas inadequadas para a geração e manutenção de uma especificação, que de certa
forma impõe mais dificuldades do que benefícios à disciplina de ER.
Em um contexto ágil de desenvolvimento de software, uma importante questão que se
levanta quanto à manutenção de uma especificação de requisitos é: será possível manter uma
especificação de requisitos de qualidade em uma metodologia ágil sem “engessar” o processo
de descoberta de requisitos e, por conseguinte, atravancar toda a metodologia?
Visando responder esta importante pergunta, este trabalho sugere o desenvolvimento
de um protótipo de ferramenta CASE para gerência de requisitos voltado à metodologia ágil
Extreme Programming (XP). Desta forma, quando aplicado ao modelo de desenvolvimento
XP, o protótipo propõe-se a manter uma especificação de requisitos alicerçada em todos os
atributos de qualidade necessários sem impor qualquer restrição à metodologia para tanto.
A fim de atingir o objetivo proposto, este trabalho está organizado em um conjunto de
seis capítulos, os quais seguem o protocolo apresentado nos próximos parágrafos deste texto.
O capítulo 1 trata de introduzir os conceitos referentes à Engenharia de Software, que
compreendem os requisitos básicos necessários aos conceitos que se seguem. Aspectos
históricos, características do software e conceito de ciclo de vida são alguns dos assuntos
tratados neste capítulo.
14
O capítulo 2 aborda o conceito de requisito, fundamental à definição do protótipo
proposto e essencial ao desenvolvimento de software e a Engenharia de Software; a
classificação dos requisitos, os atributos de qualidade de requisitos e os problemas
relacionados são também amplamente discutidos neste tópico.
O capítulo 3, por sua vez, se atém a disciplina de Engenharia de Requisitos, uma
importante subárea da Engenharia de Software que trata exclusivamente da definição do
processo de descoberta, classificação, priorização, validação e gerência dos requisitos de um
software.
No capítulo 4 apresenta-se a metodologia ágil Extreme Programming, enfatizando suas
principais características e valores, ressaltando como ela trata os requisitos durante o processo
de desenvolvimento e avaliando-se qual é o grau de atendimento da especificação de
requisitos gerada quanto aos atributos de qualidade necessários.
O capítulo 5 apresenta o conceito de ferramenta de apoio ao processo de
desenvolvimento de software. Neste capítulo são apresentadas quatro ferramentas de gerência
de requisitos para a metodologia Extreme Programming oferecidas gratuitamente na grande
rede, a partir das quais é feita uma análise comparativa. Com base nos resultados obtidos com
a análise, conjuntamente com os critérios de seleção definidos para as ferramentas e os
atributos de qualidade, apresenta-se no capítulo 6 a modelagem do protótipo em termos de
casos de uso, diagramas de classe e interface com o usuário.
15
1. ENGENHARIA DE SOFTWARE
Neste capítulo são abordados aspectos históricos que deram origem a Engenharia de
Software, uma importante área da Engenharia que visa a melhoria constante do processo de
desenvolvimento de software, com a finalidade de garantir qualidade e cumprimento de
prazos e custos. Conceitos como software, processo de software e modelo de processo de
software compreendem o universo de trabalho das técnicas de Engenharia de Software
existentes.
1.1. Histórico
O software é indispensável ao funcionamento da sociedade contemporânea. Ele
controla infra-estruturas e serviços essenciais a nossa vida. Redes de água, eletricidade, redes
bancárias, bolsa de valores, telefonia, entre outros, têm suas atividades controladas por
sistemas de informação em computador. O software está incorporado à rotina de qualquer
pessoa, direta ou indiretamente.
Mas afinal, o que realmente é software? Segundo Pressman (2002) por software
entende-se os programas, estruturas de dados e a documentação de operação e uso que,
quando executados, fornecem a função e o desempenho desejados.
O software apresenta características peculiares em relação aos demais produtos
produzidos pelos seres humanos. O software é elemento de um sistema lógico e não físico
(PRESSMAN, 2002). Para Sommerville (2007), ele [o software] é abstrato e intangível, não
limitado por materiais e leis físicas ou processos de manufatura.
16
As características do software residem, segundo Pressman (2002), em três importantes
itens, a saber:
a) O software é desenvolvido, ou passa por um processo de engenharia, não é
manufaturado.
No desenvolvimento de software a relação entre as pessoas envolvidas na
atividade e o trabalho a ser realizado é diferente de um processo de manufatura
convencional. Além disso, os custos de desenvolvimento do software estão
concentrados na engenharia, o que pressupõem que a gerência de projetos de
software deva ser diferente da gerência de projetos de fabricação.
b) Software não se desgasta.
O software não é suscetível às adversidades físicas que afetam praticamente todos
os outros produtos feitos pelo homem. Quando, por exemplo, é necessário trocar
uma peça do motor de um automóvel o processo é relativamente simples, pois
existem peças de reposição. Todavia, quando o software falha não existem peças
de reposição, o custo de manutenção pode ser elevado em razão da complexidade
do processo e, de quebra, pode indicar que houve um erro no projeto do mesmo.
c) A maior parte do software continua a ser construída sob encomenda.
Diferentemente de outras áreas da engenharia, como a mecânica e a elétrica, por
exemplo, o conceito de reuso de componentes de software ainda é incipiente.
Embora já esteja bem difundido este conceito em função das linguagens
orientadas a objetos, por exemplo, muito é feito do princípio (sob encomenda) em
um software.
Em vista das características atípicas que o produto de software possui, o seu
desenvolvimento apresenta grande complexidade. Existem inúmeros problemas que podem
surgir no decorrer do desenvolvimento que podem vir a comprometer o produto final. O
grande dilema vivenciado pelos desenvolvedores desde os primórdios da indústria do software
é como desenvolver um produto confiável e de qualidade que respeite os custos e os prazos de
entrega previamente estipulados.
17
Na década de 60, os problemas com desenvolvimento de software atingiram níveis
críticos. As causas para este estresse na indústria do software, segundo Vergílio (2009), se
baseavam basicamente nos seguintes problemas:
a) Cronogramas e custos imprecisos;
b) Inexistência de dados históricos sobre o processo de desenvolvimento;
c) Comunicação deficiente com o usuário;
d) Carência de conceitos quantitativos sobre confiabilidade, qualidade e
reusabilidade;
e) Manutenção difícil.
A evolução do hardware também representava um agravante ao desenvolvimento de
software. Projetos até então tidos como não realizáveis tornaram-se possíveis em função do
novo hardware permitir a sua execução. Com isso o software a ser produzido apresentava-se
maior e mais complexo do que os sistemas anteriormente desenvolvidos (SOMMERVILLE,
2007).
Em função dos problemas encontrados, os desenvolvedores observaram que o
desenvolvimento informal de software, feito até então, não mais suportava as necessidades de
projeto apresentadas. Era necessária alguma mudança para reverter o quadro crítico que
estava instaurado na indústria do software.
A resposta a então denominada “crise do software” veio em 1968, com a organização
de uma conferência para discutir a turbulência que a indústria do software estava enfrentando.
Dentre as discussões feitas na busca por soluções foi proposto o conceito inicial de
“Engenharia de Software”, como um conjunto de técnicas e métodos formais de
desenvolvimento, na intenção de eliminar o amadorismo e formalizar todo o processo de
desenvolvimento de software (SOMMERVILLE, 2007).
Ainda segundo Sommerville (2007), a Engenharia de Software é uma disciplina de
engenharia relacionada com todos os aspectos de produção de software, desde os estágios
iniciais de especificação do sistema até sua manutenção, depois de entrar em operação. Ela se
preocupa com o software como produto (PAULA FILHO, 2001), utilizando sólidos princípios
18
de engenharia com o intuito de obter o software de maneira econômica, com características de
confiabilidade e eficiência no uso em máquinas reais (PRESSMAN, 2002).
1.2. Processo de Software
A engenharia de software se fundamenta no processo (PRESSMAN, 2002). O
processo, portanto, é o que garante que as metodologias e ferramentas usadas pela Engenharia
de Software tenham o efeito esperado.
Segundo Campos (1999), processo é um conjunto de causas que provoca um ou mais
efeitos. Sempre que algo ocorre (efeito, fim, resultado) existe um conjunto de causas que
podem ter influenciado a sua ocorrência. A saída de qualquer processo, portanto, é um efeito
de sua execução.
Segundo Rabello (2006), os processos são importantes porque imprimem consistência
e estrutura a um conjunto de atividades. Um processo institucionalizado garante um padrão e,
por conseguinte, ajuda a manter as características de qualidade do produto final, mesmo sendo
este produzido por indivíduos diferentes.
Para Sommerville (2007), um processo de software é um conjunto de atividades que
leva a produção de um software. Pressman (2002) afirma que o processo define uma estrutura
para um conjunto de áreas-chave de processo que deve ser estabelecida para a efetiva
utilização da tecnologia de Engenharia de Software. Tais áreas formam a base para o controle
gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são
aplicados, os produtos de trabalho produzidos, os marcos estabelecidos, a qualidade
assegurada e as modificações geridas.
Todo o processo possui atividades que devem ser executadas no seu decorrer. Existem
diferentes processos de software na literatura. Segundo Sommerville (2007), dentre todos os
processos, as atividades que lhes são comuns compreendem:
a) Especificação de software: definição das funcionalidades e restrições do software;
b) Projeto e implementação do software: produção do software que atenda as
especificações;
c) Validação do software: validação do software com o cliente a fim de garantir que
ele esteja de acordo com as especificações;
19
d) Evolução do software: evolução do software durante seu ciclo de vida para
acompanhar as necessidades dos clientes.
Pressman (2002) entende, por sua vez, que todo o processo de software pode ser
composto por três fases, a saber:
a) Definição: definição dos requisitos. O foco da fase é descobrir “o quê” o software
deve fazer;
b) Desenvolvimento: O foco da fase é o “como”. Esta fase engloba o projeto, a
codificação e os testes do software;
c) Manutenção: O foco desta fase são as mudanças, sejam elas para corrigir erros,
adaptar, melhorar ou inserir novas funcionalidades no software.
1.3. Modelo de ciclo de vida
A aplicação de um processo de software não se dá diretamente no desenvolvimento de
um software. A utilização de um modelo de processo de software permite focalizar aspectos
diferenciados de um mesmo processo de software. Há modelos que enfocam a entrega rápida
de um protótipo inicial do sistema ao usuário. Outros, por sua vez, orientam a total
especificação do sistema e uma única entrega ao cliente.
Um modelo de processo de software, segundo Sommerville (2007), é uma abstração de
um processo de software. Cada modelo representa um processo sob determinada perspectiva.
Ou seja, o modelo representa parcialmente um processo de software e não a sua totalidade.
É possível também entender modelo de processo de software (ou paradigma de
engenharia de software) como uma estratégia de desenvolvimento que abrange camadas de
processos, métodos e ferramentas na resolução de problemas. (PRESSMAN, 2002)
Existem na literatura inúmeros modelos de processos de software. O exemplo mais
clássico é o modelo em Cascata, proposto por Royce em 1970. Além dele, pode-se citar o
Desenvolvimento Evolucionário, o Desenvolvimento Orientado ao Reuso, o Desenvolvimento
Incremental, o Desenvolvimento Formal de Sistemas e os modelos ágeis, como SCRUM, a
Extreme Programming, o Feature Driven Development (FDD), entre outros.
20
Embora cada modelo apresente suas particularidades, é possível agrupá-los em dois
grandes grupos. O primeiro grupo engloba os modelos ditos tradicionais, e o segundo, os
modelos ditos ágeis.
Os modelos tradicionais caracterizam-se por serem baseados no modelo Cascata. A
principal característica do modelo Cascata é o seu enfoque linear e sequencial ao processo de
software. No Cascata, as fases que compõe o modelo devem ser executadas na ordem correta,
iniciando pela primeira e seguindo seqüencialmente até a última. O Cascata foi concebido de
outros processos de engenharia predecessores com a finalidade de orientar o desenvolvimento
de grandes produtos de software. Embora seja eficaz no desenvolvimento, é um modelo
burocrático e rígido que dá ao cliente pouca visibilidade do andamento do projeto. No grupo
dos métodos tradicionais encontram-se modelos como a Prototipação e suas variações, o
Desenvolvimento Incremental, o Espiral, o Processo Unificado (UP) e o Rational Unified
Process (RUP), entre outros.
Em suma, os modelos de desenvolvimento de software tradicionais orientam o
desenvolvimento de software por meio de uma estrutura bem definida de desenvolvimento,
cobrando disciplina e comprometimento com a metodologia por parte da equipe de
desenvolvimento. (RABELLO, 2006).
Já os modelos ágeis apresentam características consideravelmente diferentes em
relação aos tradicionais. A origem destes modelos baseia-se na crítica, por parte de
programadores e consultores, à burocracia que os modelos tradicionais impõem ao projeto de
desenvolvimento de um software.
Mais precisamente, o desenvolvimento ágil de software surgiu em fevereiro de 2001
com a formação da Agile Software Development Alliance (conhecida também como Agile
Alliance). Os fundadores foram 17 metodologistas que propuseram um manifesto com o
objetivo de encorajar a adoção de melhores meios de desenvolver software. Basicamente, o
manifesto é composto por quatro declarações de valores, que são:
a) Indivíduos e interações valem mais que processos e ferramentas.
b) Um software funcionando vale mais que documentação extensa.
c) A colaboração do cliente vale mais que a negociação do contrato.
d) Responder a mudanças vale mais do que seguir um plano.
21
Outra importante produção da equipe da Agile Alliance foi um conjunto de 12
princípios fundamentais que devem ser seguidos por qualquer metodologia ágil. A seguir está
sendo listado este conjunto de princípios segundo Ambler (2004).
1. A maior prioridade é satisfazer ao cliente mediante entregas de software de
valor em tempo hábil e continuamente.
2. Receber bem as mudanças de requisitos, mesmo em uma fase mais avançada
no desenvolvimento. Os processos ágeis direcionam as mudanças para obter vantagens
competitivas para o cliente.
3. Entregar software em funcionamento com frequência de algumas semanas a
alguns meses, de preferência na menor escala de tempo.
4. As equipes de negócio e de desenvolvimento devem trabalhar juntas
diariamente durante todo o projeto.
5. Construir projetos ao redor de indivíduos motivados. Dar-lhes o ambiente e o
apoio de que eles precisam e confiar neles para realizar o trabalho.
6. O método mais eficiente de levar informação a uma equipe de
desenvolvimento e fazê-la circular é a conversa cara a cara.
7. Ter o software funcionando é a principal medida de progresso.
8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários deveriam ser capazes de manter um ritmo constante
indefinidamente.
9. Atenção contínua a excelência técnica e a um bom projeto aumentam a
agilidade.
10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é
essencial.
11. As melhores arquiteturas, requisitos, projetos provêm de equipes organizadas.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz
e então se ajustar e adaptar seu comportamento.
Observa-se desta forma que a Engenharia de Software surgiu com a finalidade de
orientar e definir um processo de desenvolvimento de software bem estruturado com vistas a
controlar os problemas relacionados ao não cumprimento de prazos e aos custos, dentre
outros. Desta forma, o processo define um conjunto básico de atividades que levam a
construção de um produto de software. A execução de um processo de software não se da
nativamente, mas sim através de um modelo de processo, que nada mais é que uma abstração
22
particular do próprio processo. No âmbito de modelos de processos de software, existem os
modelos prescritivos, oriundos do Cascata, que implementam um conjunto de atividades
rigidamente definidas e burocráticas, e os ágeis, originados de uma oposição aos métodos
prescritivos, que enfatizam o desenvolvimento rápido, a simplicidade, a presença constante do
cliente e uma boa comunicação.
23
2. REQUISITOS
Para iniciar-se o desenvolvimento de um software, utilizando um modelo qualquer de
processo de software, uma das primeiras atividades a ser realizada é compreender quais são as
necessidades e expectativas do cliente em relação ao produto a ser desenvolvido. As
informações recolhidas neste processo representam os requisitos que o software deve atender.
Especifica-se um software em termos de seus requisitos. Segundo Sommerville
(2007), “os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e
suas restrições operacionais”. Os requisitos representam necessidades que os clientes
apresentam e buscam sanar através do sistema a ser desenvolvido ou modificado.
Os requisitos de um sistema, como explica Sommerville (2007), podem ser
apresentados em diferentes níveis de abstração. Ou seja, em um extremo, um requisito
expressa simplesmente um serviço ou uma restrição que o sistema deve apresentar de forma
abstrata. Em outro extremo, um requisito define de forma detalhada e específica uma função
do sistema.
Os diferentes níveis de abstração dos requisitos de um sistema, desde o mais abstrato
até o mais específico, são de fundamental importância ao processo de desenvolvimento de
software. Jacobson, Booch e Rumbaugh (1999), em seu livro The Unified Software
Development Process afirmam que a coleta de requisitos possui dois objetivos: encontrar os
verdadeiros requisitos e representar estes requisitos de modo satisfatório para os usuários,
clientes e desenvolvedores. Ainda segundo os autores, os verdadeiros requisitos são aqueles
que quando implementados trarão o valor esperado para os usuários. Já a representação dos
requisitos visa descrevê-los de uma forma que estes possam ser entendidos por usuários e
clientes, além dos desenvolvedores.
24
No desenvolvimento de um sistema, os requisitos podem surgir de várias fontes. A
principal delas, de fato, é o cliente. Mas também é possível extrair requisitos do domínio,
como por exemplo, as leis fiscais no caso do desenvolvimento de um sistema contábil. Outro
exemplo seria uma restrição de projeto que afirma que o software deva apresentar um taxa de
erros menor que 0,001%. Todas as situações apresentadas representam necessidades que o
sistema deve atender. Todavia, cada um dos requisitos acima especificados aponta
características essencialmente distintas (de diferente enfoque). Em vista dessa separação, é
possível classificar os requisitos em grupos distintos.
Segundo Sommerville (2007), os requisitos podem ser classificados como requisitos
de usuário e requisitos de sistema.
2.1. Requisitos de usuário
Os requisitos de usuário são declarações em linguagem natural e/ou em diagramas
acerca de serviços e restrições que o sistema deve atender. O objetivo é oferecer aos usuários
uma descrição compreensível e não técnica dos requisitos funcionais e não-funcionais do
sistema, de modo que haja compreensão dos mesmos.
Um grande problema encontrado em expressar requisitos em linguagem natural é a
dificuldade em se garantir precisão na descrição do requisito de modo a evitar ambiguidades.
Também é comum a ocorrência de confusão na descrição dos requisitos em razão da
condensação de vários requisitos em um texto único, ou mesmo, quando falta compreensão
dos requisitos por parte dos responsáveis pela criação do documento de requisitos a ser
apresentado ao usuário.
2.2. Requisitos de sistema
Os requisitos de sistema definem detalhadamente as funções, os serviços e as restrições
operacionais do sistema. Normalmente os requisitos de sistema são escritos na forma de um
contrato entre o cliente e a equipe de desenvolvimento.
Resumidamente, os requisitos de sistema são versões estendidas dos requisitos de
usuário que são utilizados pelos engenheiros de software como ponto de partida para o projeto
25
do sistema. Contudo, os requisitos de sistema não devem descrever como o sistema pode ser
implementado e projetado. Devem apenas detalhar e explicar como os requisitos de usuário
serão fornecidos pelo sistema.
Sommerville (2007) classifica os requisitos de sistema em três classes distintas:
requisitos funcionais, requisitos não funcionais e requisitos de domínio.
2.2.1. Requisitos Funcionais
“Os requisitos funcionais de um sistema descrevem o que o sistema deve fazer”
(SOMMERVILLE, 2007). A principal característica que os requisitos funcionais apresentam
é o alto grau de detalhamento, especificando cada função que o sistema deve implementar em
termos de entrada, saída, exceções, etc.
A especificação de requisitos funcionais deve abranger todos os serviços exigidos pelo
usuário (completeza) de forma não contraditória. Todavia, teoria e prática neste caso
mostram-se ligeiramente distantes. Ao especificar requisitos funcionais de um sistema com
dimensões consideravelmente grandes e de domínio complexo é praticamente impossível
atingir, de fato, consistência e completeza. A origem dessa dificuldade recai nos aspectos
humanos do processo. Uma explicação é a ocorrência de erros e omissões ao se redigir o
requisito, mediante dificuldades de entendimento que o escopo do sistema a ser desenvolvido
apresenta. Outro caso, mais convencional, é a falta de unanimidade entre os próprios
envolvidos (stakeholders) na descrição de suas necessidades.
2.2.2. Requisitos não-funcionais
Os requisitos não funcionais são aqueles requisitos que não apresentam ligação com
funcionalidades que o sistema precisa apresentar. Eles relacionam-se com propriedades
emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento.
Uma falha na especificação de um requisito não funcional pode afetar o sistema de forma
acentuada, podendo causar até o seu descarte. Um exemplo de tal afirmação é um requisito de
confiabilidade de um sistema crítico de controle de uma usina nuclear, que não é atingido pelo
sistema em simulações de operação feitas. Devido ao alto grau de exigência de confiabilidade
26
requisitado, o sistema não poderá entrar em operação existindo grande probabilidade de
descarte do mesmo.
Sommerville (2007) divide os requisitos não-funcionais em três grupos, a saber,
requisitos de produto, requisitos organizacionais e requisitos externos.
a) Requisitos de produto: especificam o comportamento do produto. Desempenho,
rapidez de execução e requisitos de confiabilidade fazem parte deste grupo.
b) Requisitos organizacionais: requisitos advindos de políticas e procedimentos
organizacionais tanto do cliente quanto do desenvolvedor.
c) Requisitos externos: Requisitos de interoperabilidade entre sistemas, requisitos
referentes às leis e a questões de caráter ético.
A figura 1 apresenta os tipos de requisitos não-funcionais segundo Sommerville
(2007).
Figura 1: Tipos de requisitos não funcionais
Fonte: Sommerville(2007), pg. 82.
2.2.3. Requisitos de domínio
Os requisitos de domínio fazem referência ao domínio da aplicação. O domínio, em
suma, representa a esfera de ação, o âmbito dentro do qual o sistema atua e é influenciado.
27
Segundo Sommerville (2007), “os requisitos de domínio podem ser novos requisitos,
podem restringir requisitos funcionais já existentes ou estabelecer a forma como cálculos
específicos devem ser gerados”.
Um exemplo básico de requisito de domínio pode ser o cálculo da velocidade média
que o software de controle de um trem deve fazer. Tal cálculo faz parte do domínio da Física.
É possível especificá-lo conforme mostra a figura 2:
Figura 2: Especificação de um requisito de domínio
Fonte: Primária
2.3. Especificação de requisitos e os problemas relacionados
Segundo Paula Filho (2001), “a Especificação dos Requisitos do Software é o
documento oficial de descrição dos requisitos de um projeto de software”. A especificação,
também conhecida como Documento de Requisitos, pode fazer referência a um módulo do
sistema ou a todo ele. Toda a especificação deve, segundo o mesmo autor, apresentar as
seguintes características:
a) Funcionalidade: descrição do software em termos de função. A pergunta chave é
“O que o software deve fazer?”.
b) Interfaces externas: maneira pela qual o software interage com as pessoas, com o
hardware, com outros sistemas e produtos.
c) Desempenho: especificação da velocidade de processamento, o tempo de resposta
e outros parâmetros requeridos pela aplicação.
28
d) Restrições impostas pela aplicação: restrições de padrões, linguagem de
programação, ambientes de operação, limites de recurso, etc.
e) Outros atributos: aqui são abordados aspectos de portabilidade, manutenibilidade
e confiabilidade.
Toda especificação de requisitos passa por uma etapa de elaboração onde, de fato, é
feita a formalização de todas as considerações acerca das necessidades do software, tomando
o ambiente de operação como base de análise. Uma boa especificação deve ser adaptável o
suficiente para atender a evolução dos requisitos no decorrer do tempo, bem como limitar-se a
descrever apenas os requisitos que o software deve atender (salvo exceções onde se faça
necessário especificar aspectos de desenvolvimento).
A seguir, cada um dos itens levantados acima são abordados e contextualizados
segundo as concepções de Paula Filho (2001).
2.3.1. Elaboração
Toda a especificação de requisitos (ou documento de requisitos) passa pela fase de
elaboração. Os membros da equipe do projeto do software são responsáveis pelo
desenvolvimento da elaboração com a indispensável participação de um ou mais usuários
chaves (ou clientes). Estes usuários ficam responsáveis, juntamente com a equipe do projeto,
pela correta especificação das necessidades que o software deve atender.
2.3.2. Ambiente
Quando o software fizer parte de um sistema mais amplo, os requisitos do software
estão contidos dentro de uma especificação mais ampla, normalmente uma Especificação dos
Requisitos do Sistema. Nessa situação o software é apenas um dos componentes do sistema e
não todo ele. Os requisitos do sistema se estendem a todas as necessidades dos componentes e
das interfaces que devem ser implementadas entre os mesmos.
Assim, todas as características requeridas para o ambiente considerado devem ser
especificadas a fim de assegurar o sucesso do projeto.
29
2.3.3. Evolução
A natureza dos requisitos é mutável. A mudança dos requisitos deve ser algo esperado
em qualquer projeto de software. Grande parte dos modelos de processo de software tem sua
estrutura moldada em favor da adaptação às mudanças nos requisitos, principalmente os
modelos ágeis. Nos modelos tradicionais, como o Cascata, uma mudança nos requisitos em
fases de desenvolvimento mais avançadas pode resultar em grandes problemas de ordem
financeira e de cronograma.
A evolução dos requisitos deve ser gerenciada, de modo que a alteração dos requisitos
seja controlada, minimizando qualquer problema decorrente.
O modelo CMMI (Capability Maturity Model Integration), um dos modelos de
melhoria de qualidade de processo mais reconhecidos no mundo, recomenda uma área de
processo voltada especificamente para gerenciamento de requisitos (Requirements
Management - REQM). Segundo Ahern (2006), para gerenciar requisitos, os profissionais
precisam desenvolver e entender o que estes requisitos significam antes de fazer qualquer
coisa com os mesmos. Depois de entendidas e confirmadas, todas as mudanças devem ser
gerenciadas, incluindo a manutenção de um histórico de mudanças e a evolução dos impactos
destas mudanças.
O gerenciamento de requisitos permite identificar inconsistências entre os requisitos e
os planos de projeto e trabalho dos produtos (software), dando condições para a execução de
ações corretivas na intenção de eliminá-las.
2.3.4. Limites
A Especificação dos Requisitos não deve incluir decisões de projeto e de desenho do
sistema, desde que estes não figurem como requisições explícitas que o cliente faz à equipe de
projeto. Para Paula Filho (2001), uma especificação deve se ater a três elementos
fundamentais:
a) Definir de forma completa e correta os requisitos do produto a ser desenvolvido.
b) Não descrever qualquer detalhe de desenho interno do sistema.
30
c) Não descrever aspectos gerenciais do projeto.
2.3.5. A problemática relacionada
Especificar requisitos utilizando linguagem natural pode trazer sérios problemas de
interpretação. A multiplicidade de interpretações possíveis para um mesmo enunciado
corroboram para erros de projeto. Sommerville (2007) aponta três agravantes do uso da
linguagem natural na especificação de requisitos de sistema:
a) A compreensão da linguagem natural depende do uso das mesmas palavras
buscando o mesmo significado tanto para leitores quanto para os elaboradores da
especificação.
b) A flexibilidade dada pela linguagem natural permite que seja escrito a mesma
coisa de várias formas distintas.
c) Difícil padronização.
Mesmo na especificação de requisitos de usuário, para os quais o uso da linguagem
natural aparentemente seria apropriado, deve-se ter cuidados especiais. Sommerville (2007)
recomenda o uso consistente da linguagem natural, utilizando ressaltos no texto e evitando ao
máximo o uso de jargões de informática.
Como forma de amenizar os problemas referentes à utilização da linguagem natural na
especificação de requisitos, principalmente os requisitos de sistema que necessitam de um
maior nível de padronização, pode-se utilizar um esquema padronizado de especificação.
Através da padronização da especificação reduz-se consideravelmente o escopo de
interpretações possíveis a um mesmo requisito. Quando fala-se em requisitos de sistema, esta
propriedade mostra-se de extrema valia, já que normalmente requisitos de sistema apresentam
um nível de detalhamento consideravelmente alto.
Sommerville (2007) apresenta uma solução de padronização de especificação de
requisitos utilizando um formulário padrão. Soluções como a criação de um glossário de
termos suscetíveis a mais de uma interpretação também são funcionais e recomendadas. A
figura 3 apresenta um exemplo de especificação de requisitos.
31
Figura 3: Especificação de requisitos utilizando um formulário padrão
Fonte: Sommerville (2007), pag. 89.
Também é possível especificar requisitos utilizando-se de linguagens gráficas. Os
diagramas auxiliam na compreensão dos requisitos e na redução de ambigüidades. O
diagrama de fluxo de dados, por exemplo, é uma ferramenta gráfica que dá aos
desenvolvedores condições de avaliar o fluxo das informações em relação às funções
implementadas e às entradas informadas. A figura 4 apresenta um Diagrama de Fluxo de
Dados, contendo a entidade externa Farmacêutico, os processos “Manter dados de
medicamentos”, “Manter dados de diagnósticos”, “Manter dados de materiais”, “Manter
dados de recomendações” e os depósitos de dados associados (Medicamentos, Diagnósticos,
Materiais, Recomendações).
32
6
Manter dados de medicamentos
Farmaceutico
5 Medicamentos
6 Diagnósticos
7
Manter dados de diagnósticos
7 Materias
10
Manter dados de materiais
8 Recomendações
9
Manter dados de recomendações
Figura 4: Exemplo de um Diagrama de Fluxo de Dados (DFD)
Fonte: Primária
A Unified Modeling Language (UML) é uma metodologia gráfica desenvolvida, dentre
outras coisas, para especificar requisitos de software. Os diagramas de casos de uso permitem
descrever funcionalidades do sistema a ser desenvolvido de forma clara e específica,
apresentando as relações estabelecidas entre os atores (entidades que atuam sobre o sistema) e
as funcionalidades do software (seus casos de uso).
A figura 5 apresenta os casos de uso para o responsável pelo almoxarifado (ator) em um
sistema de controle de estoque.
Figura 5: Diagrama de Casos de Uso
Fonte: Primária
33
2.4. Qualidade dos Requisitos
A qualidade dos requisitos elicitados determina profundamente a qualidade do produto
de software desenvolvido. Requisitos incompletos e inconsistentes comprometem o
entendimento do problema, podendo causar desvios custosos durante o desenvolvimento do
software.
Paula Filho (2001) apresenta oito características necessárias a uma Especificação de
Requisitos para que a mesma apresente qualidade. Segundo o autor é necessário que uma
especificação seja correta, precisa, completa, consistente, priorizada, verificável, modificável
e rastreável para apresentar de fato qualidade. A seguir, cada um destes atributos de qualidade
é abordado separadamente.
2.4.1. Correção
“Uma Especificação dos Requisitos está correta se todo requisito presente nela
realmente é um requisito do produto a ser construído” (PAULA FILHO, 2001). Os requisitos
devem expressar de forma correta as necessidades do cliente, de modo que recebam a
aprovação formal do mesmo.
2.4.2. Precisão
A precisão na Especificação dos Requisitos é obtida se cada requisito apresentar
apenas uma única interpretação, tanto pelo cliente quanto pelos desenvolvedores. Para obter a
precisão pode-se utilizar técnicas, como as apresentadas na seção 2.3.5, que trata de
problemas relacionadas à especificação de requisitos.
34
2.4.3. Completeza
Uma Especificação dos Requisitos não pode conter pendências. Ela deve possuir, para
ser considerada completa, todos os requisitos significativos referentes à funcionalidade,
desempenho, restrições de desenvolvimento, atributos e interface. Deve também definir todas
as respostas do software para todas as entradas possíveis, válidas e inválidas, em todas as
situações possíveis.
Vale ressaltar que, dificilmente em um sistema complexo, consegue-se atingir total
completeza nos requisitos. O escopo do software muitas vezes impossibilita o total
conhecimento e especificação de todas as necessidades, eventos e entradas possíveis e
necessárias.
2.4.4. Consistência
A consistência em uma especificação é obtida quando não existem conflitos entre os
requisitos.
Os conflitos podem ser basicamente de três tipos:
a) Conflitos entre características do mundo real: são exemplos deste tipo de conflito
formatos de relatórios, cores, etc.
b) Conflitos de ordem lógica ou temporal: quando dois ou mais requisitos se
contradizem na especificação da ordem de ocorrência de determinada ação.
c) Conflitos de definição: quando um ou mais verbetes são utilizados para designar
um mesmo objeto do mundo real.
2.4.5. Priorização
A priorização dos requisitos se dá em duas perspectivas: importância e estabilidade.
A estabilidade estima a probabilidade de um requisito mudar no decorrer do projeto.
Quanto à importância, pode-se ter requisitos essenciais, cuja necessidade de atendimento é
crítica; requisitos desejáveis, cujo atendimento aumenta o valor do produto e requisitos
opcionais, que podem ser atendidos se houver tempo hábil e recursos disponíveis.
35
2.4.6. Verificabilidade
Para uma Especificação de Requisitos ser verificável é necessário que:
a) Todos os requisitos nela contidos sejam verificáveis.
b) Exista um processo para verificar requisitos que seja finito, que tenha custo
compensador, que possa ser executado por pessoas ou máquinas, e que mostre a
conformidade final do requisito.
2.4.7. Modificabilidade
Uma especificação é modificável se a sua estrutura for maleável o suficiente para que
uma alteração seja executada de forma fácil, completa e consistente. Para alcançar a
modificabilidade, uma especificação requer uma organização coerente, feita através de índices
e referências cruzadas, ausência de redundância entre os requisitos e definição separada dos
mesmos no texto.
2.4.8. Rastreabilidade
A rastreabilidade de um requisito pressupõe que seja possível determinar seus
antecedentes e conseqüentes de maneira simples, ou seja, que se possa determinar, em relação
a um dado requisito, quais são os requisitos afetados por ele e quais o afetam dentro da
Especificação de Requisitos. A rastreabilidade dos requisitos permite, segundo Rational
Unified Process (2009), que seja possível:
a) Compreender a origem dos requisitos.
b) Gerenciar o escopo do projeto.
c) Gerenciar mudanças nos requisitos.
d) Avaliar o impacto no projeto da mudança em um requisito.
e) Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar,
talvez o requisito não seja atendido).
36
f) Verificar se todos os requisitos do sistema são desempenhados pela
implementação.
g) Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.
Paula Filho (2001) apresenta dois tipos distintos de rastreabilidade, um denominado
rastreabilidade para trás e outro chamado de rastreabilidade para frente. A rastreabilidade para
frente permite localizar quais os resultados do desenvolvimento são afetados pelo requisito
considerado. Já a rastreabilidade para trás permite encontrar a origem de cada requisito.
Conhecer as necessidades do cliente e desenvolver um software que realmente as atenda
é o principal ingrediente para o sucesso de um projeto de desenvolvimento. De fato, o
processo de extração dos requisitos é complexo e sujeito a inúmeros percalços, uma vez que é
uma atividade extremamente centrada na interação com pessoas. Sabe-se que pessoas distintas
apresentam uma visão diferenciada sobre um mesmo aspecto do ambiente e cabe ao analista
encontrar um ponto em comum. É muito importante que este processo de descoberta dos
requisitos gere uma especificação de requisitos de qualidade, que de fato reflita as reais
necessidades do cliente.
Tanto a rastreabilidade quanto os demais itens que definem teoricamente a qualidade
dos requisitos são preocupações de uma importante subárea da Engenharia de Software
denominada Engenharia de Requisitos. A ER engloba um conjunto de técnicas formais de
coleta, análise, documentação e gerência de requisitos de software que visa criar e manter um
documento de requisitos. O capítulo 3, que segue, aborda especificamente a Engenharia de
Requisitos e suas diversas atividades.
37
3. ENGENHARIA DE REQUISITOS
Erros na especificação de requisitos são muito custosos na indústria do software.
Segundo a Borland®
Software Corporation (2009), em média 40% do esforço durante um
projeto de software deve-se a retrabalho. Quem mais contribui para este valor são os erros de
requisitos, representando mais da metade do total. Mas qual é a explicação para tal fato? A
figura 6 faz uma representação clássica da dificuldade de entendimento entre as partes
envolvidas em um projeto de um software.
Figura 6: Dificuldades de compreensão
Fonte: http://wagnergomes.files.wordpress.com/2008/05/levantamentorequisitos.jpg
A Engenharia de Requisitos surgiu para tentar contornar problemas relacionados com a
especificação de requisitos de um software como os apresentados na figura 6. Ela se apresenta
como uma disciplina da Engenharia de Software que se preocupa com a elicitação dos
38
requisitos das fontes de informação disponíveis, e posterior análise, verificação,
documentação e gerenciamento dos mesmos. A ER fornece um mecanismo adequado para
atender o que o cliente deseja. O processo de engenharia de requisitos visa criar e manter uma
especificação dos requisitos com todos os atributos de qualidade (correteza, precisão,
completeza, consistência, priorização, verificabilidade, modificabilidade e rastreabilidade).
Pressman (2002) define a Engenharia de Requisitos como
“O uso sistemático de princípios, técnicas, linguagens e ferramentas comprovadas
para a análise, documentação, evolução continuada das necessidades do usuário e
especificação do comportamento externo de um sistema para satisfazer as
necessidades do usuário, que sejam efetivas em termos de custo”.
Sommerville (2007) divide o processo de Engenharia de Requisitos em quatro
subprocessos. Estes subprocessos relacionam-se com a avaliação da real utilidade do sistema
para o cliente (estudo da viabilidade), obtenção dos requisitos (elicitação e análise), conversão
destes requisitos em alguma forma padrão (especificação) e a averiguação de se os requisitos
especificados de fato definem o sistema desejado pelo cliente (verificação).
A figura 7 apresenta o processo de Engenharia de Requisitos proposto por Sommerville
(2007).
Figura 7: Processo de Engenharia de Requisitos
Fonte: Sommerville (2007), pg. 50.
39
Pressman (2002), por sua vez, entende que a engenharia de requisitos é um conjunto de
seis passos distintos, que são a elicitação dos requisitos, análise e negociação de requisitos,
especificação de requisitos, modelagem do sistema, validação de requisitos e gestão de
requisitos.
Embora Sommerville (2007) e Pressman (2002) apresentem um número distinto de
etapas para definir a Engenharia de Software, pode-se observar que é meramente uma questão
de agrupamento. O processo de Engenharia de Requisitos é de consenso.
A seguir serão apresentadas as etapas da Engenharia de Requisitos mesclando-se os
conceitos apresentados por ambos os autores.
3.1. Estudo da Viabilidade
O estudo da viabilidade visa, ao final do processo, elaborar um relatório que informa ao
cliente se é ou não é viável prosseguir com as próximas etapas da Engenharia de Requisitos.
Para iniciar-se o estudo da viabilidade é necessário compreender os requisitos preliminares do
negócio, ter uma descrição (esboço) superficial do sistema e também entender como o sistema
proposto irá apoiar os processos de negócio da empresa.
Para Sommerville (2007), o estudo de viabilidade deve responder três questões
importantes:
a) O sistema contribui para os objetivos da organização?
O sistema deve ter sua utilidade vista de forma clara e o seu uso deve contribuir
para os objetivos da organização. Do contrário, o software nasce sem nenhuma
utilidade.
b) O sistema pode ser implantado com a tecnologia atual e dentro das restrições
definidas de custo e prazo?
Verifica-se se a tecnologia disponibilizada pela organização, os recursos
financeiros a serem despendidos e o tempo estipulado para o desenvolvimento do
software permitem de fato o seu desenvolvimento.
40
c) O sistema pode ser integrado a outros sistemas já implantados?
Normalmente o novo software precisa comunicar-se com os sistemas legados
(sistemas já existentes e em funcionamento). Verifica-se, portanto, se a
comunicação entre os sistemas legados e o novo é possível.
É de vital importância que as fontes selecionadas para extração de informações, tanto no
estudo de viabilidade, quanto nos demais subprocessos da Engenharia de Requisitos, sejam
fidedignas. Do contrário, omissões e/ou erros podem se propagar para etapas mais adiantadas
do desenvolvimento, podendo comprometer seriamente todo o projeto.
Pressman (2002) coloca o estudo da viabilidade dentro da etapa de Elicitação de
Requisitos, sendo um dos produtos de trabalho da mesma a declaração de viabilidade para o
sistema em questão.
3.2. Elicitação e análise dos requisitos
Tendo o relatório de viabilidade do sistema homologado a real utilidade e
possibilidade de desenvolvimento do sistema, segue-se para a etapa de elicitação e análise dos
requisitos.
Nesta etapa, os engenheiros trabalham junto aos stakeholders (envolvidos) do sistema
a fim de aprender o que o sistema deve fazer, como deve fazer e quais são as restrições
impostas a ele.
Aparentemente, a elicitação de requisitos apresenta-se como uma atividade simples de
ser realizada. Basta que o analista peça ao cliente o que ele deseja que o software faça e está
feito. Certo? Não, totalmente errado!
A elicitação é um processo complicado, que impõe dificuldade aos profissionais que a
executam. Inúmeras situações problemáticas podem ocorrer durante a elicitação.
As maiores dificuldades encontradas envolvem aspectos de comunicação. Sommerville
(2007) elenca cinco itens que normalmente originam problemas durante a elicitação, enquanto
que Pressman (2002) os divide em três grupos distintos, a saber, problemas de escopo,
problemas de entendimento e problemas de volatilidade. A seguir serão apresentados os
principais problemas encontrados durante esta etapa segundo os atores citados:
41
a) Stakeholders não sabem o que querem do sistema computacional especificamente,
tendo dificuldade de articular seus pedidos ou mesmo fazendo pedidos
demasiadamente custosos de serem desenvolvidos. Neste caso, se tem um problema
de entendimento e de escopo, pois além de não ser sabido quais as funções que o
sistema deve executar, existe dificuldade na identificação das necessidades.
b) Os stakeholders expressam os requisitos em seus próprios termos, deixando
muitas vezes implícitos termos técnicos de sua rotina. Um típico problema de
entendimento.
c) Diferentes stakeholders possuem diferentes requisitos, cada qual expresso de uma
forma distinta. O analista precisa encontrar e gerenciar pontos comuns e conflitos
existentes nos requisitos. Apresenta-se como um problema de entendimento.
d) Fatores políticos da organização podem ter forte influência nos requisitos
elicitados. Normalmente, quando problemas como estes ocorrem o escopo do
sistema tenta ser manipulado para beneficiar pessoas específicas, ou seja, os
envolvidos tentam criar um sistema que os favoreça.
e) O ambiente do sistema é naturalmente mutável. Em decorrência, os requisitos do
sistema também tendem a se modificar no tempo. Resumindo, os requisitos são
voláteis.
A análise e elicitação é um subprocesso composto por várias atividades. Sommerville
(2007) a divide em quatro atividades distintas que são: a obtenção de requisitos, classificação
e organização de requisitos, priorização de requisitos e documentação de requisitos.
Na atividade de Obtenção de Requisitos o objetivo é reunir informações sobre o
sistema a ser desenvolvido e os sistemas já existentes das diferentes fontes de informação
existentes, tais como documentos, stakeholders, aspectos de domínio, etc. Esta atividade
possui forte interação entre os analistas e os stakeholders do sistema. Pontos de vista do
sistema são definidos. Ou seja, a visão apresentada por cada fonte de informação acerca do
sistema representa um ponto de vista específico. Um ponto de vista é olhar o sistema sob
determinada perspectiva. Embora eles sendo distintos, muitos dos requisitos apresentados por
pontos de vista distintos tendem a apresentar características comuns.
Na obtenção dos requisitos são empregadas técnicas que visam diminuir os problemas
de escopo e de entendimento durante a etapa. Exemplos de técnicas de elicitação são
etnografia, casos de uso (UML), entrevista, questionário, etc.
Na Classificação e Organização de Requisitos os requisitos recolhidos são organizados
em conjuntos coerentes, considerando-se a relação existente entre os mesmos.
42
Na Priorização e Negociação de Requisitos os requisitos são priorizados, ou seja, são
postos numa listagem por ordem de prioridade, os conflitos entre requisitos são buscados e
uma resolução aos mesmos é aplicada. Pressman (2002) sugere uma abordagem interativa
para resolver conflitos, onde os clientes, usuários e analistas expõem suas considerações a fim
de encontram um ponto de acordo comum, de modo que cada um alcance certo grau de
satisfação.
Na Documentação de Requisitos são produzidos documentos de requisitos, tanto
formais quanto informais.
3.3. Especificação dos Requisitos
Pode-se especificar os requisitos de diferentes maneiras. É possível fazê-la através de
um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de
cenários de uso, um protótipo ou qualquer combinação dos anteriores (PRESSMAN, 2002).
A especificação adapta-se ao tipo de sistema a ser desenvolvido. Para sistemas grandes,
de difícil entendimento, pode ser necessário utilizar mais de uma forma de especificação,
enquanto que para um sistema de domínio conhecido, e de pequeno porte, uma coleção de
cenários de uso é suficiente.
A especificação de um sistema tem a finalidade de “descrever a função e o desempenho
de um sistema baseado em computador e as restrições que vão governar o seu
desenvolvimento” (PRESSMAN, 2002).
3.4. Validação dos Requisitos
“A validação dos requisitos dedica-se a mostrar que os requisitos realmente definem o
sistema que o usuário deseja” (SOMMERVILLE, 2007). Na validação examina-se a
especificação dos requisitos previamente criada a fim de encontrar ambiguidades,
inconsistências, omissões e erros, fazendo as correções necessárias. Também é avaliada a
conformidade entre as normas de projeto, processo e produto previamente estabelecidos e os
produtos de trabalho obtidos.
43
A validação é importante porque desenvolver um requisito incorreto pode levar a
custos excessivos no contexto de um projeto de desenvolvimento de software. Estes custos
aumentam quase que exponencialmente à medida que o desenvolvimento do sistema avança,
como pode ser observado na figura 8.
Figura 8: Custos de erros nos requisitos
Fonte: Adaptação do vídeo disponível em
http://www.borland.com/media/en/edm/rdm_solution_demo/rdm.html
Os requisitos devem ser validados tomando por base os aspectos de qualidade de
requisitos conforme apresentado na seção 2.4.
3.5. Gerenciamento de Requisitos
O gerenciamento de requisitos é uma atividade que visa controlar o problema da
volatilidade dos requisitos. Ou seja, a necessidade de mudança em um software persiste
durante todo o seu ciclo de vida.
A mudança nos requisitos não pode ser vista como um problema, mas sim como uma
característica inerente ao próprio software. Os requisitos mudam porque a evolução natural
também se aplica a eles. Muito mais o software deve se adaptar ao meio do que o inverso.
44
O objetivo do gerenciamento de requisitos é compreender e controlar as mudanças dos
requisitos de sistema. É necessário ter condições de acompanhar os requisitos
individualmente, manter as ligações entre os requisitos dependentes e quando necessário
permitir determinar o impacto de uma mudança de um requisito em relação aos demais.
(SOMMERVILLE, 2007).
Muito embora os objetivos do gerenciamento de requisitos sejam os mesmos, cada
metodologia de desenvolvimento de software o realiza de maneira particular, o que é uma
característica aplicável à Engenharia de Requisitos como um todo.
O que deve ser respeitado, contudo, em qualquer abordagem dada ao processo de ER é
o seu objetivo fundamental: gerar e manter uma especificação de requisitos de qualidade.
Desta forma, seja em uma metodologia ágil ou seja em uma metodologia prescritiva, o
processo de Engenharia de Requisitos deve focar a construção de um documento de requisitos
que defina realmente o software que o cliente necessita. A forma de construir a especificação
de requisitos também não segue um padrão. Em alguns modelos, por exemplo, a especificação
de requisitos é feita através de um documento detalhado e formal (Cascata), enquanto em
outros como a Extreme Programming, a especificação dos requisitos é feita através de
estórias, escritas pelo próprio cliente e destituídas de qualquer regra formal para a escrita. O
próximo capítulo trata exatamente da relação entre a formalidade teórica pregada pela
Engenharia de Requisitos, fortemente presente nos métodos prescritivos, e a “liberdade”
apregoada pela Extreme Programming.
45
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS
Os modelos de desenvolvimento de software estão classificados em dois grandes
grupos, conforme descrito na seção 1.3, que são os modelos prescritivos ou tradicionais e os
modelos ágeis.
Modelos prescritivos seguem uma linha pouco flexível no desenvolvimento do
software. Tomando por exemplo o modelo Cascata, que foi o primeiro modelo desenvolvido,
observa-se uma clara sequência inflexível de atividades que são executadas ao longo do
tempo. A figura 9 apresenta a estrutura do Cascata segundo Sommerville (2007).
Figura 9: Modelo Cascata
Fonte: Sommerville (2007)
Basicamente, os modelos prescritivos se valem de três premissas básicas (FREIRE,
2009), que são:
46
a) É necessário realizar uma análise detalhada dos requisitos antes de projetar a
arquitetura de um sistema.
b) É necessário realizar um estudo detalhado da arquitetura do sistema antes de
iniciar a implementação.
c) É necessário testar completamente o sistema antes de colocar em produção o
software.
Desenvolver software seguindo estas premissas é perfeitamente possível. É tão
possível que muitos projetos de desenvolvimento de software utilizam ainda hoje modelos
prescritivos. Todavia, o desenvolvimento tradicional apresenta alguns problemas conforme
explica Freire (2009). Segundo o autor, os métodos tradicionais supõem que seja possível
prever o futuro, dada a grande quantidade de estudos e documentações realizadas antes da
realização de qualquer implementação. Outro ponto negativo é a pouca participação do cliente
no projeto, que muitas vezes participa apenas nas etapas de elicitação dos requisitos e de
implantação do software. O terceiro problema apontado refere-se à burocracia que tais
modelos impõem ao projeto. Um grande número de documentos é gerado a cada etapa, sendo
que os mesmos identificam o grau de avanço do projeto. Trocando em miúdos, o progresso é
indicado pela burocracia!
As metodologias ágeis surgiram então como uma nova forma de desenvolver software
de maneira mais eficiente e menos burocrática. Tendo como marco o manifesto ágil de 2001,
os métodos ágeis orientam-se por um conjunto de princípios, conforme apresentados na seção
1.3 que tratam aspectos tanto humanos quanto técnicos do desenvolvimento de software.
Dentre as metodologias ágeis existentes merece destaque a Extreme Programming,
como sendo umas das principais representantes desta nova filosofia.
A Extreme Programming foi desenvolvida por Kent Beck em um projeto sitiado na
DaimlerChrysler, no qual ele utilizou novos conceitos idealizados sobre o desenvolvimento
de software para dar forma ao novo modelo de desenvolvimento.
Beck (2004) define a Extreme Programming como “uma metodologia leve para times
de tamanho pequeno á médio, que desenvolvem software em face a requisitos vagos que se
modificam rapidamente” . Ainda segundo o autor, o que diferencia a XP das demais
metodologias refere-se aos seguintes pontos:
a) Feedback antecipado, concreto e contínuo derivado dos ciclos curtos de
desenvolvimento.
47
b) Abordagem incremental do projeto, que gera um plano geral que pode evoluir
com o passar do tempo.
c) Confiança nos testes automatizados escritos por programadores e clientes.
d) Confiança na comunicação oral, teste e código-fonte como formas de comunicar a
estrutura e o objetivo do sistema.
e) Confiança em um processo evolutivo que perdura tanto quanto o sistema em si.
f) Confiança na intensa colaboração de programadores com habilidades comuns.
g) Confiança em práticas que combinam tanto com os instintos a curto prazo dos
programadores quanto com os interesses de longo prazo do projeto.
A XP aponta quatro dimensões que podem ser melhoradas em qualquer projeto de
software. São elas a comunicação, a simplicidade, a coragem e o feedback. Estas quatro
dimensões são conhecidas como valores e são essenciais a qualquer projeto que venha a
utilizar a metodologia. Observa-se que os valores da XP têm grande enfoque nas pessoas, na
equipe de desenvolvimento, visto que é muito importante ter-se de fato uma equipe de
desenvolvimento e não apenas um grupo.
4.1. Valores
Os quatro valores fundamentais da XP representam o pilar sobre o qual toda a
metodologia sustenta-se. Todos eles, igualmente, apresentam-se como indispensáveis à
execução do modelo. A seguir é apresentado cada um deles, ressaltando-se a sua importância.
4.1.1. Comunicação
A comunicação é um requisito para o sucesso do desenvolvimento de software
(AMBLER, 2004). Comunicar é executar um processo no qual são trocadas informações
usando-se de algum recurso, como a fala, a escrita, os gestos, etc. Quando uma comunicação é
estabelecida, cria-se um canal por onde trafegam informações nos dois sentidos. Ou seja,
quem informa recebe informação também pelo mesmo caminho.
48
É importante ter comunicação em um projeto de software porque simplesmente a sua
falta é catastrófica. Desenvolvedores devem trocar informações entre si para resolver
problemas, propor melhorias, organizar o trabalho e também devem trocar informações com
os clientes de modo que ambos estejam de comum acordo sobre o que o software a ser
desenvolvido deve fazer.
4.1.2. Simplicidade
Simplicidade significa fazer de forma simples. A engenharia de software recomenda a
criação e manutenção de modelos, arquiteturas teóricas do funcionamento do software. Muitas
vezes, os desenvolvedores buscam desenvolver arquiteturas que predigam necessidades
futuras, ainda não citadas pelo cliente na esperança de tornar a manutenção um processo
menos “azedo”. Todavia, conforme Ambler (2004) coloca, ao tentar predizer necessidades
futuras, a probabilidade de ser uma decisão acertada é praticamente a mesma de ser uma
decisão errada. Em vista disso, desenvolver o software priorizando apenas as necessidades
expressas e necessárias da melhor forma possível é uma decisão melhor do que predizer o
futuro. Quanto à modelagem, o fato de ser simples não implica que ela é incompleta ou
inexistente. É perfeitamente possível ler um resumo de um livro e ter uma ótima idéia da obra
original, não é? É o mesmo que ocorre com os modelos. Eles existem na XP em virtude da
necessidade, e os mesmos são simplesmente simples.
4.1.3. Coragem
A coragem é o aspecto humano do desenvolvimento ágil. É necessário ter coragem
para manter-se firme na metodologia, quebrar dogmas antigos acerca do desenvolvimento. É
necessário ter coragem para acreditar nas pessoas, para admitir que as pessoas podem falhar e
que os problemas futuros serão resolvidos no futuro. A coragem é o tempero que dá sabor às
metodologias ágeis, em especial a XP.
49
4.1.4. Feedback
A única maneira de se obter a garantia de que o trabalho desenvolvido está correto é
recebendo feedback (retorno) do mesmo (AMBLER, 2004). O retorno, em um projeto de
software, pode ser a opinião de um cliente ao trabalhar com um novo release (entrega) do
software ou a opinião de um colega de equipe de desenvolvimento, por exemplo. É
importante ter retorno sobre os modelos abstratos do software, afinal eles orientam o
desenvolvimento. E a melhor maneira de obter retorno de um modelo é implementar o modelo
e fazer o cliente testá-lo.
4.2. Ciclo de Vida XP
O ciclo de vida de um projeto na Extreme Programming, segundo Ambler (2004),
pode ser definido conforme mostra a figura 10.
Figura 10: Diagrama esquemático da metodologia XP
Fonte: Ambler (2004), pg. 185
Conforme observa-se na modelo acima, o ciclo de vida de um projeto na metodologia
XP está dividido em cinco etapas (fases) distintas: exploração, planejamento, iterações para
entrega, produção e manutenção.
50
4.2.1. Fase de Exploração
A fase de exploração é a primeira fase do desenvolvimento XP. Nesta etapa são
coletadas as primeiras estórias de usuário e é definida uma base arquitetural para o sistema. É
importante ressaltar que o cliente é parte integrante da equipe XP durante todo o projeto,
sendo indispensável ao sucesso do mesmo.
As estórias de usuário desempenham um papel fundamental na metodologia XP, tal
qual a participação do cliente no projeto o é. Elas são escritas pelo cliente, usando linguagem
natural, nos termos que ele deseja utilizar. Não há qualquer restrição ou obrigatoriedade de
formalismos nas estórias de usuário. Elas são simplesmente escritas em cartões (story cards),
usando-se as ferramentas mais simples (papel e lápis).
As estórias de usuários representam os requisitos do sistema. Elas são utilizadas em
substituição a uma vasta documentação normalmente gerada pelo processo de especificação
de requisitos explicado na seção 3 (Engenharia de Requisitos). Apresentam um baixo
detalhamento, mas tem o foco voltado estritamente no que o cliente necessita.
Outras importantes utilidades que as estórias de usuário têm dentro metodologia XP
estão na estimativa de tempo do release e nos testes de aceitação, como será visto nas
próximas seções.
4.2.2. Fase de Planejamento
Nesta fase é realizado o trabalho de planejamento da versão. Juntamente com o cliente
é selecionado o menor e melhor conjunto de estórias de usuário que fará parte da versão
(AMBLER, 2004). Na filosofia XP existe o conceito de tempo ideal de desenvolvimento, que
nada mais é do que o tempo que será empregado para desenvolver uma estória de usuário se
não existirem distrações, adição de novas estórias, e, é claro, se o desenvolvedor souber
exatamente o que deve fazer. Em relação ao tempo ideal de desenvolvimento são feitas as
seguintes considerações:
a) O tempo de desenvolvimento estimado para a estória não alcança uma semana:
Deve-se combinar algumas estórias de modo a alcançar um tempo mínimo de uma
semana.
51
b) O tempo de desenvolvimento estimado para a estória excede três semanas: Deve-
se quebrar a estória em partes menores.
c) O tempo ideal de desenvolvimento de uma estória é de uma a três semanas.
Para cada estória de usuário é feito um cartão de tarefas, onde são descritas as
atividades necessárias para desenvolvê-la. A descrição pode ser feita de várias formas, desde
textualmente até utilizando-se desenhos esquemáticos, ficando a cargo do profissional a
escolha do modo de descrição.
Tendo em mãos as estórias de usuário conjuntamente com os cartões de tarefas é
possível estimar o trabalho necessário para implementá-las com maior precisão.
4.2.3. Fase de iterações para entrega
A fase de iterações para entrega é o momento, dentro de um projeto XP, em que é
despendido o maior esforço em termos de desenvolvimento (modelagem, programação, teste e
integração).
Inicialmente é feito um planejamento da iteração levando-se em conta as estórias de
usuário selecionadas para serem desenvolvidas na fase corrente. A estimativa de tempo se dá
pela divisão de cada estória de usuário em tarefas. Inicialmente, o cliente prioriza quais são as
estórias de usuário que podem ser imediatamente implementadas para fornecer suporte útil ao
negócio (SOMMERVILLE, 2007). Feito isso, segue-se com o desenvolvimento das estórias
de usuário. O desenvolvimento apresenta particularidades interessantes na filosofia XP. A
primeira delas é que grande parte da modelagem ocorre em curtas reuniões realizadas em pé
(stand-up meeting), onde os desenvolvedores trocam idéias entre si sobre o trabalho que está
sendo desenvolvido no momento (AMBLER, 2004). A stand-up meeting tem por objetivo
comunicar problemas, soluções e manter o foco da equipe no que está trabalhando
(EXTREME PROGRAMMING, 2009).
A segunda particularidade diz respeito à forma com que os programadores
desenvolvem o código. Na XP, a programação é feita aos pares (pair programming). Ou seja,
cada dupla senta-se em frente a um computador e desenvolve conjuntamente. Sommerville
(2007) aponta as seguintes vantagens da programação em par:
52
a) Apóia a ideia de propriedade e responsabilidade comuns para o software.
b) Atua como um processo informal de revisão porque cada linha de código é vista
por mais de uma pessoa.
4.2.4. Fase de produção
A fase de produção focaliza-se na garantia de que o software esteja pronto para entrar
em produção (AMBLER, 2004). São executados testes como o de sistema, de carga e
instalação. O software, portanto, deixa o ambiente de desenvolvimento e passa a operar no
ambiente real, de produção.
Segundo Ambler (2004), na fase de produção o ritmo de desenvolvimento diminui e
aspectos como documentação e correção de defeitos recebem o foco do trabalho.
Quando os testes demonstrarem a existência de algum defeito no sistema é necessário,
obviamente, realizar atividades que visem corrigi-los o mais rápido possível.
Já a documentação deve ser desenvolvida e otimizada, desde que a sua existência
justifique-se por uma necessidade e não de uma imposição burocrática. Diferentes
documentos podem ser desenvolvidos: Dentre eles, pode-se citar:
a) Documentação do Sistema: É o tipo de documentação mais importante
(AMBLER, 2004). Oferece aos desenvolvedores e profissionais responsáveis pela
manutenção uma visão geral do sistema, através de visões gerais da arquitetura
técnica e de negócios, requisitos de alto nível do sistema, resumo das decisões
importantes de projeto, diagramas e modelos. O objetivo é ser uma ferramenta que
permita o entendimento do sistema desenvolvido.
b) Documentação de Operações: Descreve dependências do sistema para com
outros, como sistemas gerenciadores de banco de dados (SGBD), por exemplo;
descrições de rotinas de backup, resumo dos requisitos de disponibilidade e
confiabilidade, perfil de carga de trabalho esperado e procedimentos de resolução de
problemas que por ventura ocorram.
c) Documentação de Suporte: Contém um conjunto de informações voltadas a quem
irá prestar suporte ao sistema.
d) Documentação de Usuário: Inclui guias de uso do software, guia de suporte e
materiais de treinamento.
53
4.2.5. Manutenção
A fase de manutenção é o estado normal dos projetos XP (AMBLER, 2004),
englobando as fases de Planejamento, Iterações para Entrega e Produção para Entrega 2 até N
do sistema. Isso se explica pelo fato de a XP utilizar uma abordagem de desenvolvimento em
iterações. Na primeira iteração, portanto, a manutenção não existe, porque o software está
“nascendo” naquele momento. A partir da segunda, parte-se de um primeiro release já
existente e prossegue-se com o seu desenvolvimento, seguindo assim sucessivamente.
4.3. Engenharia de Requisitos aplicada a Extreme Programming
A Engenharia de Requisitos se faz necessária tanto nas metodologias ágeis quanto nas
metodologias tradicionais. Certamente, a forma de emprego das técnicas de ER é adaptada a
filosofia do modelo de software aplicado. Seja ágil ou tradicional, o fato é que se faz
necessário, em um processo de desenvolvimento de software, despender esforços para a
descoberta e gerência dos requisitos do software a ser construído.
Na Extreme Programming, os requisitos são elicitados do cliente na forma de estórias
de usuário, escritas em cartões pelo próprio cliente em linguagem natural. Como o cliente é
parte integrante da equipe XP, sendo sua presença fundamental ao funcionamento da
metodologia, pode-se concluir que o processo de obtenção dos requisitos e de validação é
otimizado consideravelmente.
Beck (2004) apresenta três razões que justificam a escrita de estórias de usuário.
Segundo o autor, para o cliente, a escrita de estórias:
a) Força uma melhor análise da funcionalidade, pois no momento da escrita da
estória ele formaliza o pensamento e busca compreender melhor o assunto sobre o
qual irá tratar.
b) Cria um vínculo psicológico, ficando sob sua responsabilidade o que está sendo
escrito.
c) Ajuda a compreender que existe um custo sobre tudo aquilo que é pedido.
54
O processo de descoberta de requisitos gera um conjunto de requisitos que de alguma
forma precisa ser documentado para posterior consulta. Documentar os requisitos é outra
atividade que cabe ao processo de engenharia de requisitos, o qual visa gerar um documento
que contenha a descrição verídica do sistema a ser desenvolvido. Esta documentação pode ser
formal, utilizando-se templates predefinidos de documentos ou pode ser feita de forma mais
informal. Na Extreme Programming, o conjunto de estórias de usuário pode ser considerado
o documento de requisitos de um projeto.
Recolher os requisitos do software e documentá-los não é garantia de que eles de fato
reflitam as necessidades do cliente. Grande parte dos problemas enfrentados no
desenvolvimento de software reside na falta de qualidade dos requisitos elicitados. Em vista
disso, é fundamental a qualquer metodologia de desenvolvimento gerir os requisitos de forma
a alcançar alto grau de excelência na suas especificações. Conforme descrito na seção 2.4, é
possível avaliar a qualidade dos requisitos contidos em uma especificação de requisitos
tomando por parâmetro oito características de qualidade, a saber, correção, precisão,
completeza, consistência, priorização, verificabilidade, modificabilidade e rastreabilidade.
Sendo a Extreme Programming uma metodologia de desenvolvimento de software,
convém neste momento submetê-la a uma avaliação segundo os critérios de qualidade de
requisitos apresentados. Para cada critério, serão descritas as características da XP que o
sustentam e/ou as deficiências enfrentadas pela metodologia no atendimento ao mesmo.
Segue a análise:
a) Quanto à correção: A correção dos requisitos refere-se à qualidade do requisito
de expressar de fato a necessidade do cliente, da forma como ele imagina. Na
Extreme Programming, o cliente é parte integrante da equipe, ele próprio escreve o
que necessita e recebe constante feedback do que está sendo desenvolvido, o que
garante a correteza da especificação dos requisitos.
b) Quanto à precisão: Precisão é a característica que um requisito tem de não
apresentar ambiguidade em seu sentido. Cliente e desenvolvedor devem lê-lo e obter
o mesmo significado. Como na XP a presença do cliente se dá em todo o
desenvolvimento, requisitos ambíguos são imediatamente mais bem especificados e,
por conseguinte, é obtida precisão em sua descrição.
c) Quanto à Completeza: A completeza refere-se à propriedade de uma
especificação de requisitos de conter todos os requisitos significativos. A
completeza pressupõe que grande parte dos requisitos sejam recolhidos
previamente, o que, em teoria, contradiz o que acontece em um projeto que utiliza
desenvolvimento incremental e ágil. A XP recolhe os requisitos à medida que o
projeto evolui diferentemente de métodos tradicionais que buscam elicitar todos os
55
requisitos antes de propriamente projetar e desenvolver o software. Todavia, pode-
se afirmar que na XP existe “completeza temporal”, ou seja, a cada iteração se tem
uma especificação dos requisitos que apresenta completeza em sua definição para
aquele dado momento do desenvolvimento.
d) Quanto à Consistência: A consistência dos requisitos é a condição de inexistência
de conflitos entre os mesmos. Tais conflitos podem ser de ordem lógica ou
temporal, de definição e de características do mundo real. Novamente a XP
consegue obter consistência nos seus requisitos pelo fato de o cliente estar presente
durante o desenvolvimento. O feedback do que foi desenvolvido se dá em um
intervalo de tempo curto, o que permite que todos os conflitos possam ser corrigidos
com rapidez e sem maiores complicações ao projeto.
e) Quanto à priorização: A priorização é a atividade onde se atribui ao requisito
uma escala qualitativa ou quantitativa de prioridade. Na XP, a priorização dos
requisitos é natural. O cliente determina quais são os requisitos que são essenciais
ao seu negócio e que, em vista disso, devem ser os primeiros a serem desenvolvidos.
A cada nova versão do sistema, o cliente prioriza as estórias que devem ser
entregues e isto se repete durante todo o projeto.
f) Quanto à verificabilidade: A verificabilidade dos requisitos diz respeito à
propriedade de um requisito de ser verificável por um processo finito, viável e
eficaz. Ela é obtida na XP através da presença constante do cliente, dos casos de
teste escritos para verificar se de fato o que foi desenvolvido comporta-se conforme
o especificado e do feedback constante obtido do cliente no projeto. Desta forma, na
XP todos os requisitos são verificáveis através de um processo finito, pouco oneroso
e eficaz.
g) Quanto à modificabilidade: A modificabilidade de uma especificação de
requisitos diz respeito à maleabilidade que a mesma possui de ser modificável,
mantendo a sua consistência e completeza. A XP tem como um de seus
“mandamentos” a simplicidade, ou seja, fazer as coisas da forma mais simples. As
estórias de usuário são escritas em cartões de papel, e não existem documentos
fortemente amarrados formando uma especificação complexa, o que permite que
modificações sejam realizadas sem maiores problemas. Além disso, toda a
metodologia foi desenvolvida para trabalhar com requisitos pouco estáveis,
devendo, portanto, a modificabilidade ser uma característica inerente ao modelo.
h) Quanto à rastreabilidade: A rastreabilidade nos requisitos é a propriedade que
permite determinar a relação de dependência entre os mesmos. A rastreabilidade é
de grande valia para uma especificação de requisitos. Para obtê-la, é necessária a
utilização de ferramentas automatizadas, denominadas ferramentas CASE
(Computer-Aided Software Engineering), que serão explicadas no próximo capítulo.
Valendo-se de uma ferramenta CASE, a XP consegue alcançar a rastreabilidade nos
requisitos sem maiores problemas.
56
Com base na avaliação proposta acima, é possível extrair dois elementos fundamentais
para que a XP obtenha todos os requisitos de qualidade: cliente sempre presente e uso de uma
ferramenta CASE.
O primeiro elemento, que diz respeito ao cliente estar sempre presente, é uma das
premissas básicas da metodologia XP. Sem o cliente presente durante todo o
desenvolvimento, a XP simplesmente não funciona, não fazendo sentido utilizar a
metodologia em projetos onde este requisito não possa ser atendido. O segundo elemento, o
uso de uma ferramenta CASE, será amplamente discutido nas próximas seções deste trabalho,
onde serão descritas as características de algumas ferramentas CASE disponíveis e, a partir do
estudo das mesmas, será proposto um protótipo de ferramenta CASE com vistas a gerenciar
requisitos em projetos baseados na metodologia XP.
Observa-se que a XP é uma das metodologias mais puristas no que diz respeito a
filosofia ágil. É de grande aplicabilidade, uma vez que enfatiza a satisfação rápida do cliente
mediante entregas funcionais em um curto espaço de tempo. Dado que a necessidade pelo
desenvolvimento rápido de software é evidente no cenário atual, a XP apresenta-se como uma
ótima opção às equipes de desenvolvimento. Contudo, a sua execução requer organização e
coragem no cumprimento das atividades e dos valores por ela apregoados; é fato que a XP
não funciona num ambiente desordenado.
No que tange à Engenharia de Requisitos, a XP utiliza uma forma particular de
execução do processo que é fortemente ligado à presença do cliente. Dentre os atributos de
qualidade de requisitos citados, a avaliação da metodologia mostrou que a grande maioria tem
forte ligação com a constante participação do cliente no projeto. A rastreabilidade, por sua
vez, mostrou ser um ponto fraco da metodologia, mas que com o auxílio de uma ferramenta
CASE pode ser facilmente contornado.
57
5. TECNOLOGIA CASE
Organizar e gerir os requisitos de um software torna-se uma atividade onerosa de ser
feita com ferramentas simples, como papel e caneta, à medida que o conjunto de requisitos
obtidos cresce. Aliado a isso, a necessidade cada vez maior de otimização do tempo utilizado
na realização de qualquer atividade torna visível a necessidade de uso de ferramentas
automatizadas de apoio a estas atividades. Otimizar o uso do tempo em um processo de
software pode ser o diferencial entre o sucesso e o fracasso de um projeto. Conforme já
exposto anteriormente, dentre os motivos que levaram a idealização da Engenharia de
Software, os atrasos meteóricos nos projetos de desenvolvimento ocupavam o topo da lista.
Uma das formas de otimizar o uso do tempo e de aumentar a qualidade da gerência de
projetos de software é utilizar ferramentas (softwares) que automatizem importantes tarefas
comuns a qualquer ambiente de desenvolvimento de software. Quando uma ferramenta de
software apóia atividades de um processo de software, como engenharia de requisitos, projeto,
desenvolvimento, teste, etc. esta recebe o nome de ferramenta CASE, do inglês Computer-
Aided Software Enginneering, em português, Engenharia de Software Auxiliada por
Computador (SOMMERVILLE, 2007).
A tecnologia CASE foi concebida, portanto, com o intuito de aprimorar o processo de
desenvolvimento de software, através da automação e integração das atividades desenvolvidas
na construção de um software. Todavia, a expectativa inicial de êxito da aplicação de
ferramentas CASE foi, de certa forma, podada segundo Sommerville (2007) pelos seguintes
motivos:
a) A Engenharia de Software é uma atividade de projeto, que baseia-se na
criatividade. As ferramentas CASE automatizam atividades, mas são incapazes de
criar por si soluções;
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP

Mais conteúdo relacionado

Mais procurados

TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA
TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTATCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA
TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTALeonardo Lima
 
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileiras
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileirasTCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileiras
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileirasDiego Wilhelm Rocha, Eng, MCP's ®, MBA
 
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...Adson Wendel
 
Apostila elementos de projeto de informática
Apostila elementos de projeto de informáticaApostila elementos de projeto de informática
Apostila elementos de projeto de informáticaFabricio Tecinfo
 
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...Eder Nogueira
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...Marcelo Dieder
 
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Claudio Cardozo
 
TCC - Estudo de caso: Implantação do Modelo MPS.BR
TCC - Estudo de caso: Implantação do Modelo MPS.BRTCC - Estudo de caso: Implantação do Modelo MPS.BR
TCC - Estudo de caso: Implantação do Modelo MPS.BREdimar Ramos
 
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710Fernanda Lobo
 
Nc bv3 pt_br_icbv3_r.3.1_lr
Nc bv3 pt_br_icbv3_r.3.1_lrNc bv3 pt_br_icbv3_r.3.1_lr
Nc bv3 pt_br_icbv3_r.3.1_lrleopaiva217101
 
TCC - Gerenciamento de Projetos X Educação corporativa
TCC - Gerenciamento de Projetos X Educação corporativaTCC - Gerenciamento de Projetos X Educação corporativa
TCC - Gerenciamento de Projetos X Educação corporativaPaula Mendes
 
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...Alessandro Brantes
 
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...Cristiano Lima
 
TCC_Gerenciamento de Projetos FGV_Giseli Daniel
TCC_Gerenciamento de Projetos FGV_Giseli DanielTCC_Gerenciamento de Projetos FGV_Giseli Daniel
TCC_Gerenciamento de Projetos FGV_Giseli DanielGiseli Daniel
 

Mais procurados (20)

TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA
TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTATCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA
TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
 
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileiras
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileirasTCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileiras
TCC - Gerenciamento de riscos aplicado a pequenas e médias empresas brasileiras
 
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
 
Apostila elementos de projeto de informática
Apostila elementos de projeto de informáticaApostila elementos de projeto de informática
Apostila elementos de projeto de informática
 
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...
PROGRAMAÇÃO DECLARATIVA COM JAVAFX: UM PARADIGMA NA CONSTRUÇÃO DE INTERFACES ...
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
 
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
 
TCC - Estudo de caso: Implantação do Modelo MPS.BR
TCC - Estudo de caso: Implantação do Modelo MPS.BRTCC - Estudo de caso: Implantação do Modelo MPS.BR
TCC - Estudo de caso: Implantação do Modelo MPS.BR
 
TCC Especialização Gerenciamento de Projetos
TCC Especialização Gerenciamento de ProjetosTCC Especialização Gerenciamento de Projetos
TCC Especialização Gerenciamento de Projetos
 
Engajamento de Partes Interessadas - Estudo de Caso
Engajamento de Partes Interessadas - Estudo de CasoEngajamento de Partes Interessadas - Estudo de Caso
Engajamento de Partes Interessadas - Estudo de Caso
 
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710
Tcc MBA Gestão de Projetos em Tecnologia da Informação 190710
 
Nc bv3 pt_br_icbv3_r.3.1_lr
Nc bv3 pt_br_icbv3_r.3.1_lrNc bv3 pt_br_icbv3_r.3.1_lr
Nc bv3 pt_br_icbv3_r.3.1_lr
 
TCC - Gerenciamento de Projetos X Educação corporativa
TCC - Gerenciamento de Projetos X Educação corporativaTCC - Gerenciamento de Projetos X Educação corporativa
TCC - Gerenciamento de Projetos X Educação corporativa
 
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...
Aplicação do método fmea ao processo de fabricação de caldeiras flamotubulare...
 
Ct java vi_2010_16
Ct java vi_2010_16Ct java vi_2010_16
Ct java vi_2010_16
 
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...
Aplicação das ferramentas PDCA e FMEA na mitigação da ocorrência de peças não...
 
TCC FGV - Diego Mendes Rodrigues
TCC FGV - Diego Mendes RodriguesTCC FGV - Diego Mendes Rodrigues
TCC FGV - Diego Mendes Rodrigues
 
TCC_Gerenciamento de Projetos FGV_Giseli Daniel
TCC_Gerenciamento de Projetos FGV_Giseli DanielTCC_Gerenciamento de Projetos FGV_Giseli Daniel
TCC_Gerenciamento de Projetos FGV_Giseli Daniel
 

Semelhante a Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP

TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...Juliano Oliveira
 
DevQA: Um futuro para analistas de testes ?
DevQA: Um futuro para analistas de testes ?DevQA: Um futuro para analistas de testes ?
DevQA: Um futuro para analistas de testes ?Kamilla Queiroz Xavier
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...JADSON SANTOS
 
A Arte dos Testes de Performance Aplicacional
A Arte dos Testes de Performance AplicacionalA Arte dos Testes de Performance Aplicacional
A Arte dos Testes de Performance AplicacionalNuno Baptista Rodrigues
 
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMASLIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMASOs Fantasmas !
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Elaine Cecília Gatto
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWInstituto Federal de Sergipe
 
Trabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasTrabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasWANDERSON JONER
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individualAdivaldo_badinho
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
Kyrios: Infra-estrutura livre para desenvolvimento de software
Kyrios: Infra-estrutura livre para desenvolvimento de softwareKyrios: Infra-estrutura livre para desenvolvimento de software
Kyrios: Infra-estrutura livre para desenvolvimento de softwareFábio Nogueira de Lucena
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software PressmanSimoneinfo
 
A Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareA Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareRobson Silva Espig
 

Semelhante a Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP (20)

TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
 
DevQA: Um futuro para analistas de testes ?
DevQA: Um futuro para analistas de testes ?DevQA: Um futuro para analistas de testes ?
DevQA: Um futuro para analistas de testes ?
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
 
A Arte dos Testes de Performance Aplicacional
A Arte dos Testes de Performance AplicacionalA Arte dos Testes de Performance Aplicacional
A Arte dos Testes de Performance Aplicacional
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMASLIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
LIVRO PROPRIETÁRIO - METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.BrPalestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
 
Trabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasTrabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de Sistemas
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individual
 
Analise aula2
Analise aula2Analise aula2
Analise aula2
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Programacao em java
Programacao em javaProgramacao em java
Programacao em java
 
Kyrios: Infra-estrutura livre para desenvolvimento de software
Kyrios: Infra-estrutura livre para desenvolvimento de softwareKyrios: Infra-estrutura livre para desenvolvimento de software
Kyrios: Infra-estrutura livre para desenvolvimento de software
 
Processo de Software
Processo de SoftwareProcesso de Software
Processo de Software
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
A Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareA Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de Software
 

Mais de Diego Lusa

Oracle XML DB - Conceitos iniciais
Oracle XML DB - Conceitos iniciaisOracle XML DB - Conceitos iniciais
Oracle XML DB - Conceitos iniciaisDiego Lusa
 
Cidades Inteligentes e Big Data
Cidades Inteligentes e Big DataCidades Inteligentes e Big Data
Cidades Inteligentes e Big DataDiego Lusa
 
Rede "Olhos do Bem"
Rede "Olhos do Bem"Rede "Olhos do Bem"
Rede "Olhos do Bem"Diego Lusa
 
Engenharia de software orientada a aspectos: do interesse ao aspecto
Engenharia de software orientada a aspectos: do interesse ao aspectoEngenharia de software orientada a aspectos: do interesse ao aspecto
Engenharia de software orientada a aspectos: do interesse ao aspectoDiego Lusa
 
Multiplicação de matrizes
Multiplicação de matrizesMultiplicação de matrizes
Multiplicação de matrizesDiego Lusa
 
Ordenação de pares e ímpares
Ordenação de pares e ímparesOrdenação de pares e ímpares
Ordenação de pares e ímparesDiego Lusa
 
Multiplicação de Matrizes
Multiplicação de MatrizesMultiplicação de Matrizes
Multiplicação de MatrizesDiego Lusa
 
O uso de tecnologias de big data na concepção e execução de estratégias de en...
O uso de tecnologias de big data na concepção e execução de estratégias de en...O uso de tecnologias de big data na concepção e execução de estratégias de en...
O uso de tecnologias de big data na concepção e execução de estratégias de en...Diego Lusa
 

Mais de Diego Lusa (10)

Oracle XML DB - Conceitos iniciais
Oracle XML DB - Conceitos iniciaisOracle XML DB - Conceitos iniciais
Oracle XML DB - Conceitos iniciais
 
Cidades Inteligentes e Big Data
Cidades Inteligentes e Big DataCidades Inteligentes e Big Data
Cidades Inteligentes e Big Data
 
Oracle XML DB
Oracle XML DBOracle XML DB
Oracle XML DB
 
JQuery Mobile
JQuery MobileJQuery Mobile
JQuery Mobile
 
Rede "Olhos do Bem"
Rede "Olhos do Bem"Rede "Olhos do Bem"
Rede "Olhos do Bem"
 
Engenharia de software orientada a aspectos: do interesse ao aspecto
Engenharia de software orientada a aspectos: do interesse ao aspectoEngenharia de software orientada a aspectos: do interesse ao aspecto
Engenharia de software orientada a aspectos: do interesse ao aspecto
 
Multiplicação de matrizes
Multiplicação de matrizesMultiplicação de matrizes
Multiplicação de matrizes
 
Ordenação de pares e ímpares
Ordenação de pares e ímparesOrdenação de pares e ímpares
Ordenação de pares e ímpares
 
Multiplicação de Matrizes
Multiplicação de MatrizesMultiplicação de Matrizes
Multiplicação de Matrizes
 
O uso de tecnologias de big data na concepção e execução de estratégias de en...
O uso de tecnologias de big data na concepção e execução de estratégias de en...O uso de tecnologias de big data na concepção e execução de estratégias de en...
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.
  • 5. “A persistência é o caminho do êxito.” Charles Chaplin
  • 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;