Universidade Federal de Pernambuco Centro de Informática. Pós-graduação em Ciência da Computação

Transcrição

1 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

2 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

3 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

4 ÍNDICE 1 INTRODUÇÃO ENGENHARIA DE REQUISITOS (ER) PROCESSO DE ENGENHARIA DE REQUISITOS ELICITAÇÃO DE REQUISITOS Entrevistas Casos de uso / cenários Brainstorming Observação e análise social Grupos focais Metodologia de Sistema Flexível O reuso de requisitos Prototipação ANÁLISE E NEGOCIAÇÃO DE REQUISITOS Joint Application Development (JAD) Priorização de Requisitos Modelagem Desdobramento da Função Qualidade (QFD) DOCUMENTAÇÃO DE REQUISITOS VALIDAÇÃO DE REQUISITOS Revisão dos requisitos Testes de requisitos GERÊNCIA DE REQUISITOS DESENVOLVIMENTO ÁGIL EXTREME PROGRAMMING (XP) O Processo de XP Práticas de XP XP e os requisitos MODELAGEM ÁGIL (MA) SCRUM O processo Scrum AS METODOLOGIAS DO CRYSTAL FEATURE DRIVEN DEVELOPMENT (FDD)

5 3.7 MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS (DSDM) DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD) TÉCNICAS DE ENGENHARIA DE REQUSITOS PARA MÉTODOS ÁGEIS ENVOLVIMENTO DO CLIENTE ENTREVISTAS PRIORIZAÇÃO JAD MODELAGEM DOCUMENTAÇÃO VALIDAÇÃO GESTÃO DOS REQUISITOS OBSERVAÇÃO, ANÁLISE SOCIAL E BRAINSTORM REQUISITOS NÃO-FUNCIONAIS CONCLUSÃO REFERÊNCIAS

6 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

7 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 97]: O processo de ER é composto por cinco atividades principais [Sommerville, 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

8 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

9 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 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

10 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 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] 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

11 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 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 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

12 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] 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 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

13 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) 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

14 algumas das exigências. As principais técnicas utilizadas para a análise de requisitos são sessões JAD, Priorização e Modelagem 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 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

15 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

16 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 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

17 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 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] 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

18 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

19 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 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

20 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

21 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 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 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

22 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

23 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

24 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 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

25 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

26 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] O processo Scrum 26

27 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

28 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

29 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

30 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

31 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

32 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

33 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