Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
UNIVERSIDADE DE PASSO FUNDO
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITO...
Diego Antonio Lusa
DESENVOLVIMENTO DO PROTÓTIPO DE UMA
FERRAMENTA PARA ENGENHARIA DE REQUISITOS
VOLTADA AO MODELO DE PROCE...
Diego Antonio Lusa
Desenvolvimento do protótipo de uma ferramenta para engenharia de requisitos
voltada ao modelo de proce...
Apesar de todas as pedras encontradas pelo
caminho, os sonhos se realizam. Apesar de
todo o cansaço, tristeza, dúvida ou m...
“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 com...
LISTA DE FIGURAS
Figura 1: Tipos de requisitos não funcionais ...............................................................
LISTA DE TABELAS
Tabela 1: Project Planning & Tracking System v. 1.6.6...............................................61
Ta...
LISTA DE ABREVIATURAS
CASE Computer- Aided Software Engineering
CMMI Capability Maturity Model Integration
CVS Concurrent ...
SUMÁRIO
INTRODUÇÃO ..........................................................................................................
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS...................45
4.1. Valores..........................................
12
INTRODUÇÃO
O desenvolvimento de software é uma atividade de engenharia (PRESSMAN, 2002).
Diferentemente de uma linha de...
13
(elicitação) merece destaque. Segundo Sommerville (2007), “os requisitos de um sistema são
descrições dos serviços forn...
14
O capítulo 2 aborda o conceito de requisito, fundamental à definição do protótipo
proposto e essencial ao desenvolvimen...
15
1. ENGENHARIA DE SOFTWARE
Neste capítulo são abordados aspectos históricos que deram origem a Engenharia de
Software, u...
16
As características do software residem, segundo Pressman (2002), em três importantes
itens, a saber:
a) O software é de...
17
Na década de 60, os problemas com desenvolvimento de software atingiram níveis
críticos. As causas para este estresse n...
18
de engenharia com o intuito de obter o software de maneira econômica, com características de
confiabilidade e eficiênci...
19
d) Evolução do software: evolução do software durante seu ciclo de vida para
acompanhar as necessidades dos clientes.
P...
20
Embora cada modelo apresente suas particularidades, é possível agrupá-los em dois
grandes grupos. O primeiro grupo engl...
21
Outra importante produção da equipe da Agile Alliance foi um conjunto de 12
princípios fundamentais que devem ser segui...
22
particular do próprio processo. No âmbito de modelos de processos de software, existem os
modelos prescritivos, oriundo...
23
2. REQUISITOS
Para iniciar-se o desenvolvimento de um software, utilizando um modelo qualquer de
processo de software, ...
24
No desenvolvimento de um sistema, os requisitos podem surgir de várias fontes. A
principal delas, de fato, é o cliente....
25
do sistema. Contudo, os requisitos de sistema não devem descrever como o sistema pode ser
implementado e projetado. Dev...
26
requisitado, o sistema não poderá entrar em operação existindo grande probabilidade de
descarte do mesmo.
Sommerville (...
27
Segundo Sommerville (2007), “os requisitos de domínio podem ser novos requisitos,
podem restringir requisitos funcionai...
28
d) Restrições impostas pela aplicação: restrições de padrões, linguagem de
programação, ambientes de operação, limites ...
29
2.3.3. Evolução
A natureza dos requisitos é mutável. A mudança dos requisitos deve ser algo esperado
em qualquer projet...
30
c) Não descrever aspectos gerenciais do projeto.
2.3.5. A problemática relacionada
Especificar requisitos utilizando li...
31
Figura 3: Especificação de requisitos utilizando um formulário padrão
Fonte: Sommerville (2007), pag. 89.
Também é poss...
32
6
Manter dados de medicamentos
Farmaceutico
5 Medicamentos
6 Diagnósticos
7
Manter dados de diagnósticos
7 Materias
10
...
33
2.4. Qualidade dos Requisitos
A qualidade dos requisitos elicitados determina profundamente a qualidade do produto
de s...
34
2.4.3. Completeza
Uma Especificação dos Requisitos não pode conter pendências. Ela deve possuir, para
ser considerada c...
35
2.4.6. Verificabilidade
Para uma Especificação de Requisitos ser verificável é necessário que:
a) Todos os requisitos n...
36
f) Verificar se todos os requisitos do sistema são desempenhados pela
implementação.
g) Verificar se o aplicativo faz a...
37
3. ENGENHARIA DE REQUISITOS
Erros na especificação de requisitos são muito custosos na indústria do software.
Segundo a...
38
requisitos das fontes de informação disponíveis, e posterior análise, verificação,
documentação e gerenciamento dos mes...
39
Pressman (2002), por sua vez, entende que a engenharia de requisitos é um conjunto de
seis passos distintos, que são a ...
40
c) O sistema pode ser integrado a outros sistemas já implantados?
Normalmente o novo software precisa comunicar-se com ...
41
a) Stakeholders não sabem o que querem do sistema computacional especificamente,
tendo dificuldade de articular seus pe...
42
Na Priorização e Negociação de Requisitos os requisitos são priorizados, ou seja, são
postos numa listagem por ordem de...
43
A validação é importante porque desenvolver um requisito incorreto pode levar a
custos excessivos no contexto de um pro...
44
O objetivo do gerenciamento de requisitos é compreender e controlar as mudanças dos
requisitos de sistema. É necessário...
45
4. EXTREME PROGRAMMING E ENGENHARIA DE REQUISITOS
Os modelos de desenvolvimento de software estão classificados em dois...
46
a) É necessário realizar uma análise detalhada dos requisitos antes de projetar a
arquitetura de um sistema.
b) É neces...
47
b) Abordagem incremental do projeto, que gera um plano geral que pode evoluir
com o passar do tempo.
c) Confiança nos t...
48
É importante ter comunicação em um projeto de software porque simplesmente a sua
falta é catastrófica. Desenvolvedores ...
49
4.1.4. Feedback
A única maneira de se obter a garantia de que o trabalho desenvolvido está correto é
recebendo feedback...
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 pr...
51
b) O tempo de desenvolvimento estimado para a estória excede três semanas: Deve-
se quebrar a estória em partes menores...
52
a) Apóia a ideia de propriedade e responsabilidade comuns para o software.
b) Atua como um processo informal de revisão...
53
4.2.5. Manutenção
A fase de manutenção é o estado normal dos projetos XP (AMBLER, 2004),
englobando as fases de Planeja...
54
O processo de descoberta de requisitos gera um conjunto de requisitos que de alguma
forma precisa ser documentado para ...
55
requisitos antes de propriamente projetar e desenvolver o software. Todavia, pode-
se afirmar que na XP existe “complet...
56
Com base na avaliação proposta acima, é possível extrair dois elementos fundamentais
para que a XP obtenha todos os req...
57
5. TECNOLOGIA CASE
Organizar e gerir os requisitos de um software torna-se uma atividade onerosa de ser
feita com ferra...
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Desenvolvimento do protótipo de uma ferramenta para Engenharia de Requisitos voltada ao modelo de processo de software XP
Upcoming SlideShare
Loading in …5
×

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

1,086 views

Published on

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

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

×