Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Transcrição

1 Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG Brasil vini.abreu@gmail.com Nos últimos anos as metodologias ágeis desempenham um papel cada vez mais participativo no desenvolvimento e no processo de criação de software. Porém, muitas vezes são ajudadas pelas metodologias tradicionais, que não atendem plenamente certos tipos de projetos, contribuindo ainda mais para o aumento do uso dos processos ágeis. Esse é o caso de projetos de desenvolvimento de software, os quais trazem muitas alterações de requisitos durante seu desenvolvimento. As práticas agíeis de desenvolvimento de software tem ganhado muitos adeptos dado sua facilidade de adaptação à mudanças em relação as metodologias tradicionais. Inserida neste contexto, a produção de projetos de software vem sendo cada vez mais exigida no que tange à produção de software de qualidade. Entretanto, o mercado do software vem passando por diversas crises ao longo do tempo, por muitos projetos de desenvolvimento de sistemas de software que falharam devido a diversos fatores, seja porque não chegam ao fim, seja por não alcançarem o objetivo esperado com relação as funcionalidades, prazo ou custo. Isso leva a verificação de quais são as causas incomuns entre tantos projetos inacabados. O foco do artigo é justamente um estudo sobre os requisitos dessa resposta. O que para os [LEFFINGWELL and WIDRIG ] [THAYER and DORFMAN ] é a falha no entendimento de requisitos que tem sido um dos maiores fatores para o insucesso dos projetos de software. Baseado nisso, o artigo envolve-se no estudo dos requisitos de gestão de requisitos no desenvolvimento de software que utilizam práticas ágeis. O que nessa interessante área, que é a gestão de requisitos de projetos de software, a condução de projetos ao sucesso, onde todos os envolvidos esperam, o gerenciamento de requisitos tem um parcela significativa para o sucesso do projeto, sendo ainda mais desafiador se tratando das práticas ágeis, onde as mudanças de requisitos são mais frequentes. Este documento tem o objetivo de reunir um conjunto de requisitos aplicados ao gerenciamento de requisitos focando as práticas ágeis. Na seção 2 são formalizados os conceitos relativos à gerenciamento de requisitos e o conceito de praticas ágeis demonstrando alguns exemplos de metodologia. Os requisitos levantados são apresentados na

2 forma de um catálogo na Seção 3. Para o levantamento desses requisitos foram abordados diversos aspectos, como o planejamento e a dimensão do projeto, a metodologia ágel que foi usada, etc. Na Seção 4 são discutidos alguns aspectos práticos, relacionados aos relatos de alguns projetos, obtidos nas referências. A conclusão se encontra na Seção Conceito A qualidade do software é definida pelo IEEE (The Institute of Electrical and Electronics Engineers) como o grau com que um sistema, componente ou processo atende aos requisitos especificados e às expectativas ou necessidades de clientes ou usuários. Já a ISO (The International Standards Organization) define qualidade como a totalidade de características de um produto ou serviço que comprovam sua capacidade de satisfazer necessidades especificadas ou implícitas [ROSENBERG 2002]. Estas duas definições, mostram que a qualidade de um software está intrinsecamente ligada ao atendimento dos requisitos. Com o conceito de que o requisito está intimamente ligado ao sucesso do produto, observamos o entendimento de [?, ZANATTA]obre o gerenciamento de requisito quanto as praticas ágeis com o aumento da utilização das práticas ágeis no cenário da produção de software, pode-se requerer que a área de engenharia de requisitos (ER) reveja alguns de seus procedimentos. Isto levando em conta que as práticas ágeis abdicam, em parte, de controles e documentação tão presente e comum nesta área. Em geral as praticas ágeis não mencionam como realizam, por exemplo, a documentação da especificação de requisitos, ou como mantêm a rastreabilidade dos requisitos. Os princípios apresentados pelo manifesto ágil e discutidos por [FOWLER ] (2003, p.1), mostram que certos valores relacionados com a área de ER continuam sendo importantes, como o entendimento dos requisitos, porém preocupam-se em não gerar muita documentação que, justificam, provavelmente nunca será lida. As observações de Zanata e Vilain mostra como o assunto é um tanto complexo, já que, a abordagem sobre gerenciamento de requisitos pelas práticas ágeis não são muito bem abordadas pelas próprias metodologias. E que os princípios das praticais ágeis comentado por Fowler são diferentes das metodologias tradicionais, mas que conceitos de ER é fundamental para um software, mesmo nas práticas ágeis, afirmando ainda que tudo ou mais no desenvolvimento de software depende dos requisitos. Onde não tendo requisitos estáveis e sólidos, também não se terá um projeto bem planejado e sólido. No entanto a ER, assim como todas as outras atividades de engenharia de software, precisa ser adaptada às necessidades do processo, do projeto, do produto e do pessoal que está fazendo o trabalho [PRESSMAN 2006]. O que deve ficar claro é que o processo de ER deve estabelecer uma base sólida entre o projeto e construção, se utilizando das práticas ágeis, que tem como principal característica a aquisição iterativa de requisitos através da comunicação face-a-face com o cliente. O que deve ser questionado e se realmente pode-se atingir a satisfação do cliente e projetos de software de qualidade se as práticas da ER forem ignoradas ou abreviadas Engenharia de Requisitos Segundo [LEITE 2006] a postura da ER é de prover ao engenheiro de software, métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos

3 que o software deve atender. De acordo com [SOMMERVILLE et al 1998] o processo de ER é composto basicamente pelas seguintes atividades [VICENTE 2008]: 1. Elicitação de Requisitos: requisitos são descobertos através da consulta com as partes interessadas (stakeholders), entrevistas e questionários, análise de múltiplos pontos de vista, brainstorm e observações e análises sociais. Além disso, protótipos e cenários também são utilizados para se ter um melhor entendimento dos requisitos; 2. Análise e Negociação de Requisitos: requisitos são analisados quanto a sua necessidade, completude, consistência e praticabilidade no contexto de custos e tempo disponível. Sendo que a partir desta análise os conflitos são resolvidos através de negociação. 3. Documentação de Requisitos: um documento de requisitos descreve o domínio de aplicação e o sistema a ser desenvolvido; 4. Validação de Requisitos: Verifica a consistência do documento de requisitos, considerando os padrões organizacionais, conhecimento sobre a organização e o sistema a ser implementado; 5. Gerenciamento de Requisitos: envolve a coleta, armazenamento e manutenção de grande quantidade de informação do ponto de vista das razões da mudanças de determinados requisitos e os seus impactos com outros requisitos extreme Programing Extreme programing (XP) é umas das práticas ágeis mais utilizadas atualmente, organizada em quatro fazes (planejamento, projeto, codificação e testes). A metodologia XP não trata explicitamente de técnicas de requisitos em detalhes, no entanto algumas práticas (ou técnicas utilizadas nestas práticas) podem ser comparadas com técnicas da ER [?] e [VICENTE 2008]: 1. O planejamento do jogo (Planning game) é uma reunião que ocorre uma vez por iteração, normalmente uma vez por semana que utiliza de histórias (story cards) que descrevem uma funcionalidade que fornece valor ao negócio do cliente. Estas histórias do usuário devem ser pensadas pelo usuário a partir do que ele deseja que o sistema deve fazer, esta prática pode ser comparada a Elicitação de Requisitos (brainstorms). 2. A enfase em teste e entrega constantes de release para validação do cliente, pode ser comparada com a validação de requisitos. A qual tem como ponto positivo a reutilização e a continuação a partir do release validado. Diferente da metodologia tradicional onde o protótipo é descartado. 3. Ainda no campo do validação de requisitos, com o cliente sempre presente temos o problema de ambiguidade minimizado e com fácil solução Scrum A pratica do Scrum é utilizado para gerenciar o processo de desenvolvimento de sistemas aplicando idéias de flexibilidade, adaptabilidade e produtividade a partir da teoria de controle de processos industriais [ABRAHAMSSON et al 2003]. Sendo um das práticas ágeis também mais usadas hoje em dia. Suas características quanto a comparação ER tradicionais são:

4 1. O Scrum utiliza backlog, o que seria conjunto de requisitos (características do projeto, funções, atualizações, bugs), priorizado pelo Product Owner (cliente), esta prática do Scrum se em caixa perfeitamente com a Elicitação de Requisitos (brainstorms) do ER tradicional. 2. Há entrega de conjunto fixo de itens do backlog em série de iterações curtas (sprints). No final de cada sprint, uma reunião é dirigida para demonstrar novas funcionalidades ao cliente e solicitando um feedback e entregue para o cliente podendo ser comparada a fase de revisão de requisitos. 3. Requisitos Essa seção apresenta um catálogo de requisitos necessário para o entendimento da gestão de requisitos aplicados a praticais ágeis. A elaboração desse catálogo foi feita baseado na pesquisa bibliográfica referentes a gerenciamento de requisitos em práticas ágeis, fazendo comparativos com as metodologias tradicional, para assim chegar em parâmetros comuns que definem a ER em práticas ágeis. Algumas dessas comparações e definições são comentadas a seguir Requisito de abordagem ágeis quanto ao XP De acordo com [MUDRIDGE 2008] com as abordagens ágeis, a compreensão de todos os requisitos antes do início do desenvolvimento pode ser quase impossível. As mudanças são inevitáveis por várias razões, sendo o contexto do cliente uns dos maiores fatores. [MUDRIDGE 2008] afirma que as equipes para melhora o entendimento essencial dos requisitos tem que ter a com ciência de três questionamentos básicos: Como as coisas realmente funcionam; O que é possível fazer; O valor comercial de uma funcionalidade específica. O XP incentiva precocemente e continuamente a compreensão destas questões e que permitem que o desenvolvimento seja revisto e refinado, assim o evoluindo. Para ativá esta evolução, os requisitos e o produto evoluem em paralelo. Com esse conceito os desenvolvedores devem ser capazes de fazer as mudanças com confiança, afirma [MUDRIDGE 2008]. Para uma conclusão critica como de Mugridge, pode-se entender que apesar do planning game ter semelhanças com a elicitação de requisitos na ER tradicional, o planning game se difere quanto ao início do projeto, onde pela metodologias tradicionais a maior parte dos requisitos são definidos, o planning game é feito de maneira incremental, de pequenas e continuas interações, sendo os conflitos de requisitos não observados no story cards para serem resolvidos nos release entregues para o cliente. É importante observa que a noção do todo do projeto é implícita, mas não definida em nenhuma parte do processo Requisito de abordagem ágeis quanto ao Scrum No Scrum o processo de definição dos requisitos é feito através de uma lista de requisitos chamada de Backlog [REFERENCIA DO LIVRO DO SCRUM], os requisitos são organizados de maneira a priorizar a disponibilidade do produto. O backlog nunca está

5 completo e os primeiros itens listados são apenas uma estimativa inicial dos requisitos. O objetivo do backlog ser dinãmico é fazer com que o software se adeque as necessidades do cliente, sendo competitivo e útil. As afirmações de [referência do livro], se encaixa ainda mais com o conceito de elicitação de requisitos e documentação de requisitos na ER tradicional, quando o mesmo afirma que enquanto existe um produto, o produto Backlog também existe, ou seja, o mesmo afirma que temos no Scrum um similaridade de aquisição e entendimento do requisito e um documento que registra esse entendimento, mesmo quando pode ser alterado para ajuste do produto. Um exemplo de produto Backlog é mostrado na figura 1: Figura 1. Um exemplo de backlog que acompanha o cilo de vida do produto 4. Aspectos Práticos 4.1. Aspectos Positivos Das técnicas de gerenciamento de requisitos [TOMAYKO 2002] afirma que: em cenários aonde os requisitos são instáveis a prática de refatoração e prototipação são bastante úteis e testes antes da programação, testes de integração e testes de interfaces gráficas validam bastante rigor a qualidade da aplicação que está sendo desenvolvida. Outro aspecto que contribui a favor das metodologias ágeis para elicitação e entendimento correto dos requisitos é o envolvimento direto com a pessoal interessada (stakeholders), que necessariamente não precisa ser o cliente. De acordo com [VICENTE 2008] Envolvimento dos stakeholders, entrevistas focam bastante no envolvimento dos stakeholders durante todo o projeto, assumindo que eles podem contribuir para

6 que decisões a respeito dos requisitos elicitados tenham qualidade e atendam as necessidades do cliente. Por outro lado, a ER tradicional se foca menos no envolvimento dos stakeholders e utiliza diversas técnicas que possuem como objetivo abordar com completude e consistência dos requisitos. Se tratando no desenvolvimento de documentação de requisitos completos [VICENTE 2008] o desenvolvimento ágil, são vistos como impraticáveis ou, pelo menos, como um custo não efetivo. Algumas práticas ágeis incluem algum tipo de documentação ou recomendam o uso do documento de requisitos (DSDM, Scrum, Crystal) mas a decisão do seu tamanho depende do time de desenvolvimento. Esta prática não é suficientemente detalhada dentro destas metodologias Aspectos Negativos 5. Conclusão Apesar de um estudo ainda esta em expansão sobre uma definição de Engenharia de requisitos em práticas ágeis, podemos já destacar alguns requisitos quase que explicito em todas as diversas metodologias ágeis que foram observadas por esse estudo, se destaca os requisitos de: comunicação, teste, histórico dos requisitos, como sendo requisitos padrões para o gerenciamento de requisitos em práticas ágeis. Referências FOWLER, M. The new methodology. LEFFINGWELL, D. and WIDRIG, D. Managing software requirements - a unified approach. page 492. LEITE, J. Requisitos: a ponte entre a organização e o software. MUDRIDGE, R. (2008). Managing agile project requirements with storytest-driven development. PRESSMAN, R. S. ROSENBERG, L. What is software quality assurance? crosstalk. pages THAYER, R. and DORFMAN, M. System and software requirements engineering. page 528. TOMAYKO, J. E. VICENTE, A. (2008). Uma investigação inicial da atividade de engenharia de requisitos em processos Ágeis. page Instituto de Ciências Matemáticas e Computação.