• Nenhum resultado encontrado

Modelo de Razões Estratégicas

Capítulo 4. Modelagem Organizacional

4.1 A técnica i*

4.1.2 Modelo de Razões Estratégicas

O modelo de Razões Estratégicas é um modelo complementar ao modelo de dependências estratégicas apresentado na seção anterior. Este modelo permite compreender e modelar de forma mais detalhada as razões associadas com cada ator e suas dependências. Enquanto o modelo de Dependências Estratégicas prove um nível de abstração, no qual modela-se somente os relacionamentos externos entre atores, o modelo de Razões Estratégicas permite uma maior compreensão a respeito das razões estratégicas de atores em relação a processos da organização e como os mesmos são expressos. O modelo de Razões Estratégicas auxilia no processo de Engenharia de Requisitos, permitindo que elementos de processos e as razões por detrás dos mesmos sejam expressas. Na Engenharia de Requisitos, o modelo de Razões Estratégicas pode ser utilizado para compreender como sistemas estão relacionados/envolvidos em rotinas de atores da organização para gerar alternativas, bem como para modelar e suportar o raciocínio de atores organizacionais a respeito destas alternativas.

O princípio básico para desenvolver este modelo é observar as razões que estão associadas com cada ator em relação aos relacionamentos de dependência com outros atores. Um bom caminho para iniciar a decomposição é observar como os Dependee

podem satisfazer os dependums associados com os mesmos e a partir desse ponto, observar e decompor as intenções e razões organizacionais estratégicas como um todo.

Basicamente, este modelo é composto de nós e ligações. Os nós no modelo de Razões Estratégicas têm como base os tipos de Dependum definidos no modelo de dependências estratégicas: objetivo, tarefa, recurso e objetivo-soft. Tem-se, basicamente, dois tipos de classes de ligações: ligação meio-fim e ligação de decomposição de tarefa. Os mesmos são descritos a seguir:

• ligação meio-fim (means-end): este tipo de ligação está associada à obtenção de um determinado fim, o qual pode ser um objetivo, recurso, objetivo-soft ou uma tarefa através de um caminho. Este caminho ou meio para obter o fim é geralmente definido em termos de tarefas que são necessárias para atingir/obter o fim desejado. • ligação de decomposição de tarefa (task decomposition): uma tarefa é modelada

em termos de sua decomposição em sub-componentes através de uma ligação de decomposição. Permite-se com este tipo de ligação a decomposição em unidades menores de um nó tarefa para representar de forma mais detalhada as razões associadas com a realização da tarefa. Estas decomposições por sua vez podem estar ligadas através de ligações de dependência a outros nós pertencentes à decomposição de outros atores. Isto é normalmente necessário, sempre que o relacionamento for relevante para a compreensão das razões e intenções organizacionais.

Neste modelo, uma rotina representa um subgrafo incluindo todas as razões, bem como os meios para se atingir um fim do ponto de vista de um ator. Através deste modelo, pode-se modelar várias alternativas (meios) para se obter fins estratégicos para um ator.

LEGENDA

Recurso Tarefa Objetivo Objetivo-soft

Ligação de decomposição de tarefa Ligação meio-fim

Ligação de Contribuição

Ator

Limite do ator

Figura 14. Modelo de Razões de Estratégicas (SR) para o Agendamento de Reuniões, considerando a existência de um sistema computacional para realizar o agendamento.

Apresentamos na figura 14, um exemplo de modelo de razões estratégicas para o problema de agendamento de reuniões. O modelo de Razões Estratégicas para este problema consiste em descrever os relacionamentos intencionais “internos” de atores da organização, tais como ligações meio-fim que relacionam elementos de processos, provendo assim representações explícitas dos “porquês”, “comos” e alternativas. Desta forma, para cada ator apresentado no modelo de Dependências Estratégicas da figura

13, descrevemos no modelo de Razões Estratégicas as razões estratégicas sobre processos associados com cada ator.

Observando a figura 14, verificamos que o ator Agendador de Reuniões deve lidar com um pedido para organizar uma reunião. Desta análise, advém a tarefa Organizar Reunião. Esta característica é importante antes de decidir, por exemplo, quais aspectos do agendamento de reuniões poderiam ser cobertos por um possível sistema baseado em computador, quais os tipos de reuniões a serem agendadas, etc. Assim, permite-se explorar as alternativas do processo de agendamento.

Podemos também verificar nesta figura, que para realizar uma reunião, o ator Iniciador de Reunião depende do ator Participante de Reunião para que o objetivo comparecer reunião seja satisfeito. O fato da reunião ser agendada é indicada pelo subobjetivo Reunião Agendada associado com a tarefa Organizar Reunião. Neste ponto, outros subobjetivos poderiam ser incluídos, tais como: equipamentos a serem reservados para a reunião e memorandos a serem enviados, visando relembrar a reunião. Observamos também que a organização da reunião deve ser feita de forma rápida e com menor esforço possível. Estes desejos são representados pelos objetivos-soft Rápida e

Pouco Esforço. O iniciador de reunião pode agendar uma reunião via processo manual

(tarefa Agendar Reunião) ou utilizando o sistema agendador de reuniões (tarefa Deixar

Agendador Agendar Reunião). Desta forma, grande parte do trabalho de agendar

reunião pode ser atribuído ao ator agendador de reuniões. O ator agendador de reuniões possui a tarefa Agendar Reunião Automaticamente, a qual é decomposta em quatro sub- componentes através da ligação decomposição de tarefa: ObterDatasDisponíveis,

EncontrarMelhorData, ProporData e ObterConcordância. Assim, para agendar uma

reunião, o sistema agendador de reuniões obtém datas disponíveis de agendamento dos participantes, encontra melhores datas possíveis de agendamento a partir do cruzamento

das datas fornecidas pelos participantes, propõe uma data específica para o agendamento e finalmente solicita concordância dos participantes em relação a data de agendamento proposta. Por sua vez, para iniciar o processo de agendamento, o iniciador de reuniões precisa fornecer para o sistema agendador de reuniões, um intervalo de datas para agendamento de reunião (dependência do tipo tarefa EntrarIntervaloDatas).

Do ponto de vista do ator Participante de Reunião, pode-se se observar que espera-se dos participantes que os mesmos participem ativamente no processo de agendamento (tarefa Concordar com Reunião) e após isto, compareçam (tarefa

Comparecer Reunião) à reunião. Para um participante, concordar com uma reunião,

consiste inicialmente em chegar a uma data conveniente (Concordar (Reunião, Data)). Isto requer que o mesmo forneça informações de disponibilidade para o sistema agendador de reuniões e então tente concordar com datas propostas. Participantes também querem selecionar datas convenientes às suas atividades, bem como desejam que o processo de agendamento seja o mais breve e com menor esforço possível. Estes desejos são representados pelos objetivos-soft Conveniente(Reunião,Data) e Baixo

Esforço, respectivamente.

De uma forma geral, a técnica i* tem sido considerada de fácil entendimento pelos diversos stakeholders. Além disso, os recursos gráficos da técnica são apontados como suficientes para representar os aspectos mais relevantes do ambiente organizacional (Alencar et al. 1999). Verificamos, no entanto, observando a técnica mais detalhadamente, que a mesma poderia contribuir e ser utilizada de forma mais efetiva no processo de Engenharia de Requisitos, se os requisitos organizacionais representados em i*, fossem relacionados aos requisitos funcionais dos sistemas pretendidos. Neste aspecto, podemos observar nas dependências do tipo objetivo, recurso, tarefa e objetivo-soft, estabelecidas entre os atores em i*, uma rica fonte de

informações para descrever requisitos funcionais e detectar alguns requisitos não- funcionais.

O que propomos é integrar este tipo de técnica com casos de uso, podendo desta forma descrever requisitos funcionais, através do mapeamento das informações representadas em i* para casos de uso. Este tipo de integração, basicamente, permite que engenheiros de requisitos possuam uma fonte de informação para a descrição de requisitos funcionais, bem como possam raciocinar a respeito de como o sistema pretendido irá satisfazer os objetivos da organização, por que ele é necessário, quais as alternativas existentes, quais as implicações das alternativas para as várias partes interessadas, entre outros aspectos.