Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
ENGENHARIA DE REQUISITOS NO
DESENVOLVIMENTO DE SOFTWARE ÁGIL
Gustavo Henrique de Carvalho Costa
MONOGRAFIA
Recife, Março de 2011
1
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Gustavo Henrique de Carvalho Costa
ENGENHARIA DE REQUISITOS NO
DESENVOLVIMENTO DE SOFTWARE ÁGIL
Trabalho apresentado ao Programa de Pósgraduação em Ciência da Computação do
Centro de Informática da Universidade
Federal de Pernambuco como requisito
parcial para a disciplina de Engenharia de
Requisitos.
Professor: Prof. Dr. Jaelson Castro
Recife, Março de 2011
2
Resumo
O tema deste trabalho é a Engenharia de Requisitos (ER) no desenvolvimento
de software ágil. A primeira parte centra-se na comparação das abordagens
tradicionais de engenharia de requisitos e desenvolvimento de software ágil. Embora
os métodos tradicionais de engenharia de requisitos são frequentemente focados em
documentos, os métodos ágeis freqüentemente tentam minimizar a documentação.
Na segunda parte é analisado as semelhanças e diferenças de ambas as
abordagens e determinado como desenvolvimento ágil de software pode se
beneficiar a partir de métodos tradicionais de engenharia.
Palavras-chave: Engenharia de Requisitos, Metodologias Ágeis, Scrum, XP,
Crystal, ASD, DSDM, FDD.
3
ÍNDICE
1 INTRODUÇÃO...............................................................................................6
2 ENGENHARIA DE REQUISITOS (ER)..........................................................7
2.1 PROCESSO DE ENGENHARIA DE REQUISITOS ................................7
2.2 ELICITAÇÃO DE REQUISITOS ..............................................................9
2.2.1 Entrevistas ........................................................................................9
2.2.2 Casos de uso / cenários .................................................................10
2.2.3 Brainstorming..................................................................................10
2.2.4 Observação e análise social...........................................................11
2.2.5 Grupos focais..................................................................................11
2.2.6 Metodologia de Sistema Flexível ....................................................12
2.2.7 O reuso de requisitos......................................................................12
2.2.8 Prototipação....................................................................................13
2.3 ANÁLISE E NEGOCIAÇÃO DE REQUISITOS .....................................13
2.3.1 Joint Application Development (JAD) .............................................14
2.3.2 Priorização de Requisitos ...............................................................14
2.3.3 Modelagem .....................................................................................15
2.3.4 Desdobramento da Função Qualidade (QFD) ...............................16
2.4 DOCUMENTAÇÃO DE REQUISITOS ..................................................16
2.5 VALIDAÇÃO DE REQUISITOS.............................................................17
2.5.1 Revisão dos requisitos....................................................................17
2.5.2 Testes de requisitos........................................................................17
2.6 GERÊNCIA DE REQUISITOS ..............................................................18
3 DESENVOLVIMENTO ÁGIL........................................................................18
3.2 EXTREME PROGRAMMING (XP) ........................................................19
3.2.1 O Processo de XP ..........................................................................19
3.2.2 Práticas de XP ................................................................................21
3.2.3 XP e os requisitos...........................................................................24
3.3 MODELAGEM ÁGIL (MA) .....................................................................25
3.4 SCRUM .................................................................................................26
3.4.1 O processo Scrum ..........................................................................26
3.5 AS METODOLOGIAS DO CRYSTAL....................................................28
3.6 FEATURE DRIVEN DEVELOPMENT (FDD) ........................................30
4
3.7 MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS
(DSDM)..................................................................................................................31
3.8 DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD).............33
4 TÉCNICAS DE ENGENHARIA DE REQUSITOS PARA MÉTODOS ÁGEIS
..................................................................................................................................35
4.2 ENVOLVIMENTO DO CLIENTE ...........................................................35
4.3 ENTREVISTAS .....................................................................................37
4.4 PRIORIZAÇÃO......................................................................................37
4.5 JAD .......................................................................................................37
4.6 MODELAGEM.......................................................................................38
4.7 DOCUMENTAÇÃO ...............................................................................39
4.8 VALIDAÇÃO..........................................................................................40
4.9 GESTÃO DOS REQUISITOS ...............................................................41
4.10 OBSERVAÇÃO, ANÁLISE SOCIAL E BRAINSTORM........................42
4.11 REQUISITOS NÃO-FUNCIONAIS ......................................................42
5 CONCLUSÃO ..............................................................................................42
6 REFERÊNCIAS ...........................................................................................44
5
1 INTRODUÇÃO
Abordagens de desenvolvimento ágil de software têm se tornado cada vez
mais populares durante os últimos anos. Práticas ágeis têm sido desenvolvidas com
o objetivo de entregar software mais rápido e garantir que o software atenda às
necessidades dinâmicas dos clientes. Em geral, estas abordagens têm alguns
princípios comuns: melhorar a satisfação do cliente, adaptando-se às necessidades
das mudanças, muitas vezes fornecendo software de trabalho, e uma estreita
colaboração do cliente com os desenvolvedores. Abordagens ágeis são baseadas
em iterações curtas, liberando uma nova versão do software a cada 1-3 meses.
Engenharia de Requisitos (ER) é um processo tradicional de engenharia de
software cujo objetivo é identificar, analisar, documentar e validar os requisitos para
o sistema a ser desenvolvido. Muitas vezes, fazer engenharia de requisitos e praticar
abordagens ágeis são vistos como incompatíveis: ER muitas vezes depende de
documentação para a distribuição do conhecimento, enquanto que o foco dos
métodos ágeis é voltado para a colaboração entre clientes e desenvolvedores. O
objetivo deste trabalho é determinar como as técnicas de engenharia de requisitos
são usados no âmbito do desenvolvimento ágil e se as abordagens ágeis poderiam
ser melhoradas pela utilização de certas técnicas de ER.
ER é um subprocesso do processo tradicional de desenvolvimento de
software. Considerando-se o modelo em cascata, um modelo padrão em engenharia
de software, a ER é a primeira de cinco fases. As cinco fases do modelo em cascata
são: definição de requisitos de sistema e projeto de software, implementação e
testes unitários, integração e testes do sistema, operação e manutenção. Estas
cinco fases são executadas de formas sucessivas e têm como objetivo resultar em
um produto de software funcionando. Mas o processo de desenvolvimento de
software passou por várias mudanças durante os últimos anos. Uma das mudanças
são as abordagens ágeis de desenvolvimento de software.
A próxima seção dá uma visão geral sobre as técnicas atuais de engenharia
de requisitos. A Seção 3 discute abordagens ágeis a partir de uma perspectiva de
engenharia de requisitos. E na Seção 4, avaliamos como a incorporação de algumas
técnicas de engenharia de requisitos podem melhorar os métodos ágeis.
6
2 ENGENHARIA DE REQUISITOS (ER)
A Engenharia de Requisitos está preocupada com a identificação,
modelagem, comunicação e documentação dos requisitos de um sistema, e em
quais contextos o sistema será utilizado. Requisitos descrevem o que será feito, mas
não como eles serão implementados [Davis, 94]. Há muitas técnicas disponíveis
para uso durante o processo de ER para garantir que os requisitos sejam completos,
consistentes e relevantes. O objetivo da ER no modelo em cascata é ajudar a saber
o que construir antes de começar o desenvolvimento do sistema a fim de evitar um
grande retrabalho. Este objetivo tem dois pressupostos principais: quanto mais tarde
os erros são descobertos, mais caro será para corrigí-los [Sommerville, 97], e é
possível determinar um conjunto estável de requisitos antes do projeto do sistema e
do começo da codificação.
A seguir, vamos examinar brevemente o processo de engenharia de
requisitos e discutir as principais técnicas que foram desenvolvidos para ele.
2.1 PROCESSO DE ENGENHARIA DE REQUISITOS
O processo de ER é composto por cinco atividades principais [Sommerville,
97]:
•
Elicitação
•
Análise e Negociação
•
Documentação
•
Validação
•
Gestão
Eles podem ser apresentadas em diferentes modelos. Os modelos mais
populares são:
•
O modelo de atividade grosseiro (ver Figura 1). Os ícones de nuvens
indicam que não há limites distintos entre as atividades.
•
O modelo em cascata. Mostra uma seqüência de fases uma após a outra.
7
•
O modelo espiral (ver Figura 2). Indica que as diferentes atividades são
repetidas até que uma decisão seja tomada, de que o documento de
requisitos seja aceito.
Figura 1: O modelo de atividade grosseiro [Sommerville, 97]
Figura 2: O Modelo Espiral [Sommerville, 97]
As entradas e saídas do processo de ER são mostrados na Figura 3. Embora
o processo de ER varie de uma organização para outra, as entradas e saídas são
similares na maioria dos casos. A ER ajuda a detectar erros anteriores, o que reduz
os custos de desenvolvimento de software. Quanto mais tarde os erros são
descobertos, mais caro será para corrigi-los [Sommerville, 97].
8
Figura 3: Processo de ER - Entradas e Saídas [Sommerville, 97]
2.2 ELICITAÇÃO DE REQUISITOS
Elicitação se refere à identificação dos requisitos e limites do sistema através
de consulta com as partes interessadas (por exemplo, clientes, desenvolvedores,
usuários). Os limites do sistema afetarão todas as técnicas de elicitação e definirão
o contexto do sistema a ser entregue. O completo entendimento das diferentes
áreas é essencial para prever o sistema que será desenvolvido.
As técnicas mais importantes para o levantamento de requisitos estão
descritas no restante desta seção.
2.2.1 Entrevistas
Entrevista é um método para descobrir fatos e opiniões de potenciais usuários
e outras partes interessadas no sistema em desenvolvimento. Os erros e equívocos
podem ser identificados e solucionados.
Existem dois tipos de entrevistas:
•
a entrevista fechada, onde o engenheiro de requisitos tem um conjunto
pré-definido de perguntas e está à procura de respostas.
9
•
a entrevista aberta, sem perguntas pré-definidas do engenheiro de
requisitos, onde há uma discussão de forma aberta com os interessados
sobre o que eles esperam do sistema.
Na verdade, muitas vezes não há limite claro entre os dois tipos de
entrevistas. Você começa com algumas questões que são discutidas e isso leva a
novas questões [Sommerville, 97]. A vantagem de entrevistas é que elas ajudam o
desenvolvedor a obter uma rica coleção de informações. Sua desvantagem é que
esta quantidade de dados qualitativos podem ser difíceis de analisar e poderá haver
informações conflitantes das diferentes partes interessadas.
2.2.2 Casos de uso / cenários
Os casos de uso descrevem as interações entre usuários e o sistema,
focando no que os usuários precisam fazer com o sistema, identificando as funções
mais importantes. Um caso de uso especifica uma seqüência de interações entre um
sistema e um agente externo (por exemplo, uma pessoa, uma peça de hardware ou
outro software), incluindo variantes e extensões que o sistema pode realizar. O caso
de uso fornece o resultado de uma tarefa específica exigida por um ator. Os casos
de uso representam os requisitos do sistema e podem ser utilizados durante as
fases iniciais do processo de desenvolvimento. Os analistas e os clientes devem
analisar cada caso de uso proposto para validá-lo [Wiegers, 99].
Os cenários são exemplos de sessões de interação, onde um único tipo de
interação entre usuário e sistema é simulado. Cenários devem incluir uma descrição
do estado do sistema antes de entrar e após a conclusão do cenário, quais
atividades podem ser realizadas simultâneamente, o fluxo normal de eventos e as
exceções para esses eventos [Sommerville, 97].
2.2.3 Brainstorming
Brainstorming é uma possibilidade de desenvolver soluções criativas
relacionadas com um determinado tópico. Normalmente, o brainstorming é uma
atividade de grupo, mas você pode também fazê-lo sozinho. Brainstorming contém
10
duas fases - a fase de geração, onde as idéias são coletadas, e a fase de avaliação,
onde as idéias coletadas são discutidas. Na fase de geração, as idéias não devem
ser criticadas nem avaliadas. Cada idéia pode levar a novas idéias. A técnica de
brainstorming leva a uma melhor compreensão do problema para todos e um
sentimento de que todos cooperaram para atingir o objetivo.
2.2.4 Observação e análise social
O método de observação envolve um investigador acompanhando usuários
enquanto eles trabalham, e tomando notas sobre as atividades que são realizadas.
A observação pode ser direta, com o pesquisador estando presente durante a tarefa,
ou indireta, quando a tarefa é observada por algum outro meio, como através da
utilização de vídeos.
O método é útil no início da especificação de requisitos para a obtenção de
dados qualitativos. Também é útil para estudar as tarefas executadas atualmente e
os seus processos. A observação permite ao observador ver o que os usuários
realmente executam em um contexto. A observação direta permite que o
investigador concentre a atenção em áreas específicas de interesse. A observação
indireta registra as atividades e permite a detecção de problemas que poderiam ter
passado despercebidos na observação direta.
2.2.5 Grupos focais
O grupo focal é uma técnica informal, onde um grupo de 4 a 9 usuários, de
diferentes origens e com diferentes habilidades discutem questões de forma livre e
se concentram nas funcionalidades ou em um protótipo do sistema.
Os grupos focais ajudam a identificar necessidades e sentimentos, as coisas
que são importantes e o que eles querem do sistema. O moderador deve seguir um
roteiro pré-planejado com diferentes temas, que são introduzidos um de cada vez
para descobrir o que as pessoas pensam sobre aquele tópico. Para os participantes,
a sessão deve ser bem aberta, uma vez que geralmente há uma grande
discrepância entre o que as pessoas dizem e o que fazem, por isso, é necessário o
11
envolvimento da técnica de observação e análise social. Os grupos focais podem
apoiar a articulação de visões, propostas do projeto e um conceito do produto.
Além disso, eles ajudam os usuários a analisar seus próprios problemas e
coisas que devem ser mudadas, e apoiam o desenvolvimento de um "sentido
comum" do sistema [Macaulay, 96], [Nielsen, 97].
2.2.6 Metodologia de Sistema Flexível
O SSM (Soft System Methodology) não foi especificamente concebido como
uma técnica de elicitação de requisitos para sistemas baseados em computadores.
Foi desenvolvido para pensar nos sistemas sócio-técnicos que incluem pessoas,
procedimentos, hardware, software, etc. A essência do SSM é que reconhece que o
sistema está embutido numa organização humana maior. Ela fornece o contexto
para entender requisitos abstratos do sistema, analisando o contexto organizacional,
e o problema em discussão. Foi um destes primeiros métodos que introduziu o
conceito de pontos de vista: diferentes pontos de vista têm percepções diferentes do
problema e dos requisitos do sistema. O SSM e outros métodos de sistema flexíveis
não são indicados para uma elicitação de requisitos detalhada. São mais eficazes
para ajudar a entender o problema, a situação organizacional. Elas produzem
requisitos abstratos para um sistema, precisando ser completado com outras
técnicas de elicitação.
2.2.7 O reuso de requisitos
O reuso de requisitos significa reutilizar especificações de requisitos ou partes
desenvolvidas em projetos anteriores. O reuso de requisitos pode ser comparado
com o uso de modelos e ser simples quando o problema dos dois projetos é
bastante semelhante [McPhee, 2001]. O reuso de requisitos só é possível em certos
casos:
•
O requisito contém informações sobre o domínio da aplicação - Requisitos
normalmente não especificam uma funcionalidade específica do sistema,
12
mas as restrições do sistema ou as operações do sistema que são
derivadas a partir do domínio da aplicação.
•
O requisito está preocupado com a forma de apresentação da informação.
•
O requisito reflete as políticas da empresa (políticas de segurança).
2.2.8 Prototipação
Um protótipo de um sistema é uma versão inicial do sistema que está
disponível no início do processo de desenvolvimento. Protótipos de sistemas de
software são frequentemente utilizados para ajudar a obter e validar requisitos do
sistema. Existem dois diferentes tipos de protótipos: o protótipo descartável que
ajuda a descobrir requisitos que causam dificuldades de compreensão, e o protótipo
evolutivo que oferece um sistema usável para o cliente e pode se tornar uma parte
do sistema final.
Esses protótipos podem ser desenvolvidos como um protótipo de papel, onde
um mock-up do sistema é desenvolvido e utilizado para experimentos sobre o
sistema, como o protótipo "O Mágico de Oz", onde uma pessoa simula as respostas
do sistema em resposta a algumas entradas do usuário ou como um protótipo
automatizado, onde uma linguagem de quarta geração ou algum outro ambiente de
desenvolvimento rápido é usado para desenvolver um protótipo executável.
2.3 ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
Análise de requisitos verifica nos requisitos a necessidade (a necessidade de
exigência), consistência (os requisitos não devem ser contraditórios), completude
(nenhum serviço ou restrição deve estar ausente) e a viabilidade (se os requisitos
são viáveis no contexto do orçamento e no cronograma disponível para o
desenvolvimento do sistema). Conflitos em requisitos são resolvidos através da
negociação de prioridades. Requisitos que parecem problemáticos são discutidos e
os stakeholders envolvidos apresentam seus pontos de vista sobre os mesmos. As
soluções para os problemas dos requisitos são identificadas e um compromisso com
um conjunto de requisitos é acordado. Geralmente, isso implica em alterações de
13
algumas das exigências. As principais técnicas utilizadas para a análise de
requisitos são sessões JAD, Priorização e Modelagem.
2.3.1 Joint Application Development (JAD)
A
metodologia
JAD
foi
desenvolvida
pela
IBM
para
acelerar
o
desenvolvimento de sistemas de informação e está embasada em dinâmicas de
grupo acompanhadas de planejamento, estruturação e sistematização de reuniões.
Guiados por um líder de reunião, usuários e analistas projetam o sistema juntos, em
sessões de grupo estruturadas. JAD utiliza a criatividade e o trabalho em equipe
para definir o ponto de vista dos usuários sobre o sistema, desde os objetivos e
aplicações do sistema até a geração de telas e projetos de relatórios. O método
indica três tipos básicos de reuniões de projeto [Teitelroit e Boff, 1991]: as sessões
estratégicas, onde são discutidos o âmbito, objetivos, recursos, políticas e mudanças
organizacionais; sessões de dados e processos e; sessões de telas e relatórios.
2.3.2 Priorização de Requisitos
Em um projeto com um cronograma apertado, recursos limitados, e com altas
expectativas dos clientes é essencial fornecer os mais valiosos recursos o mais cedo
possível. Quando a prazo é curto, mas nem todas as funcionalidades foram
implementadas, algumas funcionalidades têm de ser descartadas.
O estabelecimento de prioridades no início do projeto ajuda a decidir quais
recursos podem ser descartados. A priorização dos requisitos deve ser feita pelo
cliente. Se um terceiro toma esta decisão para o cliente, poderá haver
discordardâncias sobre a definição das prioridades. Tanto o cliente quanto o
desenvolvedor
devem
prover
informações
para
essa
priorização.
Os
desenvolvedores devem apontar os riscos técnicos, custos ou dificuldades. Com
essas informações, o cliente pode alterar a prioridade de algumas funcionalidades.
Os
desenvolvedores
também
podem
propor
a
implementação
de
uma
funcionalidade, quando a mesma tem maior impacto sobre a arquitetura do sistema,
mesmo tendo uma menor prioridade [Wiegers, 99].
14
2.3.3 Modelagem
Modelos do sistema são uma importante ponte entre o processo de análise e
o de projeto. Alguns métodos utilizam diferentes técnicas de modelagem para
formular ou analisar os requisitos do sistema. As técnicas mais populares de
modelagem são [Sommerville, 97]: modelos de fluxo de dados, modelos de dados
semânticos e as abordagens orientadas a objeto.
Figura 4: Notação do diagrama de fluxo de dados [Sommerville, 97]
O modelo de fluxo de dados é baseado na notação de que os sistemas
podem ser modelados como um conjunto de funções que interagem entre si. Ela usa
diagramas de fluxo de dados (DFDs) para representar graficamente as entidades
externas, processos, fluxo de dados e armazenamento dos dados. (Veja a figura 4
para a notação do diagrama de fluxo de dados)
No modelo de dados semântico, o modelo de sistema deve ainda descrever a
forma lógica dos dados que são processados pelo sistema. Isso pode ser feito
usando o modelo relacional em que os dados são especificados como um conjunto
de
tabelas
com
algumas
colunas
que
representam
as
chaves
comuns,
independentemente da organização física do banco de dados.
O modelo de dados semântico inclui o modelo entidade-relacionamento. A
entidade em um banco de dados, os atributos que lhe pertencem e as relações
explícitas entre eles são identificados.
O princípio básico de um modelo orientado a objetos é a noção de um
objeto. Um objeto define um conjunto de atributos e operações comuns a ele
associados. Os conceitos básicos para a abordagem orientada a objetos são:
15
•
Classe
•
Operações de serviços
•
Encapsulamento
•
Herança
A comunicação entre objetos são baseadas em mensagens causando uma
operação a ser invocada. A operação executa o método apropriado e retorna uma
resposta.
2.3.4 Desdobramento da Função Qualidade (QFD)
QFD é uma das ferramentas da qualidade que foi criada na década de 60
pelo japonês Yoji Akao e que tem como objetivo principal permitir que a equipe de
desenvolvimento do produto incorpore as reais necessidades do cliente em seus
projetos de melhoria.
Na prática, o QFD corresponde a quatro matrizes onde é feito o
planejamento do produto e que costuma ser chamada genericamente de casa da
qualidade. A partir dos requisitos dos consumidores, que podem ser captados
através de pesquisas, reclamações, etc., que geralmente são coletados na forma de
idéias vagas ou conceitos generalizados, a equipe de projeto traduz estas idéias ou
conceitos em requisitos de projeto que podem ser mensuráveis e, portanto,
transformados em características efetivas do produto.
2.4 DOCUMENTAÇÃO DE REQUISITOS
O objetivo da documentação de requisitos é comunicar o entendimento dos
requisitos entre as partes interessadas e os desenvolvedores. O documento de
requisitos explica o domínio da aplicação e do sistema a ser desenvolvido. Pode ser
a base para posterior avaliação dos produtos e processos (concepção do sistema,
casos de teste, verificação e validação) e para controle das mudanças.
Um bom documento de requisitos deve ser claro / não ambíguo, completo,
correto, compreensível, consistente, conciso e viável. Dependendo da relação
16
cliente-fornecedor, o documento de especificação pode ser parte do contrato
[Macaulay, 96].
2.5 VALIDAÇÃO DE REQUISITOS
O objetivo da validação dos requisitos é certificar que os requisitos
representam uma descrição aceitável do sistema a ser desenvolvido. As entradas
para o processo de validação são o documento de requisitos, os padrões
organizacionais e o conhecimento organizacional. As saídas são uma lista de
problemas que contém os problemas relatados com o documento de requisitos e das
ações acordadas, para lidar com os problemas relatados. Técnicas utilizadas para
validação de requisitos são a revisão dos requisitos e testes dos requisitos.
2.5.1 Revisão dos requisitos
A revisão dos requisitos irá assegurar que os requisitos:
•
estão completos
•
são consistentes
•
são inequívocos
•
podem ser testados
Há revisões formais e informais dos requisitos. O objetivo das revisões
informais é criticar e melhorar as condições dos requisitos. A revisão informal ocorre
gradualmente e ao longo do processo de ER, com as partes interessadas. O objetivo
da revisão formal é aprovar o documento de requisitos e autorizar o projeto. Por
isso, ocorre quando o documento de requisitos está, teoricamente, completo [Pottts,
98].
2.5.2 Testes de requisitos
Teste de software é parte integrante da engenharia de software. Mas se o
software é escrito com base em requisitos mal-entendidos o resultado não será o
17
desejado. Por esta razão, a escrita de testes de requisitos deve ser iniciada tão logo
o trabalho sobre os requisitos para um produto seja iniciado [Robertson, 2000]. A
vantagem de se escrever testes é que os problemas com os requisitos são muitas
vezes descobertas antes de concepção e desen [McPhee, 2001].
2.6 GERÊNCIA DE REQUISITOS
O gerenciamento de requisitos engloba todas as atividades envolvidas com o
controle
de
mudanças,
controle
de
versão,
rastreamento
de
requisitos,
acompanhamento do status dos requisitos (ver figura 5). O objetivo do
gerenciamento de requisitos é o de capturar, armazenar, disseminar e gerenciar
informações. Gerenciar informação significa organização, análise e rastreabilidade.
A rastreabilidade é uma técnica usada para proporcionar relacionamentos
entre os requisitos, o projeto e o desenvolvimento de um sistema a fim de ajudar o
gerenciamento de suas mudanças [Wiegers, 99].
Figura 5: Atividades de Gerenciamento de Requisitos [Wiegers, 99]
3 DESENVOLVIMENTO ÁGIL
Em relação ao desenvolvimento tradicional, o desenvolvimento de software
ágil é menos orientado a documentos e mais orientado a código. Isso, no entanto,
18
não é sua principal característica, mas sim um reflexo de duas diferenças mais
profundas entre os dois estilos [Fowler, 2000]:
•
Métodos ágeis são adaptativos ao invés de preditivos. Com os métodos
tradicionais, o processo de software é planejado em detalhes por um longo
período de tempo. Isso funciona bem se não houver grandes mudanças, e
o domínio da aplicação e as tecnologias de software sejam bem
compreendidas pela equipe de desenvolvimento. Os métodos ágeis foram
desenvolvidos para se adaptar as mudanças.
•
Métodos ágeis são orientados às pessoas ao invés de processos. Eles
confiam na experiência das pessoas, na competência e na colaboração
direta, do que em rigor dos processos centrados em documentos, para
produzir software de alta qualidade.
Nesta seção, os métodos ágeis mais comuns são brevemente discutidos.
3.2 EXTREME PROGRAMMING (XP)
XP (eXtreme Programming) é uma disciplina de desenvolvimento de software
com base nos valores da simplicidade, comunicação e feedback. Ele trabalha,
trazendo toda a equipe, juntamente com a presença de práticas simples, com
feedback suficiente para permitir que a equipe possa ver onde estão e para ajustar
as práticas à situação desejada.
3.2.1 O Processo de XP
Um projeto XP atravessa algumas fases durante o seu ciclo de vida. Essas
fases são compostas de várias tarefas que são executadas. Abaixo será dada uma
explicação das principais fases de um projeto XP de modo a se ter uma idéia de
como o projeto flui ao longo do tempo.
Um projeto XP passa pelas seguintes fases: exploração, planejamento inicial,
iterações do release, produção, manutenção e morte.
19
A fase de exploração é anterior à construção do sistema. Nela, investigações
de possíveis soluções são feitas e verifica-se a viabilidade de tais soluções. Os
programadores elaboram possíveis arquiteturas e tentam visualizar como o sistema
funcionará considerando o ambiente tecnológico (hardware, rede, software,
desempenho, tráfego) onde o sistema irá rodar. Com isso, os programadores e os
clientes vão ganhando confiança, e quando eles possuírem estórias suficientes, já
poderão começar a construir o primeiro release do sistema. Sugere-se que seja
gasto no máximo duas semanas nessa fase.
A fase de planejamento inicial deve ser usada para que os clientes
concordem em uma data para lançamento do primeiro release. O planejamento
funciona da seguinte forma: Os programadores, juntamente com o cliente, definem
as estórias (casos de uso simplificados) a serem desenvolvidos e as descrevem em
cartões. Os programadores assinalam certa dificuldade para cada estória e,
baseados na sua velocidade de desenvolvimento, dizem quantas estórias podem
desenvolver em uma iteração. Depois, os clientes escolhem as estórias de maior
valor para serem desenvolvidas na iteração – isso é chamado planejamento de
iteração. O processo então se repete até terminar as iterações do release. O tempo
para cada iteração deve ser de uma a três semanas e para cada release de dois a
quatro meses.
Na fase das iterações do release são escritos os casos de teste funcionais e
de unidade. Os programadores vão seguindo mais ou menos o seguinte fluxo de
atividades na seguinte ordem (em cada iteração): escrita dos casos de testes;
projeto e refatoramento; codificação; realização dos testes; e integração. À medida
que esse fluxo vai sendo seguido, o sistema vai sendo construído segundo os
princípios, valores e práticas. Depois de terminado o primeiro release, já se terá uma
idéia melhor das tecnologias e do domínio do problema, de modo que as iterações
poderão ser mais curtas nos
releases subseqüentes
e já se poderá fazer
estimativas mais confiáveis com o que se aprendeu das iterações passadas.
Depois do final do primeiro release, considera-se o início da fase de produção
onde cada release subseqüente do sistema, depois de construído, é colocado para
rodar em um ambiente que simula o ambiente de produção para ver seu
comportamento em termos de desempenho. Podem-se fazer testes de aceitação
adicionais para simular o funcionamento real do sistema no ambiente alvo.
20
A fase de manutenção pode ser considerada como uma característica
inerente a um projeto XP. Em XP você está simultaneamente produzindo novas
funcionalidades, mantendo o sistema existente rodando, incorporando novas
pessoas na equipe e melhorando o código. Mecanismos como: refatoramento,
introdução de novas tecnologias, e introdução de novas idéias de arquitetura podem
ser utilizados em um projeto XP. É importante ressaltar que a manutenção dada em
um sistema que já está em produção deve ser feita com muita cautela, pois uma
alteração errada pode paralisar o funcionamento do sistema resultando em prejuízos
para o cliente.
A fase de morte corresponde ao término de um projeto XP. Existem duas
razões para se chegar ao final de um projeto, uma boa e a outra ruim. A boa razão é
quando o cliente já está satisfeito com o sistema existente e não enxerga nenhuma
funcionalidade que possa vir a ser desenvolvida no futuro. A má razão para a morte
em XP seria o projeto ter se tornado economicamente inviável, devido a dificuldades
de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros.
3.2.2 Práticas de XP
Extreme Programming possui doze práticas que consistem no núcleo
principal do processo e que foram criadas com base nos ideais pregados pelos
valores e princípios apresentados anteriormente na seção 3.2.1. Segundo um
dos criadores de XP, Kent Beck, estas práticas não são novidades, mas sim
práticas que já vêm sendo utilizadas a muitos anos, com eficiência, em projetos de
software. Muitas das práticas de XP não são unanimidades dentro da comunidade
de desenvolvimento de software, como por exemplo, programação em pares. No
entanto, o valor e benefícios de tais práticas devem ser avaliados em conjunto e não
individualmente, pois elas foram criadas para serem usadas coletivamente, de forma
a reduzir as fraquezas umas das outras. As doze práticas de XP são comentadas
abaixo.
•
O jogo do planejamento: O planejamento de um release e das iterações
são feitos com base nas histórias (casos de uso simplificados) e conta
com a colaboração de toda a equipe de desenvolvimento, inclusive o
21
cliente. No final de um release é feita uma determinação rápida do escopo
do próximo, através da combinação de estimativas e prioridades do
negócio. As estimativas podem ser refeitas durante as iterações à medida
que os programadores aprenderem mais sobre o sistema.
•
Releases pequenos: Kent Beck (1999) diz: “cada release deve ser tão
pequeno quanto possível, contendo os requisitos mais importantes para o
negócio”. Isso possibilita ter releases freqüentes, o que resulta em maior
feedback para clientes e programadores, facilitando o aprendizado e a
correção dos defeitos do sistema. Beck sugere que os releases sejam de
curta duração, normalmente de dois a três meses.
•
Metáfora: A intenção da metáfora é oferecer uma visão geral do sistema,
em um formato simples, que possa ser compartilhada por clientes e
programadores. A idéia da metáfora é que seja feita uma analogia entre o
sistema que está sendo desenvolvido e um sistema, não necessariamente
de software, que todos entendam, com o objetivo de obter um “vocabulário
comum” para a posterior criação de nomes de classes, subsistemas,
métodos, etc.
•
Projeto simples: Pode-se explicar esta prática em duas partes: A primeira
diz que devem ser projetadas as funcionalidades que já foram definidas e
não as que poderão ser definidas futuramente. A segunda diz que deve
ser feito o melhor projeto que possa entregar tais funcionalidades. Esta
prática tem o intuito de enfatizar que o projeto simples deve se concentrar
em soluções simples e bem estruturadas para os problemas de hoje e que
não se deve perder tempo investindo em soluções genéricas que
procurem atender a funcionalidades futuras, pois como os requisitos
mudam constantemente tais soluções genéricas podem não ser mais a
realidade do futuro.
•
Testes constantes: Os testes em XP são feitos antes da programação.
Existem dois tipos de teste: teste de unidade e teste funcional. Os
testes de unidade são feitos para verificar tudo que possa dar errado. Os
testes unitários são automatizados, e toda vez que o programador
escrever código, ele irá verificar se o sistema passa em todos os testes.
Os testes funcionais são usados para verificação, junto ao cliente, do
sistema como um todo. Os testes
servem como um mecanismo para
22
assegurar que o sistema está sempre rodando livre de erros, e também
servem para dar feedback aos programadores e clientes sobre as falhas
encontradas.
•
Refatoramento: São constantes melhorias no projeto do software para
aumentar sua capacidade de se adaptar a mudanças. O refatoramento
consiste
em aplicar uma série de passos para melhorar o projeto do
código existente, tornando-o mais simples e melhor estruturado, sem
alterar sua funcionalidade.
•
Programação em pares: Todo o código produzido em XP é escrito por um
par de programadores, que possuem papéis distintos, sentados lado-alado e olhando para o computador. Um parceiro será responsável pela
codificação e pensará nos algoritmos e na lógica de programação. O outro
parceiro observa o código produzido e tenta pensar mais estrategicamente
em como melhorá-lo e torná-lo mais simples, além de apontar possíveis
erros e pontos de falha. Além disso, as duplas são constantemente
trocadas e os papéis também com o objetivo de que todos os membros da
equipe possam ter conhecimento sobre todas as partes do sistema.
•
Propriedade coletiva do código: A programação em pares encoraja duas
pessoas a trabalharem juntas procurando atingir o melhor resultado
possível. A propriedade coletiva encoraja a equipe inteira a trabalhar mais
unida em busca de qualidade no código fazendo melhorias e
refatoramentos em qualquer parte do código a qualquer tempo.
•
Integração contínua: O código das funcionalidades implementadas pode
ser integrado várias vezes ao dia. Um modo simples de fazer isso é ter
uma
máquina dedicada para integração. O importante é que na
integração as funcionalidades só podem ser integradas se não houver
erros, caso contrário os erros devem ser corrigidos.
•
Semana de quarenta horas: Essa não é uma regra que obriga as equipes
em projetos XP a trabalharem somente 40 horas por semana. No entanto,
Beck diz que não se deve trabalhar duas semanas seguidas além desse
tempo, pois o cansaço e a insatisfação de trabalhar horas extras pode
resultar numa queda de qualidade do código.
23
•
Cliente no local: Deve ser incluído na equipe uma pessoa da parte do
cliente, que irá usar o sistema, para trabalhar junto com os outros e
responder as perguntas e dúvidas. Mesmo que não seja possível obter
alguém da parte do cliente deve-se ter alguém que tenha conhecimento
suficiente do negócio para exercer este papel.
•
Padrões
de
codificação: Como XP prega a propriedade coletiva de
código, onde todos podem alterar e fazer refatoramento de qualquer parte
do código a qualquer momento, então é mais do que necessário que se
tenha padrões de codificação.
3.2.3 XP e os requisitos
XP não se refere explicitamente às técnicas de engenharia de requisitos em
detalhes, mas sobre o processo geral de desenvolvimento de software e que deve
ser feito durante o processo.
Várias práticas XP (ou técnicas utilizadas nestas práticas) podem ser
comparadas com as técnicas levemente modificadas na ER. Especificamente,
durante o jogo do planejamento, as técnicas de elicitação de ER, como entrevistas,
brainstorming e priorização são usadas. A principal "ferramenta" utilizada para
elicitação são os cartões de história em que os usuários escrevem suas histórias de
usuário. Queremos destacar que as histórias do usuário são diferentes dos casos de
uso. Uma história de usuário é uma descrição de um recurso que fornece o valor de
negócio para o cliente. Os casos de uso são descrições das interações do sistema e
de seus usuários (por exemplo, um diálogo especial) e não, necessariamente,
agregam valor aos negócios.
Antes que as histórias possam ser escritas em cartões, os clientes têm que
pensar sobre o que eles esperam do sistema e fazer com que a funcionalidade seja
necessária. Este processo é uma espécie de brainstorming.
Desenvolvedores pedem mais detalhes para determinar o que os clientes
realmente querem que o sistema faça, e estimam o esforço necessário para
desenvolvê-la. Com base nestas estimativas e do tempo disponível na próxima
iteração, os clientes estão, por sua vez, capazes para escolher as histórias a serem
desenvolvidos.
24
3.3 MODELAGEM ÁGIL (MA)
A modelagem ágil é uma metodologia baseada na prática para modelagem
e documentação eficazes de sistemas baseados em software. É um conjunto de
práticas guiado por princípios e valores para profissionais de software aplicarem em
seu dia a dia. Em outras palavras, não define procedimentos detalhados sobre como
criar um determinado tipo de modelo. Em vez disso, fornece conselhos sobre como
ser um modelador eficiente [Ambler, 2004].
Scott Ambler (2004), apresenta os princípios básicos da MA:
•
Inicialmente, a equipe deve entender que seu maior objetivo é desenvolver
software, e qualquer atividade que não auxilie no desenvolvimento deve
ser evitada, caso não seja justificável;
•
O objetivo secundário é possibilitar o próximo trabalho, e esse trabalho
será uma nova versão do software, ou então, dar suporte a versão atual.
Por isso é fundamental desenvolver uma documentação suficiente para
que os próximos envolvidos no processo dêem continuidade ao
desenvolvimento.
•
Diminuir a carga de trabalho para agilizar o processo e suportar as
mudanças. Deve-se ter o discernimento de escolher apenas o essencial.
•
Adotar soluções simples, pois elas resolvem o problema e são fáceis de
desenvolver. Se estratégias simples falham, as complexas também, por
isso, primeiramente optar pela simplicidade;
•
Mudanças ocorrem, fazem parte do processo mesmo em fases adiantadas
do projeto. Geralmente os requisitos estipulados pelo cliente mudam ao
longo do processo, e os desenvolvedores devem estar cientes para
receber essa mudança com naturalidade.
•
Mudar o software incrementalmente ao invés de efetuar grandes
mudanças com menos freqüência.
•
Modelar o software com um propósito bem definido, caso contrário a
modelagem não se justifica. Para criar um modelo, primeiramente é
necessário estipular quem precisará deste modelo, e qual o principal
motivo para sua criação.
25
•
Possuir mais de um modelo, visto que para cada parte do software um
modelo específico é mais adequado. É preferível utilizar diversos modelos
de forma simples para cada parte do software a tentar aplicar modelos
complexos que “representam o sistema como um todo”.
•
Fazer um trabalho de qualidade, pois modelar de forma ágil não significa
desenvolver de forma desleixada.
•
O retorno dos clientes deve ser maximizado, afinal, é ele que investe
tempo e dinheiro no processo. A equipe deve posicionar-se no lugar do
cliente, e imaginar se realmente investiria na solução que está sendo
proposta.
MA não se refere explicitamente a nenhuma técnica de ER, mas algumas das
práticas de MA suporta diversas técnicas de ER (por exemplo, testes e
brainstorming). A idéia básica da MA é oferecer aos desenvolvedores um guia de
como construir modelos que resolvam problemas de projeto. MA destaca a diferença
entre os modelos informais, cujo único objetivo é apoiar frente a frente à
comunicação e os modelos que são preservados e mantidos como parte da
documentação do sistema. Este último é o que é freqüentemente encontrado em
abordagens de ER.
3.4 SCRUM
Scrum é um método para gerenciar o processo de desenvolvimento de
sistemas através da aplicação de algumas idéias da teoria de controle de processos
industriais (adaptabilidade, flexibilidade e produtividade) [Schwaber & Beedle, 2001].
Scrum não propõe qualquer técnica de desenvolvimento de software específico para
a implementação. Ele se concentra em como uma equipe deve trabalhar em
conjunto para produzir um trabalho de qualidade em um ambiente em mudança
[Abrahamsson et al, 2002].
3.4.1 O processo Scrum
26
As fases do Processo de Scrum são: pré-planejamento, desenvolvimento e
pós-planejamento [Abrahamsson et al, 2002].
Na fase de pré-planejamento (pre-game phase), os requisitos são descritos
em um documento chamado backlog. A seguir os requisitos são classificados por
prioridade, onde são estimados “o esforço” para o seu desenvolvimento. Nesta fase
inclui a definição dos integrantes da equipe, identificação da necessidade de
treinamento, as ferramentas a serem utilizadas, como também uma lista com os
prováveis riscos de projeto. A fase é concluída com uma proposta de arquitetura de
software. As alterações futuras devem ser descritas no backlog.
Na fase de desenvolvimento (game phase), os riscos previamente
identificados devem ser mapeados e acompanhados ao longo do projeto para avaliar
o seu impacto. Nesta fase, o software é desenvolvido em ciclos interativos (sprints),
onde são adicionadas novas funcionalidades. Cada um desses sprints com duração
de 2 a 4 semanas são desenvolvidos de forma tradicional (análise, projeto,
implementação e testes).
Já na fase de pós-planejamento (post-game phase) é onde acontece a
integração do software, os testes finais e a documentação do usuário. A equipe se
reúne para analisar o estado do projeto e o software atual é apresentado ao cliente.
As principais técnicas são o scrum product backlog, sprints e scrums. No que
diz respeito à ER, o product backlog desempenha um papel especial no scrum.
Todos os requisitos considerados necessários ou úteis para o produto estão listados
no product backlog. Ele contém uma lista ordenada de todos as funcionalidades,
melhorias e bugs. O product backlog pode ser comparado com um documento de
requisitos incompleto e em constante mudança, contendo os requisitos necessários
para o desenvolvimento. Cada sprint, iteração com 30 dias de desenvolvimento, está
prevista com base nas informações incluídas no product backlog. Tarefas
selecionadas a partir do product backlog são movidas para o sprint backlog.
Nenhuma alteração será feita para o sprint backlog durante o sprint. Ou seja, não há
flexibilidade nos requisitos durante um sprint, mas há total flexibilidade para o cliente
escolher os requisitos do próximo sprint.
Durante uma sprint a equipe de desenvolvimento passa por várias fases
(reunião de planejamento da sprint, sprint, revisão da sprint). O objetivo da reunião
de revisão da sprint é de que os participantes (clientes e desenvolvedores) tenham
27
entendimento do sistema, sua arquitetura técnica e design, bem como as
funcionalidades entregues.
O conhecimento adquirido na reunião de revisão de sprint e o product backlog
atual é a base para a próxima reunião de planejamento do sprint. Uma parte da
reunião de revisão de sprint, onde os participantes adquirem conhecimentos sobre o
sistema, pode ser comparado à revisão de requisitos e a uma apresentação do
protótipo evolutivo para o cliente.
3.5 AS METODOLOGIAS DO CRYSTAL
As Metodologias do Crystal são uma família de metodologias diferentes, das
quais as metodologias adequadas podem ser escolhidos para cada projeto. Os
diferentes membros da família podem ser adaptados para atender diferentes
circunstâncias. Os membros da família Crystal são indexados por cores diferentes
para indicar o "peso": claro, amarelo, laranja, vermelho, magenta, azul, violeta, e
assim por diante. Quanto mais escura for a cor, mais "pesada" será a metodologia.
Um projeto com 80 pessoas precisa de metodologias mais pesadas do que um com
apenas 10 pessoas [Abrahamsson et al, 202].
Existem algumas características comuns à família Crystal, tais como o
desenvolvimento incremental com ciclos de no máximo quatro meses, ênfase maior
na comunicação e cooperação das pessoas, não limitação de quaisquer práticas de
desenvolvimento, ferramentas ou produtos de trabalho e incorporação de objetivos
para reduzir produtos de trabalho intermediários e desenvolvê-los como projetos
evoluídos.
28
Figura 6: Um incremento do Crystal Laranja [Abrahamsson et al, 2002]
O ciclo de vida desta família de metodologia é baseado nas seguintes
práticas:
•
Staging: Planejamento do próximo incremento do sistema. A equipe
seleciona os requisitos que serão desenvolvidos na iteração e o prazo
para sua entrega;
•
Edição e revisão: Construção, demonstração e revisão dos objetivos do
incremento;
•
Monitoramento: O processo é monitorado com relação ao progresso e
estabilidade da equipe. É medido em marcos e em estágios de
estabilidade;
•
Paralelismo e fluxo: No Crystal laranja, as diferentes equipes podem
operar
com
máximo
paralelismo.
Isto
é
permitido
através
do
monitoramento da estabilidade e da sincronização entre as equipes;
•
Inspeções de usuários: são sugeridas duas a três inspeções feitas por
usuários a cada incremento;
•
Workshops refletivos: são reuniões que ocorrem antes e depois de cada
iteração com objetivo de analisar o progresso do projeto.
29
•
Work Products (Produtos de Trabalho): seqüência de lançamento,
modelos de objetos comuns, manual do usuário, casos de teste e
migração de código.
•
Padrões: padrões de notação, convenções de produto, formatação e
qualidade usadas no projeto.
•
Ferramentas: ferramentas mínimas utilizadas.
3.6 FEATURE DRIVEN DEVELOPMENT (FDD)
FDD é um processo de curta iteração para desenvolvimento de software com
foco no projeto e na fase de desenvolvimento [Abrahamsson et al, 2002]. FDD não
recomenda um modelo de processo específico.
FDD é composto por cinco processos seqüenciais. Os três primeiros são
executados no início do projeto e os dois últimos durante cada iteração [Fowler,
2000].
•
Desenvolvimento de um modelo geral
•
Construção de uma lista de funcionalidades
•
Planejamento por funcionalidade
•
Projeto por funcionalidade
•
Desenvolvimento por funcionalidade
Os dois papéis mais importantes na FDD são o programador-chefe, um
desenvolvedor experiente capaz de liderar equipes pequenas de desenvolvimento e
de participar da análise de requisitos e da modelagem do projeto, e o proprietário da
classe, que trabalhará com a classe que é atribuída a ele [Lefebvre et al, 1999]. Na
primeira fase, um modelo geral é desenvolvido por membros do domínio e pelos
desenvolvedores. A lista de funcionalidades é construída na segunda fase com base
no modelo global. O modelo global é composto de diagramas de classe com
classes, links, métodos e atributos. As classes e links estabelecem a forma do
modelo. Os métodos expressam o comportamento e é a base para a construção da
lista de funcionalidades. Uma funcionalidade em FDD é uma função que agrega
valor para o cliente. As funcionalidades da lista de funcionalidades são priorizadas
30
pela própria equipe. A lista de funcionalidades é revisada pelos membros do domínio
[Lefebvre et al, 1999].
FDD propõe um encontro semanal de 30 minutos para que a situação das
funcionalidades seja discutida e um relatório sobre a reunião seja escrito [Lefebvre
et al, 1999]. Esses relatórios podem ser comparados com o monitoramento / gestão
dos requisitos.
3.7 MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS (DSDM)
O framework DSDM consiste em três fases sequenciais: Pré-Projeto, Projeto
e Pós-Projeto. A fase de Projeto do DSDM é a mais elaborada das três fases. Ela
consiste em cinco níveis formados por uma abordagem passo-a-passo e iterativa no
desenvolvimento do software. As três fases e os correspondentes níveis são
explicados a seguir.
Figura 7: Processo DSDM [Stapleton, 95]
Fase 1 - O Pré-Projeto: Na fase do pré-projeto, o projeto candidato é
identificado, tratando-se depois do seu plano de financiamento e sendo assegurado
um compromisso de realização. Tratar destas questões numa fase inicial evita
problemas futuros em fases mais avançadas do desenvolvimento do projeto.
31
Fase 2 - O Ciclo de Vida do Projeto: A visão geral de um processo DSDM,
presente na Figura 7, representa o ciclo de vida do projeto nesta segunda fase da
metodologia. Ela mostra os 5 níveis que a equipe de desenvolvimento terá de
percorrer para criar um software. Os dois primeiros níveis, o Estudo de Viabilidade e
o Estudo de Negócio, são fases sequenciais que se complementam. Depois destas
fases estarem concluídas, o sistema é desenvolvido iterativamente e de forma
incremental nos níveis de análise funcional, projeto e implementação.
Nível 1 - O Estudo de Viabilidade: Durante
este
nível
do
projeto,
a
viabilidade de utilização da DSDM para este projeto é examinada. Os pré-requisitos
para o uso da DSDM são encontrados, respondendo a questões como: “Este projeto
pode ir de encontro às necessidades de negócio apontadas?”, “Este projeto é
adequado ao uso da DSDM?” e “Quais são os riscos mais importantes envolvidos?”.
As técnicas mais importantes utilizadas nesta fase são os workshops.
Para entrega ao cliente, são preparados neste nível o relatório e o protótipo
de viabilidade que dizem respeito à viabilidade do projeto em mãos. A estes,
adicionam-se um esboço global do plano para o resto do projeto e um registo de
risco que identifica os riscos mais importantes no projeto.
Nível 2 - O Estudo do Negócio: O estudo do negócio incrementa todo o
trabalho realizado no estudo de viabilidade. Depois do projeto ser declarado viável
para o uso da DSDM, este nível examina as necessidades dos usuários envolvidos.
Mais uma vez, os workshops são uma das técnicas mais valiosas. A informação
retirada destas sessões é colocada numa lista de requisitos. Uma importante
propriedade desta lista de requisitos é a possibilidade de se definir prioridades.
Baseado neste escalonamento, um plano de desenvolvimento é construído como
uma linha mestra para o resto do projeto.
No final deste nível, deverão estar prontos para serem entregues ao cliente:
uma definição de área de negócio que descreve o contexto do projeto dentro da
companhia, a definição da arquitetura do sistema que fornece uma arquitectura
global inicial do software em desenvolvimento juntamente com o plano de
desenvolvimento que realça os passos mais importantes no processo de
desenvolvimento. Na base destes dois últimos documentos está a lista de
prioridades dos requisitos. Por fim, o registro de risco é atualizado com os fatos que
foram identificados durante esta fase da DSDM.
32
Nível 3 - Análise Funcional: Os requisitos que foram identificados nos níveis
anteriores são convertidos para um modelo funcional. A prototipagem é uma das
técnicas chaves dentro deste nível, que ajuda no bom envolvimento do usuário final
com o projeto. O protótipo desenvolvido é revisto pelos diferentes grupos de
usuários. Para assegurar a qualidade do projeto, os testes são desenvolvidos em
cada iteração da DSDM. Uma importante parte dos testes é realizada na análise
funcional. Isto pode ser feito através de testes com usuários finais e revisão da
documentação. Neste nível, é necessário entregar ao cliente o modelo funcional e o
protótipo funcional. Além destes dois documentos, a lista de requisições é
atualizada, sendo apagados os itens que foram desenvolvidos e repensado as
prioridades dos requisitos restantes.
Nível 4 – Projeto: O ponto central desta iteração da DSDM é a integração das
componentes funcionais do nível anterior num sistema que satisfaça as
necessidades do usuário. Mais uma vez, os testes são uma das atividades mais
importantes. Ao usuário, serão entregues o protótipo do projeto para que estes
efetuem testes ao produto-protótipo.
Nível 5 – Desenvolvimento: No nível de desenvolvimento, o sistema testado e
a sua documentação são entregues aos usuários finais que deverão começar a ser
treinados para a futura utilização do novo software. O sistema a ser entregue foi
revisto para incluir todos os requisitos que foram definidos nos primeiros níveis do
projeto.
Fase 3 - Pós-Projeto: A fase de pós-projeto assegura um sistema eficiente.
Isto é desenvolvido através da manutenção e melhoramentos de acordo com os
princípios da DSDM. Até mesmo a iniciação de novos projetos, para atualizar o
sistema existente ou desenvolver um novo sistema, é possível.
3.8 DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD)
Os
princípios
do
ASD
são
provenientes
de
pesquisas
sobre
o
desenvolvimento iterativo. ASD fornece uma estrutura para o desenvolvimento de
sistemas grandes e complexos com orientação suficiente para impedir os projetos de
cair no caos. O método estimula o desenvolvimento iterativo e incremental com
33
prototipagem constante. O processo ASD contém três fases que se sobrepõem:
especulação, colaboração e aprendizagem (ver Figura 8).
Figura 8: Processo ASD [Highsmith, 96]
Highsmith (1996) diz que os nomes das fases enfatizam a diferença do
desenvolvimento de software tradicional. "Especulação" em vez de "planejamento",
porque o planejamento sempre indica que não há incertezas. A importância do
trabalho em equipe é destacada pela "colaboração". Em um ambiente imprevisível,
pessoas têm a necessidade de se comunicar para serem capazes de lidar com as
incertezas.
"Aprendizagem" salienta que os requisitos mudam durante o desenvolvimento
e existe a necessidade de um conhecimento sobre isso. Na ASD desvios não são
uma falha do sistema, mas levarão para uma solução correta.
Cada projeto começa com a definição da missão do projeto, uma breve
declaração indicando o curso do projeto. Durante a fase de iniciação do projeto, o
cronograma geral bem como os prazos e os objetivos para os ciclos de
desenvolvimento são definidos. Um ciclo em ASD dura entre quatro e oito semanas.
Como ASD é orientada a componentes em vez de orientado a tarefas, ela foca nos
resultados e sua qualidade. A próxima fase é o planejamento do ciclo adaptativo que
contém a fase de colaboração onde o ASD aborda a visão orientada a componentes.
34
Ciclos do planejamento são repetidos quando ocorrem novas exigências e os
componentes têm de ser refinados. Revisões com a presença do cliente
demonstram a funcionalidade do software durante o ciclo. A fase de release é a
última fase de um projeto ASD. Não há recomendações de como esta fase deve ser
realizada, mas a ênfase está na importância de capturar as lições aprendidas.
Como em outros processos ágeis, ASD é baseada em ciclos de
desenvolvimento iterativo. ASD destaca que um método cascata só funciona em um
ambiente bem compreendido e bem definido. Mas as mudanças são freqüentes no
desenvolvimento de software e é importante ser capaz de reagir às mudanças e
utilizar um método de tolerância às mudanças.
4 TÉCNICAS DE ENGENHARIA DE REQUSITOS PARA MÉTODOS ÁGEIS
Quase todas as técnicas de engenharia de requisitos descritas no capítulo 2
podem ser encontradas nas diferentes abordagens ágeis, embora elas não possam
ser utilizadas na mesma área ou na mesma medida. Este capítulo descreve a
maneira pelas quais as abordagens ágeis incorporam essas técnicas e dá um breve
resumo dessa análise.
4.2 ENVOLVIMENTO DO CLIENTE
Um ponto-chave em todas as técnicas de Desenvolvimento Ágil é ter 'acesso'
ao cliente ou 'in loco' (XP). Esta é a base para uma comunicação e um feedback
rápido. Ambos os levam a uma melhor compreensão dos requisitos (no lado do
desenvolvedor) e do processo de desenvolvimento (no lado do cliente). Envolver o
cliente é o primeiro objetivo das abordagens ágeis. No XP, por exemplo, assume-se
que um representante do usuário é o ideal, aquele que: pode responder
corretamente todas as perguntas que os desenvolvedores possam ter, ele/ela esteja
habilitada a tomar decisões vinculativas e sejam capazes de tomar as decisões
corretas.
35
O envolvimento dos interessados é também um ponto chave no trabalho atual
de ER. As partes interessadas têm sua própria visão sobre o sistema a ser
desenvolvido.
As diferentes técnicas de levantamento de ER têm como objetivo obter o
máximo de informações possíveis sobre o sistema, de todas as pessoas envolvidas
(usuários, especialistas do domínio, etc.) Em 1995, o relatório CHAOS do Standish
Group [Group, 1995] mostraram a importância crítica da participação do cliente. O
envolvimento do cliente foi determinado como sendo o motivo número um para o
sucesso do projeto, enquanto a falta de envolvimento do usuário foi a principal razão
dada para os projetos que tiveram dificuldades.
Assim, a ER tradicional e métodos ágeis concordam sobre a importância da
participação dos interessados. A diferença entre as abordagens tradicionais e os
métodos ágeis é que nas abordagens tradicionais o cliente está envolvido
principalmente durante a fase de ER e não durante a fase do desenvolvimento do
software em si, já os métodos ágeis envolvem o cliente no processo de
desenvolvimento como um todo.
Embora os métodos ágeis sejam baseados em um forte envolvimento do
cliente durante todo o processo de desenvolvimento, ainda há um problema. Na
maioria dos casos, os métodos pedem vários clientes com diferentes experiências,
mas às vezes apenas um cliente está disponível para trabalhar com a equipe de
desenvolvimento. Isso significa que nem todas as questões levantadas podem ser
respondidas com detalhes suficientes. Isso pode resultar em atrasos no
desenvolvimento ou em tomada de decisões potencialmente incorretas. Além disso,
algumas áreas de negócio não podem ser suficientemente compreendidas pelo
cliente, de modo que ele não pode dizer a equipe de desenvolvimento sobre os
requisitos relacionados. Mesmo que os requisitos sejam levantados em sessões de
grupo (DSDM, Scrum) não é garantido que os usuários ou clientes com a base
necessária estejam presentes.
Mas o mesmo problema surge em levantamento de requisitos tradicionais.
Apesar de existirem diversas técnicas para elicitar requisitos, ninguém pode garantir
que todas as áreas problemáticas sejam cobertas. Outras técnicas como revisões ou
testes são necessários para garantir que esses problemas sejam descobertos.
36
4.3 ENTREVISTAS
Como o envolvimento do cliente é o principal objetivo do desenvolvimento ágil
de software, a técnica mais comum relacionado com a ER são as entrevistas. As
entrevistas permitem o acesso direto para o conhecimento necessário. É conhecido
por todos que as cadeias de transferência de conhecimento levam à erros e à
desinformação. Desenvolvedores que tem contato direto com o cliente conseguem
informações com menos erros.
As
comunicações
pessoais
estabelecem
relações
entre
clientes
e
desenvolvedores, aumentando a confiança no trabalho. Todas as abordagens ágeis
enfatizam que falar com o cliente é a melhor maneira de obter as informações
necessárias para o desenvolvimento e para evitar mal-entendidos. Se alguma coisa
não está clara ou está definida de forma vaga, clientes ou colaboradores devem
tentar se comunicar com a pessoa responsável para evitar a transferência indireta
de conhecimento.
4.4 PRIORIZAÇÃO
Priorizações podem ser encontradas em todas as abordagens ágeis. Uma
prática comum é o desenvolvimento da funcionalidade com a mais alta prioridade
para ser capaz de entregar o que agrega maior valor ao cliente. Durante o
desenvolvimento, o conhecimento e a compreensão do projeto aumenta e novos
requisitos são adicionados. Portanto, a priorização é repetida com freqüência
durante todo o processo de desenvolvimento para manter as prioridades
atualizadas. A priorização ajuda os clientes a entender as diferenças entre os
requisitos e de que forma eles podem afetar o sistema.
4.5 JAD
Sessões JAD são usados em ASD para aumentar a participação do cliente.
Durante as sessões JAD, os desenvolvedores e clientes discutem as características
37
do produto desejado. Esse tipo de discussão pode ser muito produtivo,
principalmente por que o líder da sessão impede que os participantes fujam do foco
da reunião. Além disso, mesmo focando a interação com o cliente às sessões curtas
de JAD, não se consegue ter a mesma eficiência que no XP, que o cliente está
presente durante o processo. Os resultados das sessões, geralmente, são
documentados e acessíveis, caso haja dúvidas mais tarde. A exigência de
documentação pode ser descartada num contexto ágil. Para ter um feedback
constante, as sessões JAD devem ser realizadas com freqüência durante o
processo de desenvolvimento.
Em DSDM, sessões JAD são usadas para obter a compreensão do novo
sistema no início de um projeto. JAD promove a compreensão, cooperação e
trabalho em equipe entre os diferentes grupos de participantes. Elas também
estimulam a participação e a confiança do cliente. JAD está claramente em sintonia
com os princípios ágeis.
4.6 MODELAGEM
Embora a modelagem seja usada em MA, o objetivo é diferente. Na MA, os
modelos são, por exemplo, usados para comunicar o entendimento de uma pequena
parte do sistema em desenvolvimento. Estes modelos são em sua maioria modelos
descartáveis. Eles são desenhades em um quadro branco ou papel e apagados
após cumprir sua finalidade. A maioria dos modelos não se torna parte da
documentação permanente ou da modelagem final do sistema. Quando a
modelagem é usada em ER, existem diferentes modelos que começam com uma
visão geral do sistema como um todo, seguido por outros modelos que entram em
mais
detalhes.
Todos
estes
modelos
normalmente
se
tornam
parte
da
documentação do sistema e precisam ser mantidos atualizados.
O objetivo da modelagem no FDD é o mesmo que na ER: O modelo
desenvolvido representa todo o sistema e o desenvolvimento é baseado nesse
modelo. Mas como o projeto e a fase de construção são iterativos, as mudanças nos
requisitos e, em conseqüência dos modelos, podem ser feitos mais tardiamente no
processo de desenvolvimento. O modelo representa um primeiro passo para iniciar o
desenvolvimento, mas não descreve completamente o sistema final.
38
4.7 DOCUMENTAÇÃO
Uma documentação completa e consistente é geralmente escassa no
desenvolvimento ágil de software. Alguns métodos ágeis incluem um tipo de
documentação ou recomendam o uso de um documento de requisitos (DSDM,
Scrum, Crystal), mas a decisão dos principais conteúdos ou a ampliação destes
resta à equipe de desenvolvimento e não está descrito em detalhes.
A falta de documentação pode causar problemas a longo prazo em
Desenvolvimento
Ágil,
sendo
compensada
pela
velocidade
no
início
do
desenvolvimento. A documentação é usada para compartilhar o conhecimento entre
as pessoas. Um novo membro da equipe terá muitas perguntas sobre o projeto, as
quais podem ser respondidas através da leitura e compreensão devida da
documentação. Pedir para outros membros da equipe, pode atrasar o trabalho, por
causa do tempo necessário para explicar um projeto complexo.
A mesma situação surge quando mudanças são feitas em um projeto
acabado. É possível que os desenvolvedores que trabalharam inicialmente no
projeto não estejam disponíveis (mudaram-se para outra empresa ou estejam
trabalhando em um novo projeto) e uma nova equipe tenha que fazer as mudanças.
Problemas a longo prazo são minimizados nos métodos ágeis, muitas vezes, por
que o código produzido é limpo e compacto.
As abordagens tradicionais tentam produzir documentação suficiente para ser
capaz de responder a maioria das perguntas que poderiam ser feitas no futuro. Para
ser capaz de fazer isso, eles precisam antecipar futuras questões futuras e
respondê-las de uma forma concisa e compreensível. Ambos os casos são difíceis,
talvez por isso que seja tão difícil escrever bons documentos. Normalmente, para
obter uma boa cobertura das questões futuras, as abordagens tradicionais produzem
documentação em excesso (ou seja, respondendo a perguntas que, de fato, nunca
serão feitas e desperdiçam dinheiro em escrever respostas a elas). Isso resulta em
problemas com a manutenção de todos os documentos em dia e problemas com os
leitores quando tentam encontrar a informação para as suas questões atuais.
As vantagens ou desvantagens da documentação estão relacionadas com o
tamanho da equipe. Com uma grande equipe, talvez seja melhor ter uma
39
documentação mais forte, em vez de explicar a mesma coisa várias vezes para
pessoas diferentes. Quando os métodos ágeis tentam escalar até equipes maiores,
muitas vezes aumentam a quantidade de documentação a ser produzida em relação
a projetos pequenos [Cockburn, 2002].
4.8 VALIDAÇÃO
A validação de requisitos desempenha um papel importante em todas as
abordagens ágeis de desenvolvimento de software. O software é validado através de
reuniões de revisão e testes de aceitação. Isso aumenta a confiança dos clientes no
programa e na equipe de desenvolvimento, porque o sistema demonstra capacidade
de trabalhar para o qual foi proposto. Reuniões de análise também mostram se o
projeto está no escopo e dentro do cronograma.
Todas as abordagens têm uma forma semelhante para validar os requisitos.
Eles usam diferentes tipos de reuniões de avaliação para apresentar o software
desenvolvido. Os clientes podem usar o software, ter uma experiência de como o
sistema funciona em detalhes e quais funcionalidades já foram desenvolvidas. Se
houver questionamentos, estas podem ser respondidas imediatamente pelos
desenvolvedores que estão presentes em cada reunião de revisão. Os clientes
também podem discutir o modo como os recursos foram aplicados com os
desenvolvedores e pedir mudanças no projeto. Durante as reuniões de revisão eles
aprendem sobre as forças, fraquezas, as vantagens e os limites do projeto e da
tecnologia. Os clientes podem verificar se os requisitos desenvolvidos foram
entendidos e, conseqüentemente, se foram desenvolvidos corretamente. Os clientes
também podem executar testes de aceitação para validar se o sistema reage da
maneira esperada e, se não, esclarecer o problema. As perguntas e os pedidos de
mudança influenciam diretamente o desenvolvimento posterior. Dependendo das
circunstâncias do método e do projeto, o software é colocado em produção após
cada revisão. Especialmente no XP, onde o cliente deve estar sempre presente
durante o desenvolvimento, a possibilidade de ser capaz de fazer perguntas e ver
que os testes estão passando aumenta a confiança na equipe de desenvolvimento e
no software.
40
Como todos os métodos ágeis são baseados em pequenas versões, a
validação é executada fortemente. Pelo menos em cada nova versão, os
desenvolvedores obtêm um feedback do cliente. Este tipo de desenvolvimento é
comparável ao de prototipagem evolutiva, onde ambos são baseados na idéia de
entregar freqüentemente um pedaço de código funcionando para melhorar o
feedback. A diferença pode ser encontrada na forte ênfase nos testes, pelas
abordagens ágeis.
4.9 GESTÃO DOS REQUISITOS
Gerenciamento de requisitos limitado é um 'atributo' comum nos métodos
ágeis de desenvolvimento de software. Do ponto de vista de ER, deve ser possível
rastrear as mudanças feitas nos requisitos, no projeto, ou na documentação, para
ver porque as alterações foram feitas. Mas o acompanhamento dessas mudanças
resulta em mais trabalho e documentação adicional.
A falta de documentação pode ser crítica, se os requisitos formam um
contrato legal entre duas organizações. Essa é a razão pela qual os contratos de
projetos ágeis, muitas vezes são baseados em tempo e despesas, e não em preço
fixo / escopo fixo. Contratos baseados em preço fixo / escopo fixo criam uma
confiança, definindo o que o cliente deverá ter, por que preço e em que tempo.
Abordagens ágeis tentam criar essa confiança, trabalhando de forma mais próxima
do cliente. Como o cliente vê a equipe de desenvolvimento trabalhando no software
e não fazendo outra coisa, ele acredita que a equipe vai entregar o software,
satisfazendo suas necessidades.
No entanto, os métodos ágeis oferecem uma boa base para gerenciamento
de requisitos. Todos os requisitos são escritos em cartões indexados (as histórias do
usuário) ou mantidos no product backlog. A diferença é o nível de detalhe em que
um requisito, história do usuário ou funcionalidade é descrita: práticas ágeis
geralmente omitem os detalhes e posterga-os para serem esclarecidos no momento
em que o requisito esteja, literalmente, sendo desenvolvido.
41
4.10 OBSERVAÇÃO, ANÁLISE SOCIAL E BRAINSTORM
Estas técnicas não são explicitamente mencionadas em nenhum método ágil
de desenvolvimento de software. Mas como são as técnicas fundamentais no
processo de levantamento de requisitos, elas podem ser usadas com qualquer uma
das abordagens ágeis. Métodos de observação podem fornecer benefícios para o
levantamento de requisitos, como, por exemplo, um 'usuário' altamente qualificado
pode não ser a melhor pessoa para falar sobre o processo de trabalho. Essas
pessoas às vezes esquecem detalhes importantes, pois o trabalho tem se tornado
parte de sua rotina. Esses detalhes podem ser descobertos durante a observação.
4.11 REQUISITOS NÃO-FUNCIONAIS
Nas abordagens ágeis, gerenciamento de requisitos não-funcionais são mal
definidos. Quando os clientes ou usuários falam sobre o que eles querem que o
sistema
faça,
normalmente
não
se
lembram
dos
recursos,
manutenção,
portabilidade, segurança ou desempenho. Os requisitos não-funcionais tendem a ser
relacionados com os requisitos funcionais e são difíceis de serem expressos. Mas a
maioria dos requisitos não-funcionais deve ser conhecida antes da fase de
desenvolvimento, pois pode afetar a escolha do banco de dados, da linguagem de
programação ou do sistema operacional. Métodos ágeis devem incluir de forma mais
explícita a manipulação dos requisitos não-funcionais. Por outro lado, a engenharia
de requisitos, não define explicitamente um tratamento para determinar os requisitos
não-funcionais.
5 CONCLUSÃO
As fases do processo de ER: elicitação, análise e validação estão presentes
em todos os processos ágeis. As técnicas utilizadas variam nas diferentes
abordagens. Como as fases não são tão claramente separadas como no processo
de ER, elas terminam se fundindo em alguns aspectos (o Jogo de Planejamento em
42
XP, por exemplo, é uma técnica de elicitação e análise). Elas também se repetem a
cada iteração, o que torna mais difícil distingui-las entre as fases e, portanto,
compará-las com as fases do processo de ER. As técnicas utilizadas em processos
de desenvolvimento ágil são, por vezes, descritas vagamente e o desenvolvimento
efetivo dessas técnicas é feito pelos desenvolvedores. Este é o resultado da ênfase
em pessoas altamente qualificadas em métodos ágeis: "bons" desenvolvedores
farão a "coisa certa". As abordagens tradicionais, por outro lado, descrevem em
detalhes o que precisa ser feito e assim provê que qualquer desenvolvedor com um
pouco mais de experiência pode fazer a coisa "certa". Infelizmente, determinar
inicialmente o que é a coisa certa em um determinado contexto de projeto é muito
difícil.
A Gestão de ER é baseada em documentos, o que não é muito bem
representado
nas
abordagens
ágeis
de
desenvolvimento
de
software.
Documentação é uma parte do desenvolvimento ágil de software, mas não na
mesma medida como na ER tradicional. Como todas as abordagens ágeis incluem
pelo menos um mínimo de documentação, é de responsabilidade da equipe de
desenvolvimento escrever a documentação suficiente para o desenvolvimento.
De modo geral, em áreas-chave (como o envolvimento das partes
interessadas) métodos ágeis e ER estão seguindo caminhos similares. A principal
diferença é a ênfase na quantidade de documentação necessária de um projeto
efetivo. Assim, as duas abordagens são bem mais parecidas do que aparentam ser.
43
6 REFERÊNCIAS
ABRAHAMSSON, Pekka, SALO, Outi, RONKAINEN, Jussi e WARSTA,
Juhani. Agile software developlment methods. Review and analysis. Espoo 2002.
VTT Publications 478. 107 p.
AMBLER, Scott. Agile Modeling. John Wiley & Sons., 2001.
AMBLER, Scott. Modelagem Ágil: Práticas
eficazes para a Programação
eXtrema e o Processo Unificado. Bookman. 2004.
BECK, Kent. Extreme Programming explained. Addison-Wesley, 1999.
BECK, Kent. Programação extrema explicada: acolha as mudanças.
Bookman. 2004.
CHECKLAND, Peter e SCHOLES, Jim. Soft Systems Methodology in Action.
John Wiley & Sons., 1999.
COCKBURN, Alistair. Agile Software Development. Addison-Wesley, 2002.
DAVIS, Alan M. Software Requirements Revision Objects, Functions, &
States. Prentice Hall PTR, 1994.
FOWLER, Martin. The new methodology. http://www.martinfowler.com/
articles/newMethodology.html, 2000.
GROUP, Standish. Chaos Report. www.standishgroup.com, 1995.
HIGHSMITH, James A. Adaptive Software Development. Dorset House
Publishing, 1996.
LEFEBVRE, Eric, COAD, Peter Coad e De LUCA, Jeff. Java Modeling in Color
with UML. Prentice Hall PTR, 1999.
SOMMERVILLE, Ian e KONTONYA, Gerald. Requirements Engineering. John
Wiley & Sons, 1997.
MACAULAY, Linda A. Requirements Engineering. Springer Verlag, 1996.
McPHEE, Christopher. Requirements engineering for projects with critical
time-to-market. Master’s thesis, University of Calgary, 2001.
NIELSEN,
Jakob.
The
Use
and
Misuse
of
Focus
Groups.
http://www.useit.com/papers/focusgroups.html, 1997.
POTTS,
Colin.
Requirements
Reviews:
Understanding
Customer
Requirements. http://www.cc.gatech.edu/computing/classes/cs3302 98 summer/721-reqts/sld001.htm, 1998.
44
ROBERTSON, Suzanne. Requirements testing: Creating an effective
feedback loop. In FEAST 2000, London, July 2000.
SCHWABER, Ken e BEEDLE, Mike. Agile Software Development with Scrum.
Prentice Hall PTR, 2001.
STAPLETON, Jennifer. DSDM - Dynamic System Development Method.
Addison-Wesley, 1995.
TEITELROIT, Ricardo e BOFF, Luiz Henrique. Metodologia JAD – Joint
Application Design: um novo enfoque de modelagem de sistemas? Anais do
Encontro Nacional de Pós-graduação em Adminitração, 1991.
WIEGERS, Karl E. Software Requirements. Microsoft Press, 1999.
45