De Histórias a Casos de Uso

Grupo: Antonio, Batista, Fábio, Odalberto e Anderson

Introdução

Durante a fase inicial do desenvolvimento de software, indiferente do processo adotado, os requisitos identificados não devem ser representados através de um modelo formal, por não serem compreendidos pelos usuários. Neste primeiro momento é necessário gerar uma metáfora simples e intuitiva que facilite a comunicação e a disseminação do conhecimento dentro da equipe envolvida. Para usuários e clientes, o uso da linguagem natural oferece maior poder de expressão, facilitando a comunicação. De outro lado, existe a necessidade dos analistas em registrar e formalizar os requisitos elicitados através da construção de modelos UML. Devido a necessidade das organizações de reter o conhecimento gerado em seus projetos e atividades, a elicitação de requisitos vem ganhando uma conotação cooperativa procurando integrar as diversas visões : Estratégica, por meio de entrevistas com o gerente, um proprietário ou administrador. Operacional, tratando diretamente com os usuários finais. É uma nova abordagem que envolve todos os participantes do processo que executam as atividades ou os que dela se beneficiam.

 

Principais problemas para elicitação

Falta de entendimento entre analistas, clientes e usuários, pois cada um destes atores possui um modelo mental diferente referente ao processo e uma forma de comunicação que dificulta a socialização do conhecimento sobre as atividades envolvidas. Requisitos inconsistentes e modelagem falha são causados por desconhecimento sobre o fluxo das informações, dependência entre fluxos incorretos e visão distorcida da forma de execução das atividades.

Muitas das inconsistências incorporadas aos requisitos do software e posteriormente á aplicação desenvolvida ocorrem durante o processo de elicitação de requisitos e elas decorrem de fatores como a comunicação entre os usuários e os analistas e a falta de registros sobre o projeto. Os clientes não possuem uma idéia clara e detalhada de suas reais necessidades, dificultando a identificação dos requisitos funcionais e a distinção entre estes requisitos e as funções desejáveis para o software. Durante o processo de explicitação do conhecimento, nem sempre os usuários identificam todas as atividades que executam. Cada atividade pode ser descrita de várias formas por diferentes usuários e, cada usuário pode apontar diferentes requisitos que podem levar a requisitos incompletos e ambíguos.

Principais problemas para elicitação

Questões em aberto mesmo com a existência de diversas soluções:

Necessidade de expressão dos Stakeholder (ou, em Português, parte interessada ou interveniente, refere-se a todos os envolvidos no processo, por exemplo, usuários, clientes, colaboradores, investidores, fornecedores, etc) através de uma linguagem natural.

Consolidação dos requisitos através de uma descrição única para cada atividade.

Formalização dos requisitos através da conversão dos cenários descritos em modelos UML e facilitar a disseminação do conhecimento produzido.

Fundamentação teórica

Há diversos enfoques nas propostas apresentadas em trabalhos publicados, mas há uma convergência quando apontam a necessidade das organizações em armazenar, gerenciar e disseminar o conhecimento gerado durante o desenvolvimento de seus projetos. Uma das abordagens estudadas é a Prática de Storytelling (Narração de histórias) devido ao emprego da Gestão do Conhecimento e sua aplicação em diversas áreas que possibilita um compartilhamento de experiências de trabalho, do conhecimento altamente contextual necessário para a solução de problemas do mundo real. Já no Group Storytelling, mais de uma pessoa contribui para a construção de uma história de forma síncrona ou assíncrona, localizada ou distribuída em diversos pontos de decisão e utilizando diversos meios. Esta é a técnica utilizada como ponto de partida para a elicitação de requisitos. A gestão do conhecimento na organização de software fornece os recursos básicos necessários para o desenvolvimento de uma cultura de trabalho na qual ocorrem constantes trocas de conhecimento e aprendizado.

Enfoque da Solução em 3 camadas
É consenso que o uso de um método cooperativo facilita e incentiva a explicação do conhecimento dos stackeholders (envolvidos) sobre as atividades, levando a requisitos consistentes, menos ambíguos e que atendam aos usuários. Na metodologia proposta neste trabalho, a observação, entrevistas e análise de documentos empregados na Engenharia de Requisitos dão lugar a narrativa, com o objetivo de explorar as inúmeras visões do negócio, do processo e da própria atividade. O uso da técnica de Group Storyteling possibilita a comunicação de uma forma simples e pouco formal entre os participantes, promove o compartilhamento do conhecimento individual sobre as atividades que devem ser apoiadas pelo software a ser desenvolvido.

Enfoque da Solução em 3 camadas
 

Primeira camada, Construção da História: Propõe a construção cooperativa de histórias para explicar o processo a ser apoiado pelo software em desenvolvimento e todo o contexto que o cerca. Para facilitar a narrativa, a história é divida em cenários. Cada cenário deve retratar o domínio do trabalho, as atividades, suas condições de execução e implicações. Este modelo explora conhecimentos e habilidades necessários para a execução das atividades, assim como os constrangimentos impostos pelo processo ou pela organização. Os usuários poderão trazer para a história figuras, representações de uma determinada situação ou mesmo de registros do cenário descrito. A criação de um glossário facilitará a construção de um vocabulário comum á equipe e através de votações, suprir a necessidade de um mecanismo de tomada de decisões e a solução de impasses. Nesta camada coexistem três papeis a serem assumidos pelos usuários: o redator, o moderador e o comentador.

Enfoque da Solução em 3 camadas
 

Terceira camada, Conversão para casos de uso: Responsável pela conversão dos cenários descritos e trabalhados anteriormente para casos de uso, resultando em um modelo formal de especificação de requisitos de software e que atenda à Engenharia de Software. Este método baseia-se em preceitos da teoria da atividade, no método de group task analisys e na construção de casos de uso e estabelece ainda um paralelo entre as informações relacionadas à teoria da atividade. Esta camada irá apoiar a interação da equipe de analistas alocados ao processo de engenharia de requisitos. O objetivo é apoiar a atividade do analista e, mantendo seu poder de decisão. Além dos papéis vistos anteriormente, existe ainda o papel do converso, responsável por converter os cenários para casos de uso. Os redatores desta camada poderão alterar as decisões dos casos de uso, depurando o que foi produzido.

Enfoque da Solução em 3 camadas
 Segunda camada, Descrição dos Cenários:  Consiste no refinamento do que foi descrito através das

histórias construídas na primeira camada. Estes cenários serão utilizados para reduzir as ambigüidades, identificar os papéis que emergem a partir das histórias .  Trata-se de uma descrição semi-estruturada que facilita a identificação dos requisitos e a posterior formalização. Possibilita a junção dos cenários relacionados, assim como o desmembramento de uma descrição que propõe duas ou mais situações independentes .
 O método aqui utilizado apóia a geração destes cenários

incentivando a cooperação entre os participantes. Os papéis a serem assumidos pelos usuários serão análogos à camada anterior.

Metodologia e estado atual do trabalho

 Como primeiro passo no desenvolvimento deste trabalho está

o levantamento bibliográfico sobre a gestão do conhecimento, elicitação de requisitos, storytelling e teoria da atividade na elicitação de requisitos além de fazer um levantamento e comparação das soluções existentes.

 Em seguida, levantamos as técnicas e ferramentas utilizadas

no decorrer do trabalho. Iniciamos o detalhamento do modelo, método e a modelagem da ferramenta a ser implementada como parte da solução proposta a serem concluídas. Ao concluir a modelagem, passa-se à implementação e em seguida, à fase de testes do artefato.

Validação dos Resultados
 Será realizado estudo de caso envolvendo uma equipe de

desenvolvimento de software, clientes e usuários do sistema que será projetado. A partir daí será realizado um estudo preliminar para detalhar as condições em que será realizado o experimento.

 De posse destas informações serão estabelecidos critérios

para análise dos resultados e elaboração de cenários, os quais envolvem elicitação de requisitos em três situações : utilizando os métodos convencionais com o uso do método proposto mas sem a utilização da ferramenta computacional e utilizando o método proposto e o artefato computacional que faça parte da solução.

 Realizado o experimento, será feita a análise dos resultados

coletados nas três situações descritas a partir dos critérios previamente estabelecidos.

Conclusão

Este é um trabalho de pesquisa que visa a criação de um modelo e artefato computacional para apoiar o processo de elicitação de requisitos de software, realizado de forma cooperativa, através de linguagem natural. Esta solução possibilita ainda a captura e formalização dos requisitos a partir das histórias obtidas através da explicação do conhecimento dos envolvidos acerca das atividades, contexto e cenários. Sua utilização irá favorecer, aliviando a carga cognitiva tanto dos analistas quanto dos usuários finais, uma vez que este se comunica através de metáforas simples. Os próximos passos incluem a identificação e detalhamento da abordagem adotada e os itens que irão compor os cenários, descrição mais criteriosa do método utilizado para a formalização dos requisitos, projeto e realização de um estudo de caso e posterior análise dos resultados encontrados.

Método base de apoio
   

CSCW é a abreviatura de "Computer Supported Cooperative Work", traduzido em Português como Trabalho Cooperativo Suportado por Computador. De uma forma genérica, o CSCW é uma área científica interdisciplinar que estuda a forma como o trabalho em grupo pode ser suportado por tecnologias de informação e comunicação, de forma a melhorar o desempenho do grupo na execução das suas tarefas. As pesquisas em CSCW são normalmente caracterizadas em um quadro de duas dimensões: a distância das pessoas cooperando (remota ou localmente), e a forma de comunicação (síncrona ou assíncrona). O CSCW enquadra-se num domínio científico interdisciplinar, envolvendo diversas áreas científicas, tanto técnicas, como sistemas distribuídos, comunicação multimédia, telecomunicações, ciências da informação, quanto humanas e sociais, como psicologia, percepção e teoria sócio-organizacional. O CSCW surgiu na década de 80, emergindo a partir da Automação de Escritório ("Office Automation"). Esta, por sua vez, apareceu cerca de dez anos antes, como uma forma de suportar o trabalho administrativo de grupos e organizações, evoluindo a partir de sistemas organizacionais como os sistemas de emissão de bilhetes de avião, que tinham surgido na década de 60.

Os programas informáticos cujo objectivo é serem usados por grupos cooperativos designam-se habitualmente por groupware. Genericamente, pode-se considerar o groupware como sendo software que suporta CSCW. As aplicações groupware mais antigas são o correio electrónico (E-mail), os grupos de discussão (newsgroup) e os sistemas de mensagens curtas, como o ICQ e o MSN Messenger.

Método base de apoio
 Um aspecto bastante importante para o groupware é a

existência de um ambiente partilhado pelos vários elementos do grupo. Este ambiente partilhado coexiste normalmente com ambientes privados de cada elemento do grupo, o que implica possuir diferentes mecanismos de gestão de acesso à informação, consoante esta seja privada ou partilhada. Neste último caso, há que ter particular cuidado com os aspectos de controlo de concorrência, de forma a assegurar a consistência da informação partilhada.

 Potenciais domínios aplicacionais da utilização de groupware:  Projecto e desenvolvimento de software, a coordenação de

processos de trabalho (Workflow), o Ensino, a telecooperação, a Arquitectura, o projecto de Engenharia, a Telemedicina e a edição cooperativa.

Método base de apoio

As aplicações groupware podem ser agrupadas de acordo com a sua funcionalidade genérica, constituindo as seguintes classes de aplicação: sistemas de comunicação; espaços de informação partilhada (Mediaspaces); coordenação de processos de trabalho (Workflow); suporte a reuniões (Workgroup computing); editores de grupo; agentes cooperantes; ensino assistido por computador (no qual se inclui o E-learning); Realidade Virtual.

       