Engenharia de requisitos para metodos ageis dissertacao

262 visualizações

Publicada em

Engenharia de requisitos para metodos ageis dissertacao

Publicada em: Engenharia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
262
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Engenharia de requisitos para metodos ageis dissertacao

  1. 1. UNIVERSIDADE FEDERAL DE PERNAMBUCO PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA EEEENGENHARIA DENGENHARIA DENGENHARIA DENGENHARIA DE RRRREQUISITOS PARAEQUISITOS PARAEQUISITOS PARAEQUISITOS PARA MMMMÉTODOSÉTODOSÉTODOSÉTODOS ÁÁÁÁGEISGEISGEISGEIS AutorAutorAutorAutor Fernanda Rodrigues dos Santos d’Amorim OrientadorOrientadorOrientadorOrientador Prof. Jaelson Freire Brelaz de Castro Recife, julRecife, julRecife, julRecife, julho 2008ho 2008ho 2008ho 2008 Universidade Federal de Pernambuco Centro de Informática
  2. 2. FERNANDA RODRIGUES DOS SANTOS D’AMORIM ENGEHARIA DE REQUISIOS PARA MÉTODOS ÁGEIS Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Prof. Jaelson Brelaz de Castro Recife 15 de Julho de 2008
  3. 3. RESUMO Coletar, entender, e gerenciar requisitos é um aspecto crítico em todos os métodos de desenvolvimento. Para métodos ágeis isto também é importante. Em particular, várias abordagens ágeis lidam com requisitos a fim de implementá-los corretamente e satisfazer as necessidades do cliente. Estas práticas focam numa interação contínua com o cliente para dar suporte a evolução dos requisitos, priorizá-los e entregar, de maneira progressiva, as funcionalidades mais importantes. Este trabalho tem como objetivo prover uma visão geral de como técnicas da Engenharia de Requisitos são aplicadas a desenvolvimento ágeis a fim de garantir a qualidade do produto final, bem como, entender como e porque a Engenharia de Requisitos ágil difere da Engenharia de Requisitos tradicional. Palavras-chave: Engenharia de Requisitos, Métodos Ágeis, Processos Ágeis, Gerenciamento de Variabilidade.
  4. 4. 7 ABSTRACT Collecting, understanding, and managing requirements is a critical aspect in all development methods. This is important for Agile Methods too. In particular, several agile approaches deal with requirements in order to implement them correctly and satisfy the needs of the customer. These practices focus on a continuous interaction with the customer to address the requirements evolution over time, prioritize them, and deliver the most valuable functionalities first. The main goal of this work is to provide a general view of how the Requirement Engineering techniques have been applied to agile development in order to assure the quality of the final product, as well as, to understanding how and why agile Requirement Engineering differs from traditional Requirement Engineering. Keywords: Requirement Engineering, Agile Methods, Agile Process, Variability Management.
  5. 5. 8 SUMÁRIO 1. Introdução ..............................................................................................................10 2. Métodos Ágeis.........................................................................................................13 3. Engenharia de Requisitos Tradicional e Ágil......................................................19 3.1 O Processo da Engenharia de Requisitos Tradicional .............................20 3.1.1 Elicitação ...............................................................................................20 3.1.2 Análise e Negociação.............................................................................20 3.1.3 Documentação.......................................................................................21 3.1.4 Validação ...............................................................................................21 3.1.5 Gerenciamento de Requisitos ..............................................................21 3.2 Processos de ER e o seu Impacto em Métodos Ágeis................................21 4. Técnicas e Abordagens da Engenharia de Requisitos para Métodos Ágeis .....23 4.1 Envolvimento do Cliente .............................................................................23 4.2 Elicitação ......................................................................................................24 4.3 Modelagem ...................................................................................................25 4.4 Documentação..............................................................................................25 4.5 Validação ......................................................................................................25 4.6 Gerenciamento .............................................................................................26 4.7 Requisitos Desnecessários ...........................................................................28 4.8 Falha de Comunicação ................................................................................29 4.9 Requisitos Não Funcionais..........................................................................30 5. O Papel e Responsabilidades de Stakeholders em Métodos Ágeis .....................32 5.1 Clientes..........................................................................................................32 5.2 Desenvolvedores...........................................................................................32 5.3 Gerentes........................................................................................................33 6. Conclusão................................................................................................................34 7. Referências Bibiográficas......................................................................................37
  6. 6. 9 LISTA DE FIGURAS Figura 1: Ciclo de Desenvolvimento Ágil [1]............................................... 15 Figura 2: Custo de Mudanças [1]................................................................... 27 LISTA DE TABELAS Tabela 1: The Crystal Family [1]................................................................... 17 Tabela 2: Principais Causas de Falhas de Projetos [1].................................. 19
  7. 7. 10 1. Introdução Mudanças cada vez mais rápidas no ambiente de negócio, no qual a maioria das organizações opera, estão desafiando as abordagens da Engenharia de Requisitos (RE) tradicional. As empresas de desenvolvimento de software precisam saber tratar, de forma consistente e eficiente, requisitos que tendem a evoluir rapidamente e se tornam obsoletos mesmo antes dos projetos serem finalizados. Dentre os fatores que contribuem para esta variabilidade estão a rápida mudança de ameaças competitivas, de preferências dos stakeholders, da tecnologia de desenvolvimento e a pressão para o produto entrar no mercado [3]. Isto, tem tornado a pré-especificação de requisitos inapropriada para projetos que possuem tais características. Métodos Ágeis (MAs), que procuram atacar os desafios emergentes destes contextos dinâmicos, têm ganho bastante interesse de pesquisadores e engenheiros de softwares [3]. MAs constituem uma família de processos de desenvolvimento de software que se tornou popular durante os últimos anos [1,7,14]. O objetivo principal desta abordagem é garantir a entrega de produtos em um menor prazo, com maior qualidade e satisfazendo às necessidades dos clientes através da aplicação dos princípios da produção enxuta para desenvolvimento de software [25]. Produção enxuta foi concebida durante a década de 50 pela Toyota [23]. Esta abordagem envolve várias práticas como desenvolvimento just-in-time, gerenciamento de qualidade total e processo de melhoria contínuo. O princípio da produção enxuta é a constante identificação e remoção de perdas, isto é, de tudo que não agrega valor para o cliente do produto final. Baseados no princípio da produção enxuta, MAs focam em [1]: • Agregar valor para o cliente • Garantir que o cliente entenda este valor e que o projeto satisfaça suas necessidades. MAs colocam muita ênfase em produzir e entregar ao cliente somente features que são úteis. Produzir algum outro artefato que não é requerido é considerado um erro.
  8. 8. 11 Segundo a filosofia ágil, adicionar uma feature que não é necessária não só consome esforço sem agregar valor, mas também produz código extra que pode conter erros, deixando o sistema mais complexo para manter, corrigir e melhorar [1]. Para garantir tal eliminação de perdas, MAs propõem ser [7]: • Mais adaptativos do que previsíveis • Mais orientados a pessoas do que orientados a processos. Para garantir a satisfação do cliente, procura-se uma colaboração estreita entre a equipe de desenvolvimento e o cliente, a fim de que [1]: • Requisitos sejam totalmente identificados. • O produto final reflita exatamente as necessidades do cliente. Engenharia de Requisitos, por outro lado, é um processo tradicional da engenharia de software com o objetivo de identificar, analisar, documentar e validar requisitos para o sistema que será desenvolvido. Freqüentemente, Engenharia de Requisitos e Métodos Ágeis são vistos como incompatíveis: tradicionalmente, ER é fortemente baseada em documentação para compartilhar conhecimento enquanto que MAs são focados em colaboração face-a-face entre desenvolvedores e clientes para atingir objetivos similares[2]. Porém, uma análise de vários processos ágeis mostra que a ER está presente em todos eles [2]. As atividades e fases é que diferem de acordo com a peculiaridade de cada processo. Mostra-se então, que a engenharia de requisitos tem grande importância para métodos ágeis, podendo-se destacar como pontos fundamentais [1]: • A maioria das técnicas de elicitação de requisitos não muda muito entre um ambiente tradicional e um ambiente ágil. • A priorização de requisitos é essencial, visto que o foco principal de MAs é a implementação das features mais valiosas para o cliente.
  9. 9. 12 • A identificação de interação entre features e o desacoplamento entre elas é também de extrema importância para a implementação de, exclusivamente, features de alta prioridade. • A identificação dos requisitos inclusos numa mesma iteração é baseada na negociação entre os clientes e a equipe de desenvolvimento. Este trabalho tem como objetivo principal expor quais técnicas e abordagens da Engenharia de Requisitos estão sendo utilizadas dentro do contexto ágil, bem como, entender como e porque a Engenharia de Requisitos ágil difere da Engenharia de Requisitos tradicional. O restante deste trabalho está organizado da seguinte forma: a seção 2 introduz brevemente Métodos Ágeis. A seção 3 descreve os objetivos e os problemas comuns da Engenharia de Requisitos. A seção 4 se aprofunda nas técnicas e abordagens da Engenharia de Requisitos aplicadas a Métodos Ágeis. A seção 5 discute o papel e responsabilidades de stakeholders no Processo Ágil. E na seção 6 discutem-se conclusões sobre a aplicabilidade da Engenharia de Requisitos para Métodos Ágeis.
  10. 10. 13 2. Métodos Ágeis Métodos Ágeis são uma família de técnicas de desenvolvimento projetadas para entregar produtos no prazo correto, com alto grau de qualidade e satisfação do cliente [1]. Esta família inclui métodos bastante variados e diferentes. Os mais populares são: • eXtreme Programming (XP) [6] • Scrum [28] • Dynamic Systems Development Method (DSDM) [32] • Adaptive Software Development (ASD) [17] • The Crystal family [12] Os promotores de MAs se deram conta que a grande variedade destes métodos poderia afastar pessoas interessadas em adotá-los, já que estas poderiam ter dificuldades em escolher o que aplicar em seus próprios processos[9,15]. Como resultado, definiram um documento contendo um conjunto de valores básicos e comuns a todos os métodos ágeis. Este documento é chamado de “Agile Manifesto” [7]. Sendo baseado em gerenciamento enxuto, estes valores focam em recursos humanos e gerenciamento de processos [1]: • Indivíduos e Interações X Processos e Ferramentas: a abordagem ágil dá muito mais ênfase à importância das pessoas e suas interações do que a processos estruturados e ferramentas. • Colaboração dos Clientes X Contratos: o relacionamento entre a equipe de desenvolvimento e o cliente é regulado através do envolvimento do cliente no processo de desenvolvimento e não através de contratos fixos e detalhados. • Software Funcionando X Documentação: o objetivo da equipe de desenvolvimento é entregar código funcionando corretamente, visto que este é o artefato que provê valor ao cliente. Código bem escrito é auto-documentado e uma documentação formal é reduzida ao mínimo.
  11. 11. 14 • Resposta à Mudança X Planejamento: a equipe de desenvolvimento tem que reagir rapidamente à variação nos requisitos. As decisões de binding que afetam esta habilidade são postergadas o máximo possível e o tempo gasto na atividade de planejamento é limitado ao que o cliente precisa. Qualquer tentativa para prever necessidades futuras é proibida. A partir destes valores, um conjunto de práticas e comportamentos comuns são identificados. Este tipo de abordagem não é uma inovação da Comunidade Ágil, elas são resultantes de experiências de sucessos e falhas no desenvolvimento de software. Algumas destas práticas estão listadas a seguir [1]: • Adaptabilidade: as metodologias têm que ser adaptadas às necessidades específicas para ambos, a equipe de desenvolvimento e os clientes. • Desenvolvimento Incremental: as diferentes etapas do desenvolvimento de software (análise, projeto, implementação e teste) são comprimidas em iterações muito curtas (de 2 semanas a 2 meses), a fim de focar em um conjunto de problemas pequenos e bem definidos que irá prover um valor real ao cliente (Figura 1). • Releases freqüentes: no fim de cada iteração, é liberado um release para o cliente testá-lo e prover feedbacks. Esta abordagem traz vários benefícios como: (1) o cliente pode usar a aplicação bem cedo, permitindo a identificação de potenciais problemas em tempo de melhorar o produto e limitando o impacto no cronograma; (2) o cliente se sente no controle do processo de desenvolvimento, visto que a evolução do projeto está sempre visível; (3) a confiança entre o cliente e a equipe de desenvolvimento aumenta já que a equipe é considerada confiável porque ela é capaz de entregar versões da aplicação que funcionam logo no início do processo.
  12. 12. 15 • Priorização de requisitos antes de cada iteração: antes de cada iteração, o cliente e a equipe de desenvolvimento identificam novos requisitos e reorganizam as prioridades dos antigos baseados nas atuais necessidades dos clientes. • Alto grau de envolvimento do cliente: o cliente está envolvido no processo de desenvolvimento através de uma constante requisição de feedbacks, a fim de identificar potenciais problemas logo no início do desenvolvimento. Em alguns casos, o cliente se torna um membro da equipe de desenvolvimento e está sempre disponível para interagir com a equipe e clarificar questões relacionadas aos requisitos. Figura. 1 - Ciclo de desenvolvimento Ágil [1] Como mencionado, os valores básicos e práticas de todos os MAs são bastante parecidos. Mesmo assim, o termo “Métodos Ágeis” identifica uma família diversa de
  13. 13. 16 metodologias de desenvolvimento com focos diferentes e pontos fortes e fracos peculiar a cada uma delas. Existem diferentes níveis de “agilidade” em MAs. Uma metodologia de desenvolvimento é mais ágil do que outra se ela requer menos overhead (o que significa não produzir valor para o cliente) [1]. Em cada metodologia, a equipe de desenvolvimento tem diferentes prioridades, processos, níveis de overhead para a interação dos membros da equipe, etc. Apesar disso, não existe uma solução única para todos os contextos. Métodos Ágeis fornecem diretrizes e um conjunto básico de práticas e comportamentos que têm que ser adaptados ao problema específico [6,9]. A aplicabilidade de MAs é ainda uma preocupação de pesquisa [4,34]. Várias questões ainda estão sendo discutidas, dentro delas estão: (1) o tamanho do problema que pode ser tratado; (2) como as pessoas são gerenciadas; (3) os domínios de aplicação no qual MAs são lucrativos [1]. • Tamanho da equipe em Métodos Ágeis A maioria dos MAs têm como alvo específico equipes de desenvolvimento pequenas, com até 16 desenvolvedores (ex., XP). Contudo, existem MAs dando suporte a um grande intervalo de tamanho de equipes (ex.. The Crystal Family). O grau de agilidade está frequentemente relacionado ao tamanho da equipe. Comunicação direta e documentação limitada só tornam-se possível com uma equipe pequena. Quando uma equipe cresce, o nível de overhead é proporcional a este crescimento. Este overhead inclui: (1) documentação e (2) comunicação mediada. Maior quantidade de documentação é requerida para compartilhar conhecimento e verificar o status do projeto porque, uma interação entre várias pessoas (many-to-many) não é mais possível [12]. Além disso, a importância da documentação cresce e se torna uma maneira de melhorar a forma como o conhecimento é compartilhado. Neste caso, só o código já não é suficiente e a comunicação direta entre a equipe de desenvolvimento e o cliente não é possível quando estas equipes são muito grandes [1].
  14. 14. 17 Tabela 1 – The Crystal Family [1] Por estas razões, equipes pequenas são mais ágeis do que equipes grandes. Contudo, os princípios básicos do gerenciamento enxuto ainda são válidos e a maioria deles são escaláveis. Um deles é a melhoria contínua do processo através da redução de perdas. Este princípio é válido independentemente do tamanho da equipe de desenvolvimento. A família Crystal é um exemplo de como a melhoria contínua do processo pode combater estas dificuldades [12]. A metodologia ágil Crystal inclui diferentes MAs que se adéquam às necessidades das equipes com diferentes tamanhos (Tabela 1). Os diferentes níveis da The Crystal Family focam em diferentes práticas a fim de gerenciar a escalabilidade. Uma escalabilidade limitada é alcançada reduzindo-se o nível de agilidade. Desenvolver grandes sistemas usando MAs é difícil ou mesmo impossível. Atualmente, o esforço de pesquisa em MAs focam em projetos de tamanho pequeno e médio, visto que mesmo nesta área a sua efetividade continua sendo investigada. Algumas práticas ágeis simplesmente não são escaláveis [1]. • Gerenciando Pessoas em Métodos Ágeis MAs focam no valor das pessoas para solucionar problemas e compartilhar informação [11], e não no processo e numa grande quantidade de documentação [24]. Contudo, a orientação à pessoas pode representar um ponto negativo bastante relevante para MAs, visto que, para se construir uma boa equipe ágil os conhecimentos e habilidades requeridas tem que ser profundos e diversificados [11]. Os membros da equipe têm que ser excelentes desenvolvedores, serem capazes de trabalhar em equipe, se comunicarem e interagirem com colegas e
  15. 15. 18 clientes, etc. Todas estas habilidades são obrigatória, na medida que os times são auto-organizáveis e não podem se basear em um processo pré-determinado e detalhado para solucionar problemas e compartilhar conhecimento [10]. • Aplicabilidade de Métodos Ágeis em Diferentes Domínios de Aplicação Uma questão chave é se MAs podem ser aplicados em todos os domínios de aplicação. Isto ainda é uma tema que está sendo investigado[4,9,34]. Em particular, como e quando a utilização de alguma prática específica resulta em benefícios [24, 8, 27]. Em geral, MAs são eficientes para construir aplicações não críticas e com tamanho limitado. Pesquisadores estão estudando outras áreas como sistemas embarcados (ex. Telefones celulares e PDAs) onde performance, comportamento de tempo real e restrição de memória são problemas inerentes [1]. MAs focam em produzir somente o que traz valor ao cliente, o que significa não construir artefatos reusáveis como por exemplo componentes. Se o objetivo do projeto é desenvolver um artefato reusável, o time de desenvolvimento irá focar neste problema e usar MAs para atacá-lo. Porém, artefatos reusáveis não são construídos em projetos cujo objetivo não seja exatamente este, porque os desenvolvedores tem que incluir features que não são úteis ao projeto em andamento[1]. MAs não são a solução para desenvolver todos os tipos de produtos. Sua aplicação é extremamente difícil e às vezes impossível para muitas áreas, como sistemas críticos de segurança, projetos muito grandes e aplicações complexas [1]. Um dos grandes desafios desta área é de se determinar em que contexto e sob quais características a aplicação de abordagens ágeis será mais lucrativa e eficiente em relação a um método tradicional.
  16. 16. 19 3. Engenharia de Requisitos Tradicional e Ágil Requisitos são a base de todos os produtos de software e sua elicitação, gerenciamento e entendimento são problemas comuns a todas as metodologias de desenvolvimento [1]. Em particular, a variabilidade de requisitos é o maior desafio para todos os projetos de software [29]. De acordo com um estudo do Standish Group [31], cinco dos oito principais fatores de falhas em projetos tem haver com requisitos (Tabela 2), Estes são: requisitos incompletos, baixo envolvimento do cliente, expectativas não realistas, mudanças nos requisitos e requisitos desnecessários [1]. Problema % Requisitos incompletos 13.1 Baixo envolvimento do cliente 10.6 Falta de recursos 12.4 Expectativa não realista 9.9 Falta de suporte gerencial 9.3 Mudanças nos requisitos 8.7 Falta de planejamento 8.1 Requisitos desnecessários 7.5 Tabela 2 - Principais Causas de Falhas de Projetos [1] Engenharia de requisitos é um dos fatores mais importante para o sucesso de um projeto de desenvolvimento de software. Ela está preocupada com a identificação, modelagem, comunicação e documentação dos requisitos de um sistema, bem como, com o contexto no qual o sistema estará inserido [2]. Requisitos descrevem quais funcionalidades estarão disponíveis e sob quais limitações o sistema irá funcionar. Eles dizem o que deverá ser feito, mas não especificam como serão implementados. Existem diversas técnicas disponíveis que são usadas para dar suporte ao processo da ER com o objetivo de garantir que os requisitos coletados sejam completos, consistentes e relevantes. O objetivo principal da ER tradicional é descobrir o que se deve fazer antes de se iniciar o desenvolvimento do sistema. Esta meta é baseada em duas suposições [2]:
  17. 17. 20 • Quanto mais tarde erros forem descobertos maiores são os custos para corrigi-los. • É possível determinar um conjunto de requisitos estáveis, antes de se começar a projetar e implementar o sistema. 3.1 O Processo da Engenharia de Requisitos Tradicional O processo da Engenharia de Requisitos consiste em cinco atividades principais: Elicitação, Análise e Negociação, Documentação, Validação e Gerenciamento [2]. 3.1.1 Elicitação Elicitação de Requisitos tenta descobrir os requisitos e identificar fronteiras do sistema consultando os stakeholders (clientes, desenvolvedores, usuários). As fronteiras definem o contexto do sistema. Durante esta atividade, é essencial o entendimento do domínio da aplicação, das necessidades do negócio, das restrições do sistema, dos stakeholders e do problema a ser resolvido. Toda esta aquisição de conhecimento é fundamental para o correto desenvolvimento do sistema. As técnicas da elicitação mais utilizadas são: Entrevistas, Cenários/Casos de Uso, Observação e Análise Social, Grupos Focado, Brainstorming e Prototipagem. 3.1.2 Análise e Negociação Análise de Requisitos tem como objeto checar os requisitos quanto a sua necessidade (o requisito é indispensável ao sistema), quanto a sua consistência (o requisito não deve ser contraditório), quanto a completude (nenhum serviço ou restrição está faltando) e quanto à realidade (requisitos são realistas no contexto de custo e prazo do projeto). Os conflitos nos requisitos são resolvidos através da priorização e negociação com os stakeholders. Soluções para os problemas identificados são acertadas e um compromisso é firmado considerando um conjunto de requisitos que foram concordados. As principais técnicas de análise e negociação são: Sessões de Joint Application Development (JAD), Priorização de Requisitos e Modelagem.
  18. 18. 21 3.1.3 Documentação O objetivo da documentação de requisitos é comunicar os requisitos entre os desenvolvedores e stakeholders do sistema. O documento de requisitos é a base para avaliar produtos e processos subseqüentes (projeto, teste, verificação e validação) e para controle de mudança. Um bom documento de requisitos não pode conter ambigüidades, tem que ser correto, entendível, consistente, conciso e realista. Em alguns casos, a especificação dos requisitos pode fazer parte do contrato do projeto. 3.1.4 Validação O objetivo da validação de requisitos é certificar que os requisitos são uma descrição aceitável do sistema a ser desenvolvido. As entradas para a atividade de validação são o documento de requisitos, os padrões e o conhecimento organizacional. As saídas são uma lista que contem os problemas encontrados e as ações necessárias para resolver os problemas reportados. As técnicas usadas para validação de requisitos são revisão e teste de requisitos. 3.1.5 Gerenciamento de Requisitos O objetivo do gerenciamento é capturar, armazenar, disseminar e gerenciar informação. Gerenciamento de requisitos inclui todas as atividades preocupadas com mudanças, controle de versão e rastreamento de requisitos. Rastreamento de requisitos provê relacionamento entre requisitos, projeto e implementação de um sistema a fim de gerenciar suas mudanças. 3.2 Processos de ER e o seu Impacto em Métodos Ágeis Os processos de desenvolvimento tradicionais têm elaborado vários padrões incluindo: (1) Padrão IEEE 830 – Práticas Recomendadas para Especificação de Requisitos de Software [18]; (2) Padrão IEEE 1233 – Guia para Desenvolvimento de Especificação de Requisitos de Sistemas [19]; (3) Padrão IEEE 1362 – Guia para Tecnologia da Informação – Definição de Sistema – Documento de Conceito de Operações [20].
  19. 19. 22 A importância de se definir padrões reside no fato de se ter um conjunto de diretrizes previamente definidas por onde toda a equipe de desenvolvimento será guiada. MAs não se baseiam nestes padrões para elicitação e gerenciamento de requisitos, porém, eles têm adaptado muitas das idéias básicas ao seu ambiente[1]. Por exemplo, em MAs toda a equipe de desenvolvimento está envolvida na atividade de elicitação e gerenciamento de requisitos enquanto em que abordagens tradicionais somente um subconjunto da equipe de desenvolvimento está envolvida. MAs entendem que variabilidade de requisitos é um problema constante em praticamente todos os projetos de software, portanto, o suporte a essas mudanças está incluso em seu processo como um ponto forte [33]. Além do mais, MAs não tentam prever mudanças ou necessidades futuras, eles só focam nas features pela quais o cliente está pagando. Esta abordagem evita o desenvolvimento de uma arquitetura geral demais que requer esforço extra[6]. O entendimento de variabilidade de requisitos tem um forte impacto na habilidade de MAs serem “enxutos”. Em geral, uma arquitetura genérica e mais abrangente é esperada para suportar a variabilidade nos requisitos que podem ser previstas com antecedência. Contudo, uma arquitetura mais complexa custa mais, não só para a equipe de desenvolvimento, mas também para a equipe de manutenção e correção de erros [1].
  20. 20. 23 4. Técnicas e Abordagens da Engenharia de Requisitos para Métodos Ágeis MAs incluem práticas focadas nos fatores chaves listados na Tabela 2 para reduzir o risco de falhas. Em particular, o objetivo principal do desenvolvimento incremental, de releases freqüentes, da priorização de requisitos antes de cada iteração e do envolvimento total do cliente é atacar os principais fatores de risco de um projeto de software [1]. 4.1 Envolvimento do Cliente Envolvimento do cliente é tido como a principal causa para um projeto obter sucesso [14], enquanto que a ausência deste compromisso é a razão fundamental para projetos não terminarem como planejados, ou seja, são concluídos com atraso e com custos extras ou simplesmente são abortados. O ponto chave de todas as abordagens ágeis é ter o cliente sempre acessível [1]. Em MAs, o cliente assume um papel fundamental. Frequentemente o termo “cliente” identifica um conjunto de stakeholders que pertencem à organização que está pagando pelo desenvolvimento de um produto de software. Neste caso, a interação entre a equipe de desenvolvimento e os stakeholders é complexa devido a diferentes percepções que os stakeholders possuem sobre o problema [5]. Em MAs, o problema de múltiplos stakeholders é resolvido reduzindo-se este número a apenas um, uma única pessoa que irá representar todos os stakeholders envolvidos no projeto. Este cliente deve ser um expert no domínio e deve também ser capaz de tomar decisões importantes como: aceitar o produto, priorizar requisitos, etc. No caso de produtos de massa, no qual não existe uma organização pagando diretamente por ele, a equipe de desenvolvimento tem que identificar um expert na área (ex. um expert no mercado em questão) que seja capaz de agir como um cliente e participar do desenvolvimento do produto [1].
  21. 21. 24 Esta abordagem só é possível se o tamanho do problema é limitado e uma única pessoa pode agir como o cliente, representando todos os stakeholders. Se o tamanho do problema não permitir o uso de tal abordagem, a equipe tem que usar outras técnicas para elicitar e gerenciar os requisitos [1]. Em alguns MAs, a técnica de participação ativa do cliente é bastante comum. Isto significa que o cliente se torna membro da equipe de desenvolvimento, ele é co- alocado com a equipe e etá sempre disponível para discutir as questões relacionadas ao projeto com qualquer membro da equipe[6]. Esta técnica define alguns requisitos específicos para o cliente [1]: • Disponibilidade: o cliente tem que estar sempre disponível para responder questões vindas da equipe de desenvolvimento. • Conhecimento geral: o cliente é o representante de todos os stakeholders. Por isso, ele tem que ser capaz de responder qualquer questão vinda da equipe de desenvolvimento, já que ele é um expert no domínio e sabe como a aplicação deve se comportar. • Poder de Decisão: o cliente é capaz de tomar decisões finais. Mudanças de requisitos, aceitação da features implementadas, etc. podem ser decididas diretamente por ele, permitindo um processo baseado em tomadas rápidas de decisões. Não é fácil ter acesso a um cliente que seja capaz de satisfazer todos estes requisitos [26]. A disponibilidade deste tipo de cliente é de fundamental importância em MAs, visto que a maioria de suas vantagens(ex. redução na documentação, entrega incremental, etc.) estão fortemente acopladas com o grau de envolvimento do usuário [1]. 4.2 Elicitação Como visto na seção anterior, o envolvimento do cliente é o objetivo principal do desenvolvimento ágil. A técnica mais comum da ER para elicitação de requisitos relacionada a isto é a entrevista. Entrevistas provêem acesso direto e não filtrado para
  22. 22. 25 a obtenção do conhecimento necessário. É fato conhecido que transferência de conhecimento em cadeia provoca mal entendidos. Por isso, todas as abordagens ágeis dão ênfase à conversa direta com o cliente salientando que esta é a melhor maneira de coletar o conhecimento necessário e preciso para o desenvolvimento do software. Caso algo não esteja claro ou esteja vagamente definido, a equipe de desenvolvimento deve procurar a pessoa responsável diretamente. Este relacionamento direto também ajuda a estabelecer um relacionamento de confiança entre desenvolvedores e clientes, que é essencial para o bom andamento do projeto. Com base nestes fatos, a entrevista é a principal técnica de elicitação nos processos ágeis de ER [2]. 4.3 Modelagem Apesar de a modelagem ser usada em MAs, o propósito é diferente quando comparado a ER tradicional. Em MAs, modelos são usados para comunicar entendimento de partes pequenas do sistema em desenvolvimento. Estes modelos são quase descartáveis. Eles são desenhados em quadros ou papéis, sem uma técnica específica de modelagem, e são apagados depois que atingirem seus objetivos, ou seja, após a equipe de desenvolvimento adquirir perfeito entendimento sobre a parte do sistema em questão. A maioria destes modelos não se tornam parte da documentação persistente do sistema [2]. 4.4 Documentação Em desenvolvimento ágil gerar documentos de requisitos completos e consistentes é visto como impraticável, ou pelo menos, como não realizável com um custo efetivo. A maioria dos métodos ágeis possui algum tipo de documentação, ou recomendam o uso de documentos de requisitos, porém, a decisão de sua extensão, conteúdo e etc., é deixada nas mãos da equipe de desenvolvimento e não são descritas em detalhes. É assumido que a documentação é bem menor do que em abordagens tradicionais [2]. 4.5 Validação Abordagens ágeis usam frequentemente reunião de revisões e testes de aceitação para validação de requisitos. Reuniões de revisão mostram se o projeto está no caminho
  23. 23. 26 certo e dentro do cronograma, aumentando assim a confiança do cliente na equipe de desenvolvimento. MAs usam diversos tipos de reunião de revisões para apresentar o novo software. Nelas, os clientes podem usar a aplicação, experimentar como o sistema funciona e determinar que funcionalidades já foram implementadas. As dúvidas dos clientes podem ser esclarecidas imediatamente pelos desenvolvedores, podendo discutir a implementação e sugerir mudanças no projeto. Durante a reunião, eles ainda aprendem sobre os pontos fortes e fracos do projeto e da tecnologia e em que área existe vantagens e limitações. Os clientes também podem executar um teste de aceitação para validar se o sistema reage da maneira esperada, caso não, esclarecer a questão na mesma hora [2]. 4.6 Gerenciamento Métodos ágeis provêem uma boa base para o gerenciamento de requisitos. Eles assumem que é muito difícil elicitar todos os requisitos do usuário logo no começo de um projeto de desenvolvimento. Também assumem que estes requisitos evoluem com o tempo, visto que, o cliente pode mudar de opinião e o ambiente técnico ou sócio- econômico também pode sofrer mudanças. Por isso, MAs assumem que mudanças são inevitáveis e incluem o gerenciamento de variabilidade de requisitos como atividade fundamental nos seus processos de ER. MAs fundamentam a coleta e o gerenciamento de requisitos em três suposições principais[6]: (1)requisitos não são bem conhecidos no começo do projeto; (2) requisitos mudam; (3) fazer mudanças não é tão caro em um contexto ágil. Em particular, MAs assumem que o custo de introduzir mudanças num produto é praticamente constante através do tempo(Figura 2), mas esta hipótese não é válida para todos os contextos. Geralmente, como fundamentado pela ER tradicional, o custo de se fazer mudanças cresce exponencialmente com o tempo. Por outro lado, se as fases de desenvolvimento estão agrupadas em iterações bem curtas (Figura 1) e as decisões de binding são tomadas o mais tarde possível, o crescimento dos custos é limitado [1, 6].
  24. 24. 27 Figura 2 - Custo de Mudanças [1] Com o objetivo de gerenciar a evolução de requisitos, MAs usam contratos com escopo de custo-variável[25]. Isto significa que tanto as features realmente implementadas no sistema quanto seus custos evoluem com o tempo. Portanto, requisitos não são especificados em detalhes em nível de contrato, mas definidos passo-a-passo durante o projeto através de um processo de negociação entre o cliente e a equipe de desenvolvimento [1]. Gerenciar variabilidade é um desafio que MAs tentam solucionar de duas técnicas [1]: • Desacoplamento de Requisitos: requisitos têm que ser o mais independentes possíveis a fim de claramente identificar o que implementar e tornar irrelevante a ordem de suas implementações. • Elicitação e Priorização de Requisitos: no começo de cada iteração, existe uma atividade de coletar e priorizar requisitos. Durante esta, novos requisitos são identificados e priorizados. Esta abordagem ajuda a identificar as features mais importantes dentro do projeto em andamento. Tipicamente, se um requisito é muito importante sua implementação é fixada para a iteração que está começando, senão, ele entra na fila de espera. Na próxima iteração, os requisitos que estão na fila são avaliados e se ainda continuarem válidos, são inclusos na lista de requisitos candidatos junto com os novos que foram identificados. Então, esta nova lista é priorizada para identificar as features que irão ser implementadas. Se um requisito não é importante o suficiente, ele ficará na lista de espera por um tempo indeterminado.
  25. 25. 28 Esta abordagem é capaz de identificar os requisitos mais importantes durante todo o projeto, e não só no começo. Requisitos que não são considerados muito importantes no início podem se tornar relevantes em algum estágio do projeto. Além do mais, o desacoplamento dos requisitos permite a implementação das features em quase qualquer ordem. Assim, as features são implementadas de a cordo com suas prioridades e não pela dependência funcional entre algumas delas [1]. São duas as principais diferenças entre uma abordagem de priorização ágil e tradicional: (1) em ER tradicional, os requisitos são priorizados apenas uma vez, enquanto que na abordagem ágil existe uma priorização a cada ciclo de desenvolvimento (Figura 1); (2) Em RE tradicional vários fatores contribuem para o estabelecimento das prioridades como: valores do negócio, risco, custo, e dependências de implementação. Já em abordagens ágeis, a priorização é baseada em somente um fator, valor do negócio definido pelo cliente [3]. 4.7 Requisitos Desnecessários Outro foco de MAs é a identificação e redução de atividades desnecessárias no processo de desenvolvimento [25]. Em particular, identificar e reduzir os requisitos desnecessários assume um papel fundamental. Em práticas enxutas, a redução deste “lixo” é extremamente importante, pois “lixo” sempre gera mais “lixo” no futuro [1, 23, 36]. A Engenharia de Requisitos em MAs focam em [7]: • Reduzir os requisitos desnecessários • Gerenciar a evolução de requisitos Requisitos desnecessários afetam profundamente o processo de desenvolvimento e a habilidade de entregar um produto capaz de satisfazer às reais necessidades do cliente. O principal efeito deste “lixo” nesta área inclui [1]:
  26. 26. 29 • Mais código fonte para escrever e custo extra • Maior complexidade do código fonte • Atrasos na entrega da versão final da aplicação contendo todas as funcionalidades requeridas. • Manutenção mais complexa e cara • Quantidade maior de recursos requeridos pela aplicação, incluindo: uso de memória, poder de processamento, uso de rede, etc. • Aumento da complexidade da aplicação do ponto de vista do cliente (ex. GUI mais completa, mais esforço para aprender a usar a aplicação, etc.) No final, todo este “lixo” gerado implica em um custo extra que afetará o cliente de maneira direta e indireta. No caso de projetos grandes, MAs não provê nenhuma solução específica. Mesmo o cliente sendo um expert no seu domínio, a tarefa de identificar as features que ele realmente precisa não é fácil. Em geral, clientes pedem mais do que precisam, incluindo uma grande variedade de features que não estarão provendo um ganho real para o seu negócio. Estes requisitos são desnecessários, portanto, são fontes de “lixo”. Com o objetivo de reduzir este tipo de risco, MAs usam as seguintes técnicas [1]: • Priorização de Requisitos: o cliente e a equipe de desenvolvimento atribuem prioridade para cada requisito a fim de identificar as features mais importantes que têm que ser implementadas primeiro. • Releases Incrementais: funcionalidades são lançadas em pequenas, mas freqüentes releases (de 2 semanas a 2 meses), com o objetivo de estar sempre coletando feedbacks do cliente. 4.8 Falha de Comunicação Um mal entendido gerado por alguma falha na comunicação entre o cliente e a equipe de desenvolvimento gera requisitos errados. A fim de reduzir a probabilidade deste
  27. 27. 30 problema, MAs adotam várias técnicas focadas na melhoria da interação entre o cliente e a equipe de desenvolvimento [1]: • Toda a equipe de desenvolvimento coleta requisitos junto ao cliente: elicitação de requisitos é uma atividade na qual toda a equipe está envolvida. Assim, o uso de documentação para compartilhar conhecimento é reduzido ao mínimo e a probabilidade de mal entendidos diminui. • Requisitos são coletados usando uma linguagem comum: requisitos são coletados usando a linguagem do cliente, e não uma linguagem formal para especificação de requisitos. Isto significa que os desenvolvedores têm que ser introduzidos ao domínio de aplicação do cliente a fim de entendê-lo. • Interação direta entre a equipe de desenvolvimento e o Cliente: não existe nenhum intermediário entre a equipe de desenvolvimento e o cliente. Esta abordagem reduz tanto o número de documentos requeridos quanto a probabilidade de mal entendidos devido à criação de camadas extras de comunicação. • Divisão de requisitos: se a equipe de desenvolvimento considerar algum requisito como sendo muito complexo, esta técnica ajuda o cliente a quebrar o requisito em outros mais simples. Esta divisão ajuda desenvolvedores s entender melhor as funcionalidades requeridas pelo cliente. 4.9 Requisitos Não Funcionais MAs não têm nenhuma técnica específica que seja uma unanimidade para elicitação e gerenciamento dos requisitos não-funcionais[2]. Estes requisitos são coletados implicitamente durante a atividade de elicitação de requisitos. A necessidade de se especificar requisitos não-funcionais é menos importante em MAs do que em contextos tradicionais devido à contínua interação com o cliente. Depois de cada iteração, o produto é lançado e o cliente pode testá-lo. Se ele identificar problemas relacionados a qualidades não-funcionais, a equipe pode adaptar o sistema para atingir estes requisitos na iteração subseqüente sem ter grande impacto no cronograma [1].
  28. 28. 31 Frequentemente, o cliente não consegue enxergar muitos dos requisitos não- funcionais (ex. escalabilidade, segurança, etc.) como um grande impacto. Isto pode afetar profundamente o lançamento da versão final da aplicação, por isso, a equipe de desenvolvimento tem que guiar o cliente a fim de identificar estas necessidades que não são facilmente visíveis. Esta abordagem para requisitos não funcionais pode representar um risco muito grande para MAs, à medida que faltam técnicas para o gerenciamento destes.
  29. 29. 32 5. O Papel e Responsabilidades de Stakeholders em Métodos Ágeis MAs requerem um alto grau de interação entre clientes, gerentes e desenvolvedores. Usualmente esta iteração não é intermediada e todos os stakeholders se encontram frequentemente em reuniões a fim de melhorar o entendimento mútuo, a qualidade do produto final e manter o projeto sob controle (no prazo e custo correto) [1]. Papéis e Responsabilidades de clientes, gerentes e desenvolvedores assumem fundamental importância e tem um grande impacto na evolução de um projeto de software [1]. 5.1 Clientes O Cliente está altamente envolvido no processo de desenvolvimento e frequentemente faz parte da equipe de desenvolvimento. A presença do cliente é extremamente importante em MAs, visto que a quantidade de documentação é reduzida ao mínimo e a equipe de desenvolvimento frequentemente pede esclarecimento sobre os requisitos. A presença constante do cliente substitui a maior parte da documentação requerida para descrever requisitos em detalhe e sua contribuição é um fator chave para o sucesso dos projetos. O cliente deve prover sempre feedbacks para a equipe de desenvolvimento a fim de identificar potenciais problemas cedo no desenvolvimento e evitar um grande impacto no cronograma do projeto. Como dito anteriormente a técnica de elicitação de Participação Ativa do Cliente traz vários benefícios, mas é muito difícil de ser implementada. Uma implementação equivocada desta prática pode reduzir a efetividade de vários MAs, visto que a maioria deles esta estreitamente acoplados com o envolvimento do cliente[1]. 5.2 Desenvolvedores Toda a equipe de desenvolvimento está altamente envolvida no gerenciamento de clientes coletando e negociando requisitos. Os desenvolvedores têm que interagir bem de perto com o cliente provendo um software que funcione e coletando feedbacks
  30. 30. 33 de grande valor. Por isto, as habilidades que são requeridas dos desenvolvedores em equipes ágeis não são comuns. Eles têm que ser desenvolvedores muito bons, tem que ser capazes de trabalhar em equipe e interagir com o cliente usando a linguagem dele[11]. Visto que MAs focam nesta interação, a equipe de desenvolvimento tem a responsabilidade de educar o cliente. MAs requerem um alto grau de comprometimento do cliente no projeto devido aos constantes feedbacks que são sempre requeridos pelos desenvolvedores [1]. A confiança entre a equipe de desenvolvimento e o cliente assume fundamental importância. A equipe tem que prover um software que funcione e de alta qualidade em cada iteração a fim de receber um bom feedback do cliente. Esta abordagem é valiosa para ambos, desenvolvedores e clientes. Enquanto os desenvolvedores podem coletar informações úteis para evitar a implementação de features desnecessárias, clientes podem usar (ou ao menos testar) o produto em poucas semanas depois do início do projeto [1]. 5.3 Gerentes Em MAs gerentes têm que criar e manter um framework para o estabelecimento de uma interação produtiva entre a equipe de desenvolvimento e o cliente. Eles podem realizar este objetivo identificando as melhores pessoas para serem incluídas nas equipes ágeis, promovendo colaboração e negociando contratos com o cliente. Geralmente, equipes ágeis trabalham com contrato com escopo de preço-variável ao invés de contrato com escopo de preço-fixo. Esta abordagem está baseada na habilidade que o gerente tem na definição de contratos para satisfazer o cliente e permitir uma grande flexibilidade no processo de desenvolvimento, como é requerido pelos MAs [1].
  31. 31. 34 6. Conclusão Este trabalho apresentou técnicas e abordagens da Engenharia de Requisitos utilizadas durante os processos de desenvolvimento ágeis. Visto que a metodologia ágil ainda é muito nova e continua evoluindo, várias das técnicas de RE continuam sendo estudadas e a efetividade de suas aplicações vem sendo avaliadas. Foi mostrado que a ER ágil difere da ER tradicional e que os processos ágeis têm uma abordagem iterativa de descoberta. Desenvolvimento ágil ocorre num ambiente onde coletar e desenvolver uma especificação de requisitos completa e não ambígua é impossível ou não apropriada [3]. Estas diferenças levaram a este conjunto de técnicas e abordagens apresentadas aqui. Foi mostrado que a intensa comunicação entre os desenvolvedores e os clientes é a prática mais importante no processo ágil. Ao invés de ser seguido um procedimento formal para se produzir uma especificação completa que descreve precisamente o sistema, ER ágil é mais dinâmica e adaptativa. Os seus processos não são centralizados em uma fase antes do desenvolvimento; eles estão igualmente espalhados através de todo o desenvolvimento [3]. Como resultado deste trabalho chega-se a algumas conclusões importantes: • Todas as atividades do processo da Engenharia de Requisitos tradicional estão presentes nos processos ágeis. As técnicas usadas é que variam nas diferentes abordagens e as fases não são tão claramente separadas. Esta abordagem “lazy” à Engenharia de Requisitos tem vantagens em relação a custos, já que ela adia o esforço/gasto com a apuração de detalhes dos requisitos o quanto puder, ou seja, minutos antes do requisito ser implementado é que ele tem que ser entendido pelos desenvolvedores. As técnicas usadas pelos processos ágeis são algumas vezes descritas vagamente e a sua implementação é deixada nas mãos dos desenvolvedores. As abordagens tradicionais, por outro lado, se baseiam na descrição detalhada do que precisa ser feito e conseqüentemente provê mais direção para como se fazer a coisa correta. Infelizmente, determinar de frente qual é a melhor abordagem em um dado contexto de
  32. 32. 35 projeto ainda é muito difícil e é uma questão que ainda está sendo investigada [2]. • O envolvimento do cliente é o ponto fundamental para o sucesso dos métodos ágeis. A principal diferença entre métodos ágeis e tradicionais é o grau deste envolvimento no processo de desenvolvimento. Porém, em relação a isto, ER tradicional e ágil têm objetivos similares visto que participação efetiva do cliente é essencial em qualquer projeto de software. • Métodos Ágeis são uma boa abordagem para desenvolvimento de software de um subconjunto relevante de projetos, mas seu limite ainda não está bem definido [1]. • Métodos Ágeis gerenciam requisitos efetivamente em projetos pequenos, mas apresentam muitos problemas em projetos grandes. MAs focam na produção de valor para o cliente, reduzindo ao máximo qualquer coisa que não ofereça este valor pelo ponto de vista do cliente. Já métodos tradicionais conseguem gerenciar bem projetos grandes, mas o seu overhead não é bom para projetos pequenos [1]. • Muitos clientes ainda encontram dificuldades em entender e acreditar em processos de desenvolvimentos ágeis, visto que, a maioria dos clientes ainda são mais acostumados a metodologias tradicionais, onde se produz uma especificação de requisitos detalhada [3]. Porém, a tendência é que a metodologia ágil ganhe força e se torne dominante para projetos com características que favoreçam a sua aplicação. Finalmente, pode-se concluir que apesar das práticas da ER ágil trazerem benefícios como um melhor entendimento das necessidades dos clientes e a habilidade de adaptarem-se as necessidades sempre em evolução dos ambientes dinâmicos de hoje, eles propõem vários e distintos desafios. Portanto, as organizações devem sempre
  33. 33. 36 comparar os custos e benefícios da ER ágil em seus ambientes de projeto antes de adotá-la.
  34. 34. 37 7. Referências Bibiográficas [1] Aurum, Aybüke; Wohlin, Claes (Eds.) “Engineering and Managing Software Requirements” 2005, XVIII, 478 p. [2]. Paetsch F, Eberlein A, Maurer F (2003) Requirements engineering and Agile software development. In Proceedings of 8th International Workshop on Enterprise Security, Linz, Austria, 9-11 June. [3] Lan Cao, Balasubramaniam Ramesh, "Agile Requirements Engineering Practices: An Empirical Study," IEEE Software, vol. 25, no. 1, pp. 60-67, Jan/Feb, 2008. [4] Ambler S (2002) When does(n’t) Agile modeling make sense? Accessed on December 5, 2004, http://www.agilemodeling.com/essays/whenDoesAMWork.htm. [5] Bailey P, Ashworth N, Wallace N (2002) Challenges for stakeholders in adopting XP. In: Proceedings of 3rd International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP2002), Alghero, Italy, 26-29 May. [6] Beck K (1999) Extreme programming explained: Embrace change. Addison-Wesley, UK. [7] Beck K, Beedle M, Bennekum A, Cockburn A, Cunningham W, Fowler M, Grenning J, Highsmith J, Hunt A, Jeffries R, Kern J, Marick B, Martin RC, Mellor S, Schwaber K, Sutherland J, Thomas D (2001) Manifesto for Agile software Development. Accessed on 5th December 2004, online at: http://www.agilemanifesto.org/. [8] Cockburn A, Williams L (2000) The costs and benefits of pair programming. In: Proceedings of 1st International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP2000), Cagliari, Italy, 21-23 June. [9] Cockburn A (2000) Selecting a project’s methodology. IEEE Software, 17(4): 64 71. [10] Cockburn A, Highsmith J (2001) Agile software development: The business of innovation. IEEE Computer, September, pp.120 122. [11] Cockburn A, Highsmith J (2001) Agile software development: The people factor. IEEE Computer, November, pp.131 133. [12] Cockburn A (2002) Agile software development. Addison-Wesley, London, UK. [13] Duncan R (2001) The quality of requirements in extreme programming. The Journal of Defence Software Engineering, June 2001 issue. [14] Cohen D, Lindvall M, Costa P (2003) Agile software development. DACS State-of-the- Art Report. Accessed 5th December 2004, http://www.dacs.dtic.mil/techs/agile/agile.pdf. [15] Cohn M, Ford D (2002) Introducing an Agile process to an organization. Access on 5th December 2004 http://www.mountaingoatsoftware.com/articles/IntroducingAnAgileProcess.pdf
  35. 35. 38 [16] Glass R (2001) Agile versus traditional: Make love, not war. Cutter IT Journal, December, 6(1): 12 18. [17] Highsmith JA (1996) Adaptive software development. Dorset House Publishing, UK [18] IEEE Standard 830 (1998) IEEE recommended practice for software requirements. [19] IEEE Standard 1233 (1998) IEEE guide for developing system requirements specifications [20] IEEE Standard 1362 (1998) IEEE guide for information technology: System definition, concept of operations document. [21] Lee C, Guadagno L, Jia X (2003) An Agile approach to capturing requirements and traceability. In: Proceedings of 2nd International Workshop on Traceability in Emerging Forms of Software Engineering, Montreal, Canada, 7 October. [22] Nawrocki J, Jasinski M, Walter B, Wojciechowski A (2002) Extreme programming modified: Embrace requirements engineering practices. In: Proceedings of International Conference on Requirements Engineering, 9-13 September, Essen, Germany. [23] Ohno T (1988) Toyota production system: Beyond large-scale production. Productivity Press Cambridge, Mass. [24] Ambler S (2001) Agile documentation. Accessed on 5th December 2004. http://www.agilemodeling.com /essays/agileDocumentation.htm. [25] Poppendieck T, Poppendieck M (2003) Lean software development: An agile toolkit for software development managers. Addison-Wesley, London UK. [26] Rasmusson J (2003) Introducing XP into Greenfield projects: Lessons learned. IEEE Software, May/June, 20(3): 21 28. [27] Ronkainen J, Abrahamsson P (2003) Software development under stringent hardware constraints: Do Agile methods have a chance. In: Proceedings of 4th International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP2003), Genoa, Italy, May 2003, pp.25 29. [28] Schwaber K, Beedle M (2001) Agile software development with scrum. Prentice Hall PTR, Australia. [29] Sommerville I, Sawyer P, (2000) Requirements engineering: A good practice guide. John Wiley & Sons, UK. [30] Smith J. (2001) A comparison of RUP and XP. Rational software white paper. Accessed 5th December 2005 http://www.isk.kth.se/proj/2003/6b3403/sa3/www/RationalUnifiedProcess/ papers/rupxp.htm. [31] Standish Group, CHAOS Report 1994. [32] Stapleton J (1995) DSDM - Dynamic system development method. Addison-Wesley, UK [33] Tomayko JE (2002) Engineering of unstable requirements using Agile methods. In: Proceedings of International Conference on Time-Constrained Requirements Engineering, Essen, Germany, 9-13 September.
  36. 36. 39 [34] Turk D, France R, Rumpe B (2002) Limitations of Agile software processes. In: Proceedings of 3rd International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP2002), Alghero, Italy, 26 - 29 May. [35] Wells D (2003) Don’t solve a problem before you get to it. IEEE Software, May/June, 20(3): 44 47. [36] Womack JP, Jones DT (1998) Lean thinking: Banish waste and create wealth in your corporation, Simon & Schuster. [37]Young R (2002) Recommended requirements gathering practices, Accessed 5th December 2004, http://www.stsc.hill.af.mil/crosstalk/2002/04/young. [38]. Abrahamsson P, Salo O, Ronkainen J, Warsta J (2002) Agile software development methods: Review and analysis. EPSOO 2002, VTT Publications 478.

×