Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 235 views

 

Statistics

Views

Total Views
235
Slideshare-icon Views on SlideShare
235
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    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 Document Transcript

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