Uma proposta para combinar técnicas de elicitação de requisitos para a
produção do documento visão e especificação de caso...
O Product Backlog, contendo os requisitos de
software deve corresponder aos objetivos registrados
no documento Visão que p...
5. Técnicas de Elicitação de Requisitos
O levantamento de requisitos desempenha um papel
importante na construção de um si...
Brainstorming contém duas fases, a fase de
geração, onde as idéias são coletadas, e a fase de
avaliação, onde as idéias co...
c) Executor: é o responsável pelo produto sendo
construído. Tem que fornecer aos participantes
uma visão geral dos pontos ...
documentação, costumam responder melhor as
mudanças [16].
As organizações ágeis se concentram na construção
de habilidades...
c) Adaptação: quando os desvios detectados
forem inaceitáveis, o processo ou material
processado deve ser ajustado o mais ...
abordagem padrão pela maioria dos analistas de
requisitos. Considerando os stakeholders já definidos
no projeto, ao reuni-...
Quais os atributos do produto são críticos para
satisfazer as necessidades selecionadas, e, portanto,
para o sucesso do pr...
Monitorar trechos
Como sistema SMAAPE devo coletar informações de trechos com
sensores localizados em determinados pontos ...
Figura 4: Casos de Uso / Atores
Os diagramas de casos de uso fornecem apoio
visual a equipe de desenvolvimento e servem pa...
[9] SOMMERVILLE, I. Engenharia de Software. 8 ed.
Português. São Paulo, Brasil: Addison Wesley, 2007.
Page: 552.
[10] LAUE...
Próximos SlideShares
Carregando em…5
×

A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

251 visualizações

Publicada em

Analyse a proposal to combine elicitation techniques to write vision document and use cases specifications. The results obtained from this study showed that the combination of selected techniques can generate effectively a vision document and use case specifications and align them to Scrum methodology by product backlog generation and user story derived from use cases.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
251
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

  1. 1. Uma proposta para combinar técnicas de elicitação de requisitos para a produção do documento visão e especificação de casos de usos alinhados à metodologia de desenvolvimento ágil Scrum André Rocha Agostinho <andre@magnadev.com.br>, Herez Moise Kattan <herez@herez.net> e Nery Signorini Neto <nery.signorini@mac.com> Abstract Analisar uma proposta para combinar técnicas de elicitação de requisitos para serem empregadas na produção do documento visão e especificação de casos de uso. Os resultados obtidos neste estudo mostraram que a combinação das técnicas selecionadas puderam produzir com eficácia o documento visão e especificações de casos de usos e alinhá-los à metodologia ágil Scrum. Analyse a proposal to combine elicitation techniques to write vision document and use cases specifications. The results obtained from this study showed that the combination of selected techniques can generate effective vision document and use case specifications and align them to Scrum methodology. 1. Introdução Com o aumento da utilização de metodologias ágeis em projetos de software, analistas e projetistas necessitam ter um maior conhecimento das técnicas de elicitação de requisitos, de modo a combinar e adaptar as técnicas de elicitações utilizadas no modelo de desenvolvimento sequencial, ou seja, em cascata ou Waterfall Model [1] com o modelo de desenvolvimento iterativo e incremental das metodologias ágeis. Este artigo propõe uma combinação de técnicas de elicitações tradicionais para a montagem do documento Visão (Rational Unified Process - RUP) [2] e para a especificação de casos de uso alinhadas à metodologia de desenvolvimento ágil Scrum, tendo como ponto de estudo inicial dos requisitos e casos de uso, a análise de um sistema qualquer de Monitoramento de Estradas, aqui denominado pelas siglas: SMAAPE (Sistema de Monitoração de Acúmulo de Águas Pluviais nas Estradas), para a criação do documento Visão. 2. Motivação As metodologias ágeis por possuir um framework aberto e focado em entregar funcionalidades com o máximo de valor possível ao cliente, preceito este, declarado no Manifesto Ágil (Agile Manifesto) [3] exigem a criação de um backlog simplificado e com requisitos estimados para a entrega em um curto ciclo de tempo. Em muitos casos a etapa de elicitação de requisitos pode ser negligenciada por interferência da filosofia ágil, que por tratar os requisitos como maleáveis e passíveis de mudanças a cada iteração pode resultar em uma partida precoce, ou seja, já se inicia o desenvolvimento das funcionalidades desejadas precocemente, sem a existência de um documento de Visão bem elaborado e com especificações de requisitos completas, sem ambiguidades, sem erros, completas consistentes e coerentes como recomenda a IEEE-830-1998 [4], sejam aos objetivos do produto de software desejado ou as necessidades dos stakeholders. Frequentemente analistas de negócios necessitam aumentar seus esforços em definir os stakeholders do projeto e elucidar todas as suas necessidades , priorizá-las e encaminhá-las a equipe de desenvolvimento. Para se alcançar o sucesso, a facilitação em elicitar informação assim como habilidades em desenhar processos irá assegurar que a produção dos requisitos de softwares se encontrem com as necessidades dos stakeholders [5]. Na metodologia ágil Scrum, o mínimo de planejamento necessário para se iniciar um projeto consiste em ter um documento de Visão e um Product BackLog bem definido [6]. No documento Visão, deve-se constar quais metas o produto de software necessita atingir, além de especificar todos os stakeholders do projeto e seus respectivos papéis.
  2. 2. O Product Backlog, contendo os requisitos de software deve corresponder aos objetivos registrados no documento Visão que por vez devem refletir aos desejos reais dos stakeholders [4]. Na Metodologia Ágil Scrum, requisitos são elaborados de forma progressiva em cada iteração denominada sprint. Em cada sprint, permite-se que stakeholders possam definir suas necessidades para garantir maior eficácia no desenvolvimento das funcionalidades. Com Scrum, frequentemente é utilizado história de usuário como técnica de elicitação de requisitos. As histórias de usuários são focadas nas funcionalidades, portanto indicadas para elicitação de requisitos funcionais na visão do usuário do sistema, são muito semelhantes aos casos de uso (Use Cases), porém, sem riqueza de detalhes importante para o desenvolvimento. É uma forma de elicitação ágil, onde costumam participar em sua criação, desenvolvedores com habilidades na disciplina de engenharia de requisitos, situação esta, comum em equipes multidisciplinares que trabalham com métodos ágeis. Embora casos de uso e histórias de usuários compartilhem a mesma meta da funcionalidade do requisito, casos de uso costumam ser rejeitados por equipes ágeis por estarem associados ao modelo tradicional de cascata. O desafio do artigo consiste em combinar técnicas de elicitação de requisitos para a produção do documento Visão e especificação de casos de uso alinhado à metodologia ágil Scrum sem descaracterizar seu comportamento iterativo e incremental, criando-se assim uma possibilidade em incorporar técnicas não ágeis de elicitação em um ambiente ágil. 3. Requisitos de Software O conjunto de requisitos define um problema do mundo real que necessita ser resolvido pelo sistema, esclarecendo o seu propósito e fornecendo todas as informações necessárias para que possa executar sua função. Individualmente, cada requisito deve ter um objetivo único e mensurável, possibilitando a sua validação [7]. A resolução de um problema cotidiano também é mencionada, definido um requisito como uma propriedade que deve estar presente em um software com o objetivo de resolver algum problema do mundo real [8]. Sommerville [9] adiciona o conceito de restrição como limitação das opções para desenvolvimento da aplicação, definindo requisitos como o conjunto formado pelas restrições operacionais de um sistema e pelos serviços por ele fornecidos. Requisitos de sistema de software são comumente classificados em funcionais, não funcionais e de domínio [10]. 4. Elicitação de Requisitos de Software Tendo como objetivo principal a obtenção de requisitos do sistema a ser desenvolvido, durante a fase de elicitação de requisitos, a equipe do projeto atua junto com os clientes, usuários e demais stakeholders para compreender as necessidades do negócio, utilizando ferramentas como entrevistas, observação, cenários e protótipos. Assim os engenheiros de software procuram entender o domínio da aplicação, as funcionalidades a serem oferecidas, as interações existentes com outros sistemas e as restrições impostas pelo negócio. Erros no registro dos requisitos funcionais durante o processo de elicitação, são muito comuns e difíceis de se corrigirem, chegando a ser estimado que 70% [11] dos erros identificados são gerados por incompletas e inconsistentes especificações do sistema [12]. Problemas de elicitação podem ser classificados como: a) Problemas de Escopo: As fronteiras do sistema não são definidas ou determinadas, onde há excesso de informações desnecessárias e informações essenciais ao sistema são omitidas ou esquecidas; b) Problemas de Entendimento: Usuários desconhecem suas necessidades, analistas possuem pouco ou nenhum conhecimento do domínio do problema, usuários e analistas falam diferentes linguagens (literalmente ou figuradamente). Informações óbvias podem ser omitidas, podem haver conflitos entre usuários pelas respectivas necessidades ou percepções de suas necessidades; requisitos são geralmente vagos e imprecisos, como por exemplo “fácil de usar” ou “robusto”. c) Problemas de Volatilidade: Requisitos evoluem no tempo, pelas necessidades de mudanças pela necessidade de mudanças dos stakeholders.
  3. 3. 5. Técnicas de Elicitação de Requisitos O levantamento de requisitos desempenha um papel importante na construção de um sistema de informação, pois é o início para toda a atividade de desenvolvimento de software. É onde o analista faz as primeiras reuniões com os clientes e/ou usuários para conhecer as funcionalidades do sistema que será desenvolvido. Algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema, além disso, a falha do analista em não descrever os requisitos de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto [22]. As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto pelo analista. A seguir serão apresentadas de forma resumida algumas dessas técnicas. 1. Entrevistas: A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. 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; b) 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; 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 pode ser difícil de analisar e poderá haver informações conflitantes das diferentes partes interessadas [9]. 2. Questionários: Os questionários são indicados, por exemplo, quando há diversos grupos de usuário que podem estar em diversos locais diferentes. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais. Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: a) Múltipla escolha; b) Lista de verificação; e c) Questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta. Na fase de preparação do questionário, deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa [4], deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização. Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa. 3. Brainstorming: Brainstorming é uma técnica para geração de idéias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem diversas possibilidades.
  4. 4. Brainstorming contém 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. 4. Prototipagem: 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. O protótipo é indicado para estudar as alternativas de interface do usuário. Problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: a) Interface de usuário; b) Relatórios textuais; c) Relatórios gráficos, entre outras. Alguns dos benefícios do protótipo são as reduções dos riscos na construção do sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção. 5. Joint Application Design (JAD): O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto. O JAD tem quatro princípios básicos: a) Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema; b) Uso de técnicas visuais: para aumentar a comunicação e o entendimento; c) Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção; e d) Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes. O JAD é composto de duas etapas principais: Planejamento, que tem por objetivo elicitar e especificar os requisitos; e Projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos). Há seis tipos de participantes, embora nem todos participem de todas as fases: a) Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança; b) Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza;
  5. 5. c) Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto; d) Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado; e) Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça; f) Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico. O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema. Os RNF’s desempenham um papel crítico durante o desenvolvimento de sistemas, e erros devido a não elicitação ou a elicitação incorreta destes estão entre os mais caros e difíceis de corrigir, uma vez que um sistema tenha sido implementado [13]. O Framework proposto por Chung [14] é abordagem mais completa até o momento e procura tratar de todos os tipos de requisitos não funcionais desde as primeiras etapas do processo de desenvolvimento de software. Apesar de ser um framework bastante completo e eficaz para lidar com requisitos não funcionais durante a elicitação de requisitos, este framework não favorece a integração destes requisitos nas etapas seguintes do desenvolvimento de software, ficando, assim, uma lacuna aberta para que conflitos entre requisitos funcionais e não funcionais passem desapercebidos durante o projeto do software. Trabalhos apresentados por Cysneiros [15] enfatizam premissas apresentadas por Chung [14] de que a falta de integração dos RNFs aos requisitos funcionais, e por consequência sua integração aos modelos conceituais, pode resultar em tempos maiores para se finalizar um software, assim como maiores custos com manutenção. 6. Metodologias Ágeis (Iterativo e Incremental) Com o aumento do interesse por metodologias ágeis no ano de 2000, principalmente após a publicação do Manifesto Ágil em 2001, muitas equipes de desenvolvimento aderiram as metodologias ágeis na esperança de reduzir o tempo de entrega de funcionalidades e minimizar a quantidade de erros. Para muitos projetos onde o crescimento do sistema aumenta a dificuldade em se adicionar novas funcionalidades, equipes creem em uma proposta de desenvolvimento ágil com menos burocracia, tornando o processo mais rápido e com maior eficiência, entregando funcionalidades prontas e testadas em curtos ciclos de tempo. Para muitas pessoas o apelo dessas metodologias ágeis é a sua reação à burocracia das metodologias de engenharia. Alguns pesquisadores creem que métodos tradicionais conferem ao desenvolvimento de software uma lentidão desnecessária, uma vez que se prendem a processos e práticas excessivamente formais. Os métodos ágeis, por sua vez, procuram aumentar a interação entre as pessoas para reduzir a documentação e a rigidez de processos, buscando o equilíbrio entre aplicar nenhum ou muitos processos [16]. Os métodos ágeis apresentam mudanças significativas nos métodos de engenharia, uma delas é ser menos orientado a documento, pressupondo-se que a parte fundamental da documentação é o código-fonte. Frequentemente pessoas associam métodos ágeis com a ausência de documentação, quando na realidade valoriza-se a criação de documentos somente quanto necessário ou quando estes servirem de apoio para o ciclo de desenvolvimento. Métodos tradicionais utilizam-se de muita documentação pois tendem a tentar planejar uma grande parte do processo de software com grande detalhe por um longo período de tempo, o que funciona bem até que as coisas mudam. Assim, sua natureza é a resistir à mudança. Os métodos ágeis, no entanto, por trabalharem com pouca
  6. 6. documentação, costumam responder melhor as mudanças [16]. As organizações ágeis se concentram na construção de habilidades individuais e na promoção de um alto grau de interação entre os membros da equipe e clientes do projeto. Equipes ágeis acreditam que projetos complexos de hoje, a compreensão vem mais da interação face a face que de documentação e não acreditam que a dependência de processos pesados faz- se por falta de habilidade, talento e conhecimento [17]. Os métodos tradicionais pressupõem a derivação precoce de um conjunto completo de requisitos estáveis de software, focando a redução de custos, mudanças através da sua eliminação, e tornar o processo de desenvolvimento de software mais previsível e eficiente. Essa meta é buscada por meio da inclusão de processos disciplinados e artefatos bem definidos que precisam ser seguidos e são dificilmente adaptáveis. Assumem ainda que desvios no planejamento são consequência de falhas no processo: alguma etapa da engenharia de requisitos que não envolveu as pessoas corretas, ou o projeto de arquitetura que não contemplou determinada restrição. Porém, há fatores externos à equipe de desenvolvimento de software e até mesmo às organizações que implicam a necessidade de alteração de requisitos de software. Os métodos ágeis surgem como uma alternativa para melhor acomodar essas mudanças, mantendo a qualidade do projeto e minimizando seus custos de implementação, para tanto utilizando práticas como entregas rápidas e sistemáticas, retroalimentação constante, priorização dinâmica de requisitos, entre outras [17]. Os métodos tradicionais pressupõem a derivação precoce de um conjunto completo de requisitos estáveis de software, focando a redução de custos, mudanças através da sua eliminação, e tornar o processo de desenvolvimento de software mais previsível e eficiente. Essa meta é buscada por meio da inclusão de processos disciplinados e artefatos bem definidos que precisam ser seguidos e são dificilmente adaptáveis. Assumem ainda que desvios no planejamento são consequência de falhas no processo: alguma etapa da engenharia de requisitos que não envolveu as pessoas corretas, ou o projeto de arquitetura que não contemplou determinada restrição. Porém, há fatores externos à equipe de desenvolvimento de software e até mesmo às organizações que implicam a necessidade de alteração de requisitos de software. Os métodos ágeis surgem como uma alternativa para melhor acomodar essas mudanças, mantendo a qualidade do projeto e minimizando seus custos de implementação, para tanto utilizando práticas como entregas rápidas e sistemáticas, retroalimentação constante, priorização dinâmica de requisitos, entre outras [17]. 7. Metodologia Scrum Definido por Ken Shwaber e Mike Beedle [18] no início dos anos 90, o Scrum é um método ágil que pode ser empregado no desenvolvimento de projetos pequenos, médios e grandes. Apoiado em uma abordagem iterativa e incremental, caracterizada pela elaboração progressiva, para aumento da previsibilidade e controle sobre os processos, o método valoriza a colaboração entre as pessoas e trabalho em equipe, melhorando a comunicação e maximizando a colaboração, combinados com iterações curtas para atingir seus resultados. Figura 3: Visão Macro do Método Scrum Conforme Schwaber e Sutherland [19] o Scrum é sustentado por três pilares: a) Transparência: todos os aspectos que afetam os resultados do processo devem ser visíveis àqueles que o gerenciam. Além disso, a compreensão dos resultados é compartilhada por todos os envolvidos no processo. b) Inspeção: os aspectos do processo devem ser inspecionados com uma frequência tal que quaisquer variações indesejáveis sejam passíveis de detecção.
  7. 7. c) Adaptação: quando os desvios detectados forem inaceitáveis, o processo ou material processado deve ser ajustado o mais rápido possível para minimizar o impacto de desvios posteriores. Os principais papéis em um projeto Scrum são o Product Owner, Time Scrum e Scrum Master. Onde: a) Product Owner é o representante do produto ou patrocinador do projeto, é a pessoa responsável por inserir itens no product backlog. Scrum Master, é responsável por remover impedimentos da equipe, convocar cerimoniais como Daily Meeting e Sprint Planning, e facilitar comunicação entre o Product Owner e o Time Scrum; b) Time Scrum, é composto por membros técnicos (desenvolvedores, designers de interface, administradores de banco de dados e outros) e caracterizado por ser multidisciplinar e auto- organizável; c) Scrum Master não representa um papel de gerente de projeto ou líder, mas sim um facilitador, é comum membros da equipe exercerem liderança situacional em suas especialidades. Como qualquer desenvolvimento iterativo e incremental, a metodologia Scrum nomeia cada iteração de sprint, sugerindo uma “timebox” de duas à quatro semanas, período em que o time Scrum deve se comprometer a entregar funcionalidades prontas e testadas. Durante a sprint o time deve estar focado no desenvolvimento dos itens de backlog que foram selecionados durante a Sprint Planning, cerimonial de planejamento que antecede o início de cada sprint. No Sprint Planning, Product Owner, Scrum Master e Time Scrum participam no planejamento do sprint elicitando e estimando requisitos que deverão ser implementados para o próximo sprint. Somente uma parte do Product Backlog é analisada e levada ao planejamento, que após ser particionada, priorizada e estimada, passa a compor o BackLog do sprint a ser iniciada, o que é chamada de Sprint BackLog. Pela metodologia Scrum ser um framework aberto, é possível engajar quaisquer técnicas de elicitação para o planejamento de requisitos , assim como cerimoniais a parte podem ser criados de acordo com a necessidade, como é o caso do planejamento do documento visão, que deve ser elaborado em conjunto com o time Scrum antes de qualquer elicitação de requisitos ou planejamento de sprints. 8. Combinando Técnicas de Elicitação para o sistema SMAAPE Visão geral sobre o SMAAPE Na tentativa em reduzir acidentes rodoviários e tornar as estradas mais seguras, o SMAAPE (Sistema de Monitoramento de Acúmulo de Águas Pluviais em Estradas) é um sistema a ser aplicado sob concessão do estado para monitorar trechos de estradas propícios a alagamento durante pancadas de chuvas. O sistema deve contar com sensores distribuídos e instalados em trechos de estradas, que ligados a uma central deve em tempo real, coletar e enviar informações do nível pluviométrico e metereológico do local. A central do SMAAPE deve receber os dados coletados pelos sensores, classificá-los e notificar somente trechos potencialmente perigosos as unidades de conservação mais próximas, que por vez, deverão encaminhar frotas de apoio ao local. Selecionando técnicas de elicitação Muitos artigos e livros descrevem diferentes formas de realizar elicitação de requisitos. Para os analistas de requisitos, os esforços em se ter uma técnica eficiente, pode-se conduzir a uma busca insaciável pela bala de prata [13] no objetivo de resolver todos os problemas de elicitação de um projeto. Entretanto, estudos [6] comprovam que projetos exigem tipicamente mais de uma técnica para ser utilizada em levantamento de requisitos. Além disso, um grande problema na elicitação de requisitos, hoje, é a diferença significativa entre especialistas e analistas inexperientes. A falta de consciência por analistas do estado da arte das técnicas e ferramentas para levantamento de requisitos, combinados com uma indisposição geral para adotá-los é o grande responsável por esta situação. Esta situação é ainda mais agravada pela atual escassez de diretrizes sistemáticas e métodos flexíveis. Para a elicitação de requisitos do SMAAPE, este artigo propõe adotar e combinar três técnicas de elicitação de requisitos mais populares entre os mais experientes analistas de requisitos. Workshops Colaborativos é considerado como uma das mais bem sucedidas técnicas de elicitação na produção de requisitos de qualidade e visto como
  8. 8. abordagem padrão pela maioria dos analistas de requisitos. Considerando os stakeholders já definidos no projeto, ao reuni-los em sessões de Brainstorming, foi possível definir as principais sessões do documento visão. Entrevistas. Para compreender os diferentes pontos de vistas dos stakeholders do projeto, as entrevistas focam em levantar diretamente as necessidades das visões individuais de cada entrevistado, descobrindo assim, novas informações, possíveis conflitos e políticas. Modelos. A utilização de documentos facilitam o entendimento entre os stakeholders e analistas e requisitos. Para o SMAAPE, documentos gráficos como IDEF0 e Modelo Semântico permitem um fácil entendimento da visão funcional do projeto, clarificando informações de entradas e de saída sem a necessidade de conhecimento técnico. Elicitando para a montagem do documento visão Para modelagem do documento visão, a utilização das técnicas Workshops Colaborativos e Entrevistas utilizando-se JAD, foram aplicadas diretamente aos seguintes stakeholders: Stakeholders Identificados: #1 Secretário de Transporte (Governo do Estado, representado pela secretaria de transporte Patrocina o projeto); #2 Diretor DER (Depto Estradas e Rodagem, responsável pelas estradas do estado); #3 Diretoria Comercial CMSP (Centro de Meteorologia de SP) (Centro Meteorológico de São Paulo, responsável pelas previsões meteorológicas do estado); #4 Superintendente regional para conservação das estradas (Secretaria responsável pela conservação das estradas); #5 Diretor Centro de Manutenção (Base Central – Gestão e Coordenação); #6 Coordenador Centro de Manutenção (Bases Instaladas – Operacionais); e #7 Polícia Federal Rodoviária (Participa do sistema através de seu acionamento preventivo ou após acidente). Fases de Elicitação 1º Fase - Reunião com os principais stakeholders. O objetivo desta reunião foca-se em responder inicialmente cinco questões relacionadas a visão do produto.  Quem está comprando o produto? Quem é o consumidor final?  Para quais as necessidades do consumidor o produto deve ser endereçado? Quais os atributos do produto são críticos para satisfazer as necessidades selecionadas, e, portanto, para o sucesso do produto?  Como o produto comparar com os produtos existentes, tanto dos concorrentes como da mesma companhia?  Qual é o prazo e orçamento para desenvolver e lançar o produto? Na primeira fase os seguintes stakeholders participaram: Secretário do Transporte como o líder da sessão, representante DER, representante CMSP e engenheiros de requisitos responsáveis pela implementação do sistema SMAAPE. 2º Fase - Entrevistas individuais com os principais stakeholders. 3º Fase - Brainstorm com todos os stakeholders. Resultados obtidos para o Documento Visão Os resultados obtidos estão divididos em três partes e agregam ao documento visão: a) Questionário do produto, b) Políticas e Restrições, c) Modelos gráficos e, d) Product Backlog inicial a) Questionário do produto Quem está comprando o produto? Quem é o consumidor final? O estado é o comprador do sistema SMAAPE e o consumidor final são os usuários de rodovias e estradas. Para quais as necessidades do consumidor o produto deve ser endereçado? Os usuários de estradas necessitam trafegar com maior segurança em rodovias e estradas em épocas que chuvas potencializam perigo em trechos com histórico de acúmulo de água, derrapagens e acidentes.
  9. 9. Quais os atributos do produto são críticos para satisfazer as necessidades selecionadas, e, portanto, para o sucesso do produto? Os atributos indispensáveis para que o sistema opere são: coleta em tempo real das informações através da alta disponibilidade e eficiência de coleta de dados dos sensores. Recebimento em tempo real das informações e eficiência na acurácia dos dados na Central de Monitoramento. Agilidade na tomada de decisões, acionamento e descolocamento das unidades de apoio ao local aferido pelo monitoramento. Como o produto se compara com os produtos existentes, tanto dos concorrentes como da mesma companhia? Não existe concorrência ou comparações com o SMAAPE por se tratar de um sistema único, inovador e de iniciativa governamental. Qual é o prazo e orçamento para desenvolver e lançar o produto? Orçamento inicial estimado em trinta milhões de reais com um prazo para lançamento de uma versão piloto em oito meses considerando alguns trechos de uma única rodovia e doze meses para o lançamento oficial considerando integramente uma única rodovia. Após o lançamento o projeto será reavaliado e um novo documento visão deverá ser montado visando atender a implementação em todas rodovias do estado. b) Políticas e restrições  Restrições de negócio (em relação ao Business da Empresa pelas informações de usuários chaves e gestores;  Políticas corporativas;  Regras de negócio;  Particularidades do negócio a ser otimização por um sistema computacional. c) Modelos gráficos Durante as reuniões, os engenheiros de requisitos produziram ao menos um documento que foi de entendimento e consentimento de todos os stakeholders. Modelo Semântico. Com o modelo semântico, os engenheiros de requisitos puderam esboçar a primeira versão estrutural do sistema SMAAPE, explicitando entidades, relacionamentos e dependências. A produção deste documento também foi de fácil entendimento por todos os stakeholders além de fornecer grande valor à equipe de desenvolvimento. Figura 5: Modelo Semântico SMAAPE d) Product Backlog Inicial O mínimo de planejamento necessário para se iniciar um projeto em Scrum consiste em ter um documento de Visão e um Product BackLog bem definidos [6]. Com o documento visão especificado, stakeholders bem definidos, políticas e restrições estabelecidas, a equipe junto com stakeholders elencam a primeira rodada de histórias do projeto SMAAPE priorizadas pelos seguintes fatores: valor do incremento do produto, o custo do desenvolvimento, a quantidade de riscos removidos ao se desenvolver o incremento do produto e o grau de incerteza no desenvolvimento. Histórias Prioridade Monitorar trechos 1 Marcar trechos como perigosos 2 Desmarcar trechos como perigosos 3 Acionar unidades de apoio 4 Notificar trechos perigosos 5 Relatório de trechos perigosos 6 Alta disponibilidade dos sensores 1 Eficiência na apuração das informações coletadas 6 Eficiência no acionamento das unidades de conservação e apoio 4 Tabela 1: RF e RNF
  10. 10. Monitorar trechos Como sistema SMAAPE devo coletar informações de trechos com sensores localizados em determinados pontos da estrada e encaminhá-los a central de monitoramento para análise. Quem Sistema SMAAPE Ação Devo coletar informações de trechos Como Com sensores Onde Localizados em determinados pontos da estrada Motivo Encaminhá-los a central de monitoramento para análise Especificando Casos de Uso Casos de uso descrevem uma sequência típica de ações que um ator executa para completar uma determinada tarefa [20]. A modelagem de casos de usos procura clarificar o ponto de visão de como os atores irão interagir com o sistema e como eles atingirão os seus objetivos. Escrever bons casos de uso é mais uma arte do que uma ciência. E, como em qualquer arte, não há regras absolutas para a criação de suas obras-primas. Porém, mesmo não existindo regras absolutas, para se especificar casos de uso, é necessário se atingir um grau de abstração a ponto de torná-lo livre de tecnologia e independente para implementações. Em metodologias ágeis, como consequência da forma de elicitação coletiva e colaborativa entre desenvolvedores e analistas de negócio, casos de usos são frequentemente substituídos por histórias de usuários, que embora compartilhem da mesma meta de interação com o usuário, não apresentam a riqueza em detalhes como os casos de usos. Informações [23] ressaltam um grande equívoco na substituição de casos de uso com histórias de usuário. Este artigo parte da seleção da história “Monitorar trechos” como fonte para especificação de casos de usos através de seu detalhamento, o que possibilita a aplicação das técnicas: a) identificação de casos de uso, b) identificação de atores e c) Diagrama de caso de uso. a) Identificando Casos de Uso: O detalhamento da história de usuário [3] “Monitorar trechos” possibilita a identificação de casos de uso com base na seguinte informação: uso: Coletar dados do trecho e Analisar dados do trecho. b) Identificando Atores Encontrar atores é um dos primeiros passos na definição de casos de uso do sistema SMAAPE. Cada tipo de fenômeno externo com o qual o sistema deve interagir é representado por um ator. Para identificar os atores, foi utilizado o seguinte questionário [21]. a) Quem vai usar a funcionalidade principal do sistema? b) Quem terá o apoio do sistema para fazer suas tarefas diárias? c) Quem terá de manter e administrar o sistema, e mantê-lo em funcionamento? d) Com quais dispositivos de hardware o sistema precisa lidar? e) Com quais outros sistemas o sistema precisa interagir? f) Quem ou o que tem interesse nos resultados (o valor) que o sistema produz? A combinação do questionário com a aplicação da técnica de especificação de história aos casos de uso, é possível identificar os atores relacionados a “Quem” executa as determinadas funções e “Como” executam. Caso de uso: Coletar dados do trecho Caso de Uso Quem (Ator) Como Coletar dados do trecho Sensor Coletando informações em tempo real das estradas Tabela 3: Casos de Uso Coletar dados do trecho Caso de uso: Analisar dados do trecho Caso de Uso Quem (Ator) Como Analisar dados do trecho Central de monitoramento Recebendo e analisando as Informações dos sensores Tabela 2: Casos de Uso Sugeridos A ação “devo coletar informações de trechos” e o motivo “encaminhá-los a central de monitoramento para análise” possibilitam a identificação dos casos de Tabela 4: Casos de Uso Analisar dados do trecho c) Diagrama de casos de uso Com os casos de usos e atores identificados, a história de usuário “Monitorar Trechos” pode ser representada graficamente através de um diagrama de caso de uso.
  11. 11. Figura 4: Casos de Uso / Atores Os diagramas de casos de uso fornecem apoio visual a equipe de desenvolvimento e servem para facilitar o entendimento e comunicação entre técnicos e analistas de requisitos. 9. Conclusão O artigo buscou atender o desafio proposto em se combinar técnicas de elicitação de requisitos para a produção do documento Visão e especificação de casos de uso alinhado à metodologia ágil Scrum. A seleção e combinação de técnicas de elicitação mostraram ser eficazes para a amostragem SMAAPE, possibilitando a rastreabilidade dos requisitos (RF e RNF) definidos com o documento visão. Durante o experimento notamos que cada vez mais são exigidos conhecimentos em técnicas de elicitação de requisitos quando utilizado metodologias ágeis para desenvolvimento. Considerando que a metodologia Scrum não oferece meio para elicitação, o analista de requisitos não somente precisa dominar diferentes técnicas (o que já é um grande desafio), mas também precisa estar apto a trabalhar com equipes colaborativas que participam efetivamente na confecção do documento visão à construção e validação das funcionalidades. Não descaracterizar o comportamento iterativo e incremental pode ser mantido na maioria das fases, mas não ao longo de todo o ciclo como, por exemplo, após a finalização do documento visão sugere-se que não existam mais mudanças nos que se diz respeito aos objetivos e características do produto, portanto, uma vez estabelecido, o documento de visão passa a ser o escopo fechado do projeto, cabendo ao Product Backlog à responsabilidade de acomodar e aceitar mudanças. 10. Referências Bibliográficas [1] 1970. Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9. Disponível em: http://www.cs.umd.edu/class/spring2003/cmsc838p/Pr ocess/waterfall.pdf Acesso realizado em 25 de abril de 2013. [2] IBM RUP – Rational Unified Process - Disponível em: http://www-01.ibm.com/software/rational/rup/ Acesso realizado em 30 de abril de 2013. [3] Manifesto for Agile Software Development, Disponível em: http://agilemanifesto.org Acesso realizado em 25 de abril de 2013. [4] IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications [5] BABOK, A Guide to the Business Analysis Body of Knowledge, Chapter 6. International Institute of Business Analysis (IIBA). [6] SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press. 2004. Disponível em: http://www.scrumalliance.org/articles/115-the-product- vision Acesso realizado em 27 de abril de 2013. [7] WITHALL, S. Software requirement patterns. 1 ed. Inglês, Redmon, EUA: Microsoft Press, 2007. Page: 384. [8] SWEBOK: Guide to the Software Engineering Body of Knowledge. Los Alamitos, EUA: IEEE Computer Society, 2004. Page: 202.
  12. 12. [9] SOMMERVILLE, I. Engenharia de Software. 8 ed. Português. São Paulo, Brasil: Addison Wesley, 2007. Page: 552. [10] LAUESEN, S. Software requirements: styles and techniques. 1 ed. inglês. Londres, Inglaterra: Addison- Wesley, 2002. Page: 591. [11] A New Approach for Software Requirements Elicitation, Prasad Rajagopal, Roger Lee, Thomas Ahlswede, Chia-Chu Chiang, Dale Karolak [12] Beichter, F. et al., “SLAN-4-A Software Specification and Design Language.” IEEE Transactions on Software Engineering, SE-10, 2, 1984, pp. 155-162. [13] Brooks Jr.,F.P."No Silver Bullet: Essences and Accidents of SoftwareEngineering" IEEE Computer Apr 1987, No 4 pp:10-19, 1987. [14] Chung L., “Representing and Using Non- Functional Requirements: AProcess Oriented Approach” Ph.D. Thesis, Dept. of Comp.. Science.University of Toronto, June 1993. [15] Cysneiros, L.M. and Leite, J.C.S.P. ‘Integrating Non-FunctionalRequirements into data model” 4th International Symposium on Requirements Engineering – Ireland June 1999. [16] FOWLER, M. The new methodology. 13 de Dezembro de 2005. Disponível em: http://martinfowler.com/articles/newMethodology.html Acesso realizado em 25 de abril de 2013. [17] HIGHSMITH, J.; COCKBURN, A.Agile Software Development: the business of innovation. IEEE Computer, num. 9 - 2001, september, pages: 120 to 127. [18] SCHWABER, K. and M. Beedle (2002). Agile Software Development with SCRUM, Prentice-Hall. [19] Ken Schwaber & Jeff Sutherland. Disponível em: http://www.scrum.org/Scrum-Guides Acesso realizado em 25 de abril de 2013. [21] UML TOOK KIT 2.0 , 1991 Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, ERIKSSON. HANS , 1991 [22] POMPILHO, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed. Ciência Moderna Ltda, 1995 [23] Nee, N., “Developing effective agile requirements relies on both user stories and use cases”, ESI Point of View, 2013

×