quarta-feira, 20 de fevereiro de 2013

Cenas dos próximos capítulos (18/02/2013)

A aula de hoje deixou um gosto de "cenas dos próximos capítulos", ou seja, fomos apresentados "ao que vem por aí" ...

  • Participação em estudo empírico - Fomos convidados a participar de um estudo empírico a ser realizado nos próximas aulas da disciplina. A responsável pelo experimento, mestranda sob a orientação da prof. Renata, passou as informações básicas sobre o trabalho, que versa sobre o alinhamento de objetivos a processos. Aqueles que aceitaram o convite já assinaram o termo de consentimento e preencheram o questionário de perfil. E ficou a curiosidade sobre como será a participação no processo;
  • Seminário - como parte da avaliação da disciplina vamos apresentar um seminário em grupo, com tema relacionado ao conteúdo que estamos estudando. O grupo do qual participo irá propor uma junção de tecnologias, sendo elas o Archimate/Armor e o GQM. Uma tarefa que está se mostrando desafiadora. Aproveitamos a aula para retirar várias dúvidas ... e novas surgiram;
  • Dando continuidade ao exercício que foi iniciado em sala de aula (o qual já comentei no post anterior), para complementar o exercício procuramos utilizar uma ferramenta automatizada para elaborar os diagramas, que já haviam sido rascunhados no papel. Decidimos usar o OpenOME. Tem sido um desafio lidar com as diferenças de notação ... só no papel era mais fácil, pois não precisávamos nos preocupar tanto com a possível mistura de notações. Foi interessante no sentido de aprendizado e principalmente por perceber o que os profissionais e acadêmicos que estão trabalhando com modelagem de objetivos devem sentir ao precisar manipular ferramentas, integrar trabalhos, entre outros, sem a disponibilização de uma notação padronizada.

segunda-feira, 4 de fevereiro de 2013

Colocando em prática ...

Na aula de 28/01/2013, após a apresentação de novos conceitos e questões da área, começamos a trabalhar em um exercício prático, que consiste basicamente em criar modelos de objetivo (em diferentes níveis de detalhe), procurando assim solidificar o conhecimento que estamos formando.

Durante a aula de 04/02/2013 prosseguimos em tal exercício. Seguem abaixo algumas das dúvidas que nosso grupo teve durante a elaboração dos modelos, como uma forma de compartilhar dúvidas que outros grupos também possam ter tido:
  • Podemos representar uma dependência indireta (isto é, um agente 1 depende de um agente 2 que depende de um agente 3 para cumprir um determinado objetivo, assim o agente 1 depende indiretamente do agente 3)? Se for agregar valor ao modelo, esclarecendo a situação, então é útil que seja representado;
  • Um soft goal pode ser decomposto em outros soft goals? Sim. Depende do quanto se quer detalhar uma ocorrência;
  • Uma tarefa pode ser decomposta em outras tarefas? Sim. E  a justificativa é a mesma apresentada acima;
  • Cada conceito só pode ter um grupo de decomposição diretamente abaixo dele? Sim, ou ficaria a dúvida de como ligar os diferentes grupos decompostos. Quando essa situação surgir é necessário organizar a hierarquia, criando um novo nível, ou refazendo as decomposições visualizadas a princípio;
  • Em um modelo, considerando a hierarquia de conceitos, qual é o conceito mais adequado para ser nó-folha? Em um modelo de mais alto nível normalmente só haverá a presença de goals (hard e/ou soft). Já em um modelo mais detalhado, onde também serão considerados os conceitos de taks e resources, é adequado que os nós-folhas sejam tasks e/ou resource (dependendo do que se está mapeando). Eles são conceitos mais concretos, portanto mais refinados, e passam justamente uma ideia mais detalhada sobre a compreensão de um objetivo inicial. É bom analisar atentamente situações onde não se consegue detalhar um objetivo, refinando-o como task(s).

Aula de 28/01/2013

Após um breve recesso ... retomada às aulas, e a aula de hoje apresentou várias questões novas. Assim, vou usar o post de hoje, não para tentar analisar algo, mas para destacar alguns dos itens debatidos na aula que julguei interessantes. Ao descrevê-los pretendo compreendê-los melhor.

  • Dois pontos fortes e característicos da Análise de Objetivos e que contribuem para a sua adoção pelas empresas e profissionais: Análise de Contribuição e Análise de Alternativas - entenda o que você pode obter com aqueles objetivos, verifique quais são as opções disponíveis - informações cruciais para o melhor funcionamento de uma empresa;
  •  OR_Decomposition versus MEANS_END. O primeiro caracteriza uma divisão de alternativas para um conceito da análise de objetivos (goal, task), permitindo assim que se visualizem opções. O MEANS_END no entanto, também é uma indicação de decomposição de algum conceito, ela representa um meio para se realizar um determinado objetivo/tarefa. Algumas diferenças: 
      - OR_Decomposition: Precisam existir pelo menos dois componentes em cada decomposição; MEANS_END: Um único componente é possível;
         - OR_Decomposition: Pode ser considerado como uma decomposição entre elementos do mesmo tipo (uma hierarquia de objetivos, por exemplo); MEANS_END: Pode ser considerado como uma decomposição entre eles elementos de diferentes tipos (entre objetivos e tarefas, por exemplo);
  •  Goal versus Task: Um . goal é algo que se pretende atingir, uma intenção. Uma tarefa é uma ação (que pode ser atômica ou complexa). Diferenciar esses dois conceitos, e principalmente aplicá-los pode se tornar confuso. Existe um padrão de nomeclatura que indica que goals devem ser descritos na voz passiva e tasks na voz ativa (é um auxílio, mas não é suficiente e é fácil de burlar). A grande questão é: o que se está pretendendo comunicar com o modelo? Como você vai descrevê-lo? E é ao obter tal resposta que você pode tomar a melhor decisão. As vezes, a caracterização de um e de outro pode se tornar um pouco repetitiva;
  • Delegação versus Dependência. Delegação e Dependência são duas formas de relacionamento entre agentes de um modelo de objetivos com algumas características em comum (há uma dependência entre um agente e outro para cumprir um objetivo / realizar uma tarefa), mas uma certa diferenciação. E devido a isso torna-se complicado identificar qual o correto relacionamento para ser aplicado entre dois agentes. A melhor maneira de diferenciá-los é encarar uma delegação como sendo uma dependência "com algo a mais", onde esse "algo a mais" é um compromisso (quem recebe um objetivo/tarefa delegada assume o compromisso de cumprir aquele objetivo/tarefa junto àquele que fez a delegação). Esse mesmo compromisso de retorno não existe em uma situação de dependência.

quarta-feira, 19 de dezembro de 2012

Por que é tão difícil?

Definir Análise de Objetivos é fácil.
Aplicar Análise de Objetivos é difícil.

A complexidade do que é necessário fazer deve funcionar como um desestimulante na indústria para se aplicar a análise de objetivos, mesmo que muitos já tenham percebido a sua importância. A academia ainda precisa encontrar uma maturidade e uma usabilidade nos métodos e ferramentas que permitam a popularização dessa atividade que oferece benefícios à Engenharia de Requisitos, e por consequência à Engenharia de Software, cujo produto é o próprio software.

Algumas dificuldades/problemas que podem ser apontados:
  • Há uma quantidade significativa de métodos e ferramentas. E ainda por cima eles não são integrados;
  • Não há padrões claramente estabelecidos;
  • A comunicação com os stakeholders é complicada - elicitar objetivo é difícil, pois as pessoas podem fazer algo sem saber dizer exatamente porque faz aquilo, entre outras considerações;
  • Sendo a análise de objetivos um processo de refinamento - até quando refinar? Qual é o ponto de parada ideal?
  • O reconhecimento do que deve ser identificado como goal e do que deve ser requirement;
  • O reconhecimento do que deve ser identificado como hard goal e do que deve ser soft goal;
  • O reconhecimento do que deve ser identificado como goal e do que deve ser task;
  • O estabelecimento de relacionamentos entre goals, entre agentes, entre goals e agentes;
  • Qual é o tipo correto de relacionamento (dependência? delegação?);
  • Se existir, qual(is) é(são) a(s) alternativa(s) de um objetivo?
  • Se existir, qual(is) é(são) a(s) contribuição(ões) de um objetivo?
  • ... (melhor parar com a lista, por enquanto).
Essas dificuldades/problemas precisam ser superadas. Algumas serão sanadas a medida que a área ganhar maturidade. Outras, deixam a impressão de que essa atividade continuará sendo uma atividade essencialmente complexa e que deve ser executada por um profissional de larga experiência.


Enterprise Architecture

Uma nova sigla que se juntou a verdadeira "sopa de letrinhas" que os profissionais da computação estão acostumados a lidar é EA (Enterprise Architecture). Tal área surge como uma estratégia de união entre a tecnologia da informação e o meio empresarial.
Para que as organizações possam retirar o máximo de vantagens das tecnologias de informação disponíveis é preciso que tais tecnologias estejam adaptadas às necessidades das organizações. A primeira palavra que vem à mente nessa união certamente passa pela informatização de Processos.

E no que isso está relacionado com a Análise de Objetivos?
Processos existem para satisfazer Objetivos. Para melhor compreender um processo é necessário ter em mente o(s) objetivo(s) que ele atende. Dessa forma, ao invés de simplesmente informatizar o processo que existe naquele momento é possível entender a sua motivação, o motivo de sua existência,  e mesmo conferir se o processo é adequado, é o melhor para atender ao objetivo ao qual está relacionado. E ao se perceber tal situação, além da visão de processos, começou-se a trabalhar também com a modelagem de objetivos, inicialmente em um caráter bastante informal, mas caminhando em direção a um formato mais adequado para beneficar a EA.

quinta-feira, 6 de dezembro de 2012

Requirements x Goals

A Análise de Objetivos é desenvolvida com o propósito de oferecer benefícios à Engenharia de Requisitos (ER), e pode desempenhar um papel fundamental para o sucesso desta etapa da Engenharia de Software em um projeto.
No entanto a Análise de Objetivos ainda precisa atingir um estágio de maturidade, de estabilidade, para que possa conquistar o mercado. Atualmente há, por exemplo, muitos métodos com focos diferentes. Não há algum método, hoje, contemplando todas as atividades associadas a análise de objetivos. De uma certa forma, lembra a situação que os métodos e notações da Orientação a Objetos enfrentavam antes que a UML fosse lançada.

Como será a "UML" da Análise de Objetivos? Quando será que ela vai surgir? Será da Academia ou do Mercado, ou de uma parceria entre ambos?

Outra questão interessante, e que é difícil de efetivamente entender e aplicar é a própria diferenciação entre o que é um requisito (requirement) e o que é um objetivo (goal). Um objetivo é definido como algo que o sistema quer atingir, enquanto um requerimento é uma característica que o sistema deve/precisa ter. São conceitos parecidos e complementares. Um requisito pode ser encarado como um refinamento de um objetivo. É dito que um requisito tem um critério de corte preciso quando comparado ao objetivo. Tratando objetivos e requisitos como complementos, em diferentes níveis de abstração, poderíamos encará-los como uma estrutura de árvore, na qual se começa com objetivos de mais alto nível de abstração que vão sendo sucessivamente refinados, aumentando os níveis da árvore até um nível de abstração menor. Os nós-folha de tal árvore são justamente os requisitos.

Mas até onde detalhar? Como reconhecer que uma característica é efetivamente um objetivo ou um goal? Parece ser uma distinção sutil, mais subjetiva, que pode variar de analista para analista, dependendo de uma série de considerações, e principalmente da experiência do analista.

quarta-feira, 28 de novembro de 2012

Organisational Goal x Individual Goal ... Resumindo

Individual Goal - Set of intended  state of affairs
Organisational Goal - Set of constraints imposed by the organisational role

Tais goals são existentes dentro de qualquer organização. Eles precisam estar claramente estabelecidos. E mesmo que haja um "goal principal", normalmente está-se falando em um "conjunto de goals", com níveis diferentes de importância. Alguns diretamente identificados, outros que são gerados de forma indireta.

Eles não são necessariamente os mesmos (para organização e indivíduos), mas devem encaminhar juntos. Podem ocorrer conflitos, o que desestabiliza a organização e consequentemente afeta os indivíduos que a compõe. Uma organização para ter sucesso não pode estabelecer seus goals sem levar em consideração os goals dos indivíduos que a compõe. Cada indivíduo deve adotar os goals da organização a que pertence. Algo como o conjunto precisa estar atento a cada elemento, e cada elemento deve seguir as regras do conjunto para que assim a organização possa progredir e prosseguir ao longo do tempo.

E aproveitando a deixa da frase final, ficou a curiosidade: como os goals de uma organização e dos indivíduos que a compõe evoluem ao longo do tempo? Como isso ocorre e é registrado?