MAPEAMENTO COGNITIVO COMO UMA TÉCNICA PARA … · O processo de engenharia de requisitos é...

622

MAPEAMENTO COGNITIVO COMO UMA TÉCNICA PARA APOIO À ENGENHARIA DE REQUISITOS.

Raquel Dias Instituto Tecnológico de Aeronáutica ITA

Praça Marechal Eduardo Gomes 50, Vila das Acácias. São José dos Campos, SP, Brasil.

[email protected]

Brenda López Instituto Tecnológico de Aeronáutica ITA


[email protected]

Mischel Carmen Neyra Belderrain Instituto Tecnológico de Aeronáutica ITA


[email protected]

RESUMO Este artigo aborda conceitos de engenharia de requisitos e propõe aplicação de mapas

cognitivos como ferramenta colaborativa e de suporte à identificação dos problemas dos stakeholders, durante o processo de levantamento de requisitos de sistemas, apresentando estudo de caso do cluster aeronáutico de São José dos Campos, São Paulo.

A técnica de mapeamento cognitivo foi criada, a partir de pesquisas em psicologia, para representar pontos de vista dos indivíduos gerando mapas cognitivos, que agregados expressam graficamente o ponto de vista coletivo para tomada de decisão, demonstrando eficiência colaborativa.

Aplicada à engenharia de requisitos revelou potencial para promover a convergência dos diferentes pontos de vista sobre as necessidades reais dos stakeholders, de forma inovativa. Demonstrou eficiência ao aproximar os requisitos declarados no início do processo de desenvolvimento com os implementados ao longo do ciclo de vida do sistema/produto.

Palavras-chave: mapa cognitivo, engenharia de requisitos, tomada de decisão, representação

do conhecimento, ferramenta colaborativa.~

1 Introdução

O ciclo de desenvolvimento de produtos tem como fase principal o levantamento das

necessidades dos stakeholders. É neste momento que são identificados os problemas que

desenvolvedores e os stakeholders precisam resolver, e para isso buscam ferramentas de

apoio para a elicitação do conhecimento. A maioria das dificuldades em todo o processo de

desenvolvimento de produtos está associada ao perfeito entendimento entre os stakeholders

e os desenvolvedores, estes, responsáveis pelo levantamento dos requisitos do futuro

623

produto. É comum a existência de retrabalhos, atrasos de cronograma, custos alterados e

insatisfação, de ambos os lados, ocasionada pela deficiência na fase de levantamento dos

requisitos.

Durante a fase de validação, os desenvolvedores confirmam se os requisitos

especificados correspondem às solicitações dos stakeholders, bem como suas reais

necessidades.

Em geral utilizam-se revisões e checklists como técnicas de apoio ao processo de

validação, junto às partes interessadas, tais como clientes, usuários e engenheiros,

analistas. Os requisitos serão revisados, os problemas identificados e sanados.

Alguns problemas mais comuns são: Kotonya (1998).

falta de conformidade com padrões de qualidade;

requisitos mal formulados, ambíguos, confusos;

erros no modelo de sistema;

conflitos entre requisitos, os quais não foram detectados e tratados na fase de análise.

Na fase de análise o detalhamento permite completo conhecimento dos problemas e

dos requisitos mais importantes, embora haja a possibilidade de mudanças ao longo do

processo de desenvolvimento, exigindo intensa iteração no processo, de forma a impactar o

mínimo possível as atividades das fases posteriores.

Estruturar o ambiente decisório de forma a identificar os problemas que os

desenvolvedores de produtos aeronáuticos enfrentam, durante a fase de levantamento de

requisitos junto aos stakeholders, foi altamente motivador pois vislumbramos a possibilidade

de criar um cenário que permitisse extrair um modelo para minimizar as deficiências que, em

geral, ocorrem nessa fase.

O objetivo deste estudo foi demonstrar a eficiência do uso de mapas cognitivos como

ferramenta de suporte à engenharia de requisitos para a identificação e estruturação dos

problemas associados à fase de levantamentos de requisitos no setor aeronáutico.

2 Engenharia de requisitos.

O objetivo da Engenharia de requisitos é capturar, analisar, validar e refinar requisitos

para o desenvolvimento de um sistema através do uso de ferramentas que auxiliam no

processo de identificação, detalhamento e gestão dos requisitos.

Existem diretrizes para a engenharia de requisitos ditadas, dentre outras, por normas

como a Electronic Industries Alliance (EIA) stander - 632 (America National Standards

Institute ANSI (1998) e Institute Electrical and Electronics Engineers (IEEE ) stander STD

(1220-1998), IEEE (2005).

624

Requisitos podem ser conceituados como atributos de um sistema que permitem

identificar a capacidade e fator de qualidade que revele a utilidade do produto para o cliente

ou usuário, Young (2003). Os requisitos podem ser classificados como:

requisitos de negócios: definem o alinhamento do produto/sistema às metas de negócios

do stakeholder;

requisitos de alto-nível: revelam a visão do stakeholder, e são descritos na sua

linguagem. Permitem a definição do escopo de um sistema, bem como a estimativa de

custos e prazos necessários para o seu desenvolvimento;

requisitos funcionais: definem as funções que o sistema/produto deve atender;

requisitos desempenho: definem o padrão de desempenho exigido pelo cliente;

requisitos de interface: definem o padrão de operacionalidade, e

requisitos de verificação e validação: definem o grau de atendimento às solicitações dos

stakeholders.

A especificação de requisitos é composta pela relação das características que os

stakeholders desejam ver implementadas através do sistema de forma a atender

plenamente suas necessidades para resolução de seus problemas. A especificação é

elaborada usando-se a linguagem dos stakeholders.

É necessário que os requisitos sejam submetidos à análise técnica para que possam

ser traduzidos para linguagem técnica (de baixo nível) expressando o papel de cada

componente do sistema de forma a atender as necessidades especificadas pelos

stakeholders.

O processo de engenharia de requisitos é composto por quatro etapas principais:

levantamento e elicitação dos requisitos, análise e negociação, modelagem, e validação dos

requisitos. Estas etapas se processam de forma iterativa e recursiva devido às mudanças

que, normalmente, ocorrem durante o processo de desenvolvimento do sistema, conforme

pode ser visto no modelo espiral apresentado pela figura 1, a seguir.

625

Fig. 1 - Processo em espiral de Engenharia de Requisitos, Alves (2007)

Os requisitos podem, simplesmente, migrarem da forma que estão para a linguagem

técnica e neste caso recebem a denominação de requisitos transferidos, no caso de

requisitos novos, serão denominados por requisitos derivados.

Os requisitos tratados pela engenharia de requisitos possuem as seguintes

características:

Rastreabilidade: os requisitos de alto e baixo níveis devem estar estreitamente

relacionados, já que são apenas conversões de linguagem. A rastreabilidade permite

que ao se verificar e validar os requisitos de baixo nível seja possível identificar o

atendimento das solicitações do cliente.

Evolução: os requisitos sofrem modificações ao longo do processo de detalhamento, e

por isso muda de status à cada nova modificação tornando-se requisito definido,

aprovado, alocado, projetado, implementado, testado e verificado.

Alocação: os requisitos têm que ser alocados onde são necessários no sistema, como se

fossem componentes físicos.

As diferentes atividades para o cumprimento da fase inicial do ciclo de vida de um

sistema são conhecidas como análises de requisitos. As atividades a serem

desenvolvidas nessa fase, são as seguintes: Kotonya (1998).

I - Identificação e Levantamento de requisitos

Atividade em que são identificados os stakeholders, e os requisitos são extraídos

através de consultas a esses envolvidos, aos documentos, ao domínio do conhecimento,

e aos estudos de mercado; as atividades envolvidas nesta fase incluem:

626

Compreensão do domínio: busca estabelecer processo eficaz de comunicação entre o

desenvolvedor e os stakeholders.

Captura: corresponde à extração dos requisitos pretendidos, através de iteração com os

stakeholders.

Identificação e análise de problemas: descrição conjunta dos problemas e das soluções

propostas.

II - Análise e negociação dos requisitos

Atividade em que os requisitos são detalhados e analisados, podendo ser

recusados ou aceitos. Algumas das atividades envolvidas na análise de requisitos

incluem:

funcionamento pretendido para o sistema.

Resolução de conflitos: é comum a existência de conflitos nos requisitos identificados ao

longo do processo de identificação dos mesmos; tais conflitos devem ser resolvidos o

mais breve possível.

Confirmação: é confirmada com os stakeholders a completude dos requisitos, sua

consistência e validade.

III - Modelagem dos requisitos

A Especificação e Documentação formalizam os requisitos aceitos em um nível de

detalhamento adequado. Em todos os tipos de especificação há dois tipos de requisitos a

considerar:

Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema opere,

de forma completa e consistente para atender aos propósitos para os quais foram

desenvolvidos.

Requisitos não-funcionais: descrevem os aspectos não-funcionais do sistema, como

restrições nas quais o sistema deve operar, ou propriedades emergentes do sistema.

Costumam ser divididos em Requisitos não-funcionais de utilidade, de confiança, de

desempenho, de suporte e de escalabilidade.

A especificação resulta no Documento de Especificação de Requisitos incluindo

uma combinação dos requisitos dos diversos stakeholders. A utilidade desse documento

é diferenciada, conforme cada envolvido no processo Kotonya (1998), Sommerville

(2007).

Clientes: utilizado para confirmar a completude dos requisitos e solicitar modificações de

forma a atender suas necessidades.

627

Gestores: utilizado para orçamentar o sistema e planejar o desenvolvimento.

Engenheiros: utilizado para compreender o sistema que será desenvolvido.

Engenheiros (testes): utilizado para elaborar e aplicar os testes para validação do

atendimento dos requisitos.

Engenheiros (manutenção): utilizado para compreensão do sistema e o interdependência

de suas partes.

IV - Validação dos requisitos

Nesta fase de validação, os requisitos especificados são verificados e confirmados

pelos decisores, de forma a refletirem perfeitamente as solicitações dos stakeholders.

Em geral são feitas várias revisões e checklists que auxiliam a execução do

processo de validação, que envolve todos os stakeholders de forma a identificar os

problemas e as possíveis ambiguidades na descrição dos requisitos.

Finalizada esta fase, é possível admitir-se que há um nivelamento do

conhecimento relacionado aos requisitos de sistema, embora modificações possam ser

exigidas ao longo do processo de desenvolvimento. Alves (2007).

Estas fases não são independentes entre si, pois uma informação obtida numa

delas pode ser utilizada nas demais. A identificação e análise de requisitos é um

processo iterativo que se inicia com a familiarização do domínio do futuro sistema, e

culmina na confirmação dos requisitos, aumentando o grau de compreensão do sistema,

a cada fase do ciclo de desenvolvimento deste.

Uma das atividades mais importantes e complexas que ocorrem no ciclo de

desenvolvimento de sistemas é a gestão dos requisitos. Trata-se de atividade em que os

requisitos são controlados em função das mudanças ambientais. A gestão dos

requisitos tem início na sua especificação formal.

Esse documento precede a definição do escopo e as estimativas de custo e

prazos, por isso qualquer mudança na base dos requisitos causam impactos, e muitas

vezes propiciam situações críticas em todo o projeto.

Os requisitos de um sistema estão em evolução constante, por diversas razões,

como por exemplo, o problema abordado não ter sido completamente definido antes da

produção do documento de requisitos, ou pela alteração dos próprios requisitos no

decorrer do projeto devido às evoluções tecnológicas ou alterações na organização na

qual será utilizado.

A resolução de conflitos entre requisitos busca o equilíbrio no atendimento das

necessidades das diferentes partes interessadas.

628

O planejamento é uma parte importante da gestão de requisitos. Devem estar

definidas desde o início políticas para:

5. gestão de mudanças: o conjunto de procedimentos que permitam avaliar o custo e

impacto das alterações;

6. tratamento dos requisitos: procedimentos para tratamento dos requisitos. Como

mencionado, o processo é iterativo ao longo de todo o ciclo de desenvolvimento

do sistema.

A atividade de validação dos requisitos culmina na elaboração de documento dos

cliente e fornecedores. Este documento norteará todos os esforços das fases seguintes

do ciclo de vida do produto. A especificação dos requisitos deve ser objetiva e clara de

forma a evitar retrabalho, minimizando custo e esforço de implementação.

Em praticamente todos os domínios do conhecimento, a extração das

características ou dos requisitos do sistema tem como principal dificuldade o fator

comunicação.

Roger Pressman ilustra o problema com uma declaração de um cliente a um

analista:

certo de qu

(1995).

3 Mapas cognitivos.

Os mapas cognitivos são expressões gráficas de discursos realizadas por um

indivíduo ou grupos de indivíduos (atores) com o objetivo de demonstrar objetos (o

problema) em contextos de interações particular, segundo Cosset & Audet (1992).

A representação gráfica é o resultado da interpretação mental do(s) ponto(s) de vista

de indivíduo(s) capturada pelo facilitador relativa aos discursos dos atores sobre

determinado problema.

O facilitador deve permanecer o mais neutro possível ao longo de todo o processo

discursivo-reflexivo-recursivo, de forma a não interferir com informações pessoais na

elaboração do mapa cognitivo; porém é, praticamente, impossível a neutralidade total. Isto

porque o facilitador precisa interpretar e construir os eventos baseado nos seus conceitos de

valores e de visão subjetiva.

Na abordagem cognitiva, o problema é identificado, detalhado e analisado através de

um processo de interação entre o facilitador e os stakeholders, em busca de uma definição

precisa, admitindo-se a intersubjetividade do grupo ou do individuo. Desta forma os mapas

629

cognitivos podem ser utilizados para resolução de conflitos de pontos de vista na definição

dos requisitos no processo de desenvolvimento de sistemas.

Os mapas cognitivos demonstram ser bastante úteis tanto como produto quanto como

ferramenta, possuindo caráter dinâmico, admitindo-se alterações e ajustes durante sua

utilização, face as modificações por parte dos decisores diante de problemas complexos.

Os componentes dos mapas cognitivos podem ser de:

Identidade - determinam as chaves do problema (eventos, processos e atores);

categorização definem escalas e perfis revelando os relacionamentos das entidades

envolvidas no problema;

causais ou de argumentação - apresentam alternativas para mudança de estado ou

posição no mapa (linhas de argumentação).

Os mapas cognitivos podem ser:

organizacionais busca-se um mapa coletivo que represente uma ferramenta de suporte

para ações organizacionais;

individuais apresentam pontos de vista individuais, isolados, e são utilizados para a

construção dos mapas coletivos. Cosset & Audet (1992).

3.1 Construção do mapa cognitivo individual

A construção de um mapa cognitivo depende de dois fatores:

abordagem inicial por parte do facilitador demonstrando empatia e

estabelecimento de um processo de negociação.

As entrevistas devem ser espontâneas permitindo ao entrevistado tranquilidade para

expor seu ponto de vista e suas informações sobre o problema. Isto porque a expressão

corporal e reações constituem-se informações relevantes para o entendimento do facilitador

sobre o problema.

O mapa cognitivo é uma hierarquia de conceitos relacionados por ligações entre os

objetivos meios e fins, que representam o sistema de valores do(s) decisor(es) na forma de

objetivos estratégicos (os conceitos superiores na hierarquia).

O processo de extração do conhecimento é cansativo, por esta razão não deve

ultrapassar mais que 90 minutos, por reunião.

O processo de elaboração de mapas é composto por quatro passos conforme

descritos a seguir: adaptação de Eden (1998), Ensslin (1998), Montibeller (1996) , Bana

(1992).

1º Passo: Definição de um rótulo para o problema.

Reuniões entre facilitador e decisor(es) para definição de rótulo para o problema

baseado em questões relevantes levantadas pelo(s) decisor(es).

630

2º Passo: Definição dos elementos primários de avaliação.

Os Elementos Primários de Avaliação (EPAs) representam os objetivos, metas,

valores, ações, alternativas, apreensões dos decisores e são definidos a partir de

entrevistas entre facilitador e decisor(es).

3º Passo: Construção dos conceitos a partir do EPAs.

Os conceitos são transformados em ações e organizados conforme existência de

similaridades, e hierarquizados por constructos subordinados e superiores, Eden (1998).

A estrutura é representada pelos constructos individuais organizados

hierarquicamente. Para garantir a corretude da percepção do facilitador face às

informações do(s) entrevistado(s), utiliza-se a observação do contraste, ou seja, o pólo

oposto psicológico, de forma explícita ou não, para a construção dos mapas.

Em geral, o facilitador adota a primeira descrição anunciada pelo(s) decisor(es),

obtida na primeira percepção que lhe vem à mente, seja esta positiva ou não.

Algumas diretrizes podem servir de orientação ao longo do processo de

construção dos conceitos, constituindo-se em boa estratégia Eden (1998).

Cada conceito deve ser orientado por uma ação, e ser claro e conciso, expresso por

apenas uma frase.

Deve-se utilizar a linguagem do(s) decisor(es), aproveitando-se as palavras e expressões

usadas, de forma a preservar o perfil do(s) decisor(es).

Deve-se identificar os valores, opções, meios e fins.

O decisor deve ser interrompido sempre que o facilitador não conseguir registrar as

percepções, porém deve-se preservar a linha de raciocínio.

Identificar, registrando na parte superior do mapa os conceitos que representam objetivos

estratégicos e/ou as metas mais importantes para o(s) decisor(es), que possam

representar ações estratégicas.

Identificar os conceitos muito explicados e justificados através das ligações com outros

conceitos e aqueles expressos emocionalmente pelo(s) decisor(es).

Evitar palavras como pode, precisa, deve.

A validação das informações contidas no mapa, devem ser realizados em um curto

período de tempo.

4º Passo: Hierarquização dos conceitos e analise do Mapa

A estrutura dos mapas cognitivos é composta por conceitos-fins identificados

-meios

631

ele pode ser alca

O processo prossegue até que o(s) decisor(es) responda(m) que o conceito é

importante por que é importante, caracterizando que se chegou ao nível hierárquico mais

alto do mapa.

Os conceitos relacionados por ligações de casualidade, par-a-par são

representados por setas.

Pode ocorrer situação em que um objetivo fim possa ser explicado por mais de um

objetivo meio, conflitantes. Neste caso Ensslin recomenda a adoção da análise

Multicritério. Ensslin (1998), Jardim (1999).

A análise dos mapas

Identificação dos clusters.

Pode-se definir um cluster como um grafo composto por um conjunto de nós inter-

relacionados. A sua identificação possibilita uma visão macro do mapa, e proporciona

redução da sua complexidade já que ressalta as ligações mais fortes que são as

intracomponentes, pois agrupam os conceitos que apresentam áreas de interesse

específicas baseadas nos conteúdos dos conceitos, e permitem uma análise separada de

cada cluster.

A detecção dos Pontos de Vista Fundamentais é feita através da observação da

topografia do mapa. Observa-se o conjunto de linhas do grafo. Essas linhas formam os

eixos de avaliação do problema Ensslin (1998), Ensslin (1996).

A análise dos ramos do grafo busca estruturar os caminhos que levam ao

conceito-fim do problema.

Esses caminhos, denominados por linha de argumentação, são compostos por

conceitos que sofrem influência e estão em posição hierárquica superior a um conceito-

meio. As linhas de argumentação dos clusters são consideradas linhas de argumentação

internas.

Os ramos do mapa são compostos por linhas de argumentação que representam

similaridade de conteúdo em relação ao ambiente de decisão.

Identificação dos Pontos de Vista Fundamentais.(PVFs)

Os pontos de vista fundamentais (PVFs) são base para ações que culminam na

tomada de decisão já que são oportunidades de escolhas entre alternativas. Os PVFs

632

carregam no seu bojo os valores considerados mais importantes pelo decisor(es) no

ambiente, permitindo antecipar as consequências advindas de tais ações.

A definição dos PVFs é feita a partir do enquadramento do mapa, quando se

determinam para cada ramo:

localização dos conceitos relacionados com o pensamento estratégico do(s) decisor(es).

localização dos conceitos que revelam ações potenciais.

localização dos conceitos que revelam ideias relacionadas com o candidato a PVF do(s)

decisor(es).

À medida que aumenta o grau de controle sobre o ponto de vista do(s) decisor(es)

é importante levar em conta as ações que influenciam tal PVF naquele ramo.

A propriedade essenciabilidade do ponto de vista no ramo configura-se

característica importante, a ser observada, ao longo da análise meios-fins, pois se trata

da necessidade de que o PVF corresponda à consequência dos objetivos estratégicos.

As propriedades controlabilidade e exaustividade dos conceitos devem ser

verificadas na análise dos objetivos fins-meios.

Realizadas as verificações das propriedades mencionadas, é possível estabelecer

critérios para avaliação de desempenho das ações conforme o PVF avaliado.

3.2 Construção do Mapa Cognitivo de Grupo ou Mapa Congregado

Quando o contexto exige mais de um decisor, configura-se a necessidade da

construção de mapa cognitivo coletivo.

O poder de decisão neste caso é compartilhado, porém os interesses podem ser

conflitantes, devido à representatividade de diferentes áreas, bem como diferenças de

perfis, personalidades, valores e etc... Ensslin (1998).

O mapa cognitivo que representa o modelo decisório de um grupo é denominado por

mapa cognitivo congregado, e pode ser abordado de duas maneiras:

Iniciar diretamente com o grupo;

Iniciar com os mapas cognitivos individuais.

Quando o levantamento é incompleto ocorre grande perda de qualidade prejudicando

a análise posterior.

O mapa congregado pode ser elaborado observando-se as seguintes etapas:

agregação dos mapas individuais através da união dos conceitos similares devendo ser

unificados pelos conceitos de sentido mais amplo; Eden (1998).

conexão entre conceitos: conectar os conceitos por ligações de influência.

633

O mapa cognitivo do grupo é obtido através da negociação entre o facilitador e os

decisores.

Uma vez elaborado o mapa agregado, com a evidência da contribuição de cada

decisor individual, este deve ser apresentado ao grupo que passará, então, a negociar

inclusão ou exclusão de conceitos, bem como suas respectivas ligações de influências para

decisores, gerando uma estrutura cognitiva coletiva denominada por mapa cognitivo

congregado.

A análise desses elementos pode levar ao estabelecimento de ações que convirjam

para a resolução dos problemas melhorando o desempenho dos processos de

desenvolvimento dos produtos/sistemas.

4 Aplicação prática A engenharia de requisitos depende muito da interação entre os stakeholders para

minimizar qualquer problema na definição de requisitos, que é a base para execução de

todo o ciclo de vida do sistema. O maior desafio dos profissionais envolvidos com o

desenvolvimento de produtos é elicitar o conhecimento de forma a entender, plenamente,

as necessidades e desejos dos stakeholders, traduzindo-as sob a forma de requisitos.

Aos requisitos estão vinculados os principais problemas que ocorrem durante o ciclo

de desenvolvimento de produtos como por exemplo, requisitos que não correspondem às

reais necessidades dos clientes, requisitos incompletos e mudanças nos requisitos já

definidos são problemas que propiciam retrabalhos, insatisfações e oneram os projetos.

Em geral, os requisitos se alteram durante o desenvolvimento de um sistema, e por

esta razão há que se estabelecer processos de engenharia de requisitos bem definidos,

definindo padrões, e dominando, conceitualmente, o problema a ser analisado e

solucionado.

Foi com a intenção de melhorar o processo de levantamento de requisitos que

realizamos a experiência de aplicar mapas cognitivos para identificar os pontos de gargalos

e as principais dificuldades enfrentadas pelos stakeholders durante a fase de elicitação dos

requisitos.

4.1 O método utilizado

Para a elaboração e análise dos mapas seguimos as teorias e recomendações

descritas na literatura publicada pelos autores Ensslin e Montibeller.

Foi utilizada a abordagem individual, com a construção do mapa cognitivo através de

entrevistas com cada decisor.

634

As entrevistas foram realizadas em ambiente neutro, tanto aos decisores, como ao

facilitador, com duração entre 60 e 90 minutos. Além das entrevistas, como informações

complementares, foi solicitado a um fornecedor a elaboração de um texto com descrição das

principais dificuldades enfrentadas por ele na qualidade de fornecedor de produtos

aeroespaciais, em ambiente clusterizado como se configura a cidade de São José dos

Campos.

À todos decisores foi solicitado que estabelecessem rótulo(s) para o(s) problema (s)

relevantes, com liberdade total de expressão.

As entrevistas aconteceram em clima de espontaneidade, colaboração e confiança de

todos os envolvidos.

A hipótese defendida de que os mapas cognitivos se prestam à melhoria do processo

de levantamento de requisitos, na identificação dos problemas impactantes, bem como a

compreensão da sistemática de elaboração do mapa, foi confirmada à medida em que foi

possível identificar e estruturar as dificuldades detectadas ao longo do processo de

engenharia de requisitos.

Os facilitadores, levando em conta os aspectos e o ambiente em que o processo

cognitivo ocorreu, concluíram que:

a liberdade de expressão e a informalidade contribuíram, sobremaneira, para o

desenvolvimento do trabalho de forma acelerada;

durante as entrevistas iniciais foi preciso redirecionar o foco para manter a linha de

raciocínio voltada para as questões levantadas pelos decisores.

4.2 Ferramenta utilizada para elaboração dos mapas. Marinho (2008)

Foi utilizado o software O IHMC CmapTools, um organizador gráfico, como

ferramenta, de apoio, para criar, editar, compartilhar, navegar e comentar mapas

conceituais.

Trata-se de um software para autoria de Mapas Conceituais desenvolvido pelo

Institute for Human Machine Cognition da University of West Florida. É uma ferramenta

colaborativa que permite interação em rede facilitando o processo de feitura dos mapas,

principalmente quando há mais de um facilitador envolvido, como foi o caso deste estudo.

Apresenta flexibilidade permitindo que módulos sejam instalados à medida em que

suas funcionalidades sejam requeridas, ao longo da feitura dos mapas.

Permite exportação dos mapas criados em formato XML/XTM, permitindo o uso dos

mapas em outros ambientes.

Disponibiliza recursos para formatação dos Mapas, permitindo que estes sejam

utilizados como imagens, vídeos, textos e até mesmo outros Mapas para detalhamento do

conhecimento.

635

4.3 Construção do modelo

Apresentamos, a seguir, como foi elaborado o modelo para estruturar e apoiar a

identificação das principais dificuldades no processo de levantamento de requisitos para

desenvolvimento de sistemas no setor aeroespacial de são José dos Campos. Os dois

clientes escolhidos demonstraram experiência e conhecimento no desenvolvimento de

foguetes e de aeronaves.

Um dos clientes, por possuir experiência como fornecedor, foi entrevistado também na

condição de fornecedor. O outro fornecedor atua no seguimento de desenvolvimento de

computador aeronáutico.

As influências externas são representadas pelo mercado profissional e concorrência

com outras empresas do ramo.

Os decisores revelaram heterogeneidade em termos de visão, métodos de atuação e

valores.

Foram construídos quatro mapas cognitivos individuais (Anexo I) como ferramentas

básicas de apoio à estruturação e identificação dos principais problemas que impactam o

processo de levantamento de requisitos.

4.3.1 Contexto decisório

Trata-se do ambiente de desenvolvimento de produtos aeroespaciais no cluster

aeronáutico em São José dos Campos, SP, durante a fase de levantamento de requisitos

junto aos stakeholders.

4.3.2 Estruturação do modelo

Para elaborar o modelo foram realizadas reuniões individuais com os dois clientes e

dois fornecedores.

Cada decisor expôs os problemas que vivencia no seu dia-a-dia com a engenharia de

requisitos.

A vantagem das entrevistas terem sido individuais, foi que o processo de

levantamento foi puro, ou seja, os decisores não foram influenciados uns pelas ideias dos

outros.

Os quatro decisores entrevistados falaram sobre seus valores, experiências e embora

a visão de cada um sobre aspectos relevantes da engenharia de requisitos foram

diferenciadas, todos convergiram a um objetivo principal que é desenvolver o produto para

satisfazer as necessidades dos stakeholders.

Apesar dos quatro decisores terem expressado o mesmo objetivo, o mapa foi

enriquecido devido aos conceitos diferentes já que foram abordados vários problemas

críticos na engenharia de requisitos o que se observa na heterogeneidade dos clusters.

636

O resultado foi a obtenção de uma visão mais abrangente dos problemas na área. Isto

pode ser constatado quando observamos a quantidade de conceitos que foram unidos com

outros similares, e que em um total de 81 conceitos, apenas 3 foram congregados

(identificados com caixas em gris no mapa congregado), além dos principais objetivos de

produzir o sistema e satisfazer as necessidades dos stakeholders. A grande maioria dos

conceitos foi relacionada por ligações de influências.

Para realizar os clusters, optou-se pela inclusão do objetivo final em cada cluster,

visando proceder a análise de cada cluster como um mapa individual.

1º Passo: Definição de um rótulo para o problema.

Na primeira reunião foi ainda solicitado aos decisores que informassem um rótulo para

definir os objetivos principais. Cabe observar que um dos fornecedores disponibilizou as

informações através de um texto, já que não dispunha de horário para participação nas

reuniões.

Os rótulos escolhidos pelos clientes foram:

Gerenciar o desdobramento dos requisitos desde o início do problema.

Satisfazer as necessidades do cliente.

Com relação aos desenvolvedores o rótulo escolhido foi:

Garantir a qualidade dos requisitos

2º Passo: Definição dos elementos primários de avaliação.

Ao final da primeira reunião foi solicitado a cada decisor que refletisse sobre os

aspectos que consideravam importantes quando pensavam nos problemas enfrentados

com engenharia de requisitos, permitindo a elaboração da lista de elementos primários de

avaliação (EPAs), resultando nas EPAs, mostrados na Tabela 1:

637

Tabela 1 Lista de Elementos Primários de Avaliação (EPAs).

Decisor Elemento Primário de Avaliação (EPA)

Cliente 1: foguete 1) Diferentes processos de engenharia de requisitos podem ser

um problema se não for bem gerenciado.

2) Questões de Comunicação.

3) Mudanças gestão/impacto das mudanças.

4) Sistema para gerenciamento dos requisitos.

Cliente 2: Aeronaves 5) Nem sempre a empresa captura a vontade do cliente.

6) Dinâmica do processo: cliente quer algo hoje e amanhã quer

outra coisa (mudanças no pedido).

7) Fator cultural.

8) Requisitos deficientes, com erros.

Fornecedor 1:

Aeronaves

9) Má qualidade dos requisitos.

10) Não levantamento dos requisitos.

11) Erros na comunicação.

Fornecedor 2:

Computador

aeronáutico

12) Treinamento.

13) Aprimoramento dos processos de engenharia de

requisitos e a integração com outros processos da empresa.

14) Escolha da ferramenta certa para o gerenciamento e

gestão de requisitos.

15) Base de requisitos estáveis.

3º Passo: Construção dos conceitos a partir do EPAs.

Ainda nesta primeira reunião foram elaborados um conceito inicial para cada EPA

indicando ação sobre cada aspecto que os decisores julgavam importantes para analisar

no contexto decisório considerado.

4º Passo: Hierarquização dos conceitos e análise dos mapas

Os facilitadores realizaram a primeira versão dos mapas cognitivos individuais,

com base nas informações colhidas na reunião. Foram, então, construídos quatro mapas,

sendo dois dos clientes e dois dos fornecedores.

Durante a reunião cada decisor foi questionado sobre o porquê da importância e

como se alcançar as ações expressadas pelos conceitos informados possibilitando a

obtenção de sequenciamento das ações meios-fins e as relações de influência

formalizando a topografia dos mapas, e corrigindo possíveis ambiguidades.

É importante notar que se dois ou mais conceitos estiverem posicionados em

mesma linha horizontal não significa que estarão no mesmo nível hierárquico.

638

Desta forma, a partir dos conceitos iniciais foram elaborados os conceitos meios e

fins resultando em 87 conceitos conforme mostrado na Tabela 2.

Tabela 2 Conceitos elaborados a partir dos conceitos iniciais.

Decisor Conceitos elaborados

Cliente 1: Foguete 23 conceitos

Cliente 2: Aeronaves 21 conceitos

Fornecedor 1: Aeronaves 18 conceitos

Fornecedor2 :

Computador aeronáutico

25 conceitos

TOTAL 87 conceitos.

Os mapas foram enviados a cada decisor pra confirmarem se a orientação das

ações estava de acordo com seus pontos de vista.

Os mapas foram novamente encaminhados aos decisores para validação e

rearranjo possibilitando identificação dos clusters.

Mapas Cognitivos do Grupo ou Mapa Agregado.

Uma vez elaborados e validados os mapas individuais, procederam-se ao

processo de agregação dos conceitos na tentativa de representar o que o grupo de

decisores considerou importante observar durante o processo de análise das dificuldades

enfrentadas pela engenharia de requisitos para o desenvolvimento de sistemas

complexos. Os facilitadores,

seja, grupos de conceitos que tratam do mesmo aspecto e apresentam forte relação de

influência.

Os mapas individuais foram agregados formando o mapa agregado do grupo, e

novamente enviados aos decisores Montibeller (1996).

Os decisores tiveram a liberdade de realizar qualquer modificação nos conceitos e

nas suas relações de influência. Os facilitadores analisaram as modificações inseridas

pelo grupo e realizaram as alterações enviando novamente o mapa agregado para

validação final do grupo.

A análise dos mapas - Identificação dos clusters

Com o mapa agregado validado, procederam-se à sua análise, inicialmente,

identificando-se os clusters, ou áreas estratégicas de interesse dos decisores para obter

o mapa congregado. Assim os conceitos cujo conteúdo apresentaram similaridade foram

agrupados formando os clusters.

639

Observa-se, na tabela 3, que ocorreram casos de conceitos pertencerem a mais

de um cluster, Cunha (1999).

Tabela 3 Identificação de clusters existentes

no mapas individuais. MAPA Clusters

Cliente 1 Necessidades

Mudanças

Cliente 2 Qualidade

Comunicação

Fornece

dor 1

Mudanças

Conhecimento

Processos

Ferramentas

Fornece

dor 2

Necessidades

Ferramentas

Gestão

A tabela 4 auxiliou no processo de identificação dos clusters em comuns de cada

mapa, resultando na detecção de oito clusters.

Tabela 4 Identificação o de clusters comuns existentes nos mapas. Cluster Cliente 1 Cliente 2 Fornecedor 1 Fornecedor 2

Necessidades X X

Mudanças X X

Qualidade X

Comunicação X

Conhecimento X

Processos X

Ferramentas X X

Gestão X

O resultado dessa análise é mostrado, através dos mapas cognitivos mostrados pelas

figuras 2 e 3 , apresentadas , a seguir.

640

Fig

2 -

Map

a co

gniti

vo c

ongr

egad

o

641

Fig

3

- Map

a co

gniti

vo c

ongr

egad

o co

m a

def

iniç

ão d

os c

lust

ers

642

Linhas de Argumentação do Mapa Cognitivo Congregado

As linhas foram identificadas através da composição dos conceitos respeitando-

se a organização do mapa devido às influências e hierarquias, e tomando como ponto de

-os até

os co

A tabela 5 mostra as linhas de argumentação detectadas na topologia do mapa

congregado.

Tabela 5 Linhas de Argumentação.

Cluster Linhas de argumentação

Sequência de conceitos

Gestão A1 C81 - C80 - C79 - C78 - C38 - C37 Gestão A2 C81 - C80 - C79 - C77 - C70 - C69 - C38 - C37 Gestão A3 C81 - C80 - C79 - C77 - C72 - C71 - C38 - C37 Gestão A4 C76 - C74 - C73 - C72 - C71 - C38 - C37 Gestão A5 C75 - C73 - C72 - C71 - C38 - C37 Treinamento A6 C63 - C62 - C58 - C77 - C70 - C69 - C38 - C37 Treinamento A7 C63 - C62 - C59 - C57 - C38 - C37 Treinamento A8 C63 - C62 - C59 - C56 - C38 - C37 Treinamento A9 C63 - C62 - C61 - C60 - C55 - C38 - C37 Treinamento A10 C63 - C62 - [C58] - C77 - C70 - C69 - C38 - C37 Treinamento A11 C63 - C62 - [C58] - C77 - C72 - C71 - C38 - C37 Ferramentas A12 C53 - C51 - C49 - C38 - C37 Ferramentas A13 C53 - C51 - C50 - C38 - C37 Ferramentas A14 C53 - C52 - C50 - C38 - C37 Ferramentas A15 C53 - [C54] - C68 - C65 - C64 - C38 - C37 Ferramentas A16 C53 - [C54] - C68 - C66 - C64 - C38 - C37 Ferramentas A17 C53 - [C54] - C68 - C67 - C64 - C38 - C37 Processos A18 C68 - C65 - C64 - C38 - C37 Processos A19 C68 - C66 - C64 - C38 - C37 Processos A20 C68 - C67 - C64 - C38 - C37

Necessidades A21 C32 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37





Necessidades A26 C31 - C27 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37




Necessidades A30 C32 - C27 - C26 - C24 - C22 - C21 - C20 - C19 -

643

C38 - C37 Necessidades A31 C23 - C22 - C21 - C20 - C19 - C38 - C37 Necessidades A32 C33 - C22 - C21 - C20 - C19 - C38 - C37

Necessidades A33 C36 - C35 - C34 - C22 - C21 - C20 - C19 - C38 - C37

Qualidade A34 C9 - C8 - C1 - C38 - C37 Qualidade A35 C10 - C8 - C1 - C38 - C37 Qualidade A36 C11 - C8 - C1 - C38 - C37 Qualidade A37 C12 - C8 - C1 - C38 - C37 Qualidade A38 C13 - C15 - C14 - C1 - C38 - C37 Qualidade A39 C16 - C15 - C14 - C1 - C38 - C37 Qualidade A40 C17 - C15 - C14 - C1 - C38 - C37 Qualidade A41 C18 - C15 - C14 - C1 - C38 - C37 Comunicação A42 C2 - C44 - C1 - C38 - C37 Comunicação A43 C3 - C44 - C1 - C38 - C37 Comunicação A44 C4 - C44 - C1 - C38 - C37 Comunicação A45 C5 - C44 - C1 - C38 - C37 Comunicação A46 C6 - C44 - C1 - C38 - C37 Comunicação A47 C7 - C44 - C1 - C38 - C37 Mudanças A48 C48 - C45 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A49 C46 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A50 C47 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A51 C42 - C40 - C39 - C38 - C37 [Cx]: Ligação a outro cluster

Ramos do Mapa Cognitivo.

Baseado nas linhas de argumentação buscamos detectar os ramos do mapa, ou

seja, o conjunto de linhas de argumentação que congregam preocupações similares no

contexto.

644

A tabela 6 mostra os ramos detectados em nossa análise.

Tabela 6 Ramos do Mapa Cognitivo Congregado.

Cluster Ramos Linhas de Argumentação que compõem o ramo

Gestão B1 A1, A2, A3

Gestão B2 A4, A5

treinamento B3 A6, A7, A8, A9, A10, A11

Ferramentas B4 A12, A13, A14, A15, A16, A17

Processos B5 A18, A19, A20

Necessidades B6 A21, A22, A23, A24, A25, A26, A27, A28, A29, A30

Necessidades B7 A31, A32

Necessidades B8 A33

Qualidade B9 A34, A35, A36, A37

Qualidade B10 A38, A39, A40, A41

Comunicação B11 A42, A43, A44, A45, A46, A47

Mudanças B12 A48, A49, A50, A52

Fig. 3 Mapa congregado exibindo clusters e Ramos.

Árvore dos Pontos de Vista Fundamentais

Para a identificação e análise dos Pontos de Vista Fundamentais (PVFs),

Como mencionamos, anteriormente, o mapa cognitivo representa uma hierarquia

de conceitos relacionados por ligações de influência entre meios e fins. Montibeller

(2000).

Os clusters são aspectos essenciais e desejáveis de serem levados em

consideração durante a avaliação de ações eixos da avaliação do problema.

Isto posto, foram identificados os candidatos aos Pontos de Vista Fundamentais

Montibeller (1996), Lima (1997) e Ensslin (1998).

645

A transição dos mapas para a elaboração da árvore de Pontos de Vista

Fundamentais foi realizada sem a presença dos decisores, conforme orientação de

Montibeller. Belton apud Montibeller (1996 ), Belton (1997).

O método adotado foi o descrito por Ensslin. Os ramos do mapa foram percorridos

em busca da identificação dos pontos de vista, no sentido meios-fins, observando-se o

grau de essenciabilidade do ponto de vista expresso pelo decisor no ramo analisado, e

no sentido fins-meios, o grau de controlabilidade dos conceitos que compõem os ramos.

Desta forma foram identificados os elementos para a composição da árvore de pontos de

vista fundamentais conforme apresentada, a seguir: Ensslin (2001).

646

Fig

4 Á

rvor

e de

Pon

tos

de v

ista

fund

amen

tais

.

647

Por último o mapa congregado e a árvore dos candidatos à pontos vista

fundamentais foi enviada aos decisores para análise conjunta com os facilitadores

sobre as ações estratégicas que poderão reduzir dificuldades no processo de

engenharia de requisitos para desenvolvimento de sistemas complexos.

Atendimento às propriedades dos Pontos de Vista Fundamentais (PVFs)

Compreensibilidade: Os pontos de vista fundamentais foram concebidos de forma

que todos os envolvidos na construção do modelo demonstraram compreensão.

Consensualidade: Os PVFs representam o consenso do grupo de decisores.

Aceitabilidade: os PVFs foram aceitos por todos que fizeram parte do processo

decisório;

Exaustividade: não existem ações pontuadas pelos decisores da mesma forma.

Coesividade: existe compatibilidade entre o papel que cada PVF em relação às

preferências dos decisores em torno dos objetivos

Não-redundância: Os PVFs prestam-se à avaliação de aspectos diferentes.

5 Resultados.

O resultado deste trabalho consistiu na elaboração de quatro mapas cognitivos

individuais, e um congregado. (Anexo1) que possibilitaram a identificação das

dificuldades enfrentadas ao longo do processo de levantamento de requisitos para

construção de sistemas complexos, neste caso, direcionados para o desenvolvimento

de produtos aeroespaciais em São José dos Campos, SP.

Os mapas revelaram oito áreas de interesse (clusters) sobre as quais convergem

a maioria das dificuldades detectadas.

A Tabela 7 mostra as ações estratégicas, reveladas pelo mapa, para análise

posterior de ações que poderão impactar as áreas de interesse .

648

Tabela 7 Áreas de impacto e ações estratégicas para cada área.

Área de Impacto Ações estratégicas.

1) Gestão 1) tomar decisão se corta ou não um requisito.

2) Manter o cronograma.

3) evitar gerar custo adicional.

2) Conhecimento 1) Investir em treinamento.

3) Ferramentas 1) escolher ferramenta que auxilie na implementação dos processos de

Engenharia de Requisitos.

2) escolher ferramenta que seja integrada a outras ferramentas da empresa.

4) Processos 1) Diminuir mudanças nos processos de Engenharia de Requisitos.

2) Aprimorar os processos de Engenharia de Requisitos.

5) Necessidades 1) Dar opções de solução ao cliente.

2) minimizar a subjetividade dos conceitos.

6) Qualidade 1) Medir as características dos requisitos.

7) Mudanças 2) Ter agilidade no desenvolvimento

8) Comunicação 3) Informar as revisões dos requisitos.

6 Conclusão

Os objetivos pretendidos deste trabalho foram alcançados de forma satisfatória,

criando oportunidade para o estabelecimento de ações que minimizem os problemas

detectados e fontes de conflitos entre fornecedores e clientes de sistemas complexos,

específicos do domínio aeronáutico.

O mapa cognitivo revelou-se uma ferramenta eficiente para a captura de

percepções individuais subjetivas já que considera o perfil de cada envolvido como

substrato de suas experiências, formação de valores, e poder de decisão no domínio

estudado.

De acordo com os desenvolvedores e clientes pesquisados neste estudo, a

atividade de validação foi considerada a mais importante, e os problemas de

comunicação foram considerados como a fonte principal de conflitos e dificuldades em

todo o processo de desenvolvimento, por vezes provocando mudanças tão

expressivas que culminam na especificação de um novo produto.

Este estudo levantou as principais dificuldades enfrentados por desenvolvedoras

de produtos aeroespaciais, considerados complexos, durante o processo de

engenharia de requisitos. Os principais resultados do estudo incluem os aspectos

descritos, a seguir:

7. Comprometimento do cronograma e atendimento aos requisitos dos

clientes.

649

8. Para os entrevistados os problemas elencados tem como fator gerador a

falta de conhecimento de todo o ciclo de desenvolvimento por parte dos

desenvolvedores, e falta de clareza das solicitações do clientes e,

principalmente, comunicação deficiente dificultando a interação

desenvolvedor-cliente.

Além de instrumento eficiente para a negociação, o processo de

desenvolvimento dos mapas cognitivos permitiram a participação de um ou mais

decisores promovendo aprendizagem a todos os envolvidos face à indução à reflexão

e a natureza recursiva que dominam todo o processo, além de estabelecer um cenário

rico para decisões racionais e confiáveis considerando que é específico para o

contexto analisado e suas particularidades..

Este cenário é relevante quando tratamos de desenvolvimento de sistemas

complexos em ambiente competitivo, heterogêneo, e com a presença de interesses

conflitantes, bem como visões diferenciadas do processo de tomada de decisão e dos

impactos propiciados pelo levantamento de requisitos de forma deficiente.

O estudo de caso do trabalho configurou-se na estruturação do ambiente para

identificação dos problemas que impactam o processo de desenvolvimento de

sistemas complexos. Construiu-se o mapa cognitivo, que demonstrou todos os

conceitos e suas ligações, que expressaram os sentimentos e as visões dos

decisores, matéria prima para a construção da árvore dos pontos de vista

fundamentais permitindo a identificação dos problemas.

6.1 Recomendações

Cabe ressaltar que os resultados apresentados correspondem a um passo inicial

para a estruturação dos problemas detectados, carecendo de continuidade, com

agregação de maior número de fornecedores e clientes, com vista à tentativa de

generalização dos pontos de gargalos no processo de levantamento de requisitos, à

luz da Engenharia de Requisitos.

Recomendamos a partir dos mapas elaborados, a estruturação de cada

problema detectado e o uso de ferramenta de decisão multicritério para a escolha das

alternativas mais adequadas para introdução de melhorias nos processos de

levantamento de requisitos e de relacionamento entre cliente e fornecedor, gerando

base para tomada de decisões ao longo do ciclo de desenvolvimento dos sistemas

complexos.

650

Agradecimentos

Agradecemos aos decisores Marina Mendonça Natalino Zenun e Francisco C.

De Amorim Terceiro e aos demais decisores que participantes desta pesquisa, e aos

colegas Tiago José Menezes Gonçalves (mestrando) e Amanda Cecília Simões da

Silva (doutoranda) pelos relatos de experiência com mapas cognitivos, e fornecimento

de literatura sobre o assunto tratado. Todas as contribuições foram essenciais para

que chegássemos ao termo deste trabalho.

7 Referências Bibliográficas.

ALVES, Carina F Uma Experiência de Engenharia de Requisitos em Empresas de Software. UFPe, Publicações CEUR . Vol 488.2007

ANSI/EIA 632, Processes for Engineering a System, Electronic Industries Alliance, 1999.

Tese de Doutorado. Universidade Técnica de Lisboa. Instituto Superior Técnico.1992

BANA e COSTA, C.A. (1995). Processo de Apoio à Decisão: Problemáticas, Actores e Acções. Apostila de Metodologias Multicritérios de Apoio à Decisão do curso de Mestrado da Engenharia de Produção e Sistemas - EPS Universidade Federal de Santa Catarina - UFSC.

BELTON, V. ; ACKERMANN, F.; SHEPHERO, I. Integrated support from problem solving through to alternative e valuation using Cope and Visa. Journal of Multi-Criteria Decision Analysis, volume 6, 1997.

BELTON, V.; MONTIBELLER, G.;ACKERMANN, F.; ENSSLIN, L. Reasoning maps for decision aid: an integrated approach for problem-structuring and multi-criteria evaluation. Journal of the Operational Research Society. Jan. 2007.

COSSETTE, P., AUDET, M. Mapping of an Idiosyncratic Schema. Journal of Management Studies. 1992. v. 29, n. 3, pp. 325-348.

CUNHA, A.C. Um modelo de avaliação para organizar e gerar aperfeiçoamento de vendas em uma empresa. Dissertação apresentada ao Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Engenharia, 1999.

EDEN C., Ackermann, F. Making Strategy. London, 1998. Sage publications Ltda.

ENSSLIN, L., MONTIBELLER NETO, G. ZANELLA, I., J., NORONHA, S., M., D. Metodologias Multicritério em Apoio à Decisão. Santa Catarina, 1998. LabMCDA. Universidade Federal de Santa Catarina.

ENSSLIN, L., MONTIBELLER NETO, I., J., NORONHA, S., M., D. Apoio à Decisão: Metodologia para estruturação de problemas e avaliação multicritérios de alternativas. Florianopolis: Insular, 2001.

IEE Norma IEEE std 1220:2005 - IEEE Standard for Application and Management of the Systems Engineering Process.

651

JARDIM, S. B. Aplicabilidade de algumas técnicas de análise multiobjetivo ao contexto decisório dos comitês de bacia hidrográfica. Porto Alegre, 1999. Dissertação (mestrado) Instituto de Pesquisas Hidráulicas/Universidade Federal do Rio Grande do Sul.

KOTONYA, Gerald; Sommerville, Ian. Requirements engineering processes and techniques. Chichester : J. Wiley, 1998

MARINHO, Simão P. P. IHCM CMAP TOOLS - Manual de uso rápido. UFMG. 1ª ed. 2008

MONTIBELLER NETO, G. Mapas Cognitivos: Uma Ferramenta de Apoio à Estruturação de Problemas - Dissertação de Mestrado, Departamento de Engenharia de Produção e Sistemas, UFSC, 1996.

MONTIBELLER, G.; BELTON, V. Qualitative operators for reasoning maps: evaluating multi-criteria options with networks of reasons. European Journal of Operational Research. V. In Press, Corrected Proof, 2007.

PRESSMAN Roger S.; Software Engineering; 5th Edition, Mac Graw Hill, 2002.

SOMMERVILLE .Software Engineering Ian Sommerville. Addison Wesley. 2007.

YOUNG, Ralph R. The Requirements Engineering Handbook; Artech House. USA, 2004.

Bibliografia complementar

Baseada numa Arquitetura dv.18, n. 1, 2008.

CHENG, L. C.; Melo Filho, L.D. R. QFD: Desdobramento da Função Qualidade na Gestão de Desenvolvimento de Produtos. Ed. Blucher, São Paulo, SP, 2007.

DECISION EXPLORER. Reference Manual. Banxia Software. Glasgow. UK. Endereço: http://www.banxia.co.uk/banxia, 2001

Rio de Janeiro: PUC-Rio, 2006.

GONZÁIn: Workshop em Engenharia de

Requisitos (WER07). Anais. Toronto, mai. 2007.

IEEE Swebok, Guide to the Software Engineering Body of Knowledge, California, 2004.

KULAK, D. and Guiney, E., Use Cases Requirements in Context, Addison -Wesley, 2000.

652

MARTINS, L.E.G. Uma metodologia de Elicitação de Requisitos de Software Baseada na Teoria da Atividade. 2001. 182f. Tese Doutorado Universidade Estadual de Campinas, Faculdade Elétrica e de Computação. Campinas, SP. 2001.

SOARES Introdução, Identificação e Análise em Engenharia de Requisitos. Antonio Lucas Soares.2005.

MAPEAMENTO COGNITIVO COMO UMA TÉCNICA PARA … · O processo de engenharia de requisitos é...

Documents

Transcript of MAPEAMENTO COGNITIVO COMO UMA TÉCNICA PARA … · O processo de engenharia de requisitos é...