utilização de metas e rastreabilidade baseada em léxico ... · desenvolvimento de software,...
TRANSCRIPT
Pontifícia Universidade Católica de Minas Gerais
Programa de Pós-Graduação em Engenharia Elétrica
Utilização de metas e rastreabilidade baseada em léxico
estendido para manipulação do conhecimento em uma pequena
empresa.
Fernando Corrêa de Mello Júnior
Belo Horizonte
2007
3
Fernando Corrêa de Mello Júnior
Utilização de metas e rastreabilidade baseada em léxico
estendido para manipulação do conhecimento em uma pequena
empresa.
Dissertação de Mestrado apresentada no Programa de Pós-
graduação em Engenharia Elétrica, da Pontifícia
Universidade Católica de Minas Gerais, como parte dos
requisitos para obtenção do título de Mestre em Engenharia
Elétrica.
Orientador: Prof. Dr. Carlos Alberto Marques Pietrobon.
Belo Horizonte
2007
4
Fernando Corrêa de Mello Júnior
Utilização de metas e rastreabilidade baseada em léxico estendido para manipulação do
conhecimento em uma pequena empresa.
Dissertação de Mestrado apresentada no Programa de Pós-graduação em Engenharia Elétrica,
da Pontifícia Universidade Católica de Minas Gerais, como parte dos requisitos para obtenção
do grau de Mestre em Engenharia Elétrica.
Belo Horizonte, 12 de março de 2007.
Prof. Dr. Carlos Alberto Marques Pietrobon (Orientador) – PUC Minas.
Prof. Dr. Arndt Von Staa – PUC Rio.
Prof. Dr. Carlos Augusto Paiva da Silva Martins – PUC Minas.
Prof. Dr. José Celso Borges de Andrade – PUC Minas.
5
A meus pais, Maria de Lourdes e Fernando, mestres antes de todos os mestres.
À minha esposa, Renata, e às minhas filhas, Júlia e Daniela, sinais e
significados de minha vida.
6
Agradecimentos
O final desta etapa de estudo não significa um fim, mas o começo de novas jornadas e
perspectivas. Portanto, consciente disso, expresso sinceros agradecimentos a muitos e tantos
adorados familiares e amigos que se revelaram ao longo desse tempo. Dessa forma, agradeço:
Ao meu orientador, Professor Dr. Carlos Alberto Marques Pietrobon, pelas
contribuições e pelo profissionalismo na condução desta pesquisa.
A Terezinha Nepomuceno, sou imensamente grato, pela gentileza e disponibilidade me
ensinando os tortuosos caminhos da língua portuguesa e pelas inúmeras leituras e correções
gramaticais deste trabalho.
A todos os pesquisadores da Pontifícia Universidade Católica de Minas Gerais por
compartilharem seus conhecimentos nos diálogos produtivos da sala de aula e pelo incentivo à
pesquisa e em especial, à colega Fabiana Costa Guedes.
Aos meus pais, pela sólida formação dada até minha juventude proporcionando-me a
continuidade dos estudos até o mestrado, meus eternos agradecimentos.
Aos meus companheiros da empresa onde trabalho, José Reinaldo, Gustavo, e Carlos,
pela cobertura, direta ou indireta, que me deram nessa longa travessia, assim como pela
confiança e compreensão.
Devo agradecer também à Renata, minha esposa, pelo incentivo e apoio na organização
técnica final deste trabalho.
Agradeço, afetuosamente, as minhas filhas, Júlia e Daniela, pelo carinho e dedicação e,
sobretudo, por compreenderem minhas ausências nas longas horas dedicadas à produção deste
trabalho.
7
RESUMO
Para garantir a qualidade do produto final, durante o processo de desenvolvimento de um
software, faz-se necessária a manipulação de diversos tipos de conhecimento. Essa manipulação
envolve desde o conhecimento obtido junto ao usuário, a partir de suas necessidades, até o
conhecimento gerado pela equipe de desenvolvimento, por meio de atividades de conversão
dos requisitos em um produto executável. A manipulação adequada desse conhecimento além
de auxiliar na produção de software de maior qualidade, agiliza o ganho de experiência do
desenvolvedor. Entretanto, a obtenção e a distribuição desse conhecimento são problemáticas
devido à falta de ferramentas de captura e recuperação e de cultura. Portanto, o objetivo deste
estudo é fornecer subsídios para facilitar a captura e a recuperação do conhecimento relativo ao
desenvolvimento de software, baseado na modelagem de metas, léxico e rastreabilidade de
requisitos. Este estudo propôs a implantação da modelagem de metas, como apoio à
transmissão do conhecimento entre o usuário e o engenheiro de software e, na modelagem de
um banco de conhecimento, a partir da rastreabilidade de requisitos baseada em léxico dos
conceitos relacionados ao desenvolvimento, com o objetivo de apoiar a equipe de responsáveis
pelo software. Desenvolveu-se uma ferramenta com o intuito de agilizar a comunicação e a
manipulação dos conhecimentos adquiridos a partir do uso de modelagem de metas e da
rastreabilidade de requisitos. Os resultados obtidos neste trabalho evidenciam que tanto a
modelagem de metas, quanto o formato da apresentação da rastreabilidade de requisitos ajudam
na comunicação entre os envolvidos durante o processo de desenvolvimento. A modelagem de
metas auxilia a manipulação do conhecimento junto ao usuário, principalmente, na fase de
elicitação e agiliza o ganho de experiência por parte do engenheiro de requisito. O formato da
rastreabilidade de requisitos baseada em léxico acelera o processo de pesquisa e se mostra
eficiente nas manipulações tanto histórica como técnica do conhecimento.
Palavras-Chave: Engenharia de Requisitos, Manipulação do Conhecimento, Modelagem de
Metas, Rastreabilidade de Requisitos, Léxico, Desenvolvimento de Software.
8
ABSTRACT
In order to assure the final product quality, it is necessary the manipulation of a wide variety of
knowledge during the software development process. This manipulation embodies, since the
user’s knowledge acquisition during the requirement elicitation process, to the knowledge
created and assembled by the development team through their activities by turning the
requirements into an executable product. An appropriate use of this knowledge does not only
promote the improvement of the software quality production but also increases the experience
gained by the software developer. However, it is difficult to acquire and distribute this
knowledge due to the lack of capturing tools, recovery tools management and culture as well.
Therefore, this study aims to supply subsidies to facilitate the capture and the recovery of the
knowledge related to the software development process, based on the goal-oriented models,
lexical and requirements traceability. This study has proposed an implementation of a goal-
oriented model to give support on transferring the knowledge from the user to the software
engineer. It also, has carried out in the modeling of a knowledge data from requirements
traceability based on the lexical model in order to help the development team. It was developed
a tool with the purpose of improving both the communication and the knowledge manipulation
which were acquired through the goals-oriented models and requirements traceability. The
results of this work indicated that not only the goal-oriented model but also the presentation
format of the requirements traceability can help the communication among all the people
involved in the software development process. The goals-oriented model supports the
manipulation of the user's knowledge, especially in the elicitation phase, and it improves the
process of obtaining more of the experience acquired by the software requirement engineer.
The requirements traceability format based on the lexical model accelerates the research
process and it has shown effectiveness in the historical and technical knowledge manipulation.
Key-words: Requirements Engineering, Knowledge Manipulation, Goal-oriented Models,
Requirements Traceability, Lexical, Software Development.
9
LISTA DE FIGURAS
Figura 1 – Modelo de Domínio baseado na Ferramenta C&L (2006) ........................................27
Figura 2 –Meta-Modelo Rastreabilidade Toranzo. .....................................................................29
Figura 3 – Modelo de domínio desenvolvido baseado em Borges e Falbo, (2001)....................31
Figura 4 – Estrutura da Memória Organizacional de ODE.........................................................32
Figura 5 – Hierarquia do Conhecimento .....................................................................................36
Figura 6 – Tipos de Rastreabilidade de Requisitos .....................................................................48
Figura 7 – Modelo de Domínio baseado em Kruchten (2003) e Pádua (2003) ..........................51
Figura 8 – PMI – Gerência de Projetos baseado em Martins (2005) ..........................................53
Figura 9 - PMI – Elementos da Gerência de Projetos baseado em Martins (2005) ....................54
Figura 10 - PMI – Diagrama de Atividades das Fases................................................................56
Figura 11 - Modelo de Visualização Projeto Discovery .............................................................58
Figura 12 – Diagrama de domínio para aquisição do conhecimento no desenvolvimento de um
software .......................................................................................................................................60
Figura 13 – Diagrama de domínio para aquisição do conhecimento no desenvolvimento de um
software utilizando Modelagem de Metas ..................................................................................61
Figura 14 – Diagrama de atividade da modelagem de metas na fase de concepção...................65
Figura 15 – Caso de uso referente a proposta de manipulação do conhecimento.......................69
Figura 16 – Modelo de Domínio da Modelagem de Metas da Ferramenta DBML....................75
Figura 17 – Ferramenta de Modelagem de Metas.......................................................................76
Figura 18 – Parte do Modelo de Metas do Software Controle de Licenciados...........................77
Figura 19 – Modelo de Metas Referente a alteração do módulo de Estatística ..........................80
Figura 20 – Diagrama de domínio referente aos macros relacionamentos existentes no
desenvolvimento de um software................................................................................................81
Figura 21 – Caso de uso da rastreabilidade baseada em léxico ..................................................84
Figura 22 – Rastreabilidade baseada no Léxico Estendido.........................................................85
Figura 23 – Apresentação da Composição da Rastreabilidade ...................................................91
Figura 24 – Formatação da rastreabilidade na voz ativa e voz passiva.......................................93
Figura 25 – Análise de Impacto na Voz Ativa ............................................................................94
Figura 26 – Análise de Impacto na Voz Passiva.........................................................................94
Figura 27 - Apresentação do Tempo e da Visão .........................................................................96
Figura 28 – Análise de formação do léxico...............................................................................101
10
Figura 29 – Modelo de Domínio da Rastreabilidade baseado no léxico...................................104
Figura 30 – Principais pacotes da Ferramenta da Rastreabilidade............................................105
Figura 31 – Interface da análise de rastreabilidade para a manipulação do conhecimento ......107
Figura 32 – Tela de formatação do texto da análise..................................................................111
11
Lista de Tabelas
Tabela 1 – Definição de pequena empresa .................................................................................33
12
Lista de Quadros
Quadro 1 – Relacionamento entre as fases do projeto e do ciclo de vida do processo ...............57
Quadro 2 – Resumo dos resultados da modelagem de metas ...................................................113
Quadro 3 – Resumo dos resulados da rastreabilidade de requisitos baseado em léxico...........122
13
LISTA DE SIGLAS
CMMI - Capability Maturity Model Integration
ER – Engenharia de Requisitos
GRE – Gerência de Requisitos
GRE_RL – Gestão de Requisitos Baseado em Rastreabilidade e Léxico
IBGE – Instituto Brasileiro de Geografia e Estatística
LAL - Léxico Ampliado da Linguagem
LEL - Linguagem Estendida do Léxico
LN – Linguagem Natural
MCT – Ministério da Ciência e Tecnologia
MPS/BR – Melhoria de Processo de Software Brasileiro
ODE - Ontology-based software Development Environment
PHP - Hypertext Preprocessor
PLN - Processamento da Linguagem Natural
PMBOK - Project Management Body of Knowledge
PMI - Project Management Institute
PU – Processo Unificado
RUP – Rational Unified Process - Processo Unificado Rational
SEBRAE - Serviço Brasileiro de Apoio às Micro e Pequenas Empresas
SGBD – Sistema de Gerenciamento de Banco de Dados
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro
SWEBOK - Software Engineering Body of Knowledge
TRE - Treinamento
UML – Unified Modeling Language (Linguagem Unificada de Modelagem)
XML - Extensible Markup Language
14
SUMÁRIO
1 INTRODUÇÃO .................................................................................................... 17
1.1 Problema ............................................................................................................ 18
1.2 Objetivos ............................................................................................................ 20
1.2.1 Objetivos Específicos ...................................................................................... 21
1.3 Motivação........................................................................................................... 21
1.4 Escopo ................................................................................................................ 22
1.5 Metodologia ....................................................................................................... 22
1.6 Contribuições Esperadas .................................................................................... 24
1.7 Trabalhos correlatos ........................................................................................... 25
1.7.1 Modelagem Orientada a Metas....................................................................... 25
1.7.2 Cenários .......................................................................................................... 26
1.7.3 Rastreabilidade ............................................................................................... 28
1.7.4 Estação TABA ................................................................................................. 30
1.7.5 Gerência de Conhecimento sobre Processos de Software .............................. 30
1.7.6 Infra-estrutura para Gerência de Conhecimento em ODE............................. 31
2 REFERENCIAL TEÓRICO ................................................................................. 33
2.1 Pequena Empresa ............................................................................................... 33
2.2 Conhecimento..................................................................................................... 35
2.3 Léxico................................................................................................................. 38
2.4 Metas .................................................................................................................. 41
2.4.1 Identificação de Metas .................................................................................... 41
2.5 Engenharia de Requisitos ................................................................................... 44
2.6 Rastreabilidade ................................................................................................... 46
2.7 Processo desenvolvimento de Software ............................................................. 49
2.7.1 Rational Unified Process - RUP ..................................................................... 50
2.7.2 Gerência de Projetos....................................................................................... 52
2.8 Projeto Discovery............................................................................................... 57
3 PROCESSO DE DESENVOLVIMENTO COM MODELAGEM DE METAS.. 59
3.1 Processo de Desenvolvimento baseado em Metas ............................................. 62
15
3.1.1 Fase Concepção .............................................................................................. 62
3.1.2 Fase Elaboração ............................................................................................. 65
3.1.3 Fase Construção ............................................................................................. 66
3.1.4 Fase Transição ................................................................................................ 67
3.2 Verificação e Validação ..................................................................................... 67
4 MODELO PROPOSTO ........................................................................................ 68
5 IMPLANTAÇÃO DA MODELAGEM DE METAS ........................................... 71
5.1 Passos para a Implantação.................................................................................. 71
5.1.1 Treinamento dos integrantes da equipe .......................................................... 71
5.1.2 Seleção de um projeto em andamento............................................................. 72
5.1.3 Modelagem de metas ....................................................................................... 72
5.1.4 Verificação com o usuário .............................................................................. 73
5.1.5 Implantação de modelagem de metas em novos projetos ............................... 73
5.2 Ferramenta DBML ............................................................................................. 73
5.3 Estudo de Caso ................................................................................................... 77
6 RASTREABILIDADE BASEADA EM LÉXICO ............................................... 81
6.1 Formatação Básica da Rastreabilidade baseada em Léxico ............................... 84
6.2 Apresentação da Rastreabilidade ....................................................................... 88
6.2.1 Composição ..................................................................................................... 90
6.2.2 Formatação ..................................................................................................... 92
6.2.3 Impacto............................................................................................................ 93
6.2.4 Tempo .............................................................................................................. 95
6.2.5 Visão................................................................................................................ 96
6.3 – Processo de Formação da Rastreabilidade ...................................................... 97
6.4 IMPLEMENTAÇÃO DA SOLUÇÃO ............................................................ 102
6.4.1 Banco de Conhecimento................................................................................ 102
6.4.2 A Ferramenta Gestão de Requisitos Baseada em Rastreabilidade e Léxico 104
6.4.2.1 Análise da Rastreabilidade ......................................................................... 105
6.4.2.2 Análise da História ..................................................................................... 107
16
7 ANÁLISE DE RESULTADOS .......................................................................... 112
7.1 Análise de Resultados da Modelagem de Metas.............................................. 112
7.2 Análise dos resultados da Rastreabilidade baseada em Léxico........................ 121
8 CONCLUSÃO E TRABALHOS FUTUROS..................................................... 128
8.1 Conclusão ......................................................................................................... 128
8.2 Trabalhos Futuros............................................................................................. 130
REFERÊNCIAS..................................................................................................... 131
APÊNDICE A - XML do modelo de meta do estudo de caso 1 ............................ 137
APÊNDICE B - XML do modelo de meta do estudo de caso 2 ............................ 142
APÊNDICE C – Formação do banco de conhecimento......................................... 146
17
1 INTRODUÇÃO
O processo de desenvolvimento de software normalmente é executado por grupos de
pessoas, os quais adotam metodologias de desenvolvimento, com o intuito de criar softwares
capazes de atingir as necessidades dos clientes/usuários. Entre os diversos fatores relacionados
à obtenção de um processo e de um produto de qualidade está a manipulação do conhecimento.
Segundo Natali e Falbo (2003), a manipulação do conhecimento é um importante recurso para
as organizações promoverem o aprendizado para os desenvolvedores. O conhecimento
adquirido e armazenado é reusado para melhorar as atividades e as decisões necessárias para a
execução de um projeto.
Entretanto, quando são consideradas pequenas empresas, tem-se diversas dificuldades e
riscos no seu ambiente e no processo produtivo, que estão diretamente relacionados ao
conhecimento. Por exemplo:
a) Pouca disponibilidade de tempo para se efetuarem os levantamentos e os estudos
preliminares, durante a fase de concepção. Esse tempo deve ser suficiente para dar apoio às
atividades de: previsão de custo, tempo de desenvolvimento do software e elaboração da
proposta (KRUCHTEN, 2003);
b) Inexistência de uma base histórica de conhecimento que possa apoiar o
desenvolvimento das atividades citadas anteriormente (PRESSMAN, 2002);
c) Determinação do escopo real do projeto. Essa determinação se torna uma
dificuldade, uma vez que, geralmente, existe uma falta de entendimento entre o engenheiro de
requisito e o usuário no repasse das informações necessárias para o desenvolvimento do
software. Isto é, o engenheiro tem dificuldade em entender as reais necessidades do usuário,
assim como, o usuário não sabe repassar exatamente as informações absolutamente necessárias
(LAMSWEERDE, 2001). Além desse problema de comunicação e entendimento entre os
envolvidos existem também as variações das necessidades particulares dos clientes. Essas
variações se encontram na forma de conduzir os negócios do cliente e os objetivos a serem
atingidos pelo produto. Tudo isso torna o trabalho mais complexo e exige uma maior
flexibilidade e parametrização do produto;
d) Diversidade relacionada tanto à natureza quanto às categorias dos produtos de
software a serem desenvolvidos. Essa diversidade muitas vezes inviabiliza a contratação do
desenvolvimento do produto, devido à falta ou dificuldade de se obter o conhecimento
necessário para elaboração do produto;
18
e) Problemas de integração das diversas ferramentas livres de apoio ao
desenvolvimento. Nesse caso, os custos de aquisição de ferramentas integradas podem estar
fora da realidade financeira da empresa. Como conseqüência, pode haver a diminuição da
produtividade na geração dos artefatos, os quais são obtidos nas atividades durante o
desenvolvimento de software;
f) Desequilíbrio entre os custos de produção e a remuneração obtida pelo
desenvolvimento do produto. Esse desequilíbrio está relacionado com custos reais, necessários
à produção do software, e o valor que o mercado está disposto a pagar pelo produto;
g) Falta de recursos próprios da empresa para investir, a longo prazo, na criação de
uma base de conhecimento capaz de ajudar em todas as atividades de produção de softwares.
Essa base de conhecimento apoiaria a reutilização dos artefatos e conhecimentos dos projetos já
desenvolvidos, ou em desenvolvimento aumentando, com isso, a produtividade da equipe
envolvida no projeto. E ainda, ajudaria a equipe de desenvolvimento na troca de informações
sobre o projeto de uma forma rápida e segura, de forma que, se poderia obter a melhoria do
entendimento real das necessidades do usuário em relação do produto.
Colocada essa realidade, são considerados relevantes os estudos que visem minimizar o
impacto desses fatores no processo produtivo de um software, particularmente, os que têm a
manipulação do conhecimento como foco.
Nesse trabalho, estuda-se a manipulação do conhecimento no apoio do desenvolvimento
de software, em uma pequena empresa, utilizando a modelagem de metas e a rastreabilidade de
requisitos baseado em léxico1.
1.1 Problema
Durante o desenvolvimento de software é necessário ter e manipular o conhecimento.
Na literatura existem várias pesquisas que tratam do processo de desenvolvimento
(PRESSMAN, 2002), da gestão de software (MARTINS, 2005) e do gerenciamento do
conhecimento (NATALI E FALBO, 2003). Duas situações devem ser pensadas: a transmissão
do conhecimento entre o desenvolvedor e o usuário e a geração do conhecimento entre os
desenvolvedores. Assim, considera-se um problema o como se obter do usuário o conhecimento 1 Léxico: Conjunto de vocábulos de um idioma, dicionário dos vocábulos usados por um autor (FERREIRA, 1999).
19
necessário ao desenvolvimento e, ainda, como apoiar a equipe de desenvolvimento de modo
que esta possa transmitir e utilizar todo o conhecimento gerado durante a produção do software.
Para a determinação das reais necessidades do usuário a serem desenvolvidas, existem
os seguintes entraves: dificuldade de transmissão do conhecimento necessário entre os
envolvidos e a mutabilidade dos requisitos. Caso esses problemas não sejam minimizados, as
empresas correm os riscos de produzir um software fora do escopo, fora do custo e do tempo
planejado e, consequentemente, com baixa qualidade.
O perfil do desenvolvedor tem uma grande influência na atividade de levantamento de
requisitos. O desenvolvedor deve ser capaz de afastar-se do mundo técnico, representado pelas
técnicas e ferramentas de desenvolvimento, e se voltar para o mundo do negócio do cliente.
Deve ter a capacidade de entender e modelar o desejo do cliente através dos objetivos a serem
atingidos com o produto. Esse entendimento deverá ser suficiente para balizar todas as
atividades do desenvolvimento do software. A partir do momento em que o desenvolvedor sabe
efetivamente o que o usuário necessita, ele tem condições de minimizar o risco da atividade de
levantamento e obter um produto final mais adequado às necessidades desse usuário.
Os usuários e os engenheiros de software são responsáveis por determinar o que o
software deverá fazer, definindo os requisitos e o escopo do desenvolvimento. Para o usuário, o
software é um meio para atingir seus objetivos, principalmente, os de negócios. O
desenvolvedor tem a visão técnica do desenvolvimento de softwares, porém, muitas vezes, não
tem a compreensão necessária daquilo que precisa ser desenvolvido, ou seja, a real necessidade
do usuário do ponto de vista tanto funcional quanto da qualidade do produto. A diferença entre
esses dois pontos de vista opostos dificulta e/ou inviabiliza o desenvolvimento do software.
Uma das formas de minimizar esses riscos seria recorrer, sempre, a um especialista no
domínio do produto, para ajudar a “traduzir”, isto é, explicitar claramente a necessidade do
usuário em uma linguagem capaz de ser entendida pelos desenvolvedores. Grandes empresas,
muitas vezes, investem nesse profissional, normalmente, denominado analista de negócio ou
analista de domínio, o qual atua entre o usuário e o desenvolvedor. Mas, essa realidade,
normalmente, não se aplica às pequenas empresas, devido, principalmente, ao custo e à
dificuldade de se encontrar e alocar esse profissional.
A geração do conhecimento entre os desenvolvedores está ligada às demais atividades
técnicas e de gestão do desenvolvimento do software. É normal encontrar-se a equipe de
desenvolvimento de uma empresa atuando em mais de um projeto ao mesmo tempo e, ainda, a
existência de uma rotatividade entre os integrantes da equipe. Para se obter sucesso no
desenvolvimento, faz-se necessária a transmissão rápida e eficaz do conhecimento, relativo às
20
decisões técnicas e de gestão, entre os integrantes da equipe. Assim, a falta de informações
sobre as soluções adotadas poderá transformar o desenvolvimento em um empreendimento sem
os devidos retornos esperados, podendo aumentar ou gerar um conflito entre os envolvidos no
processo.
Segundo Togneri et al. (2004), os problemas relativos à transmissão do conhecimento
entre os integrantes da equipe de desenvolvimento podem resultar em uma série de
dificuldades, tais como: perda do conhecimento sobre a aplicação em desenvolvimento,
podendo ficar restrita à pessoa e não à empresa; escassez de conhecimento sobre o domínio da
aplicação, o que dificulta a especificação dos requisitos; dificuldade em localizar as
informações sobre as soluções adotadas no desenvolvimento e dificuldade na reutilização do
conhecimento entre projetos semelhantes.
Neste trabalho, pretende-se focalizar os aspectos relacionados à necessidade de se obter,
reter, armazenar e distribuir o conhecimento gerado pela equipe de desenvolvimento de
software.
1.2 Objetivos
Diante desses pressupostos, o objetivo geral dessa dissertação é utilizar a modelagem de
metas e a rastreabilidade de requisitos baseado em léxico na manipulação do conhecimento
necessário para o desenvolvimento de software com qualidade e que seja adequado à pequena
empresa. Essa manipulação deverá permitir o armazenamento e a transmissão entre os
envolvidos no processo de desenvolvimento, tanto na fase externa, que envolve a captura do
requisito junto ao usuário, quanto na fase interna, que envolve as atividades de
desenvolvimento e as atividades de gestão.
21
1.2.1 Objetivos Específicos
a) Desenvolver uma ferramenta que possibilite manipular o conhecimento necessário,
entre as partes envolvidas, para o desenvolvimento de software, com a utilização da
modelagem de metas e a com a rastreabilidade dos requisitos baseado em léxico;
b) Criar um modelo de banco de dados de conhecimento, a fim de que se possa registrar
e relacionar os léxicos existentes em todo o desenvolvimento de um produto de
software;
c) Fazer a rastreabilidade dos artefatos e atividades feitas no desenvolvimento do
produto a partir da base de conhecimento modelada para a ferramenta;
d) Verificar se os conhecimentos armazenados e recuperados ajudarão na melhoria da
qualidade do trabalho da equipe de desenvolvimento e do produto de software gerado.
1.3 Motivação
A grande motivação deste trabalho partiu de uma situação problema, vivenciada por
diversas pequenas empresas de desenvolvimento e manutenção de software. Estas empresas
possuem recursos financeiros e humanos limitados, que inviabilizam e desencorajam o
desenvolvimento de alguns projetos. Essa inviabilização parte, principalmente, em relação à
contratação de mão de obra especializada (especialistas no domínio), que detêm o
conhecimento sobre o domínio do projeto a ser desenvolvido, o que minimizaria os problemas
relacionados à atividade de elicitação. Além disso, enfrenta-se dificuldades de criar uma maior
independência de informações ou conhecimento entre os membros da equipe. Assim, percebe-
se a necessidade de estudar mecanismos simples e baratos que pudessem ajudar as pequenas
empresas a resolver os problemas de conhecimento na produção de softwares, que seriam
gerados com maior qualidade, a um custo compatível com a realidade das mesmas.
22
1.4 Escopo
O escopo dessa dissertação, referente à manipulação do conhecimento, será baseado no
processo de desenvolvimento e de gestão de projetos de uma pequena empresa de
desenvolvimento de software.
1.5 Metodologia
O trabalho aqui descrito pode ser caracterizado como sendo uma pesquisa aplicada, pois
envolve o estudo de problemas relativos à manipulação de conhecimento em uma empresa de
desenvolvimento de software. A pesquisa descrita nesse trabalho pode ser considerada como
qualitativa, uma vez que, os resultados obtidos foram analisados de modo a explicar a
manipulação do conhecimento em uma pequena empresa de desenvolvimento de software.
Inicialmente, efetuou-se um levantamento bibliográfico dentro do contexto dos
problemas relativos à transmissão do conhecimento para o desenvolvimento de um software.
Esses problemas se relacionam tanto com a engenharia de requisitos, como com a distribuição
do conhecimento entre os integrantes da equipe de desenvolvimento da empresa. Durante o
levantamento restringi-se o estudo, focalizando os temas modelagem de metas e rastreabilidade
de requisitos baseado em léxico.
A partir desse estudo, fez-se uma avaliação de uma pequena empresa, com o objetivo de
identificar a ocorrência dos principais problemas relacionados à engenharia de requisitos e à
distribuição do conhecimento. Na engenharia de requisitos foram percebidos os seguintes
entraves: dificuldades em compreender as reais necessidades dos usuários e dificuldades em
documentar essas necessidades.
Na distribuição do conhecimento entre os integrantes da equipe de desenvolvimento, foi
identificada uma grande dependência técnica em relação a um determinado membro da equipe
do projeto. Esta dependência dificultava tanto a implementação de novas funcionalidades,
quanto a resolução de problemas dos produtos em fase de manutenção. Nas empresas de maior
porte esse problema é minimizado, devido ao fato do conhecimento estar distribuído entre um
maior número de pessoas e entre os setores da própria empresa.
23
O passo seguinte foi dividir a pesquisa em duas partes. A primeira parte abrangeu o
estudo e a criação de uma ferramenta para ajudar na documentação dos requisitos dos usuários,
e a segunda parte, a formação de uma base de conhecimento que possibilitasse o
compartilhamento do conhecimento gerado na produção do software entre os integrantes da
equipe. Acredita-se que a união destas duas partes gera o conhecimento necessário para o
desenvolvimento de software com qualidade.
Para a criação da ferramenta de modelagem e documentação dos requisitos, o trabalho
baseou-se na modelagem de metas descrita por Lamsweerde (2001), mas focalizando apenas os
conceitos de captura da necessidade do usuário e o registro através da modelagem gráfica. A
seguir, foi alterado o processo de desenvolvimento da empresa para utilizar a modelagem de
metas nas atividades de engenharia de requisitos de modo que, cada meta modelada
“trafegasse” no processo de desenvolvimento vinculando-se em todos os artefatos durante a
execução das atividades.
Após os estudos e a alteração do processo, implementou-se a modelagem de metas. Esta
modelagem foi implementada, inicialmente, de forma manual, pelos engenheiros de software.
Os engenheiros utilizaram a modelagem de metas tanto nos levantamentos de requisitos,
juntamente com os usuários, quanto nas reuniões de verificação dos requisitos, com a equipe de
desenvolvimento. O passo seguinte foi o desenvolvimento da ferramenta de modelagem. Os
modelos de metas passaram a ser construídos utilizando essa ferramenta desenvolvida. A
seguir, implantou-se o desenvolvimento colaborativo, em que o usuário não podendo ficar
dentro das dependências da empresa, faria o início da modelagem de metas e transmitiria o
modelo para a equipe de desenvolvimento efetuar o refinamento do mesmo. Durante todo o
processo de implementação da modelagem de metas foram levantados os problemas e as
vantagens da sua utilização.
A segunda parte da pesquisa consistiu em estudar mecanismos de registro e recuperação
do conhecimento, gerado pela equipe de desenvolvimento durante as suas atividades de
construção do software. A partir destes estudos, o banco de conhecimento foi modelado
baseando-se em três trabalhos: cenários (LEITE ET AL, 1997), ontologia baseada na
Linguagem Estendida do Léxico (LEL) (FELICÍSSIMO ET AL, 2003), e rastreabilidade
(TORANZO, CASTRO e MELLO, 2002).
Após a modelagem do banco de conhecimento, desenvolveu-se uma ferramenta para
armazenar e recuperar o conhecimento produzido pelos engenheiros de software. O primeiro
módulo da ferramenta consistiu em verificar a utilização de cenário, com base no léxico e na
interpretação da narrativa do requisito, efetuada pelo usuário (LEITE ET AL, 1997), LEL
24
(FELICÍSSIMO ET AL, 2003). A partir da interpretação, ou seja, da identificação dos léxicos
existentes na narrativa, foi desenvolvida a rastreabilidade destes léxicos para a formação e
geração do conhecimento (TORANZO, CASTRO e MELLO, 2002).
O passo seguinte foi um estudo de identificação dos léxicos e seus relacionamentos nos
modelos de processo de desenvolvimento e gestão de projetos, baseado, respectivamente, no
Rational Process Unified (RUP) e na metodologia Process Management Institute (PMI). Uma
vez identificados os léxicos, os seus relacionamentos foram mapeados e implementados no
banco de conhecimento.
Por fim, fez-se uma análise da eficiência deste mapeamento, na geração e transmissão
do conhecimento pela equipe de desenvolvimento do software. Após esse trabalho de análise da
eficiência, foram importadas para o banco de conhecimento as informações históricas dos
projetos já realizados, de acordo com o léxico e os relacionamentos definidos. As informações
importadas eram relativas à gestão de projetos. A seguir, iniciou-se o trabalho para validar a
usabilidade das interfaces utilizadas para recuperar o conhecimento e para detectar novas
necessidades de melhoria.
1.6 Contribuições Esperadas
Esta dissertação pretende fornecer as seguintes contribuições:
a) Adequar e validar o modelo de metas a ser usado por pequenas empresas de
desenvolvimento de software, com o objetivo de apoiar na elaboração do escopo, na
transmissão das informações e no entendimento necessário ao desenvolvimento de software,
entre os usuários e os engenheiros de softwares;
b) Apresentar um modelo de base de conhecimento o que permitirá aos stakeholders
trabalharem de modo integrado, com uma única forma de apresentação e navegação, com todas
as visões relativas ao desenvolvimento: processo, gestão e técnica. E ainda, permitir a
rastreabilidade entre estas visões;
c) Apoiar a transmissão do conhecimento, ou seja, melhorar a comunicação necessária
entre o usuário e a equipe de desenvolvedores e dentro da própria equipe. Esta melhoria na
comunicação irá diminuir a dependência do conhecimento individual das pessoas envolvidas no
processo de desenvolvimento;
25
d) Apresentar um modelo que possa atingir os objetivos de rastreabilidade
normalmente exigidos pelos modelos de maturidade;
e) Ajudar o desenvolvedor na interpretação da narrativa do usuário sobre suas
necessidades. Considera-se narrativa a história que o usuário conta para o desenvolvedor e que
diz respeito às suas necessidades, ou seja, seus requisitos. Esta história geralmente está
relacionada à experiência passada do usuário em relação ao seu próprio negócio e objetivos a
serem atingidos. A forma como é feita a narrativa pode influenciar na apreensão dos
significados por parte do desenvolvedor.
1.7 Trabalhos correlatos
O registro dos requisitos de software ajuda a transformar as necessidades do usuário em
uma documentação capaz de apoiar a criação do conhecimento necessário ao desenvolvimento
do software. Consideram-se trabalhos correlatos os que enfocam a aquisição das necessidades
do usuário como ponto forte na qualidade do produto final. Dentre eles, destacam-se os
seguintes:
1.7.1 Modelagem Orientada a Metas
Dardenne, Fickas e Lamsweerde, (1991) e Lamsweerde (2001) baseiam seus estudos na
modelagem de metas para a aquisição e gerenciamento dos requisitos. Nessa modelagem, os
requisitos a serem desenvolvidos fornecem o suporte às metas e através das metas trabalha-se o
escopo do produto. Nessas propostas, a modelagem das metas e requisitos é construída de duas
formas: uma através de um grafo e outra através de um modelo formal. No grafo, são indicadas
as condições em que cada sub-meta e requisito fornecem o suporte à meta hierarquicamente
superior.
O software de modelagem de metas Objectiver 1.5.1. baseia-se nos conceitos de
Lamsweerde (2001). Trata-se de uma ferramenta para modelar metas e requisitos do software e
que pode ser adquirida e utilizada pelas empresas. No software, verifica-se que existe uma
26
integração do registro das metas, do registro dos requisitos e do modelo de classe de objetos. A
integração desses três elementos gera a rastreabilidade entre os modelos e apresenta o
conhecimento dos problemas a serem resolvidos e da solução adotada pelo engenheiro de
software (OBJECTIVER, 2006). Para o este projeto não se considerou o uso dessa ferramenta,
pelos seguintes motivos:
• Esse software não implementa todos os modelos complementares utilizados pelo
desenvolvedor previstos na UML (Unified Modeling Language). Os demais modelos
UML são importantes para o registro do conhecimento das soluções adotadas no
desenvolvimento;
• A ferramenta não se integra com as demais ferramentas de modelagem UML,
normalmente, utilizadas pela equipe de desenvolvimento, o que gera um custo adicional.
Portanto, o Objectiver (2006) seria mais uma ferramenta de modelagem para o
desenvolvedor exigindo um investimento a mais para a produção do software;
• O registro das metas e requisitos deve ser uma tarefa de mão dupla, ou seja, usuário e
desenvolvedor integrados, para se evitar um custo adicional na aquisição dessa
ferramenta e treinamento de utilização da mesma para o usuário.
A proposta da ferramenta, desse trabalho, é uma simplificação em relação ao Objectiver
(2006). Deseja-se apenas gerar o modelo de metas/requisitos, dentro de um processo
colaborativo de desenvolvimento e que seja integrado com a base de conhecimento que estamos
propondo.
1.7.2 Cenários
Leite e Franco, (1993), Leite et al. (1997), e Silva, Leite e Breitman, (2005) descrevem
um processo para capturar e registrar as necessidades do usuário. Esse processo visa adquirir o
conhecimento baseado em cenários e Léxico Ampliado da Linguagem (LAL). Apresentam,
ainda, uma ferramenta para a edição colaborativa de cenários e léxicos, com o controle de
criação e atualização dos mesmos. Essa ferramenta apóia o processo de desenvolvimento de
software guiado por requisitos, tanto na documentação, quanto na transmissão do conhecimento
relativo ao vocabulário do sistema a ser construído. A figura 1 apresenta o modelo de domínio
obtido a partir do banco de dados disponibilizado da ferramenta C&L (C&L, 2006).
27
Figura 1 – Modelo de Domínio baseado na Ferramenta C&L (2006)
Pode-se verificar que o conhecimento é transmitido nos seguintes itens: cenário, léxico
e conceito.
• Na descrição do cenário são registrados todos os léxicos existentes na narrativa. Esse
registro facilita, para o engenheiro de software, o entendimento do requisito a partir dos
conceitos previamente cadastrados na ferramenta C&L;
• O léxico, dicionário do projeto, contém as informações importantes para o entendimento
do sistema, tais como: o vocábulo, os conceitos e os impactos existentes no projeto. O
entendimento dos impactos e do cenário a ser desenvolvido será facilitado pela
identificação dos léxicos, previamente cadastrados;
• O projeto pode ter vários cenários que caracterizam os requisitos a serem
desenvolvidos. Isso ajuda na documentação e transmissão do conhecimento entre os
envolvidos no projeto.
A ferramenta permite cadastrar os conceitos estruturados a partir de uma hierarquia dos
mesmos. As informações geradas ficam estáticas dentro do cenário, ou seja, os léxicos são
identificados e são apresentados os seus conceitos. Na proposta, dessa dissertação, as
informações são trabalhadas de forma estática e dinâmica. A análise estática consiste na
apresentação do conceito e na identificação de todos os léxicos utilizados na narrativa do
usuário. A análise dinâmica apresenta todo o conhecimento já existente e rastreável de cada
léxico. São considerados importantes esses dois tipos de análise na transmissão do
conhecimento entre os envolvidos na identificação das soluções adotadas anteriormente. A
28
união destas duas análises representa o conhecimento já elaborado para o projeto em
desenvolvimento ou já desenvolvido. Esse conhecimento é a base para o engenheiro de
software tomar as decisões necessárias para o projeto.
Nitsche e Bortoli (2006), desenvolveram uma ferramenta para auxiliar a comunicação
entre engenheiros de requisito e cliente, na etapa de definição dos requisitos. A ferramenta é
baseada nos conceitos do LAL de acordo com o apresentado em Leite e Franco (1993). Similar
a C&L (2006), a ferramenta consiste na dicionarização dos léxicos utilizados pelo domínio do
software a ser construído. A dicionarização é obtida a partir da definição dos símbolos e dos
contextos utilizados pelo léxico. Nesse dicionário é identificado o conceito, ou seja, as noções e
o impacto que podem ser representados como uma rastreabilidade do léxico a partir da
identificação da ligação com outros léxicos.
1.7.3 Rastreabilidade
Toranzo, Castro e Mello (2002) propõem um meta-modelo, para efetuar a
rastreabilidade dos elementos que compõem o desenvolvimento de um sistema. A figura 2
apresenta o meta-modelo, que utiliza como base a classe elemento. A classe elemento
representa qualquer nível de abstração das necessidades de rastreabilidade do sistema. Através
de suas subclasses ElementoGeneralizável e Relacionamento é possível fazer a rastreabilidade,
a qual é feita a partir do relacionamento entre os elementos, de modo a identificar as hierarquias
existentes entre eles. Para cada elemento rastreável é possível identificar os seguintes itens:
• Satisfação: indica as dependências de satisfação existentes entre os elementos. Por
exemplo: um conjunto de requisitos satisfaz uma meta. A meta somente será atingida se
esse conjunto de requisitos for contemplado;
• Recurso: indica as dependências de recursos existentes entre os elementos. Por
exemplo: um método é um recurso de uma determina classe;
• Responsabilidade: indica a participação de pessoas que atuam em um determinado
elemento. Por exemplo: um determinado desenvolvedor define um conjunto de
requisitos;
29
• Representação: indica a forma como é feita a representação de um determinado
elemento. Por exemplo: o diagrama de metas representa as metas e os requisitos que a
satisfazem;
• Alocação: indica o tipo de associação existente entre os elementos na hierarquia. Por
exemplo: os pacotes, ou seja, subsistemas que compõem um determinado sistema;
• Agregação: indica o tipo de associação de composição entre os elementos. Por exemplo:
uma história é composta por um conjunto de classes e métodos.
Figura 2 –Meta-Modelo Rastreabilidade Toranzo.
Fonte: Toranzo, Castro e Mello (2002)
A diferença da proposta, dessa dissertação, em relação a Toranzo, Castro e Mello (2002)
é que esses autores propõem um meta-modelo de rastreabilidade, mas não apresenta o como
utilizar a rastreabilidade. Não fica claro como é feita a apresentação dos resultados de
rastreabilidade a partir da base de conhecimento. Considera-se a apresentação um importante
fator na transmissão do conhecimento. A apresentação da rastreabilidade, dessa dissertação, é
uma estrutura baseada em linguagem natural, que possui formato baseado em sujeito, verbo,
objeto e estado. Acredita-se que a formação de sujeito, verbo e objeto facilitará a compreensão
do conhecimento por parte da equipe de desenvolvimento, por se tratar de uma apresentação
mais natural, mais próxima da linguagem escrita. A identificação do estado completa as
informações sobre um determinado relacionamento, ajudando no entendimento da solução
adotada. Pode-se citar, por exemplo, que se uma atividade for executada por um determinado
30
usuário, em uma determinada data e em um determinado tempo, poderá ser representada da
seguinte forma:
• Sujeito: nome do usuário
• Verbo: executou
• Objeto: a atividade de elicitação.
• Estado: na data de 12/09/2006.
A formatação dessas informações, de acordo com o citado acima, é importante para a
“experiência” gerada no conhecimento.
1.7.4 Estação TABA
O projeto TABA (MONTONI ET AL, 2006) visa apresentar uma forma de trabalhar os
processos de desenvolvimento com base na gerência de conhecimento, para garantir a produção
de produtos de alta qualidade e melhorar os processos de software. O formato para a obtenção
do conhecimento, apresentado por Montoni et al. (2006), é feito de forma textual e baseado na
ligação existente entre as atividades e os artefatos produzidos. Considera-se que, além do
problema de manter as informações atualizadas, o formato textual é um dificultador para a
transmissão do conhecimento. Esse dificultador está relacionado às diversas interpretações que
podem surgir sobre o registro do conhecimento entre as atividades e os artefatos.
1.7.5 Gerência de Conhecimento sobre Processos de Software
No processo de desenvolvimento de software, Borges e Falbo (2001) descrevem uma
ferramenta para apoiar a disseminação do conhecimento. A figura 3 apresenta um modelo de
domínio da ferramenta, que trabalha com a estruturação do conhecimento, a partir das lições
aprendidas na realização do projeto. As lições aprendidas abrangem determinados objetos, tais
como: atividade, artefato, procedimento. A idéia de Borges e Falbo (2001) é apoiar o líder do
projeto na adaptação do processo de desenvolvimento, a partir de um processo padrão e das
31
experiências adquiridas com as lições aprendidas. Entretanto, o conhecimento ficou restrito ao
processo e não vem integrado a todos os elementos do desenvolvimento, uma vez que se
considera as lições aprendidas apenas uma parte do conhecimento gerado. Além das lições
aprendidas, considera-se como sendo uma base de conhecimento todas as decisões técnicas que
envolvem qualquer modelagem do sistema.
Borges e Falbo (2001) tratam o conhecimento no nível textual, o que pode ser um
complicador para a sua utilização. Na proposta, dessa dissertação, aliada ao texto, está a
estruturação do conhecimento em um grafo. Este relata a seqüência natural do relacionamento
(sujeito, verbo, objeto e estado).
Figura 3 – Modelo de domínio desenvolvido baseado em Borges e Falbo, (2001)
1.7.6 Infra-estrutura para Gerência de Conhecimento em ODE
Segundo Natali e Falbo (2003), o conhecimento obtido no desenvolvimento de software
é um recurso importante de uma organização e o seu uso promove um aprendizado evolutivo,
evitando que um mesmo erro seja cometido novamente. Os autores apresentam uma infra-
32
estrutura para apoiar a gerência do conhecimento de forma a armazenar a memória
organizacional da empresa, baseado em ontologia.
A figura 4 apresenta um modelo de domínio capaz de armazenar três tipos de
conhecimento: instâncias de ontologia, artefatos gerados e lições aprendidas. Através dos
relacionamentos de composição é criada a base do conhecimento que, necessariamente, tem que
estar apoiado em uma ontologia. Diferentemente desta proposta, o modelo apresentado nesse
trabalho, permitirá armazenar todos os tipos de artefatos gerados no desenvolvimento,
relacionando-os com as atividades que foram necessárias para a sua implementação, sem se
basear em ontologia. A lição aprendida será considerada um léxico. Acredita-se que, dessa
forma, é possível relacioná-la com qualquer outro léxico, seja ele, artefato ou atividade, seja do
processo ou da gestão do projeto.
Figura 4 – Estrutura da Memória Organizacional de ODE
Fonte: Natali e Falbo (2003)
33
2 REFERENCIAL TEÓRICO
2.1 Pequena Empresa
O mercado brasileiro de empresas de informática é composto na sua maioria por
pequenas empresas. Em 2001, a SOFTEX realizou uma pesquisa para identificar as principais
características de seus associados. Essa pesquisa mostrou que 77% das organizações associadas
são consideradas como microempresa e/ou de pequeno porte. O critério de classificação do
Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (Sebrae), foi utilizado para a
definição do porte da empresa (MCT, 2001).
O Sebrae (2006) utiliza os critérios de receita bruta anual e número de pessoas alocadas
para a definição do porte da empresa. A tabela 1 apresenta as faixas utilizadas pelo Sebrae para
empresas do setor de serviços.
TABELA 1
Definição de Micro e Pequena Empresa
Critérios de Enquadramento Receita Bruta Anual Pessoas
Microempresa Até R$ 433.755,14 Decreto nº 5.028/2004
de 31 de março de 2004. Pequeno Porte R$ 433.755,14 a R$ 2.133.222,00
Microempresa até R$ 240.000,00 SIMPLES
Pequeno Porte R$ 240.000,00 a R$ 2.400.000,00
Microempresa até 9Número de Pessoas Alocadas
Pequeno Porte 10 a 49Fonte: Serviço Brasileiro de Apoio às Micro e Pequenas Empresas - Sebrae (2006).
As pequenas empresas apresentam características distintas das empresas de maior porte.
Essas características influenciam na análise de qualquer estudo que as envolve. Kelly e
Culleton (1999), no seu trabalho de melhoria de processo de desenvolvimento de software para
pequenas empresas, apresentam as seguintes características para pequenas empresas:
• Os engenheiros de software estão envolvidos em todas as atividades que envolvem o
processo de engenharia de software;
34
• São empresas criativas, dinâmicas e inovadoras;
• O sucesso das organizações frequentemente está vinculado à criatividade e inovação
dos seus empregados.
O Instituto Brasileiro de Geografia e Estatística (IBGE, 2001), realizou um estudo com
o objetivo de apresentar um panorama das micro e pequenas empresas comerciais e de serviços
no Brasil. Nesse estudo, foram apresentadas algumas características sobre as micro e pequenas
empresas, tais como:
• Baixa intensidade de capital;
• Altas taxas de natalidade e de mortalidade;
• Forte presença de proprietários, sócios e membros da família como mão-de-obra
ocupada nos negócios;
• Poder decisório centralizado;
• Estreito vínculo entre os proprietários e as empresas, não se distinguindo,
principalmente em termos contábeis e financeiros, pessoa física e jurídica;
• Registros contábeis pouco adequados;
• Contratação direta de mão-de-obra;
• Utilização de mão-de-obra não qualificada ou semi-qualificada;
• Baixo investimento em inovação tecnológica;
• Maior dificuldade de acesso ao financiamento de capital de giro;
• Relação de complementaridade e subordinação com as empresas de grande porte.
A empresa na qual foi realizada o estudo de caso dessa dissertação, apresenta várias das
características apontadas tanto pelo IBGE, quanto por Kelly e Culleton (1999). Dentre essas
características pode-se destacar:
• A maior parte das pessoas alocadas é sócia da empresa;
• Os projetos são distribuídos entre os sócios para serem elaborados;
• Um dos sócios fica como responsável técnico, gestão e por iniciar a fase de
concepção do projeto;
• Os demais integrantes da empresa participam da construção do projeto e realizam
todas as atividades do processo de engenharia de software. Geralmente, estão
envolvidos em mais de um projeto;
• Toda a equipe necessita ter a capacidade de representar a empresa junto ao cliente,
tanto na elaboração do projeto, quanto na elucidação das dúvidas;
35
• A hierarquia do poder é horizontal, ou seja, não existe uma sobreposição clara de
poder entre os sócios. O que dificulta, às vezes, algumas decisões sobre o processo de
desenvolvimento;
• Como parte da estratégia de desenvolvimento, a empresa busca parcerias com outras
empresas maiores, o que acarreta uma diversidade muito grande de domínio de
software a serem construídos. Sendo assim, a empresa é muito suscetível às
mudanças tecnológicas apresentadas pelo mercado.
Com Base nas características da pequena empresa, as técnicas a serem adotadas tanto
para o processo, quanto para o desenvolvimento dos produtos devem ser motivantes e com
resultados adequados à sua realidade. Isso é importante para minimizar o risco de abandonar a
utilização das técnicas no decorrer do tempo. Os produtos que são desenvolvidos e/ou
adquiridos para a automação da empresa devem ser:
• Baratos, devido à falta de capital para investimento próprio. O capital existente é
utilizado para o treinamento nas tecnologias a serem usadas no desenvolvimento dos
produtos solicitados pelos clientes e na própria elaboração desses produtos;
• Fáceis de usar e de aprender, afim de motivar a utilização da ferramenta pelas pessoas
envolvidas no processo de desenvolvimento;
• Fornecer uma visão abrangente sobre todos os elementos do desenvolvimento, ou
seja, com a possibilidade de trabalhar de forma integrada.
2.2 Conhecimento
Segundo Ferreira (1999), conhecer é o ato de ter noção, informação, saber; e
conhecimento é o ato ou efeito de conhecer, apontando experiência, discernimento, critério,
apreciação. Portanto, o conhecimento envolve uma interpretação baseada na experiência sobre
alguma coisa, fato ou informação. Assim, gerenciar, distribuir e criar conhecimento envolvem o
fato e o registro da experiência obtida com esse fato. Desse modo, o registro é fundamental para
que o processo de desenvolvimento de software possa ser bem sucedido a longo prazo.
De acordo com a Figura 5, Tuomi (1999) apresenta a hierarquia do conhecimento, para
uma memória organizacional, obtida a partir do dado, informação, conhecimento, inteligência e
sabedoria. Dado é o fato mais simples que, a partir da estruturação, torna-se a informação. A
36
interpretação ou o significado dado para a informação gera o conhecimento. A utilização desse
conhecimento, a partir de uma escolha das alternativas disponíveis, gera a inteligência. Quando
o comportamento inteligente é guiado por valores e compromissos, esse comportamento torna-
se sabedoria. A curva, representada no gráfico, é para simbolizar que a hierarquia do
conhecimento é obtida através do aprendizado.
Figura 5 – Hierarquia do Conhecimento
Fonte: Tuomi (1999)
De acordo com essa hierarquia do conhecimento, a estruturação, ou seja, a interpretação
ou significado dado para os dados e as informações obtidas, durante o processo de
desenvolvimento de software, podem gerar o conhecimento necessário para ser reutilizado pela
equipe de desenvolvimento. Essa estruturação consiste no registro dos relacionamentos
existentes entre os elementos, envolvendo os três itens da produção de um software: processo
de desenvolvimento (ciclo de vida), gestão de projetos e artefatos produzidos.
Segundo Polanyi, Nonaka e Takeuchi (apud Tuomi, 1999), o conhecimento é dividido
em: explícito e tácito. O conhecimento explícito é transmitido formalmente e o tácito é um
conhecimento pessoal difícil de ser formalizado. Para Ferreira (1999), o conhecimento explícito
é o que pode ser expresso formalmente, de forma clara, pode ser desenvolvido e pode ser
explicado. O conhecimento tácito por não ser expresso de algum modo, é deduzido. Portanto, o
conhecimento gerado, durante a realização das atividades do desenvolvimento de um software,
37
deve ser mapeado, a fim de se obter o registro do conhecimento explícito. Esse registro deverá
ser feito através de uma representação. Esta representação facilitará para o desenvolvedor a
obtenção do conhecimento tácito necessário para a realização de suas atividades. Assim, pode-
se evoluir na hierarquia do conhecimento, conforme apresentada por Tuomi (1999).
O conhecimento gerado necessita ser representado através de um modelo para que
possa ser realmente usado de forma eficaz. Esse modelo auxiliará a equipe de desenvolvedores
a tomarem as decisões sobre o conhecimento obtido e afetará as atividades do desenvolvimento
do projeto. Segundo Davis (apud Campos, 2001, p.49), o conceito de representação de
conhecimento engloba as seguintes idéias:
a) É um mecanismo usado para se raciocinar sobre o mundo, em vez de agir
diretamente sobre ele. Esse raciocínio deve ser feito na correspondência especificada entre os
dois mundos: o da semântica da representação e o da fidelidade, sendo que, esta última é difícil
de ser atingida completamente, pois a única representação completa de um objeto é o próprio
objeto;
b) É uma aproximação imperfeita da realidade (abstração), pois ao selecionar-se uma
representação, esta-se tomando um conjunto de decisões sobre “como” e o que “ver” desse
mundo;
c) É uma teoria fragmentada de raciocínio que especifica quais inferências são válidas
e quais são recomendadas. Uma representação é motivada por alguma percepção de como as
pessoas argumentam ou por alguma crença sobre o que significa raciocinar;
d) É um meio de computação pragmaticamente eficiente. A representação pode tornar
o entendimento possível, mas não facilmente computável;
e) É um meio de expressão, isto é, uma linguagem na qual se pode dizer coisas sobre o
mundo real.
Segundo Davis (1992) (apud Campos, 2001 p.49), o modelo da representação do
conhecimento nunca será completo. No entanto, deve ser o suficiente para comunicar o
entendimento e ajudar na interpretação por parte de quem irá utilizá-lo. Portanto, a criação do
modelo de forma eficiente e eficaz auxiliará na implementação de um comportamento
inteligente (TUOMI, 1999). Isso ajudará o ciclo de transmissão do conhecimento entre os
desenvolvedores.
Segundo Togneri et al. (2004), é necessário ter uma gerência do conhecimento “para
facilitar a captura, o armazenamento, a organização e o compartilhamento do conhecimento,
visando promover o seu reuso e disseminação”. Segundo Ramesh (2002), a gerência do
conhecimento envolve a aquisição, a assimilação e o uso do conhecimento explícito e tácito
38
existente em toda a organização. De acordo com autor, “o processo de conhecimento na
engenharia de software é qualquer conhecimento explicito ou tácito que envolve as atividades,
passos e processos envolvidos na criação de uma solução de software”. Portanto, o essencial
para a geração do conhecimento é a criação de uma rede de relacionamentos entre
objetos/objetos, pessoas/pessoas e de relacionamentos entre objetos e pessoas. O autor
acrescenta que não basta somente disponibilizar o conhecimento para os envolvidos; deve ser
avaliada a forma de apresentação, a capacidade de absorção das pessoas envolvidas e o valor
que essas pessoas dão ao conhecimento. Estes são fatores críticos para o sucesso da
transferência do conhecimento entre os integrantes da equipe de desenvolvimento (RAMESH,
2002).
O conhecimento, normalmente, é fragmentado nas diversas ferramentas, documentos e
pessoas envolvidas no processo de desenvolvimento. A unificação destes fragmentos de forma
que possam ser recuperados e aplicados no desenvolvimento do produto é a maior preocupação
do conhecimento em desenvolvimento de software. Essa unificação é feita a partir da
rastreabilidade entre os elementos e pela implementação dos seus relacionamentos (RAMESH,
2002). Segundo esse autor, desenvolvedores com menor experiência se beneficiarão da
unificação desses fragmentos a partir do entendimento dos relacionamentos existentes e dos
registros dos desenvolvedores mais experientes sobre as soluções adotadas. Por fim, “para que
ocorra o aprendizado organizacional, o conhecimento sobre os projetos, incluindo aquele no
processo de Engenharia de Requisitos (ER), deve ser documentado e organizado em uma
memória organizacional, que apoiará as tomadas de decisões em projetos futuros” (TOGNERI
ET AL., 2004).
2.3 Léxico
Segundo Ferreira (1999), léxico “é o conjunto de vocábulos de um idioma; dicionário
dos vocábulos usados por um autor”. Em sistemas computadorizados, o léxico é utilizado nos
sistemas de Processamento da Linguagem Natural (PLN). Specia e Rino (2002) descrevem o
processo de formação de um léxico enriquecido, e Fano et al. (1989) descrevem uma
ferramenta de PLN para apoiar o desenvolvimento de software. O léxico é utilizado, também,
para ajudar no entendimento e na especificação de requisitos (LEITE E FRANCO, 1993).
39
Em sistemas de PLN, o léxico é um recurso lingüístico voltado tanto para a
interpretação, quanto para a geração da Linguagem Natural. Segundo Specia e Rino (2002), o
léxico:
Consiste em um conjunto de palavras ou expressões da LN, chamadas de itens lexicais, associadas à sua descrição, ou seja, a um conjunto de traços (morfológicos, sintáticos e semânticos, por exemplo) cujos valores fornecem as informações necessárias para que tais palavras ou expressões sejam processadas pelo sistema. Cada item, juntamente com sua descrição, é chamado de entrada lexical. (SPECIA e RINO, 2002, p. 1).
Na engenharia de software o léxico é usado para definir tanto o universo de discurso do
domínio da aplicação, quanto o universo de discurso do processo de desenvolvimento de um
software.
Na atividade de desenvolvimento de um produto de software existem vários tipos de
entrada lexical. Essas entradas podem ser mapeadas, a partir do domínio do problema relativo
aos requisitos do software, no ciclo de vida do processo de desenvolvimento do produto e nas
atividades de gestão do processo de desenvolvimento. O conhecimento a ser transmitido para a
equipe de desenvolvimento será obtido a partir da identificação desses léxicos e dos seus
relacionamentos. Esses relacionamentos formarão a rastreabilidade de qualquer entrada lexical.
Uma entrada lexical pode variar o seu conceito de acordo com a sua utilização. Por
exemplo, a entrada lexical “escopo” que na sua semântica representa o limite da visão sobre um
determinado alvo, ou seja, pode ter seu significado alterado. Quando o engenheiro de software
determina o “escopo” de um projeto, ele está relacionado com os requisitos de usuário. Quando
o líder de um projeto, através das suas atividades de gestão, determina o “escopo”, este está
relacionando-o às atividades que deverão ser trabalhadas para atingirem o objetivo do projeto.
Semelhante a este contexto, os tipos de entrada lexical variam no processamento da linguagem
natural. Eles podem estar representados na sua forma canônica, necessitando de algum processo
de derivação para serem entendidos.
No sistema de PLN, este tipo de variação está representado pelas flexões de gênero,
número, grau, modo e tempo (SPECIA e RINO, 2002 e FANO ET AL., 1989). Portanto, para
que o conhecimento possa ser gerado a partir da rastreabilidade, todo léxico deverá estar
relacionado a um tipo de léxico. O tipo de léxico é uma especialização do próprio léxico. Este
relacionamento permitirá o entendimento do problema, ou seja, o léxico “escopo” poderá estar
ligado ao tipo de léxico “projeto” e ao tipo de léxico “produto”, ou ainda, ao tipo de léxico
40
“visão de processo” e ao tipo de léxico “visão de gestão”. Assim, o conceito do “léxico escopo”
irá variar de acordo com o relacionamento que possuir com outros léxicos (tipo léxico).
Para Fano et al. (1989), o processo de desenvolvimento da base de conhecimento para a
formação de um sistema de PLN inicia-se com a identificação do léxico e do seu conceito e
deve, também, ser evolutivo. O processo é evolutivo devido aos seguintes fatores: a)
complexidade de se determinar e entender os termos do domínio do problema; b) a iteratividade
do ciclo de vida do processo de desenvolvimento de software, que permitem o surgimento de
novos requisitos, durante o desenvolvimento. Portanto, à medida que o conhecimento vai sendo
adquirido, deve-se reavaliar a formação da base do conhecimento.
Similar ao processo de desenvolvimento, a rastreabilidade formará o conhecimento
através da identificação do léxico e seus relacionamentos durante todo o ciclo de vida do
produto. Para cada léxico e seus relacionamentos deve-se identificar também os conceitos
existentes sobre os mesmos. Essas identificações consistem em uma das atividades da equipe de
desenvolvimento e deverão ser apoiadas por ferramentas, para facilitar o seu manuseio e
atualização, de forma que, o conhecimento gerado possa ser armazenado e utilizado por todos
os integrantes da equipe de desenvolvimento.
De acordo com Leite e Franco (1993), a construção do léxico é baseada na idéia de
aquisição do vocabulário, ou seja, “entender a linguagem do problema sem se preocupar em
entender o problema”. A principal meta “é registrar os sinais (palavras e frases), que são
peculiares do domínio”. Portanto, a compreensão do universo de discurso será realizada mais
rapidamente, se os envolvidos no processo de desenvolvimento de um software utilizar em um
vocabulário comum. Essa compreensão do vocabulário ajudará na transmissão do
conhecimento durante a atividade de elicitação de requisitos.
A Linguagem Estendida do Léxico1 (LEL) é gerada a partir de símbolos. Esses símbolos
são definidos de acordo com o domínio que se deseja representar (LEITE e FRANCO, 1993). O
léxico é identificado por um nome e por sua descrição, ou conceito. As entradas do LEL são
classificadas conforme a classificação utilizada no Universo de Discurso: Sujeito, Objeto,
Verbo e Estado. Leite e Franco (1993) apresentam a criação da linguagem léxico estendido em
quatro passos: identificar as principais fontes de informações do universo do discurso; criar
uma lista de sinais relevantes para o universo do discurso; definir o significado desses sinais e
validar o léxico criado.
1 LEL – Léxico Estendido da Linguagem é uma representação dos símbolos da linguagem, ou LAL – Léxico Ampliado da Linguagem (Silva, Leite e Breitman, 2005).
41
2.4 Metas
Normalmente, um software é desenvolvido para melhorar ou aprimorar a rotina de
trabalho e/ou o negócio de uma empresa ou de um departamento. A área de informática serve
de suporte para vários departamentos, para que estes possam atingir ou alavancar os negócios
da empresa. Assim, a informática se apresenta como uma ferramenta fundamental para a
melhoria e racionalização do processo produtivo.
Ao contratar o desenvolvimento de um software, em busca de maior eficiência e
produtividade, o cliente se preocupa com os objetivos a serem alcançados.
A Meta é o objetivo que o sistema (software + ambiente), como um todo, deverá atingir
na visão do usuário, ou seja, na visão do negócio no qual o produto a ser construído estará
inserido (DARDENNE, FICKAS e LAMSWEERDE, 1991), (LAMSWEERDE, 2001).
Um modelo de metas envolve quatro conceitos importantes, segundo Dardenne, Fickas
e Lamsweerde (1991):
• Agente: é quem processa a ação. Ou seja, é aquele que tem a responsabilidade sobre as
metas, ou o que tem o desejo de ela ser alcançada – Ex: stakeholderes, atores;
• Metas: são os objetivos que o sistema deverá alcançar. Não pode ser descrita
exclusivamente em termos de objetos e ações. Não é operacional, e sim o alvo a ser
atingido pelo sistema a ser construído. Ex: Maior capacidade de previsão de tempo de
desenvolvimento, melhor controle sobre as vendas, dentre outras;
• Restrições: são as condições/ações que influenciam a realização das metas. Podem ser
feitas antes, durante e após a realização. São obtidas através dos relacionamentos
existentes entre as metas. Ex: para ter maior capacidade de previsão, deve-se antes
trabalhar as atividades do planejamento;
• Riscos: Identificação dos riscos ou obstáculos para se conseguir atingir a meta desejada.
2.4.1 Identificação de Metas
Durante o desenvolvimento de software, o foco inicial a ser trabalhado e modelado deve
ser o negócio do cliente. Esta postura permite identificar como o sistema contribuirá para a
42
melhoria do processo produtivo do cliente, de modo que se possa entender o domínio no qual o
software está inserido. Essa atividade deve-se iniciar procurando identificar quais as metas que
o usuário pretende alcançar com o produto a ser desenvolvido. Adotando-se esta postura,
obriga-se o usuário a descrever seu negócio e suas atividades, impedindo que detalhes do
software sejam discutidos em um primeiro momento.
A forma de perguntar é muito importante nesta fase de levantamento. Não se deve
iniciar com expressões do tipo “O que você quer?”. A tendência é que ele não responda o que
ele realmente quer. Para cada meta dos stakeholders deve-se procurar trabalhar e refinar através
das perguntas “Como você quer?” e “Por quê você quer?”. O “Como?“ irá permitir um melhor
entendimento e ajudará na formulação do refinamento e identificação das sub-metas. O “Por
quê?“ ajudará a elaborar o nível superior de abstração das metas, construindo assim, toda a
hierarquia das metas (LAMSWEERDE, 2001). Estas duas perguntas ajudarão a compreender o
negócio e a forma como o sistema deverá estar inserido.
Durante esse trabalho de refinamento de metas, os requisitos funcionais e não
funcionais surgirão naturalmente. Os requisitos não funcionais, em determinados momentos,
poderão sofrer fusões com as metas. É importante modelar o requisito não funcional como
metas, pois estes darão apoio às demais metas e requisitos funcionais. Deve-se ter sempre em
mente que Meta é o que se deve atingir, e Requisito é o que deverá ser feito para atingir-se as
metas.
Os requisitos devem relacionar-se com as metas, funcionando como mecanismo de
suporte para o alcance das mesmas. Todas as metas devem ser suportadas por requisitos. Uma
meta sem requisito poderá indicar que ela não deve ser atingida, ou que necessita de um melhor
refinamento. Por sua vez, um requisito que não dá suporte a nenhuma meta indica que este
requisito não faz parte do escopo, ou necessita de um maior refinamento (LAMSWEERDE,
2001).
Segundo Lamsweerde (2001), a modelagem de metas apresenta as seguintes
vantagens:
a) Permite a resolução e documentação de conflitos entre os stakeholders. Fica mais
fácil e transparente discutir e buscar uma aprovação, entre os stakeholders, através do gráfico
gerado na modelagem, além de indicar o caminho que o projeto deverá seguir. E, sobretudo,
ficará representada no gráfico a decisão tomada e o porquê da decisão. Isso, ainda, ajuda a
justificar e explicar a presença de especificações não compreendidas pelo cliente;
b) Melhora a elaboração do escopo do produto. Durante a fase de concepção do
projeto é de extrema importância identificar o escopo a ser construído. O escopo é a base do
43
planejamento e das estimativas de recursos, de custos e de tempo do projeto (MARTINS,
2005). As metas, avaliadas como objetivo do usuário, ajudarão na criação e no controle dos
limites do projeto, a partir da ligação de todos os requisitos com as metas identificadas e
refinadas. O produto deverá dar suporte às metas durante a sua execução;
c) Facilita o levantamento de requisitos. Para o usuário, é mais fácil descrever seus
objetivos do que propriamente os requisitos do software, devido a inúmeros problemas
detectados na fase de elicitação de requisitos (GOGUEN E LINDE, 1993). Pois, para o usuário
é mais fácil, inicialmente, dizer que tem a necessidade de controlar melhor a alocação das
atividades de todos os seus colaboradores, do que dizer que o produto deve permitir a seleção
de uma atividade, alocação da quantidade de horas, a data, os problemas na execução etc.
Através dessa abordagem e do múltiplo refinamento das metas, os requisitos necessários para a
implementação surgirão naturalmente;
d) Melhora a comunicação entre os stakeholders. A modelagem gráfica, do tipo grafo,
facilita a comunicação entre os envolvidos. O modelo ajuda a visualizar o conjunto de metas e a
comunicar e entender a estrutura desejada pelos stakeholdes do produto a ser construído. Um
modelo representa uma simplificação do software a ser construído. Dessa forma, a
documentação e a visualização das decisões que devem ser tomadas ao longo do projeto ficam
registradas e embasadas;
e) Facilita a negociação das prioridades do desenvolvimento. Se perguntar a um
usuário qual requisito deve ser feito primeiro, a tendência é que ele responda “todos”. Para o
usuário é difícil separar um requisito do outro. Entretanto, se perguntar qual meta é prioritária,
o usuário consegue identificar as mais importantes e de maior relevância para o seu trabalho.
Essa identificação ajuda na divisão do projeto.
44
2.5 Engenharia de Requisitos
Independentemente do processo de desenvolvimento escolhido, seja ele rígido baseado
em fases e fluxos (KRUCHTEN, 2003), (LARMAN, 2002), (PADUA, 2003), seja ele baseado
nos processos ágeis (BECK, 2004), a engenharia de requisitos aplicada no desenvolvimento de
qualquer produto de software resulta em melhorias no processo e na gestão da qualidade do
produto final (NUSEIBEH E EASTERBROOK, 2000). A análise de requisitos é a atividade
mais crítica no ciclo de vida de um software. Erros durante essa etapa podem causar
conseqüências desastrosas para o software, para o cliente e para o desenvolvedor
(DARDENNE, FICKAS e LAMSWEERDE, 1991). Existem inúmeros problemas e formas de
levantar requisitos de software, conforme descritos por Nuseibeh e Easterbrook (2000) e
Goguen e Linde (1993). Mas, independentemente da forma escolhida, todas buscam o
entendimento do que deve ser feito, ou seja, transformar as necessidades e desejos dos clientes
em um software executável e controlado pelo computador.
Acredita-se que, além de buscar o entendimento do que precisa ser feito, é necessário
modelar esses requisitos, com o propósito de melhorar esse entendimento e, assim, gerar o
conhecimento necessário, para o desenvolvimento do software, conforme os trabalhos de
cenários, metas, modelagem de requisitos não funcionais. Conforme descreve-se no seção 2.4
(metas), considera-se que, independentemente da forma de levantamento dos requisitos
escolhida, deve-se começar entendendo onde o usuário deseja chegar, registrando o “como” e o
“por que” de cada meta, identificando os agentes e as suas restrições.
A atividade de análise dos requisitos é dividida em dois passos, segundo Dardenne,
Fickas e Lamsweerde (1991):
1- Elicitação dos requisitos: fase geradora do conhecimento necessário para a
elaboração da arquitetura do sistema;
2- Especificação Formal: momento em que o modelo elaborado na elicitação será
refinado e validado através de uma linguagem formal.
A atividade inicial da elicitação é o levantamento e o refinamento de metas, que devem
ser realizados através de algum processo de modelagem. Durante essa atividade é importante a
identificação dos agentes envolvidos e das restrições que darão suporte à satisfação de cada
meta. O modelo proposto por Lamsweerde (2001) apresenta um diagrama baseado em grafos,
utilizado para representar o refinamento hierárquico de metas e sua ligação com os requisitos e
45
submetas, indicando a condição e a forma de contribuição de cada sub-meta / requisito para a
meta hierarquicamente superior. Esta modelagem permite realizar a representação de todo
processo de levantamento, facilitando o entendimento e a comunicação com o usuário.
Acredita-se que as vantagens citadas por Lamsweerde (2001) somente serão atingidas se
a atividade de levantamento for efetuada de forma integrada, ou seja, usuário e desenvolvedor
gerando o conhecimento necessário para o desenvolvimento, a fim de melhorar a comunicação
entre eles. O modelo de metas apresentado por Lamsweerde (2001) utiliza o modelo formal e o
modelo gráfico. Acredita-se que o modelo formal é uma boa forma de documentar e validar
requisitos, mas não apresenta vantagens para a integração com o usuário e para a solução dos
problemas de levantamento existentes. Por outro lado, o modelo gráfico apresenta a vantagem
de ser mais eficiente na comunicação entre o desenvolvedor e o usuário, no entanto,
Lamsweerde (2001) não discute como será desenvolvido esse modelo. Entende-se que o
modelo deve ser criado pelo desenvolvedor, a partir das informações fornecidas pelo usuário,
considerando que eles possam trabalhar juntos, ou não. Entende-se que, a forma apresentada
por esse autor não pressupõe a integração com o usuário em sua plenitude.
Na proposta, dessa dissertação, o modelo é desenvolvido através de refinamentos
sucessivos, efetuados tanto pelo desenvolvedor quanto pelo usuário. O modelo criado não será
mais um modelo de desenvolvimento de software, e, sim, um modelo de comunicação e
validação entre o usuário e o desenvolvedor. A documentação inicial do desenvolvimento
poderá se tornar um investimento para ambos os interessados. A aquisição do conhecimento do
sistema a ser construído será realizada através dos conceitos elaborados durante este
refinamento. O sucesso desse refinamento poderá influenciar diretamente na aquisição do
conhecimento e na geração da documentação necessária para o usuário e o desenvolvedor. O
modelo de metas refinado, aliado ao modelo de requisitos, os quais darão suporte às metas,
deve ser construído gradualmente e registrado em um banco de dados.
Sem o apoio de uma ferramenta é muito difícil aplicar os conceitos de construção em
mão dupla e a geração de documentação automática para o usuário e para o desenvolvedor, de
acordo com as necessidades do projeto. Sem o registro das metas e requisitos em um banco de
dados, é difícil a sua gestão, pois pode consumir um investimento muito grande de tempo para
gerenciar as atividades e os conflitos existentes.
As atividades de modelar meta, identificar requisitos e as histórias (narrativas do
usuário) para a sua execução devem ser atividades em espiral e transversal, em todas as fases do
desenvolvimento. Acredita-se que o conhecimento deve ser adquirido gradualmente, através de
feedback do usuário. Esse feedback poderá confirmar o que está sendo feito e poderá gerar
46
mudanças que ocorrem nos requisitos. Essas mudanças podem estar relacionadas ao não-
entendimento na fase inicial, ou à própria mudança gerada pelo crescimento da necessidade do
usuário, ou ainda, por alguma mudança na direção dos negócios do usuário, ou por força de lei.
2.6 Rastreabilidade
A rastreabilidade é uma parte relevante do processo de desenvolvimento e deve ser
considerada pelas empresas, para melhorar a qualidade do produto final e para a obtenção do
nível de maturidade, tanto para o CMMI, a partir do nível 2, quanto para o MPS/BR (2006), a
partir do nível G. A sub-prática 1.4 (Manter a Rastreabilidade Bidirecional de Requisitos), da
gerência de requisitos do modelo de maturidade CMMI (2006), descreve a necessidade de
implementação da rastreabilidade na empresa da seguinte forma:
A intenção desta prática específica é manter a rastreabilidade bidirecional dos requisitos para cada nível de decomposição do produto. Quando os requisitos são bem gerenciados, a rastreabilidade pode ser estabelecida, desde um requisito fonte até seus requisitos de mais baixo nível e destes de volta para o seu requisito fonte. Tal rastreabilidade bidirecional auxilia a determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos de mais baixo nível podem ser rastreados para uma fonte válida. A rastreabilidade de requisitos pode também cobrir os relacionamentos com outras entidades, como produtos de trabalho intermediários e finais, mudanças na documentação de design, planos de testes e tarefas de trabalho. A rastreabilidade deverá cobrir os relacionamentos horizontais e verticais, como as interfaces. A rastreabilidade é particularmente necessária na condução da análise do impacto de mudanças de requisitos nos planos do projeto, atividades e produtos de trabalho. (CMMI, 2006, p.97).
A partir dessa sub-prática, pode-se destacar os seguintes elementos:
• Bidirecionalidade, ou seja, ter a possibilidade de acompanhar os efeitos de qualquer
artefato produzido durante o ciclo de vida do produto, tanto do mais alto nível para o
mais baixo nível, quanto ao contrário, do mais baixo nível para o nível mais alto. Por
alto nível pode-se considerar as metas e os requisitos do usuário e, por baixo nível,
tabelas de banco de dados e métodos implementados das classes de objetos.
47
• Relacionamento com outras entidades, ou seja, ter a possibilidade de relacionar esses
artefatos produzidos com as atividades que foram necessárias para a sua produção.
Essas atividades são relacionadas com o ciclo de vida do produto e com as atividades de
gestão de projeto.
Segundo Ramesh (2002), a rastreabilidade é um dos componentes chaves para a
transmissão do conhecimento. A rastreabilidade deve permitir o acompanhamento do requisito
durante todo o seu processo de transformação no produto de software. A transformação dos
requisitos em software envolve desde as atividades de elicitação de requisitos, até a criação do
produto para ser utilizado pelos usuários. Essa transformação é mapeada a partir da criação e
manutenção dos relacionamentos entre objetos1 e pessoas2. Estes relacionamentos formarão a
rastreabilidade, e esta ajudará a criar, armazenar, recuperar, transferir e aplicar o conhecimento
para a criação de um produto de software. Segundo o autor, a “rastreabilidade ajuda a gerar o
conhecimento explícito e tácito sobre o processo de desenvolvimento de software e suas
saídas”, pois, a habilidade de relacionar as fontes do conhecimento levará os envolvidos a
“insights” e idéias sobre o produto que está sendo construído. E ainda facilitará a colaboração, a
comunicação e a criação do conhecimento entre os integrantes da equipe de desenvolvimento
(RAMESH, 2002).
O desenvolvimento de software é uma atividade de risco, principalmente devido às
possíveis mudanças de requisitos que ocorrem durante todo o projeto. A rastreabilidade poderá
ajudar nessa gestão de mudança, uma vez que, é possível: identificar o impacto da alteração;
calcular o impacto em todo o relacionamento entre os objetos alterados; eliminar os
relacionamentos que não têm impacto na alteração; efetuar a alteração em todos os
relacionamentos; verificar o impacto das alterações após terem sido implementadas. A partir
dessa análise, é possível então calcular o tempo e o custo do impacto das alterações (DICK,
2005).
De acordo com Gotel e Finkelstein (1994), a rastreabilidade de requisitos refere-se à
habilidade de descrever e seguir o ciclo de vida do requisito de forma bidirecional, ou seja,
tanto para frente quanto para trás. Gotel e Finkelstein (1994) dividem a rastreabilidade em
dois tipos básicos a serem implementados:
a) Rastreabilidade do Pré-Requisito: preocupa-se com a rastreabilidade dos
requisitos antes de iniciar o processo de transformação do requisito em software;
1 Objetos – Artefatos produzidos nas atividades de construção de um software. 2 Pessoas – Indivíduos envolvidos nas atividades de construção de um software.
48
b) Rastreabilidade do Pós-Requisito: preocupa-se com a rastreabilidade dos
requisitos a partir do desenvolvimento do processo de transformação do requisito em
software.
Figura 6 – Tipos de Rastreabilidade de Requisitos
Fonte: Gotel e Finkelstein (1994)
A figura 6 apresenta o relacionamento entre os dois tipos de rastreabilidade
apresentada por Gotel e Finkelstein (1994). A Rastreabilidade do Pré-requisito está relacionada
com a obtenção dos requisitos junto com o usuário e a Rastreabilidade do Pós-requisito está
relacionada com os artefatos e a ligação entre estes artefatos com os requisitos levantados junto
com o usuário para a produção do produto final.
Existem várias propostas e métodos para construir uma rastreabilidade de requisitos,
tais como: matriz de rastreabilidade, referências cruzadas, redes de relacionamentos, dentre
outras. Esses trabalhos dão maior ênfase a algum aspecto da divisão proposta por Gotel e
Finkelstein (1994). Toranzo, Castro e Mello (2002), por exemplo, apresentam um meta-modelo
baseado em uma rede de relacionamentos entre os elementos. Esse modelo trabalha bem a
rastreabilidade do pós-requisito. Leite et al. (1997), Leite e Franco (1993), descrevem a
aquisição do requisito baseada em cenários. A forma proposta permite iniciar o processo de
rastreabilidade do pré-requisito, uma vez que o enfoque é a descrição do usuário a partir de suas
necessidades. Após a criação do cenário é feita a “interpretação” das necessidades descritas. Na
49
mesma linha de trabalho, Antoniol et al. (2002) trabalharam a rastreabilidade entre o código e a
documentação, a partir de um processo que interpreta os textos dos documentos analisados.
Para efetuar a rastreabilidade segundo Kean (1998), três questões devem ser trabalhadas
e definidas:
a) O que necessita ser rastreável?
b) Quais relacionamentos necessitam ser feitos?
c) Como, quando e quem é responsável pelas informações mantidas no banco de dados?
O propósito de se trabalhar estas três questões é dar maior qualidade às informações
rastreáveis, de modo que essas possam realmente se transformar em conhecimento a ser
utilizado por toda a equipe. É de suma importância a determinação do que deve ser rastreável e
os seus relacionamentos devem estar focados na característica da empresa, na capacidade de
absorção pelos integrantes da equipe e o valor que cada membro da equipe dá ao conteúdo
rastreável. Da mesma forma, é necessário ter um responsável por verificar estes
relacionamentos e depois validar se os objetivos de rastreabilidade foram atingidos com os
dados e informações armazenadas no banco de dados.
2.7 Processo desenvolvimento de Software
Segundo Pressman (2002), a Engenharia de Software “é uma disciplina que integra
processo, métodos e ferramentas para o desenvolvimento de software”. Assim, todo
desenvolvimento de software deve seguir um processo pré-definido e gerido, de forma a
garantir a qualidade do produto final durante todo o desenvolvimento do produto de software.
Segundo Booch, Rumbaugh, Jacobson (2000) “um processo é um conjunto de passos
parcialmente ordenados com a intenção de atingir uma meta”. Para Pressman (2002),
“é um dialogo no qual o conhecimento, que deve se transformar em software,
é reunido e embutido no software. O processo provê interação entre usuários
e projetistas, entre usuários e ferramentas em desenvolvimento e entre
projetistas e ferramentas em desenvolvimento [tecnologia]. É um processo
interativo no qual a própria ferramenta serve como meio de comunicação,
50
com cada nova rodada de diálogo atraindo mais conhecimento útil do
pessoal envolvido” (PRESSMAN, 2002, p.17).
A definição de Pressman (2002) ajuda a compreender a necessidade de estudar e
verificar mecanismos que possam auxiliar a transmissão do conhecimento entre todos os
envolvidos, sejam eles, usuários, projetistas e ferramentas. Na proposta, dessa dissertação, o
mecanismo para apoiar a elicitação dos requisitos do usuário é baseado em metas e o
mecanismo para apoiar a comunicação entre os desenvolvedores é a rastreabilidade com base
no léxico.
A seguir, são detalhados o processo de desenvolvimento RUP (Rational Unified
Process) e a Gestão de Projetos, com a finalidade de apoiar a identificação das fontes de
informação do universo do discurso relativo ao processo e a gestão. As classes e os
relacionamentos existentes entre as classes representam os léxicos, de processo e de gestão, a
serem identificados e trabalhados pela empresa durante o desenvolvimento de um projeto.
2.7.1 Rational Unified Process - RUP
Segundo Larman (2004), o “PU (Processo Unificado) surgiu como um processo popular
para o desenvolvimento de software visando à construção de sistemas orientados a objetos”. O
PU utiliza uma abordagem de desenvolvimento iterativo, cujo ciclo de vida é baseado em
refinamentos e incrementos através das iterações. Essas iterações utilizam uma realimentação, a
partir dos usuários, para uma adaptação dos requisitos do sistema (LARMAN, 2004).
O RUP é um processo de engenharia de software desenvolvido pela Rational Software
Corporation, a partir de um refinamento detalhado do PU (LARMAN, 2004). De acordo com
Kruchten (2003), “seu objetivo é assegurar a produção de software de alta qualidade que
satisfaça as necessidades de seus usuários finais dentro de prazos e orçamentos previsíveis”. O
RUP é um guia que orienta a construção de modelos através da UML (Unified Modeling
Language). A UML é uma linguagem gráfica adequada para a modelagem de sistemas. Através
dos seus diagramas, ela consegue representar a estrutura, o relacionamento e o comportamento
do sistema a ser construído (BOOCH, RUMBAUGH, JACOBSON, 2000).
51
Figura 7 – Modelo de Domínio baseado em Kruchten (2003) e Pádua (2003)
A figura 7 apresenta o modelo de domínio do RUP, baseado em Kruchten (2003) e
Pádua (2003). Nesse modelo o processo RUP é uma agregação de fases e fluxos. Essas fases e
fluxos são utilizados pela equipe de desenvolvimento para a elaboração de um projeto.
As fases são representadas por um período de tempo, são separadas por marcos bem
definidos que orientam o progresso do processo de desenvolvimento do software. O seu
conjunto representa o ciclo do desenvolvimento do software. As fases podem ser especializadas
em concepção, elaboração, construção e transição.
Os fluxos do RUP são especializados em fluxo técnico e fluxo gerencial. Os fluxos
técnicos correspondem às atividades de desenvolvimento do projeto. Os fluxos gerenciais
correspondem às atividades de controle e garantia de qualidade que agem na realização dos
fluxos técnicos e na elaboração do produto final.
52
Dentro de cada fase existem o planejamento e a execução de uma ou mais iterações.
Uma iteração consiste em um script ou roteiro, a partir de um conjunto de fluxos. Esses scripts
utilizam critérios de aprovação para a sua realização. Esses critérios indicam a forma de
aprovação dos produtos gerados nas atividades existentes na iteração.
Uma atividade é um trabalho desempenhado por um indivíduo e pode ser dividida em
etapas, as quais podem ser especializadas em reflexão, desempenho e revisão. A reflexão
corresponde ao entendimento da natureza e dos artefatos ligados à atividade. O desempenho
corresponde à criação ou à atualização dos artefatos. A revisão se relaciona à inspeção dos
resultados baseada em critérios pré-estabelecidos. A atividade é executada por uma pessoa, a
qual é representada pelo papel que desempenha no processo de elaboração do software. Uma
pessoa pode desempenhar um ou mais papéis durante o ciclo de produção do software.
Uma atividade consome e gera artefatos, que são produtos ou sub-produtos tangíveis.
São produzidos, modificados ou usados nas atividades executadas pelos indivíduos alocados no
processo. Os artefatos podem ser especializados em várias formas e formatos, tais como
modelos, elementos de modelo, documentos, relatórios e códigos fontes. Os artefatos e as
decisões tomadas na produção dos artefatos correspondem ao conhecimento gerado durante o
desenvolvimento.
2.7.2 Gerência de Projetos
A Gerência de Projetos é um processo que vem sendo estudado, desenvolvido e
melhorado ao longo das últimas décadas. Em 1969, foi fundado o Project Management Institute
(PMI) nos Estados Unidos. O PMI é uma entidade internacional que regulamenta e distribui
conhecimentos relacionados com a Gerência de Projetos. Sua missão, segundo Martins (2005),
é “promover o profissionalismo e desenvolver o estado da arte na gestão de projetos provendo
aos seus associados serviços e produtos; e estabelecendo a aceitação do gerenciamento de
projetos como uma disciplina e uma profissão”.
O PMI elaborou o Project Management Body of Knowledge (PMBOK). Este é um
guia que descreve as áreas de conhecimento necessárias aos profissionais que trabalham com
gerenciamento de projetos. O principal objetivo do guia é “identificar o subconjunto do
Conjunto de conhecimentos em gerência de projetos que é amplamente reconhecido como boa
53
prática”. A idéia do guia é fornecer uma visão geral das práticas de gerência de projetos
reconhecida pelo seu valor e sua utilidade (PMBOK, 2004).
A figura 8 apresenta um modelo de domínio que descreve as áreas de conhecimento
mapeadas a partir do PMBOK. No PMBOK os processos são organizados em fases, sendo elas:
iniciação, planejamento, execução, controle e encerramento. Estas fases são interligadas pelas
atividades divididas em áreas de conhecimento, através de resultados que são produzidos e
utilizados pelas mesmas. As áreas de conhecimento trabalhadas no PMBOK são:
gerenciamento integrado, gerenciamento do escopo, gerenciamento do tempo, gerenciamento
de custos, gerenciamento de qualidade, gerenciamento de recursos humanos, gerenciamento de
comunicações, gerenciamento de risco e gerenciamento de aquisições.
Figura 8 – PMI – Gerência de Projetos baseado em Martins (2005)
A figura 9 apresenta o diagrama de domínio dos elementos da gerência de projetos.
Os elementos são distribuídos dentro das fases, ou seja, durante a fase de iniciação é definida a
missão e o objetivo do projeto, bem como a alocação do responsável (gerente) e a geração do
termo de referência. São identificados e separados o escopo do projeto e o escopo do produto,
para facilitar o gerenciamento do projeto e a sua rastreabilidade. Cada escopo tem suas metas a
54
serem atingidas. No caso do escopo do produto, as metas são refinadas nos requisitos do
usuário. Neste momento, também, são listadas as premissas e restrições levantadas para a
execução. Os riscos são identificados e criados os planos de ações corretivas que deverão ser
executados. O resultado das atividades desenvolvidas deve ser o plano de projeto.
Figura 9 - PMI – Elementos da Gerência de Projetos baseado em Martins (2005)
Na fase de planejamento, as metas são convertidas em um plano de ação e estima-se o
prazo e o custo do projeto. São identificados os stakeholders (pessoas e entidades que têm
interesse no projeto como: os desenvolvedores e os clientes). O resultado das atividades de
planejamento deverá ser o escopo detalhado, a estrutura de divisão de trabalho, o cronograma, a
alocação das pessoas envolvidas, o plano de tratamento de risco e o plano de comunicação. De
acordo com Martins (2005), “do equilíbrio de todos estes elementos, obtemos um projeto de
qualidade, onde, ao final do projeto, o custo e o prazo foram respeitados, o produto foi entregue
conforme pedido pelo cliente e o moral da equipe continuou elevado”.
55
A fase de execução do projeto corresponde às ações necessárias para que haja o
sincronismo entre o planejado e o executado. Nessa fase, deve ser garantido o esforço
necessário para o cumprimento das estimativas e, principalmente, o caminho crítico elaborado
na fase de planejamento. O caminho crítico das atividades determinadas para execução do
projeto corresponde, segundo Martins (2005), “ao caminho cuja duração é a mais longa do
cronograma, e qualquer atraso em uma das atividades deste caminho provoca atraso no projeto
inteiro”.
A fase de controle é o elo entre todas as fases do projeto. Inicia-se no planejamento e
ocorre paralelamente à fase de execução e finaliza na fase de encerramento. O objetivo dessa
fase é o acompanhamento das atividades, com o intuito de medir, comparar e avaliar. Pode-se
assim, indicar os ajustes e as ações corretivas e preventivas necessárias para o projeto. Assim,
serão conhecidos e gerenciados os desvios que aparecem durante a execução. O controle deve
ser feito nos seguintes itens: escopo, tempo, custos, riscos, qualidade, comunicação; ou seja, em
todas as áreas do conhecimento alocadas e desenvolvidas no projeto. Esses ajustes são
registrados através das lições aprendidas.
O encerramento consiste na fase de formalização do aceite do projeto e encerramento de
todos os contratos firmados para a execução. Também é feita a avaliação e análise das falhas
ocorridas. A partir da avaliação, é elaborada uma lista de recomendações para evitar tais
ocorrências em novos projetos. A lista de recomendações é implementada pelo registro das
lições aprendidas. Constrói-se assim, a base histórica de desenvolvimento de projetos.
56
A figura 10 apresenta um diagrama de atividades mostrando a relação existente entre as
fases do projeto. O relacionamento entre cada fase é feito através de atividades que asseguram a
ligação entre as fases. São apresentados, também, os principais artefatos produzidos em cada
fase durante a sua execução.
Figura 10 - PMI – Diagrama de Atividades das Fases
Para o gerenciamento dos projetos é necessário distinguir o ciclo de vida do projeto das
fases de gerenciamento de projetos. O quadro 1 apresenta a relação entre as fases do ciclo de
vida do produto e as fases de projeto. O ciclo de vida do produto, ou seja, o processo de
software fornece a base das atividades que abrangeram o planejamento a ser desenvolvido
acompanhado e executado pela gestão de projetos. Este relacionamento é baseado na classe de
atividades cujos relacionamentos fazem a união entre as duas disciplinas – processo de
engenharia de software e gestão de projetos. Esses relacionamentos devem ser mapeados para a
construção do conhecimento integrado do desenvolvimento do software.
57
Fase Inicialização Planejamento Execução Controle Finalização
Concepção X X
Elaboração X X X
Construção X X X
Transição X X X X
Quadro 1 – Relacionamento entre as fases do projeto e do ciclo de vida do processo RUP
A fase de inicialização ocorre no ciclo de vida concepção. Tanto a inicialização quanto a
concepção tratam da elaboração da proposta e do início do desenvolvimento do projeto. A fase
de planejamento deve ocorrer em todos os ciclos de vida do processo unificado. Na concepção,
é elaborado o planejamento do projeto como um todo. Esse planejamento é caracterizado como
sendo o plano de fase. Por se tratar de um processo iterativo a fase de planejamento também
deve ocorrer no final de cada iteração. Ou seja, no final de cada iteração é feito o plano de
iteração da próxima iteração a ser desenvolvida no projeto. A fase de execução corresponde ao
trabalho de transformar as necessidades do usuário em um produto de software, de acordo com
o que foi planejado e modelado. Esse trabalho é feito nos ciclo de vida elaboração, construção e
transição. A fase de controle corresponde à verificação e comparação entre o planejado e o
executado, e ocorre em paralelo com a execução. A fase de finalização corresponde à
implantação do projeto e a aquisição do aceite do cliente. No ciclo de vida do processo
unificado, a fase de finalização corresponde à última iteração da transição.
2.8 Projeto Discovery
O Projeto Discovery (PIETROBON, 2007), tem por objetivo estudar como visualizar a
informação e conhecimento sobre processo de desenvolvimento de software, gerando um
ambiente de visualização que seja hipermídia, multimídia e interativo, fazendo uso de
ferramentas para modelar o processo, o conhecimento e a visualização. Ele é um visualizador
de conhecimento sobre processos, que segue o modelo visto na figura 11. Da figura percebe-se
que, dado um item de processo, pode-se obter um conhecimento utilizando um recurso visual.
Por exemplo, caso se queira saber quem está envolvido na atividade de teste, pode-se obter a
resposta em fotos ou um texto com o nome das pessoas.
58
Figura 11 - Modelo de Visualização Projeto Discovery
Fonte: Pietrobon, 2007.
Intuitivamente, o ambiente funciona da seguinte maneira: dado um item de processo P,
determina-se o que se quer saber (item de conhecimento - C) e então se escolhe a forma de se
obter este conhecimento, ou seja, a forma de visualização (V) que vai ser a mais adequada para
se obter este conhecimento.
Algumas características do modelo / ambiente proposto são:
• Pode-se ter mais de uma maneira de visualizar os dados e, portanto, mais de uma
maneira de se obter o conhecimento;
• Uma visualização pode fornecer mais de um item de conhecimento;
• Um conhecimento para ser alcançado necessita de mais de um item de processo;
• Diversos itens de processo podem permitir alcançar o conhecimento;
• Um item de conhecimento pode ser obtido por meio de diversos mecanismos de
visualização;
• Com o passar do tempo, existe um acréscimo da quantidade de conhecimento do
usuário;
• Nem todos os usuários podem ter acesso a todos os conhecimentos
Este trabalho de pesquisa se enquadra no Projeto Discovery, fornecendo meios de
visualizar conhecimento sobre os itens de processos relacionados a requisitos de software.
Visual Conhecimento
Processo
PVC
59
3 PROCESSO DE DESENVOLVIMENTO COM MODELAGEM DE METAS
A partir do pressuposto de que as metas auxiliam na geração dos requisitos do
software, verifica-se a sua capacidade de transmissão do conhecimento entre o usuário e o
engenheiro de software, através da modelagem, dentro de um processo de desenvolvimento de
software.
Para a transmissão do conhecimento, trabalha-se apenas com a modelagem visual, que
consiste em: metas e requisitos. Os demais objetos trabalhados na modelagem de metas
conforme Lamsweerde (2001), não foram tratados, pois, considera-se que estão diluídos nos
artefatos e processos, já usualmente utilizados. Os objetos desconsiderados podem estar
relacionados com os elementos já usualmente utilizados na gestão de projetos e nos diagramas
da UML. Os agentes podem estar relacionados com os atores que fazem interação com o
produto de software e/ou com os stakeholders que estão envolvidos na produção. Os obstáculos
podem ser relacionados com a gerência de risco. Neste caso, a gerência de risco passa a
considerar também a possibilidade de que os requisitos possam ou não atingir as metas
modeladas.
A situação a ser trabalhada está representada no diagrama de domínio, na figura 12. De
acordo com essa figura, as necessidades do usuário podem ter interpretações diferentes por
parte do engenheiro de software. Essa interpretação permite construir os modelos do mundo
real através da UML, os quais serão transformados em software. A interpretação feita pelo
engenheiro de software permite conhecer o domínio que está sendo desenvolvido. O ato de
desenvolver e o ato de conhecer geram a experiência para o engenheiro. Esta experiência será
utilizada nos próximos projetos a serem desenvolvidos, a partir da utilização de algum tipo de
banco de conhecimento. Este banco de conhecimento equivale, na proposta, à rastreabilidade
baseada em léxico.
60
Figura 12 – Diagrama de domínio para aquisição do conhecimento no desenvolvimento de um software
A questão a ser pensada, de acordo com o modelo apresentado, é: qual o tempo
necessário para que o engenheiro de software tenha conhecimento suficiente, tanto para
interpretar as reais necessidades do usuário, quanto para tomar as decisões relativas á
construção do produto? Mesmo os engenheiros de software mais experientes em
desenvolvimento de projeto podem ter dificuldades de entender e trabalhar um determinado
domínio ainda não conhecido. Pois, segundo Tuomi (1999), o conhecimento é a interpretação
da informação, portanto a experiência do domínio será afetada pela capacidade de interpretar a
informação. Essa experiência poderá diminuir ou alongar o período necessário para a
compreensão do que tem que ser desenvolvido, afetando a aquisição do conhecimento por parte
do engenheiro de software.
A tomada de decisão para a construção dos modelos que representaram o mundo real é a
inteligência (TUOMI, 1999). Portanto, o conhecimento obtido por meio da interpretação pode
não ser suficiente para que as decisões de projeto sejam tomadas. Esse impasse afeta o ciclo de
vida do produto e as alterações dos requisitos.
Parte-se da hipótese de que a modelagem de metas ajudará a diminuir o tempo
necessário para adquirir o conhecimento sobre um determinado domínio. A modelagem de
metas permitirá ao engenheiro de software abstrair-se do seu mundo técnico e voltar-se para o
mundo real do usuário. Essa abstração do mundo técnico ocorrerá a partir do momento em que
61
o engenheiro de software se preocupar mais em entender os objetivos de negócio do usuário e
não somente com os requisitos do sistema.
Dessa forma, a figura 13 apresenta o modelo de aquisição das necessidades do usuário
baseada em metas. Uma vez que atender as metas é o objetivo de negócio do usuário, então
todas as suas necessidades devem dar suporte a uma ou mais metas de negócio. Tanto o
engenheiro de software, quanto o usuário devem estar focados nessas metas. Para o engenheiro,
as metas ajudam no entendimento do que tem que ser desenvolvido. E para o usuário, as metas
ajudam a definir o que o software deverá fazer. O entendimento das metas auxilia a
compreensão das necessidades a serem desenvolvidas. Essa compreensão melhorará a
interpretação das necessidades a serem implementadas. Por conseqüência, o tempo necessário
para efetuar o entendimento poderá diminuir.
Figura 13 – Diagrama de domínio para aquisição do conhecimento no desenvolvimento de um software utilizando Modelagem de Metas
62
3.1 Processo de Desenvolvimento baseado em Metas
O modelo de processo de desenvolvimento baseado em Metas consiste na
implementação da modelagem de metas, no processo de engenharia de requisitos, inicia-se na
fase de concepção, passando por todas as fases do processo RUP (KRUCHTEN, 2003). O
conhecimento será obtido a partir das atividades de engenharia de requisito e será transmitido
para a equipe de desenvolvimento através do modelo de metas.
A importância de se iniciar com metas, de forma bem definida com os stakeholders, está
na identificação do modelo do negócio do cliente. Deve-se primeiramente conhecer o propósito
que o cliente tem para o software. O trabalho de identificação e modelagem das metas deve ser
feito de forma colaborativa entre o engenheiro de software e o usuário.
A partir do processo, baseado no RUP, já definido para o desenvolvimento do software,
foram feitas alterações nas atividades e no documento de especificação de requisitos e na
proposta de desenvolvimento de software, de forma a abranger as atividades de modelagem de
metas e o registro da mesma nos documentos. Nas seções seguintes são descritas essas fases
considerando estas modificações
3.1.1 Fase Concepção
Um processo de desenvolvimento de software inicia-se com a solicitação, por parte do
cliente, de um produto de software. Os desenvolvedores precisam fazer o levantamento de
requisitos capaz de balizar a atividade de construir a proposta de desenvolvimento do software
(KRUCHTEN, 2003). Normalmente, os custos da fase de concepção são absorvidos pelos
desenvolvedores. Estes por sua vez têm dificuldade em repassar esse custo para o cliente.
Sendo assim, esta fase é de vital importância para o sucesso financeiro e para o cumprimento
do tempo estabelecido na construção do produto.
Nesta fase, o primeiro passo é a identificação dos stakeholders envolvidos no processo
do levantamento inicial. Isso tem por objetivos: delinear o escopo do produto; identificar os
principais requisitos a serem desenvolvidos, em nível suficiente para balizar a construção da
63
proposta; e fazer as estimativas iniciais de custo e tempo de desenvolvimento (KRUCHTEN,
2003, e LARMAN, 2004).
O levantamento deve iniciar-se com a identificação das metas que cada stakeholders
tem em relação ao produto a ser construído. A partir desta identificação e, antes de iniciar o
processo de detalhamento dos requisitos, o desenvolvedor deverá analisar as metas e modelá-
las de modo a preparar-se para o passo de refinamento. Os requisitos já identificados,
preliminarmente, devem ser alocados às suas metas, de forma que estas metas tenham o suporte
desses requisitos para serem atingidas (LAMSWEERDE, 2001). É importante que durante todo
o processo de levantamento e refinamento, sejam verificadas as metas e os requisitos que estão
sem suporte ou sem ligação. Essas metas e requisitos devem sempre ser reavaliados, e
aprovados pelos stakeholders, pois no modelo final, nenhuma meta poderá ficar sem suporte de
requisito, ou requisito sem estar ligado a uma ou mais metas. Os trabalhos de alocar os
requisitos e as metas forçam o desenvolvedor a pensar no problema sem se preocupar com a
solução do mesmo. Este processo consiste em verificar as respostas do por que e do como, na
visão do usuário. Conforme já descrito anteriormente, o por que mostra ao desenvolvedor a
hierarquia superior da meta ou requisito, e o como mostra a forma de se obter respostas para a
meta ou o requisito que está sendo analisado.
O refinamento das metas corresponde ao processo de responder ao “Como?” e ao “Por
quê?” de cada meta ou requisito (LAMSWEERDE, 2001). O refinamento deve ser feito pelos
stakeholders e pelo desenvolvedor, de forma a obter um melhor entendimento, entre ambos, do
que tem que ser feito, definindo assim, o escopo do projeto. É importante para cada nível de
refinamento identificar as condições (and / or) e a forma de contribuição (positivo ou negativo)
de cada “sub-meta” (ou meta refinada), com a meta do nível hierarquicamente superior
(LAMSWEERDE, 2001).
A cada meta modelada ou refinada, o desenvolvedor deverá identificar a situação em
que ela se encontra. A situação poderá ser totalmente refinada, parcialmente refinada ou não
refinada. Esta identificação ajudará o entendimento entre as partes e permitirá identificar os
esforços que devem ser feitos para o trabalho de identificação de todas as metas que o produto
deverá atingir.
A meta totalmente refinada indica que o entendimento já foi absorvido pelo
desenvolvedor e, portanto, todos os requisitos já foram identificados de forma a atender a meta.
Se a meta ainda se encontra parcialmente refinada, isto indica que, existe o
entendimento, mas ainda há dúvidas sobre os requisitos que darão suporte à meta. É possível
que no momento de alocar os requisitos, a meta tenha que ser um pouco mais refinada.
64
Não refinada, indica que a meta não está entendida e, portanto, não é possível alocar
requisitos que lhes dêem suporte.
Provavelmente, durante o processo de refinamento serão encontrados conflitos entre as
metas. Esses conflitos devem ser identificados e gerenciados. Para cada conflito deve-se tomar
uma decisão juntamente com os stakeholders envolvidos. Essa decisão poderá enfocar uma
adequação da meta, um conjunto de metas ou ainda poderá ser a eliminação das metas
conflitantes. Neste último caso, é preciso selecionar um ramo do gráfico do modelo de metas
desenhado. Essas decisões deverão ser identificadas por cores diferentes, para representar a
decisão tomada. O gerenciamento desse conflito irá ajudar na elaboração do escopo do trabalho
a ser desenvolvido. Sendo assim, todos os conflitos devem estar registrados no modelo.
O processo de refinamento poderá gerar várias dúvidas quanto ao que vem a ser meta e,
ou, requisito do sistema. O objetivo do refinamento é chegar a um nível tal que o refinamento
seguinte corresponda ao detalhamento dos requisitos do projeto a ser desenvolvido. Nesse
ponto, o modelo de metas deverá estar entendido e acordado entre todos os stakeholders, com
os requisitos de usuário já alocados em todas as metas.
Ao término do trabalho de levantamento dos requisitos e do refinamento das metas, são
desenvolvidos o escopo final do produto, as estimativas de custo e prazo e elaborada a proposta
de desenvolvimento. As metas darão apoio nessas atividades a partir do momento em que as
necessidades de negócio foram mapeadas. Além disso, as metas também darão sustentação a
decisões tomadas para o desenvolvimento do projeto.
A figura 14 apresenta um diagrama de atividade que resume a proposta de modelagem
de metas na fase de concepção. Apresenta, principalmente, a necessidade de desenvolver o
refinamento de metas até a definição dos requisitos, através da colaboração entre o cliente e o
desenvolvedor.
65
Figura 14 – Diagrama de atividade da modelagem de metas na fase de concepção
3.1.2 Fase Elaboração
Após a aprovação do projeto, inicia-se a fase de elaboração. A fase de elaboração
caracteriza-se pelo desenvolvimento conceitual do projeto e a criação dos modelos que servirão
de base para a construção do produto (KRUCHTEN, 2003 e LARMAN, 2004).
Inicia-se, assim, o detalhamento dos requisitos. Esse detalhamento inicia-se com o
modelo de metas, o qual já contém os requisitos de usuário a serem detalhados e a identificação
dos stakeholders que darão suporte ao levantamento dos requisitos. Todos os requisitos
66
detalhados e os novos requisitos identificados deverão dar suporte a uma ou mais metas. Não
poderá haver metas sem requisitos e requisitos sem metas (LAMSWEERDE, 2001). Qualquer
uma dessas situações deverá indicar a necessidade refinar as metas, ou melhorar a identificação
do requisito, ou que o requisito ou a meta estão fora do escopo do desenvolvimento a ser
realizado.
Na fase de concepção, os requisitos preliminares foram apenas alocados a cada meta. Na
fase de elaboração, os refinamentos dos requisitos, através das “histórias” relatadas pelos
usuários, melhoram o conhecimento necessário sobre o que tem que ser desenvolvido. O que
permitirá aos desenvolvedores não se desviarem dos objetivos do sistema a ser construído.
Esse processo poderá ajudar a garantir a qualidade do software. Este acompanhamento será
feito a partir da rastreabilidade baseada em léxico.
O Gestor do projeto deve acompanhar essas atividades do processo, de forma a garantir
e controlar a qualidade do produto e do próprio processo. Deve acompanhar a construção dos
planos de testes que irão verificar e validar requisitos com as metas. Nos planos de testes alfa e
beta, deve ser indicado como o software estará ajudando a atingir a meta, sendo esses testes a
verificação e a validação, respectivamente, do que o software realmente terá que fazer e atingir.
O usuário deverá acompanhar a execução do planejamento dos testes betas, a fim de verificar
se o modelo de metas desenvolvidas será atingido. O gestor deverá relacionar as atividades e os
artefatos para a produção do software na rastreabilidade baseada no léxico, de forma que o
conhecimento sobre o desenvolvimento seja transmitido entre os integrantes da equipe de
desenvolvimento.
3.1.3 Fase Construção
A fase de construção corresponde à transformação da solução proposta em um produto
executável, capaz de ser implantado para o usuário (KRUCHTEN, 2003 e LARMAN, 2004).
Nesta fase são feitos os testes para garantir que o produto será entregue com qualidade e sem
erros. Os testes devem ser executados de acordo com o planejamento efetuado. O nível de
qualidade do produto é obtido a partir dos testes e da verificação da conformidade com o que o
usuário deseja em relação ao software, ou seja, a conformidade atingida entre modelo de
metas/requisitos.
67
3.1.4 Fase Transição
Essa fase caracteriza-se pela disponibilização do produto para a comunidade de
usuários, bem como a avaliação dos objetivos alcançados (KRUCHTEN, 2003 e LARMAN,
2004). Essa avaliação deverá seguir, no primeiro momento, o plano de teste beta. No segundo
momento, o usuário deverá fazer a validação de acordo com o modelo de metas em seu poder.
A idéia é a de que no primeiro momento, o usuário seja conduzido, pelo desenvolvedor, durante
os testes de verificação. No segundo momento, o usuário, já treinado, irá validar sem a presença
do desenvolvedor, mas com o foco no plano de metas acordado entre as partes. O documento de
aceite do usuário deverá ter como base o plano de metas e deverá indicar o grau de
conformidade/qualidade atingido pelo produto.
3.2 Verificação e Validação
Durante todo o processo de desenvolvimento, é importante que o desenvolvedor
identifique quais metas foram atingidas para certificar-se de que as decisões tomadas
correspondem às interpretações feitas inicialmente. Este passo tem por objetivo balizar a
aquisição da experiência. Esta experiência será reusada durante os passos seguintes. Isso é feito
através da verificação dos requisitos modelados ou desenvolvidos, com as metas identificadas e
modeladas durante o refinamento. Os modelos do projeto, os planos de testes, os planos de
implantação e treinamento, devem sempre focar as metas a serem atingidas. Essa verificação
deverá ser apoiada, também, pela rastreabilidade baseada em léxico.
A validação do usuário, através do modelo de metas, estará ratificando a experiência
adquirida pelo desenvolvedor, mostrando os acertos e os erros apresentados pelo produto em
relação às metas a serem atingidas.
68
4 MODELO PROPOSTO
Como foi visto nos capítulos anteriores, o foco desse trabalho é para que pequenas
empresas consigam capturar, reter e disseminar o conhecimento sobre a aplicação e o processo
de desenvolvimento. A figura 15 ilustra o fluxo do conhecimento durante o processo de
transformação dos requisitos em um produto de software. Através dessa figura, pode-se
compreender como o conhecimento obtido junto ao usuário é capturado e disseminado para que
a equipe de desenvolvimento possa realizar suas atividades.
Na figura 15 são apresentados os dois pontos do conhecimento que devem ser tratados
no desenvolvimento de um software. O primeiro ponto do conhecimento se refere às
necessidades do usuário. O segundo ponto do conhecimento se refere à geração da base de
conhecimento pela equipe de desenvolvimento.
Nota-se que as necessidades do usuário, representadas nessa figura, são obtidas como
um conjunto de narrativas1 que devem ser interpretadas, compreendidas e satisfeitas pelo
engenheiro de requisitos para o desenvolvimento do produto. O engenheiro de requisitos, na
atividade de elicitação, deve utilizar a modelagem de metas como ferramenta para a
interpretação e compreensão dessas narrativas do usuário.
No modelo proposto, tem-se que, a partir do modelo de metas, o engenheiro de
requisitos transmite o conhecimento necessário para a equipe de desenvolvimento realizar suas
atividades de transformação dos requisitos em artefatos de software. Essa transmissão,
normalmente, é efetuada em reuniões técnicas entre os integrantes da equipe e através do
registro do modelo de metas no banco de conhecimento.
Após o entendimento dos requisitos, a equipe de desenvolvimento realiza atividades
para a construção do software. Essas atividades podem ser relacionadas à especificação,
modelagem, programação e gestão do projeto. O produto resultante dessas atividades são os
artefatos, os quais irão representar uma parte ou o todo de um produto de software. As
atividades e os artefatos representam o conjunto de narrativas que caracterizam o conhecimento
gerado pela equipe de desenvolvimento.
A equipe de desenvolvimento tem que tomar decisões durante a realização das suas
atividades. Essas decisões são tomadas em função do conhecimento existente e refletem-se nos
artefatos produzidos e por conseqüência, na qualidade do produto final. Assim, essas decisões 1 Narrativa: a maneira de narrar; Narração; História; (FERREIRA, 1999). Narração: exposição escrita ou oral de um fato; Ato ou efeito de narrar. (FERREIRA, 1999).
69
acumuladas geram a experiência da equipe para a produção do software. Essa experiência deve
ser armazenada no banco de conhecimento para que a própria equipe possa usufruir, mais tarde,
do conhecimento gerado durante o desenvolvimento.
Nessa proposta, o modelo de metas, as atividades, os artefatos e as decisões de projeto
devem ser armazenados no banco de conhecimento a partir dos conceitos relacionados à
rastreabilidade baseada no léxico. Dessa forma, a manipulação da rastreabilidade irá consistir
na manipulação do conhecimento gerado na produção do software. Essa manipulação permitirá
a transmissão do conhecimento entre os integrantes da equipe, de modo a propiciar,
conseqüentemente, a melhoria da qualidade das atividades e dos artefatos produzidos.
Figura 15 – Caso de uso referente a proposta de manipulação do conhecimento
70
Nos capítulos seguintes procura-se o modo de se obter esse modelo de disseminação de
conhecimento. O detalhamento será apresentado nos capítulos cinco (5) e seis (6). O capítulo
cinco (5) apresentará a implantação e a ferramenta para a manipulação do conhecimento
relacionado às necessidades do usuário baseado na modelagem de metas. O capítulo seis (6)
apresentará a manipulação do conhecimento pela equipe de desenvolvimento, a partir da
rastreabilidade baseada em léxico. O capítulo sete (7) apresentará a solução proposta para o
banco de conhecimento e a ferramenta desenvolvida para a manipulação do conhecimento
descrita no capítulo seis (6). O capítulo oito (8) apresentará os resultados, conclusão e trabalhos
futuros.
71
5 IMPLANTAÇÃO DA MODELAGEM DE METAS
A inserção das atividades de modelagem de metas no fluxo do processo de
desenvolvimento da pequena empresa, descrito no capítulo 3, foi elaborado de forma aderente
ao MPS/BR (2006). São utilizados do MPS/BR o processo Gerência de Requisitos (GER) e o
Treinamento (TER). Isso foi necessário devido à falta de experiência da equipe na
documentação dos requisitos utilizando metas e devido à política adotada na empresa para a
institucionalização da modelagem de metas como ferramenta de apoio a gerencia de requisitos.
Do GER buscou-se o a comunicação contínua entre os fornecedores dos requisitos e o
engenheiro de requisitos (GRE 1), na melhoria do entendimento dos requisitos (GER 2) e na
rastreabilidade dos requisitos entre os planos de projeto e os produtos (GER 5) (MPS/BR,
2006).
5.1 Passos para a Implantação
O processo de implantação da modelagem de metas orientou-se de acordo com os
resultados esperados do processo de treinamento TER do MPS/BR. A responsabilidade do
treinamento é da empresa desenvolvedora, visto que se refere à uma atividade da engenharia de
requisito. A estratégia do treinamento foi elaborada de modo a garantir que todos os integrantes
da equipe tenham o conhecimento necessário sobre a modelagem de metas, de acordo com as
atividades definidas para o processo.
5.1.1 Treinamento dos integrantes da equipe
Para o treinamento dos integrantes da equipe foi preparado um material e um estudo de
caso baseado em Lamsweerde (2001), com relação à modelagem de metas. Depois foi
apresentada a forma de se utilizar as perguntas como e por que, para fazer o modelo de metas,
72
focando principalmente a estrutura hierárquica que as duas perguntas ajudam a construir. O
treinamento foi realizado nas dependências da empresa no formato de reuniões técnicas. Essas
reuniões caracterizam-se pela apresentação do tema por um membro da equipe. Após a
apresentação há a discussão da técnica entre os integrantes.
5.1.2 Seleção de um projeto em andamento
Os integrantes da equipe de desenvolvimento desenvolveram o modelo de metas dos
projetos em andamento. Optou-se por escolher um projeto em andamento pelo fato dos
requisitos já serem de domínio dos integrantes, o que facilitaria o entendimento da
rastreabilidade entre o requisito e a meta, a discussão entre os integrantes e a verificação de
conformidade do modelo desenhado.
O objetivo desse passo, foi o de avaliar o quanto as metas ajudariam os integrantes a se
abstraírem do mundo técnico e voltar-se para o mundo do negócio. E ainda, possibilitaria
identificar as dificuldades para a criação do modelo. Nesse contexto, o desenvolvimento do
modelo não poderia envolver o usuário, mas somente, o entendimento existente sobre o produto
até o momento.
5.1.3 Modelagem de metas
O desenvolvedor iniciou o modelo a partir de um requisito qualquer do projeto. E,
através da pergunta por que, o desenvolvedor deveria identificar a meta a ser atingida. Depois
com o como verificou se o requisito realmente atendia à meta. O passo seguinte foi fazer o
mesmo, ou seja, perguntar o como e o por que de cada meta modelada e de cada requisito
colocado no modelo.
Se o desenvolvedor tivesse dificuldade em iniciar a modelagem de metas, deveria
colocar como meta os requisitos não funcionais, identificados para o desenvolvimento dos
projetos em andamento. Depois disso, ele deveria fazer o processo de responder o como e o por
que.
73
5.1.4 Verificação com o usuário
A partir do modelo de metas pronto, o desenvolvedor verificou com o usuário o
resultado da modelagem. O objetivo desse passo é validar as metas levantadas e verificar se as
metas ajudam a identificar novos requisitos dos projetos já em andamento.
5.1.5 Implantação de modelagem de metas em novos projetos
A implantação de metas para os novos projetos iniciou-se com a adesão do usuário no
processo de modelagem. Foram explicados os conceitos de meta e a ligação com requisitos.
Não foi dada ênfase à forma de fazer o refinamento, visto que, inicialmente, seria uma tarefa do
desenvolvedor. O desenvolvedor iria estudar o modelo de metas e solicitar o refinamento em
um ou mais pontos do modelo. Desta forma, os novos projetos foram trabalhados, utilizando
metas como levantamento de requisitos, mas com a modelagem feita manualmente.
5.2 Ferramenta DBML
Desenvolveu-se a ferramenta DBML (Desenvolvimento Baseado em Metas e Léxico)
para dar apoio à atividade de elicitação de requisitos baseado em metas. Os objetivos da
ferramenta são:
• Possibilitar uma maior integração entre os clientes e os desenvolvedores;
• Permitir aos desenvolvedores fazerem o modelo de metas e a documentação dos
requisitos de forma mais amigável e integrada com as demais ferramentas da empresa;
• Fornecer aos desenvolvedores um documento atualizado para fazer a atividade de
verificação de metas com todos os outros artefatos produzidos durante o trabalho;
• Permitir uma maior agilidade na comunicação e na diminuição do tempo da fase de
concepção;
74
• Dar apoio ao processo de validação junto ao cliente.
A ferramenta de modelagem de metas é dividida em dois módulos: Gestão e
Modelagem. O primeiro módulo tem como objetivo facilitar a comunicação e o registro das
metas e dos requisitos e, o segundo módulo tem como finalidade efetuar a modelagem visual
das metas.
O módulo de gestão da ferramenta foi desenvolvido em PHP (Hypertext Preprocessor).
A plataforma na internet foi escolhida, para facilitar a comunicação entre os clientes e os
desenvolvedores. Dessa forma, o processo de refinamento das metas pode ser feito à distância.
O desenvolvedor cadastra inicialmente os envolvidos e o tipo de papel de cada stakeholder, de
forma que todos os interessados tenham acesso à ferramenta e ao modelo de metas do projeto.
O módulo de modelagem foi desenvolvido em Delphi. O processamento do módulo é
local, sem necessidade de estar integrado à rede. A comunicação entre os dois módulos é feita a
partir de arquivos XML. No apêndice 1 e 2 é apresentado um exemplo de um arquivo XML
utilizado na integração entre os dois módulos da ferramenta.
A utilização da DBML começa com a lista de metas e requisitos levantados inicialmente
com o usuário. O resultado do primeiro levantamento das metas é convertido em um modelo
inicial a ser refinado em mão dupla. As metas e os requisitos são cadastrados e é liberado o
arquivo XML do projeto. Os stakeholders devem realizar o download do arquivo e efetuar a
verificação e a identificação de novas metas, de acordo com a sua própria visão. No final, os
stakeholders devem transmitir o modelo para o desenvolvedor através do módulo de Gestão.
Uma vez que as metas dos stakeholders foram cadastradas na ferramenta, inicia-se o
processo de entendimento e análise do conflito. Para cada meta o desenvolvedor cadastra o seu
grau de refinamento, ou seja, verifica se a meta está suficientemente entendida e se já é possível
efetuar o detalhamento dos requisitos. Esse trabalho pode ser feito juntamente com o cliente, ou
separadamente, dependendo da forma de comunicação desenvolvida entre o cliente e o
desenvolvedor.
De posse das metas é feito o cadastro preliminar dos requisitos e realizada a ligação
com as metas. O desenvolvedor irá fazer as previsões de tempo, recurso e custo para o
desenvolvimento. A ferramenta irá emitir a proposta para ser aprovada e assinada pelo cliente.
Sendo aprovada a proposta, o modelo de metas projetado é utilizado para efetuar toda a
elicitação de requisitos. Todos os requisitos são cadastrados a partir da metas, para garantir o
alinhamento entre desenvolvedores e metas. A partir desse momento, todos os modelos gerados
serão cadastrados e alinhados com os requisitos que estarão automaticamente alinhados com as
metas.
75
A figura 16 apresenta o diagrama de domínio da ferramenta. As metas e os requisitos
são especializações do escopo. Os requisitos dão suporte às metas através dos seus
relacionamentos. As metas são definidas pelos stakeholdes e são refinadas, indicando a
contribuição e a condição do refinamento. Cada meta poderá estar em um determinado grau de
refinamento.
Figura 16 – Modelo de Domínio da Modelagem de Metas da Ferramenta DBML
A figura 17 apresenta as principais funcionalidades da ferramenta de modelagem de
Metas. O desenho oval em cinza representa o nome do projeto ou do módulo que está sendo
analisado. Os desenhos ovais em verde apresentam as metas a serem atingidas pelos requisitos
representados pelos retângulos azuis. Quando se deseja indicar um conflito entre as metas, o
desenho oval verde é convertido para um oval em amarelo. Ao clicar com o mouse direito sobre
qualquer meta, são apresentadas as funções de: propriedades da meta, associação, conflito e
necessidade de refinamento das metas. Na janela de propriedades das metas é possível indicar
um nome e uma descrição para a meta, bem como indicar as respostas das perguntas como e
por que. Essas descrições serão usadas mais tarde para análise do léxico. Na janela de
76
associação, é possível ligar a uma meta ou requisito, indicando a forma de contribuição,
positiva (+), ou negativa (-). Na janela de propriedade dos requisitos é possível indicar um
nome e a descrição do mesmo. O modelo de metas pode ser analisado para indicar o grau de
refinamento das metas, bem como a consistência de suporte entre metas e requisitos. O
resultado da análise é apresentado na janela Análise.
Figura 17 – Ferramenta de Modelagem de Metas
A ferramenta de modelagem de metas não tem por objetivo efetuar o controle de versão
das metas/requisitos. Este controle será efetuado no módulo de Gestão, através da integração
com o banco de conhecimento, que será apresentado no capítulo 6.
77
5.3 Estudo de Caso
Para ilustrar o desenvolvimento utilizando metas, é apresentada uma parte do
levantamento de metas de um projeto de controle de produção e comercialização de sementes
híbridas. Esse estudo de caso foi efetuado como parte do treinamento dos desenvolvedores e
posteriormente validado pelo usuário.
Figura 18 – Parte do Modelo de Metas do Software Controle de Licenciados
A figura 18 apresenta parte das metas e dos requisitos que deram suporte às metas para
o desenvolvimento do projeto de controle de licenciados. Dentre as metas existe um conflito
entre a meta de redução de custo e a meta de gerenciamento. Após a análise do conflito, a meta
redução de custo foi indicada com a cor amarela e isso representa um adiamento da análise e
solução do conflito durante a fase de elicitação, visto que a meta de gerenciamento foi
considerada mais adequada às necessidades do negócio do cliente do que a meta de redução de
custo. No apêndice 1 é apresentado o arquivo XML gerado nessa modelagem.
A seguir é apresentada de forma descritiva a modelagem de metas transcrita das janelas
de propriedade da ferramenta, conforme a figura 18:
78
Nome do Projeto: Licenciados.
• Meta Gerenciamento:
o Descrição: Melhorar o gerenciamento da distribuição de sementes entre os
licenciados.
o Como?
• Controlar melhor a distribuição das sementes;
• Controlar a comercialização das sementes;
• Controlar o faturamento a ser cobrado a título de royalty.
o Por que?
• O negócio da empresa é a pesquisa e não a produção e comercialização
de sementes para plantio, desta forma é de vital importância conhecer as
informações de negócio para o planejamento e o futuro da empresa.
• Meta Controle:
o Descrição: Controlar a distribuição de sementes.
o Como?
• Através da confecção dos planos de comercialização, produção e
marketing.
o Por que?
• É necessário o controle da distribuição para conhecer e efetuar o
planejamento do que tem que ser produzido e identificar as técnicas a
serem utilizadas no plantio, melhorando o gerenciamento.
• Meta Comercialização:
o Descrição: Controlar a comercialização das vendas das sementes feitas pelos
licenciados.
o Como?
• Recolhendo mensalmente as informações de comercialização dos
licenciados através da fatura;
• Recolhendo informações de comercialização dos concorrentes através de
um levantamento de mercado.
o Por que?
• Através das informações de comercialização, consegue-se visualizar se o
planejado foi alcançado e efetuar o cálculo do royalty;
79
• Permitir, também, a identificação do foco de maior potencial agrícola e
de mercado.
• Requisito Plano de Produção:
o Permitir cadastrar o plano de produção solicitado pelo licenciado, com os dados
técnicos relativos à produção da semente.
• Requisito Pl. Comercialização:
o Permitir cadastrar os dados relativos aos valores de previsão de venda das
sementes produzidas, bem como as regiões e as formas de comercialização.
• Requisito Plano de Marketing:
o Permitir cadastrar o plano de marketing contendo as informações de mercado e
da região a qual se pretende atuar.
• Requisito Receber Fatura:
o Permitir cadastrar os dados da fatura emitida pelo licenciado na venda dos
produtos licenciados para comercialização.
• Requisito Calcular Royalty:
o Calcular o valor do Royalty a ser pago pelo licenciado, a partir dos dados da
fatura e do tipo de produto comercializado.
O segundo estudo de caso apresentado tem como objetivo verificar a eficácia da
utilização de metas na transmissão do conhecimento com o propósito de verificar se houve,
realmente, uma redução do número de possíveis alterações dos requisitos após a entrega de
qualquer parte do produto. Muitas das alterações dos requisitos surgem a partir do momento
em que o usuário tem acesso ao produto. A partir da sua utilização surgem novas necessidades.
Este estudo de caso é um exemplo de um dos levantamentos feito para o módulo de estatística
de um projeto da empresa.
O módulo de estatística já tinha sido implantado e o usuário tinha uma necessidade de
alteração. A verificação foi feita da seguinte forma:
• Primeiro o usuário falou da sua necessidade de alteração.
• Na elicitação da necessidade foi definido o que o sistema deveria fazer.
• A partir do requisito definido efetuou-se a identificação das metas.
• Durante este processo, verificou-se a necessidade de alteração do requisito previamente
definido.
A necessidade do cliente era totalizar o faturamento mensal e comparar com o mesmo
mês do ano anterior. No primeiro momento, sem preocupar-se com as metas que o usuário
80
necessitava atingir, foi determinada a forma de pesquisa e a forma de apresentação da alteração
solicitada. Após a definição da alteração e do acordo entre as partes do que deveria ser feito
pelo desenvolvedor, foi utilizada a modelagem de metas para verificar se o requisito realmente
atendia à necessidade do cliente.
Iniciou-se com a pergunta por que ele desejava esta alteração, ou seja, qual a meta de
negócio que ele desejava atingir. No final, foram identificados novos requisitos que deveriam
ser feitos. No caso, os novos requisitos foram: o cálculo do mês em relação ao total do ano atual
e do ano anterior e ainda a plotagem do gráfico apresentando todas as relações calculadas.
A figura 19 apresenta o gráfico de metas feito após o levantamento de requisitos. Foram
identificadas as metas: Conhecer o Faturamento, para ajudar na tomada de decisões; e
Melhorar a Disponibilização de Recursos, para melhora da alocação dos recursos, de acordo
com as características do faturamento mensal e anual. Os requisitos cálculo de faturamento
mensal, cálculo de faturamento anual e o cálculo das relações existentes entre os meses e os
totais anuais dão suporte às duas metas. O requisito de plotagem do gráfico dá suporte aos
requisitos de cálculo. No apêndice 2 é apresentado o arquivo XML gerado nessa modelagem.
Figura 19 – Modelo de Metas Referente a alteração do módulo de Estatística
81
6 RASTREABILIDADE BASEADA EM LÉXICO
Neste capítulo é apresentada a segunda parte da proposta de manipulação do
conhecimento que trata da rastreabilidade baseada em léxico.
A figura 20 apresenta os elementos e os relacionamentos existentes no desenvolvimento
de um produto de software. Esse desenvolvimento é feito através de atividades realizadas por
uma equipe de pessoas, alocadas em organizações ou empresas. Essas atividades devem estar
estabelecidas dentro de um processo definido. Cada projeto, a partir das suas características,
deve ter um processo adequado ao seu desenvolvimento. As atividades produzem e consomem
artefatos que irão formar ou compor o produto final. No desenvolvimento dessas atividades é
necessário que haja atividades relacionadas à gestão do projeto para a garantia da qualidade. Os
elementos e os relacionamentos entre esses elementos geram o conhecimento na produção de
um software.
Figura 20 – Diagrama de domínio referente aos macro relacionamentos existentes no desenvolvimento de um software
82
Para manipular e propagar o conhecimento gerado por todos esses elementos e
relacionamentos, propõe-se usar rastreabilidade baseada em léxico. A rastreabilidade baseada
em léxico nos permite associar os conceitos existentes nos léxicos de cada
elemento/relacionamento dentro do contexto. Essa associação de conceitos através da
rastreabilidade pode facilitar a aquisição, propagação e manipulação do conhecimento.
Os elementos envolvidos na retenção e transmissão do conhecimento estão relacionados
às atividades do processo, atividades de gestão e artefatos produzidos. Portanto, para manipular
o conhecimento relativo ao desenvolvimento de um software, esse trabalho parte das seguintes
premissas:
• Todos os elementos existentes no desenvolvimento do software, tais como: processo,
gestão, metas, requisitos, atividades e artefatos, são considerados como léxico. Por ser
um léxico o elemento tem a ele associado um conceito. Esse conceito pode variar de
acordo com o contexto utilizado;
• As estruturas dos relacionamentos existentes entre os léxicos formarão o conhecimento
a ser manipulado pela equipe de desenvolvimento.
Ramesh (1998) agrupa as organizações quanto à forma de entender e fazer a
rastreabilidade dos requisitos, agrupando os usuários em low-end users e high-end users. Por
low-end users entende-se a rastreabilidade como uma imposição dos responsáveis pelo projeto,
e esses implementam modelos mais simples de dependência entre os requisitos e os artefatos.
Nesse relacionamento de dependência não existe o registro da rastreabilidade ligada ao
processo e à gestão. Por high-end user entende-se a rastreabilidade como um importante
elemento para a qualidade final do projeto. Com o high-end user implementam-se esquemas
mais ricos de rastreabilidade dos requisitos. Além do relacionamento dos requisitos com os
artefatos, são implementados os elementos do processo e da gestão, os quais incluem na
rastreabilidade as razões das tomadas de decisão sobre um relacionamento e a confecção de um
artefato.
Pode-se classificar os agrupamentos de usuário proposto por Ramesh (1998), quanto ao
entendimento1 e compreensão2, considerando também a definição de conhecimento apresentada
por Tuomi (1999). O primeiro grupo, low-end users tem a rastreabilidade como apoio à
atividade de elicitação, no que se refere à descoberta da formação do requisito e/ou artefato.
Esta formação indica qual ou quais artefatos geraram o requisito. O conhecimento, neste caso, é
manipulado para o entendimento do domínio do problema não para a sua compreensão. O 1 Entendimento - Juízo, opinião. (FERREIRA, 1999). 2 Compreensão - Faculdade de perceber; percepção. Conjunto das características gerais que formam um conceito e que são os atributos dos objetos designados por um termo. (FERREIRA, 1999).
83
entendimento permite ter uma visão da formação do artefato ou requisito. A compreensão, além
dessa visão, permite visualizar os motivos ou fatos que apoiaram a transformação do requisito
no artefato.
Essa rastreabilidade, do grupo low-end users, apóia a equipe em situações de dúvida em
relação a uma questão já existente a nível de desenvolvimento. Ela dificulta a elaboração de
questões sobre o desenvolvimento que estão fora do contexto do produto em construção. Nesse
contexto, ela ajuda a manipular o conhecimento adquirido pela equipe de desenvolvimento,
enquanto o produto está sendo desenvolvido. Mas, dificulta a utilização do conhecimento
gerado pela construção de projeto por equipes diferentes ou, ainda, pela construção de um outro
projeto. Os engenheiros de software poderão ter inúmeras dúvidas com relação ao como foi
desenvolvido o software. Essas dúvidas poderão surgir devido à falta de visualização das
atividades e das decisões que envolveram a transformação do requisito no artefato.
Por sua vez, o segundo grupo (high-end user) pode maximizar a manipulação do
conhecimento. Essa maximização ocorre porque permite ao engenheiro de software
compreender o processo de transformação do requisito em um artefato de software. A
compreensão desse processo pode ajudar na geração da experiência necessária para avaliar o
desenvolvimento e para a tomada de decisão sobre os impactos e as alterações no projeto
corrente, sempre que necessário. E pode ainda, auxiliar na busca de conhecimento para apoiar a
elaboração de novos projetos.
Independentemente do tipo de grupo low-end users ou high-end user considerado por
Ramesh (1998), na rastreabilidade, a implementação do léxico poderá ajudar na compreensão
do problema ou requisito que está sendo rastreado. Além disso, pode identificar a formação ou
transformação do requisito e identificar os conceitos que estão vinculados a cada elemento da
rastreabilidade.
A rastreabilidade, que mostra a formação e a razão em todos os sentidos (high-end
user), ajuda a equipe de desenvolvimento a compreender e a formar uma opinião sobre todo o
conjunto de artefatos desenvolvidos. Nesse caso, o conhecimento é tratado em um aspecto mais
abrangente, o que permite ao integrante da equipe obter os conceitos já existentes e ainda a
formar os seus próprios “conceitos” sobre o processo utilizado e sobre o produto em
desenvolvimento.
A figura 21 resume a idéia da manipulação do conhecimento com base na
rastreabilidade e no léxico. O engenheiro de software no momento de pesquisar a
rastreabilidade de qualquer elemento deve ter à sua disposição os relacionamentos existentes
entre os artefatos, atividades do processo e atividades de gestão. Vinculado, a cada elemento,
84
ou seja, a cada léxico existe um conceito. Esse conceito é apresentado junto com a
rasteabilidade para ajudar na disseminação do conhecimento. Essa disseminação irá apoiar ao
engenheiro de software na tomada de decisões sobre o projeto.
Figura 21 – Caso de uso da rastreabilidade baseada em léxico
6.1 Formatação Básica da Rastreabilidade baseada em Léxico
A rastreabilidade corresponde à ligação entre dois ou mais elementos. A rastreabilidade
baseada no léxico estendido corresponde à ligação entre os diversos elementos do léxico de
modo a identificar os relacionamentos entre sujeito, verbo, objeto e estado (figura 22).
85
Figura 22 – Rastreabilidade baseada no Léxico Estendido
O sujeito e o objeto, normalmente, são os elementos representados pelas atividades de
processo e gestão e pelos artefatos produzidos. Exemplos desses elementos podem ser vistos
nos modelos de domínio do RUP (figura 7) e do PMI (figura 8) apresentados no capitulo 2
seção 2.7. O sujeito é relacionado a outro léxico o qual atua como objeto e, esse relacionamento
é obtido por meio da identificação do verbo que os correlaciona. Essa identificação pode ajudar
na interpretação e na compreensão da rastreabilidade, uma vez que ela identifica o tipo de ação
existente entre os dois elementos. O relacionamento entre os léxicos pode ser complementado
com informações existentes no estado.
O estado é caracterizado por ser um complemento. Esse complemento também pode ser
um léxico que corresponde a uma caracterização do relacionamento existente entre o sujeito e o
objeto. Esse complemento é importante para completar as informações essenciais, para que haja
o entendimento e a compreensão necessários à rastreabilidade entre o sujeito e o objeto.
O complemento pode ser especializado em situação, dados complementares e condição.
Na figura 22, a especialização está representada como incompleta, pois existe a possibilidade de
inclusão de novas especializações importantes na manipulação do conhecimento. Por exemplo,
uma empresa poderá optar pela especialização de uma ação também. Ou seja, a empresa deseja
vincular à rastreabilidade a ação que a equipe deve executar, quando ocorrer aquele tipo de
ligação existente entre os dois léxicos.
O mais importante é que se possa criar as condições necessárias para a manipulação do
conhecimento do processo de software, respeitando as características da empresa e das pessoas
envolvidas no mesmo. Visto que, o conhecimento está relacionado à experiência anterior das
86
pessoas, acredita-se que, quanto mais completa for a rastreabilidade, maior será o conhecimento
gerado, auxiliando como suporte na tomada de decisões.
No estudo efetuado, utiliza-se o complemento nas seguintes situações para a
manipulação do conhecimento:
1) Situação: o complemento situação possibilita completar a informação da rastreabilidade
entre os dois léxicos com algum critério de execução. Como por exemplo:
A meta X é suportada pelo Requisito Y que está totalmente concluído.
• Léxico sujeito: Meta X
• Verbo de ligação1: é suportado
• Léxico objeto: Requisito Y
• Complemento: Totalmente concluído
O complemento totalmente concluído foi obtido a partir do registro da situação do
desenvolvimento do requisito. Esse tipo de complemento normalmente apóia a busca de
conhecimento do processo do desenvolvimento.
2) Condição: esse complemento indica uma condição para que o relacionamento entre os dois
léxicos ocorra. Como por exemplo:
A DIRF (Declaração de Imposto de Renda Pessoa Física) deverá ser gerada a partir
dos atendimentos que estiverem na condição de repassado.
1. Léxico sujeito: DIRF
2. Verbo de ligação: é gerada
3. Léxico objeto: atendimentos
4. Complemento: repassados
1 Verbo de Ligação: nessa dissertação o conceito de verbo de ligação está relacionado ao fato de ligar o sujeito ao objeto e não na concepção da gramática normativa brasileira, tais como ser, estar, permanecer, ficar.
87
O complemento repassados é uma condição que pode existir para atendimentos
realizados pelo médico. No caso apresentado, a DIRF somente será gerada com os valores
desses atendimentos. Os demais, atendimentos, não podem fazer parte dos valores a serem
informados na DIRF. Essas condições correspondem a uma máquina de estado (diagrama de
estado da UML), relativo à classe atendimentos. Esse tipo de complemento normalmente apóia
a busca do conhecimento relativo às regras de negócio do software que está sendo
desenvolvido.
3) Dados Complementares: esse complemento possibilita completar a informação da
rastreabilidade com dados gerais que não foram necessários no mapeamento da
rastreabilidade pela empresa. Por exemplo:
O Requisito X foi definido pelo Stakeholder Y conforme descrito no documento Z.
• Léxico sujeito: Requisito X
• Verbo de ligação: foi definido
• Léxico objeto: Stakeholders Y
• Complemento: Documento Z
O complemento Documento Z é um documento disponível para download, e se encontra
na apresentação do relacionamento entre os dois léxicos. Esse documento tem as informações
complementares relativas à definição do requisito X pelo Stakeholder Y, importantes para a
geração do conhecimento por parte do engenheiro de software. Esse tipo de complemento
normalmente apóia a busca de conhecimento mais detalhado sobre um determinado elemento
do léxico que não foi contemplado na rastreabilidade.
A vantagem da rastreabilidade baseada em léxico está na forma da apresentação, pois a
mesma se assemelha:
a) Ao formato natural da linguagem escrita de comunicação utilizada pelas pessoas;
b) Ao formato das técnicas de trabalho, desenvolvido pelo engenheiro de software.
O engenheiro de software, através das técnicas de modelagem, relaciona os elementos
existentes no domínio do problema com os elementos existentes no domínio da solução e,
ainda, relaciona os elementos dentro do domínio do problema e dentro do domínio da solução.
88
O engenheiro de software busca com esses relacionamentos construir um projeto de um produto
de software
6.2 Apresentação da Rastreabilidade
A utilização da rastreabilidade, como fonte de conhecimento, está relacionada
diretamente com a forma da sua apresentação, ou seja, sua visualização. É importante que a
apresentação da rastreabilidade tenha uma navegação fácil e rápida, de forma a obter o
conhecimento necessário. Dentro do propósito do Projeto Discovery (PIETROBON, 2007), este
trabalho se propõe a apresentar uma abordagem que facilite esta visualização. Segundo
Nascimento e Ferreira (2005), os objetivos da visualização são “ampliar nossas atividades
cognitivas, melhorando o entendimento e aproveitamento do que é exposto e levando à
aquisição e solidificação do conhecimento”.
A sugestão de trabalhar em forma hierárquica, ou seja, visualizar em forma de árvore, é
devido à sua simplicidade, facilidade de implementação e de domínio publico. Existem classes
disponíveis nas mais diversas linguagens de programação, o que agiliza o processo de
construção da ferramenta. E, ainda, não existe a necessidade de efetuar um treinamento, visto
que, as pessoas estão acostumadas com os conceitos e com a sua navegação, a partir da sua
utilização em outros softwares. Cada nó da árvore representa o sujeito e/ou objeto. A relação
existente entre o sujeito e objeto corresponde ao verbo. Cada nó pode ser representado por um
ícone, com o objetivo de facilitar a identificação do léxico. Dessa forma, acredita-se que a
visualização proposta poderá atingir os dois atributos apresentados por Mackinlay, (1986) (aput
Nascimento e Ferreira, 2005 p.10). Esses atributos consistem em: expressividade (mostrar os
dados de interesse do usuário) e efetividade (facilidade de compreender os dados apresentados).
Segundo Sommerville,
Existem muitas relações entre requisitos e outros requisitos e entre os requisitos e o projeto de sistema. Há também elos entre os requisitos e as razões básicas da proposição desses requisitos. Quando são propostas modificações, é preciso verificar o impacto dessas mudanças sobre outros requisitos e o projeto de sistema. A facilidade de rastreamento é uma propriedade geral de uma especificação de requisito, que reflete a facilidade de se encontrar requisitos relacionados. Existem três tipos de informações
89
sobre a facilidade de rastreamento, que podem ser mantidas: informações sobre a facilidade de rastreamento de origem que vinculam os requisitos aos stakeholders que propuseram esses requisitos; informações sobre a facilidade de rastreamento de requisitos que vinculam requisitos dependentes dentro do seu respectivo documento, essa informação é utilizada para avaliar quantos requisitos provavelmente serão afetados e a extensão das mudanças; informações sobre a facilidade de rastreamento de projeto que vinculam os requisitos aos módulos de projeto em que esses requisitos são implementados, para a avaliação do impacto das mudanças.” (SOMMERVILLE, 2003, p. 120).
Gotel e Finkelstein (1994), trabalham a rastreabilidade fundamentada nos seguintes
itens: contribuição, contribuidor, estrutura social, relação de contribuição, estrutura da
contribuição e rastreamento baseado em contribuição. Ramesh e Jarke (2001) apresentam um
meta modelo que divide a rastreabilidade em três dimensões: as fontes, os interessados e os
objetos de produto ou do processo. Esses autores agrupam os relacionamentos existentes entre
as dimensões em dois grupos. Um relacionado ao produto e o outro ao processo. Os autores
Toranzo, Castro e Mello, (2002) classificam a rastreabilidade em quatro níveis: ambiental,
organizacional, gerencial e desenvolvido. Quanto aos relacionamentos existentes entre os
elementos, o autor aponta os seguintes: satisfação, recurso, responsabilidade, representação,
alocado e agregação.
Entende-se que essas divisões reconhecidas por esses autores representam uma visão
diferente dos relacionamentos entre os elementos. A forma como será apresentado o resultado
para o usuário da rastreabilidade, nesses autores, também é diferente. Por outro lado, acredita-se
que todas elas apresentam a possibilidade de efetuar a manipulação do conhecimento, uma vez
que tratam dos principais elementos do processo de desenvolvimento integrados na
rastreabilidade: gestão, processo e artefatos.
A manipulação do conhecimento pode estar diretamente relacionada com a capacidade
da rastreabilidade transmitir informações. A visualização dos elementos rastreados deve
considerar os objetivos e levar o usuário a rastrear um determinado elemento para adquirir
algum tipo de conhecimento. Os objetivos do usuário consistem na busca de conhecimento para
realizar alguma atividade ou para ajudar na tomada de alguma decisão. Para facilitar e apoiar
essa busca do conhecimento, a rastreabilidade tem que ser vista sob a ótica da
apresentação/visualização que será feita junto ao usuário.
A visão da apresentação da rastreabilidade busca facilitar a aquisição do conhecimento
por parte do usuário e acredita-se que as visões apresentadas pelos autores Gotel e Finkelstein
(1994), Ramesh e Jarke (2001) e Toranzo, Castro e Mello, (2002) estão incorporadas dentro da
90
forma, aqui, de apresentar a rastreabilidade. A apresentação da rastreabilidade é dividida em
dois itens: formação e visão. Cada um tem uma função específica na busca do conhecimento
por parte do usuário.
Quanto à formação da apresentação da rastreabilidade, essa foi subdividida em:
composição, formatação, impacto e tempo, para qualquer elemento rastreável. Essa formação
da apresentação busca incorporar os principais relacionamentos existentes entre os elementos
dentro da rastreabilidade. A análise da rastreabilidade desses elementos consiste na fonte de
informação que o usuário necessita para a busca do conhecimento, capaz de agilizar o seu
processo de adquirir experiência e de tomada de decisão.
Com o objetivo de separar o conhecimento de acordo com a sua origem, a visualização
proposta neste trabalho, dessa formação da rastreabilidade, foi dividida em três visões: visão
técnica, visão de processo e visão de gestão. Essas visões podem ser trabalhadas pelo usuário
em um formato de combinação entre os elementos técnicos, os elementos de processo e os
elementos de gestão. Ou seja, esses elementos da formação da rastreabilidade podem ser vistos
de modo agrupado ou individualmente, de acordo com a necessidade do usuário da
rastreabilidade. Essa combinação é importante para aliar a rastreabilidade aos objetivos que o
usuário tem na aquisição do conhecimento específico junto à sua função exercida no projeto.
Essa separação, também, diminui o conjunto de léxicos a serem apresentados para a busca do
conhecimento na rastreabilidade baseada em léxico. O controle dessas combinações de visões e,
por conseqüência, do número de léxicos apresentados simultaneamente, também, pode agilizar
o processo do conhecimento efetuado pelo usuário.
Nas seções seguintes são descritas as divisões apresentadas nessa seção correspondentes
à composição, formatação, impacto, tempo e das visões: técnicas, processo e gestão. Para cada
uma, mostra-se como é a visualização na estrutura hierárquica.
6.2.1 Composição
A composição representa os relacionamentos existentes diretamente entre os léxicos,
que expressam que um léxico sujeito é constituído por vários léxicos objetos. Esses
relacionamentos e esses léxicos objetos fazem parte diretamente da constituição do léxico
91
sujeito, seja a rastreabilidade anterior à sua transformação (pré-requisito), seja a rastreabilidade
posterior à sua transformação (pós-requisito).
A visualização conjunta da composição, em um mesmo nível hierárquico, pode permitir
ao usuário da rastreabilidade uma maior agilidade no processo de conhecer, pois são
apresentados todos os elementos que constituem o item analisado.
A figura 23 exemplifica a apresentação da composição. De acordo com a figura, o
requisito Gerar Fatura tem quatro composições: é narrada por, foi realizada, é formada por e
foi autorizado. Essas quatro composições são representadas pelos verbos de ligação existentes
entre o sujeito em análise e os objetos. No exemplo apresentado, o sujeito em análise é o
Requisito – Gerar Fatura, o qual é narrado pelas histórias Selecionar Espelhos e Visualizar
Valores. Para o desenvolvimento desse requisito foram necessárias as atividades de Elicitação,
Modelagem, Programação e Teste. Esse desenvolvimento foi autorizado pelo Ator Fernando e
é formado pela classe de interface intGerarFatura, pela classe de controle contGeracaoFatura e
pelas classes entidades Fatura, Atendimento, Convênio, Espelho e Procedimento.
.
Figura 23 – Apresentação da Composição da Rastreabilidade
A composição pode variar de acordo com o tipo de léxico representado pelo léxico
sujeito. Mas, normalmente serão representados por questões como as listadas a seguir:
• Documentos utilizados para o seu entendimento;
92
• Atividades realizadas para a sua transformação;
• Artefatos produzidos pelas atividades que estão diretamente ligados ao léxico analisado;
• Relação existente entre o que foi planejado e o que foi executado;
• Decisões necessárias para a execução das atividades que representam as lições
aprendidas para o léxico analisado;
• Modelos produzidos que representam o léxico analisado;
• Classes utilizadas para a sua transformação em um produto de software;
• Métodos implementados às necessidades das classes;
• Tabelas de banco de dados, cujo objetivo é mapear as classes entidade modeladas.
6.2.2 Formatação
A rastreabilidade deve ser apresentada em duas formatações simultâneas, ou seja, a
voz ativa e a voz passiva. A voz ativa indica a composição do artefato na hierarquia direta, ou
seja, indica que um léxico L1 é constituído de um léxico L0. Ela representa o processo de
relacionamento no formato natural, ou seja, a composição natural do léxico analisado. A voz
passiva representa o processo de relacionamento inverso da composição, ou seja, indica por
quem o léxico analisado é constituído. A análise simultânea destas duas formatações ajuda na
agilização da compreensão do elemento que está sendo rastreado.
A figura 24 apresenta a formatação da rastreabilidade simultânea na voz ativa e voz
passiva. No exemplo apresentado, a História - Visualizar Valores - é formada pelas classes
atendimento, espelho, intGerarFatura e Procedimento. Simultaneamente, para ajudar na
compreensão do item analisado, é apresentada a voz passiva. A voz passiva indica que o sujeito
História Visualizar Valores é uma narrativa do requisito Gerar Fatura .
93
Figura 24 – Formatação da rastreabilidade na voz ativa e voz passiva
6.2.3 Impacto
A análise do item impacto consiste na possibilidade de se conhecer a composição de
cada léxico objeto relacionado ao léxico sujeito analisado. O impacto é apresentado em forma
de árvore na rastreabilidade. Essa análise permite avaliar o impacto a partir do entendimento da
constituição de qual ou quais elementos poderão ser afetados em uma possível mudança. Esse
entendimento é obtido a partir da identificação da rastreabilidade do elemento ligado
diretamente ao item analisado. Ou seja, o impacto é apresentado a partir da navegação em
árvore de toda a rastreabilidade de todos os elementos que constitui o elemento analisado.
A figura 25 apresenta um exemplo da análise de impacto na Voz Ativa do léxico
Meta–Atender bem o médico. Ela é composta pelo relacionamento é suportado por que está
ligado diretamente com os requisitos Calcular Impostos, Digitar Rapidamente e Gerar o
Espelho. Com a apresentação do impacto é possível navegar em cada um desses itens,
verificando a sua composição. No exemplo apresentado o Requisito – Digitar Rapidamente é
composto pelos relacionamentos é narrada por e foi autorizado. No próximo nível de impacto,
o exemplo mostra a constituição da História Digitar Rapidamente. Ela é composta pelo
relacionamento é formada por. Este relacionamento está ligado às classes Atendimento e
Procedimento. Assim, é possível verificar o impacto de qualquer mudança na meta Atender
bem o médico.
94
Figura 25 – Análise de Impacto na Voz Ativa
A apresentação do impacto também deve ser feita na Voz Passiva. Na figura 26, é
apresentada uma análise da rastreabilidade de impacto de alteração da classe atendimento. No
exemplo, é apresentado o possível impacto até a Meta – Atender bem o médico.
A análise de impacto indica que qualquer alteração na classe atendimento poderá
afetar a história Digitar Rapidamente, e que, por conseqüência, a composição poderá afetar os
requisitos Gerar Espelho e Digitar Rapidamente. Neste último caso, ainda poderá afetar a meta
Atender bem o médico.
Figura 26 – Análise de Impacto na Voz Passiva
95
6.2.4 Tempo
A rastreabilidade deverá ser apresentada de forma temporal. Ela deve permitir a visão
da composição, da formatação e do impacto em um determinado período de tempo. A
comparação temporal da rastreabilidade pode ajudar a fortalecer o conhecimento adquirido.
Esse fortalecimento ocorre através da aquisição da experiência que existe nas alterações dos
léxicos e dos relacionamentos da rastreabilidade. Essas alterações ocorrem durante todo o ciclo
de vida do projeto e do produto e são registradas através da manutenção dos artefatos e da
atualização da base de conhecimento. A experiência é adquirida a partir do momento em que se
pode comparar um léxico no tempo. Essa comparação poderá ajudar a compreender a situação
atual de um determinado léxico identificando as decisões tomadas no decorrer do tempo.
Toda alteração da base de conhecimento deverá ser atualizada a partir de uma data de
vigência. Qualquer alteração em um artefato, por exemplo, seja inclusão de um novo método,
seja uma alteração de um método atual, deverá ser atualizada na base de conhecimento da
rastreabilidade com a data da alteração. Se a alteração da base for uma atualização de um léxico
já existente, deverá ser criado um novo registro de rastreabilidade e o registro anterior deverá
ter a sua data final atualizada com a data da alteração menos um dia. Dessa forma, garante-se a
formação temporal da base de conhecimento.
É de suma importância ter-se a condição de navegar nas decisões de projeto em um
determinado período, bem como, de promover para a gerência de alteração de requisitos a
possibilidade de verificar quais foram as alterações de um determinado léxico (artefato). Essa
temporalidade ajuda na rastreabilidade vertical, ou seja, na identificação das versões da base de
conhecimento e na comparação entre os léxicos da mesma base.
A figura 27 corresponde a uma parte da interface da consulta da rastreabilidade baseada
em léxico. O tempo é trabalhado de acordo com a informação da data e da lista apresentada nos
histórico de alterações. O resultado da pesquisa corresponde às informações existentes no
banco de conhecimento de acordo com a data informada. Na pasta histórico de alterações sâo
apresentadas todas as alterações registradas na base de conhecimento para o léxico pesquisado.
Dessa forma, é possível efetuar as comparações necessárias para se obter o entendimento,
relativo às alterações ocorridas para o léxico durante o seu ciclo de vida.
96
Figura 27 - Apresentação do Tempo e da Visão
6.2.5 Visão
O volume de informações trabalhadas na rastreabilidade é muito grande. Essas
informações têm o propósito de ajudar os desenvolvedores a tomarem decisões sobre o projeto.
As decisões são tomadas de acordo com o conhecimento adquirido. Para ajudar na aquisição do
conhecimento, a apresentação da rastreabilidade deverá seguir a combinação de três visões:
técnica, de processo e de gestão.
A divisão dessas visões é apresentada como argumento de pesquisa e busca do
conhecimento na tela de consulta da rastreabilidade da ferramenta desenvolvida (figura 27). Ela
é importante para agilizar a busca do conhecimento em relação à aquisição dos objetivos e em
relação ao que se deseja pesquisar e o conhecimento que se quer obter.
a) Visão técnica.
A visão técnica corresponde, na rastreabilidade dos léxicos, aos modelos criados para a
representação do mundo real e aos artefatos que representam a conversão dos requisitos em
algo executável. A visão técnica reflete o domínio da aplicação em termos de solução de
software.
97
b) Visão de processo.
Essa visão corresponde à identificação das atividades definidas no processo para a
elaboração de cada léxico da visão técnica.
c) Visão de Gestão
Essa visão corresponde à identificação das lições aprendidas, dos objetivos e motivos da
tomada de decisão para cada atividade desenvolvida na visão do processo. A visão de gestão se
detém na comparação entre o previsto e o realizado relacionadas às previsões de tempo, custo e
resultado do projeto.
As visões são trabalhadas na rastreabilidade baseada em léxico de acordo com a seleção
a ser efetuada no momento da realização da pesquisa. Essa seleção poderá ser de uma ou mais
visões de acordo com a figura 27.
6.3 – Processo de Formação da Rastreabilidade
Sayão e Leite (2005) descrevem o processo de formação da rastreabilidade composto
das seguintes etapas: definição, registro dos elos, recuperação de entidades associadas e
evolução dos elos. Na rastreabilidade baseada no léxico, utiliza-se o processo de formação da
seguinte forma:
• Definição: envolve definir todos os léxicos que serão rastreáveis. Nessa definição, é
importante separar os léxicos internos dos externos. Os léxicos internos se referem à
tecnologia, ao processo e à gestão. Eles são controlados internamente pela empresa
desenvolvedora. Os léxicos externos se referem aos requisitos e à transformação dos
mesmos em artefatos, e são controlados pelos usuários e pelos engenheiros de
requisitos. É importante separar os léxicos externos e internos devido ao formato
diferenciado da aquisição e da atualização do banco de conhecimento. Os léxicos
internos são obtidos a partir da definição da tecnologia, do processo a ser utilizado e da
característica de gestão da empresa. Esses léxicos, normalmente, são padronizados e
mudam de acordo com o tipo de projeto. São mais fáceis de serem reusados. A sua base
98
de conhecimento é adquirida em treinamentos feitos pelos engenheiros de software. Os
léxicos externos são obtidos a partir das atividades de elicitação de requisitos e do
entendimento do domínio do projeto. O conhecimento é adquirido gradualmente durante
a elaboração do produto e dos retornos obtidos nas iterações do processo de
desenvolvimento;
• Registro dos Elos: envolve a definição dos tipos de relacionamentos existentes entre os
léxicos e a definição dos seus conceitos. Nos léxicos internos, os tipos de
relacionamentos e conceitos estarão apoiados no processo de desenvolvimento definido
pela empresa. É obtido a partir de definições de projetos anteriores, reaproveitando-se o
processo de projetos similares. Nos léxicos externos, a formação dos elos, ou
relacionamentos, irá acontecer durante o processo de desenvolvimento. Esses léxicos
envolvem o registro da composição de todos os artefatos. Os conceitos relativos a esses
léxicos deverão ser atualizados sempre que o contexto do conceito principal do léxico
mudar em relação a sua utilização;
• Recuperação: é apresentada na ferramenta através da apresentação da rastreabilidade
baseada no léxico;
• Evolução: são os aperfeiçoamentos feitos na base de conhecimento a partir da análise de
manipulação do conhecimento e da parametrização para organizar futuros
relacionamentos entre os léxicos.
O processo de geração do conhecimento, necessário ao desenvolvimento de software,
inicia-se com o planejamento das atividades que devem ser seguidas durante a confecção do
software. Nessa fase, identificam-se os léxicos, relativos às atividades de gestão e do processo,
e as estruturas de relacionamentos que existirão entre os léxicos. As estruturas de
relacionamento devem ser compostas de acordo com o contexto e a visão desejada para a gestão
do conhecimento.
A execução das atividades, relacionadas com a geração dos artefatos, será a base para a
transformação das necessidades do usuário em um produto executável pelo computador. O
registro dessas atividades formará o conhecimento dos desenvolvedores. Esse registro é feito a
partir dos léxicos e das estruturas de relacionamento proposto.
A parte final da geração do conhecimento corresponde ao registro das lições aprendidas
durante todo o desenvolvimento, ou seja, as lições aprendidas na execução das atividades
(gestão) e as lições aprendidas na construção de algum artefato de software.
O conhecimento, conforme é concebido neste trabalho, divide-se em:
99
• Conhecimento externo: corresponde à busca do conhecimento a ser desenvolvido,
mediado pelo usuário;
• Conhecimento interno: corresponde ao registro de todos os elementos produzidos
durante a confecção do software.
A rastreabilidade do conhecimento externo inicia-se com a modelagem de metas. O
próprio modelo sugerido por Lamsweerde (2001) apresenta a rastreabilidade dos requisitos em
relação às metas que o produto deverá atingir. Dessa forma, cada meta ou cada requisito será
considerado um léxico e o relacionamento de suporte, obtido a partir dos refinamentos,
formarão o conhecimento necessário ao desenvolvimento.
A rastreabilidade do conhecimento interno corresponde ao trabalho de registrar a
rastreabilidade dos requisitos, modelados a partir de metas, com todas as atividades realizadas e
artefatos produzidos. Essa rastreabilidade deve ser feita de modo a registrar a transformação do
requisito em algo executável e registrar as decisões tomadas durante a realização das atividades.
Esse registro corresponde à atualização do banco de conhecimento.
O sucesso da manipulação do conhecimento, a partir da rastreabilidade, está na
capacidade de se manter o banco de conhecimento atualizado. Esta atualização deverá ocorrer
no momento em que a atividade manipuladora dos léxicos estiver sendo executada. Um
conhecimento gerado e não atualizado, ou atualizado fora do tempo, poderá perder o sentido
para uma determinada pessoa que tem a necessidade de usar o conhecimento armazenado.
Nesse caso, é necessário desenvolver programas que façam a manutenção do banco de
conhecimento no momento em que está sendo gerado. As atividades consideradas relevantes
para a atualização do banco são:
a) A análise da história: a história corresponde à necessidade do usuário relativo a um item do
desenvolvimento. Nessa análise são gerados os léxicos e os relacionamentos relativos ao
domínio do problema;
b) A modelagem nas ferramentas utilizadas para o desenvolvimento: o engenheiro de
requisitos utiliza ferramentas para modelar o projeto. Dentre essas ferramentas pode-se
citar:
• Ferramenta de banco de dados: deve ler a estrutura do banco de dados e atualizar o
banco de conhecimento com os dados das tabelas, campos e formatos. No momento
da atualização deverá registrar a data da alteração e quem a fez, através do
relacionamento entre o tipo de léxico “tabela” e tipo de léxico “usuário”;
• Ferramenta de Modelagem UML: normalmente as ferramentas de modelagem UML
fazem exportação em XML. Esses arquivos XML são entradas de dados para a
100
atualização dos modelos UML. No caso, o modelo de classe de software foi o único
utilizado para a atualização do banco de conhecimento. O modelo de classe
representa de forma estática o domínio do problema apresentando os léxicos que
devem ser relacionados para a estruturação do conhecimento relativo ao software.
Os modelos dinâmicos, tais como, diagrama de estado e diagrama de interação não
são mantidos na mesma intensidade do diagrama de classe. O diagrama de estado
representa uma análise da classe efetuada, normalmente, no inicio do projeto e é
facilmente atualizado na própria ferramenta de rastreabilidade. O Diagrama de
seqüência é uma representação da execução da história; e a análise da história já foi
contemplada na ferramenta, conforme item a;
c) Cadastramento da ferramenta de rastreabilidade: os léxicos e os relacionamentos
identificados durante a fase de planejamento e de execução das atividades devem ser
cadastrados na ferramenta;
d) Identificação das tabelas descritivas: a partir da identificação e alteração do conteúdo das
tabelas descritivas do sistema, o léxico deverá ser atualizado. As tabelas descritivas
normalmente correspondem a um estado, ou a uma situação que determinadas classes
podem assumir durante o seu ciclo de vida no sistema. A sua atualização é difícil devido ao
fato de que a responsabilidade de atualização é do usuário do sistema e está fora do controle
da empresa desenvolvedora. Normalmente, são identificadas na análise de novas histórias
e/ou nas mudanças de requisitos;
e) Integração com outros sistemas: normalmente existem sistemas que apóiam a gestão do
processo de desenvolvimento de software. A equipe que trabalha nesse processo tem que
efetuar a atualização dos resultados de suas atividades. Esse controle representa fontes de
rastreabilidade para a atualização do banco de conhecimento, uma vez que esses sistemas
registram a realização das atividades em relação à produção dos artefatos.
101
Figura 28 – Análise de formação do léxico
A figura 28 apresenta o diagrama de domínio que faz parte da formação do
conhecimento baseado na rastreabilidade. As classes representam os léxicos que devem ser
mapeados. Os relacionamentos entre as classes representam os elos entre os léxicos. Os léxicos
e os seus conceitos deverão ser obtidos a partir dos elementos do desenvolvimento do sistema,
tais como visões técnicas, processo e gestão.
A visão técnica é obtida através dos artefatos. Os artefatos podem ser especializados nos
modelos e nos documentos que representarão o domínio do problema. O domínio do problema
corresponde ao glossário do sistema. Os conceitos dos léxicos são fornecidos pelos usuários
durante a atividade de elicitação de requisitos e pelas técnicas de modelagem do projeto.
A visão do processo é obtida a partir das atividades que pertencem a um ciclo de vida. O
ciclo de vida corresponde ao processo de desenvolvimento definido pela empresa. Na definição
desse processo, a empresa estabelece as atividades e por conseqüência os conceitos relativos à
cada atividade. As atividades são desenvolvidas por pessoas.
102
A visão de gestão corresponde às decisões que devem ser tomadas pelas pessoas durante
a execução da atividade para a geração do artefato. A ligação das decisões com as atividades e
os artefatos corresponde à gestão do conhecimento realizado pela empresa. As atividades têm
estimativas que correspondem às decisões de planejamento do projeto.
6.4 IMPLEMENTAÇÃO DA SOLUÇÃO
A implementação da solução da rastreabildiade baseada em léxico, consistiu na
modelagem de um banco de conhecimento e no desenvolvimento de uma ferramenta capaz de
manipular este banco, atingindo os objetivos da apresentação definida na seção 6.2.
6.4.1 Banco de Conhecimento
O banco de conhecimento consiste no registro e na manipulação dos léxicos e seus
relacionamentos baseado na construção de sujeito, verbo, objeto e estado. A sua modelagem
deve implementar o formato de apresentação discutido no capítulo 5.
A figura 29 apresenta o diagrama de domínio relativo ao modelo do banco de
conhecimento implementado na ferramenta de rastreabilidade baseada em léxico. As principais
classes para a manipulação do conhecimento são: Léxico, TipoLexico, LéxicoTipo, Conceito,
Conhecimento, Complemento, Visão e Vigência. A classe Léxico representa qualquer elemento
relativo ao desenvolvimento de software. Essa classe consiste em uma entrada lexical que tem a
ela associada uma descrição ou conceito. Esses conceitos representam informações sobre um
determinado domínio. A classe TipoLexico representa um agrupamento da classe léxico de
forma que se possa representar as variações que um determinado léxico pode ter, de acordo
com a sua utilização ou contexto. Essas variações para um mesmo léxico estão representadas na
classe LexicoTipo. Essa classe representa o relacionamento entre as classes Léxico e
TipoLéxico. A classe LexicoTipo pode ter a ela associada as variações dos conceitos relativos a
classe Léxico. Os conceitos são representados pela classe Conceito. Essa classe pode ser
especializada nas subclasses conceitoLexico e ConceitoLexicoTipo. Esse conjunto de classes e
103
subclasses representa o dicionário ou glossário utilizado pelo domínio do software que está
sendo construído de acordo com o contexto utilizado.
A classe Conhecimento consiste na representação do relacionamento entre sujeito, verbo
e objeto. O sujeito e o objeto são obtidos a partir da classe LexicoTipo. Essa classe irá fornecer
tanto o sujeito, quanto o objeto no relacionamento da rastreabilidade. A classe Léxico sem a sua
contextualização não formará nenhum relacionamento na rastreabilidade baseada no léxico
sendo, então, sempre necessário identificar o contexto em que o léxico está sendo utilizado. A
classe Conhecimento está relacionada com a classe Complemento. A classe Complemento
corresponde ao estado e é especializada nas subclasses: situação, condição e
dadosComplementares.
A classe Visão agrupa o conhecimento gerado de forma que o mesmo possa ser
recuperado de acordo com os objetivos desejados pelo engenheiro de software. Essa classe
pode ser especializada nas subclasses: técnica, processo e gestão.
A classe Vigência permite a geração histórica do conhecimento, registrando todas as
suas atualizações ocorridas durante o desenvolvimento do projeto. É importante para viabilizar
a pesquisa histórica de todas as alterações existentes no banco de conhecimento, a partir das
atividades efetuadas pela equipe de desenvolvimento.
104
Figura 29 – Modelo de Domínio da Rastreabilidade baseado no léxico
6.4.2 A Ferramenta Gestão de Requisitos Baseada em Rastreabilidade e Léxico
A base de conhecimento deve ser manipulada a partir de uma ferramenta (GRE_RL –
Gestão de Requisitos Baseada em Rastreabilidade), projetada para facilitar a manipulação do
conhecimento pelos integrantes da equipe. A figura 30 representa os principais pacotes que
foram implementados para a manipulação da rastreabilidade. Os principais pacotes são o léxico,
a rastreabilidade e a manutenção. O pacote léxico tem como objetivo fazer a manipulação dos
dados básicos do cadastro da rastreabilidade, bem como o de atualizar as composições da
rastreabilidade que não serão obtidas a partir da manutenção automática e da análise da história.
O pacote rastreabilidade tem por objetivo fazer a manipulação da base de conhecimento. Nesse
pacote será possível fazer a análise da rastreabilidade de qualquer léxico e a análise da
formatação da história. O pacote de manutenção tem por objetivo fazer a integração das
105
ferramentas utilizadas pela empresa com a base de conhecimento da rastreabilidade. A base do
conhecimento é mantida a partir da atualização do diagrama de classe de software,
desenvolvido com a UML, e a partir da manutenção das tabelas armazenadas no banco de
dados e utilizadas pelo software.
Figura 30 – Principais pacotes da Ferramenta da Rastreabilidade
6.4.2.1 Análise da Rastreabilidade
A análise da rastreabilidade tem por objetivo transmitir o conhecimento armazenado no
banco de conhecimento. A interface da análise da rastreabilidade foi elaborada para que o
usuário possa obter todas as informações rapidamente, garantindo, desse modo, a absorção do
conhecimento.
A figura 31 apresenta a interface da análise da rastreabilidade para a manipulação do
conhecimento. Essa interface é composta por várias outras interfaces. A primeira delas tem por
objetivo selecionar um determinado léxico para se efetuar a análise. A seleção pode ser feita
indicando o tipo de léxico e/ou a descrição do léxico. De acordo com a seleção efetuada será
106
apresentada uma lista posicionada à direita na tela. A partir da formação dessa lista deverá ser
selecionado um item de léxico para efetuar a análise da rastreabilidade.
A interface de análise é dividida em Voz Ativa, Voz Passiva, Histórico de Alterações,
Conceitos, Léxicos Consultados e Download. O conteúdo das interfaces é preenchido de acordo
com a data da pesquisa e visão desejada. A interface Voz Ativa lista a rastreabilidade da
composição de forma direta e, a pasta Voz Passiva apresenta a rastreabilidade da composição de
forma inversa. A interface Histórico de Alterações apresenta todas as alterações efetuadas para
o léxico que está sendo analisado. A interface Conceito apresenta todos os conceitos que o
léxico tem de acordo com o contexto utilizado. O contexto é indicado para cada ligação do
léxico com o tipo de léxico. A interface Léxico Consultados armazena todos os léxicos
consultados pelo usuário formando uma lista seqüencial das análises efetuadas. Essa interface
permite efetuar a pesquisa a partir da identificação de léxico analisado carregado na lista. Isso
agiliza o processo de consulta e navegação. A pesquisa do léxico pode ser feita clicando em
qualquer léxico das interfaces Voz Ativa, Voz Passiva e Léxico Consultados. A interface
Download apresentada os arquivos disponíveis registrados nos dados complementares do
relacionamento entre os léxicos (figura 31).
Abaixo da interface da seleção da pesquisa do léxico e do resultado da seleção é
apresentado o conceito do léxico. Esse conceito é preenchido toda vez que o mouse é
posicionado em cima de qualquer léxico. O conceito é apresentado de acordo com o tipo de
léxico a que ele estiver relacionado. Se o léxico não tiver um conceito relacionado ao tipo de
léxico, o conceito original do léxico é apresentado (figura 31).
107
Figura 31 – Interface da análise de rastreabilidade para a manipulação do conhecimento
6.4.2.2 Análise da História
A análise da rastreabilidade, citada na seção anterior, permite a manipulação do
conhecimento de forma pontual, ou seja, a partir da seleção de um item do léxico e do estudo
do resultado da sua apresentação em todas as interfaces. Durante o processo de
desenvolvimento, a atividade de elicitação de requisito gera cenários para a elaboração do
projeto. Esses cenários correspondem às histórias que devem ser implementadas para satisfazer
as necessidades do usuário. Portanto, a análise da história consiste em uma importante fonte de
origem para a manipulação do conhecimento.
Na ferramenta, a análise da história consiste na busca e/ou identificação de todos os
léxicos que irão envolver o cenário correspondente à história. O resultado final, apresentado
108
após a análise da história, será uma possível composição de todos os léxicos e relacionamentos
que deverão ser tratados durante as atividades de modelagem e implementação.
A criação e análise dessas histórias, além de ajudar na identificação do conhecimento
armazenado para uma solicitação do usuário, poderão dar suporte para a consulta da base de
conhecimento e para o cadastramento mais rápido dos léxicos. Com relação à consulta da base
de conhecimento, o apoio está no fato de a análise da história buscar todos os léxicos
armazenados e o resultado dessa busca corresponder a uma provável composição. Com o
conceito de análise de impacto, descrito no capítulo 5, e com a navegação em árvore, é possível
analisar a composição de cada léxico participante da análise da história montada. Com relação à
rapidez do cadastramento, a ferramenta de análise permite alterar o resultado apresentado,
incluindo novos léxicos e relacionamentos. Não há necessidade, portanto, de se efetuar um
cadastramento isolado no módulo de léxico, o que levaria a uma atividade mais lenta de
cadastro e não contribuiria para a absorção do conhecimento.
O processo de análise da história consiste em efetuar uma leitura no texto informado e
identificar os léxicos já cadastrados e léxicos ainda inexistentes. A história será considerada
como um léxico sujeito e todos os léxicos encontrados serão considerados como objetos para a
formação da composição. A partir desse conceito será montado o impacto, ou seja, a
identificação de novos sujeitos e objetos na história.
Esse processo de identificação corresponde a:
a) Separar frase por frase.
A classe analisadora da história separa primeiramente todas as frases existentes no
cenário. A separação das frases é efetuada pelo ponto final. Após a identificação de cada frase,
essas são adicionadas a uma lista a ser analisada.
b) Analisar a frase.
Em cada frase existente na lista, é efetuada a identificação do sujeito, verbo, objeto e
estado. O processo de identificação do sujeito e objeto consiste em:
• Identificação do sujeito e objeto efetuada pela antecedência de elemento
identificador. O elemento identificador pode ser representado por um artigo a, o,
as, os, um, uns, uma, umas, ou ainda pelas preposições pelo, pela, pelos, pelas.
Esses artigos e preposições devem ser cadastrados na ferramenta. Isso é
109
necessário para flexibilizar e ajudar na identificação do sujeito e objeto. Os
usuários têm formas diferentes de expressar suas idéias. No decorrer do
desenvolvimento, ou o usuário é orientado a escrever as suas histórias em um
formato mais rígido, ou os elementos identificadores são cadastrados para ajudar
na identificação dos sujeitos e objetos;
• Identificação do sujeito a partir da primeira palavra da frase. Caso a primeira
palavra não corresponda a um elemento identificador e não tenha sido
identificado nenhum sujeito para a frase, a primeira palavra será considerada o
sujeito da frase. Não foi implementada a possibilidade de identificação de
sujeitos compostos;
• Identificação do sujeito e objeto a partir da pesquisa no banco de conhecimento.
Uma outra forma de identificar o sujeito e o objeto é a busca na base de
conhecimento dos léxicos já cadastrados. Por exemplo: se na análise da história
foi identificado o léxico Atendimento, a ferramenta busca no banco de dados a
existência desse léxico. Caso exista o léxico, então ele será considerado um
sujeito ou um objeto. Se o léxico aparecer no início da frase, será considerado
um sujeito. Se o léxico analisado aparecer após a identificação do sujeito da
frase, esse então, será considerado o objeto;
• Identificação do verbo de ligação. O conteúdo da frase existente entre o sujeito e
o objeto será considerado o verbo de ligação. Esse conteúdo poderá identificar
os métodos que deverão ser implementados. Esse verbo de ligação identificado
não será mapeado diretamente para a análise da história entre o sujeito e o
objeto. O verbo que irá representar o relacionamento entre o sujeito e o objeto
será obtido a partir do cadastro de tipos de relacionamentos efetuados
previamente na ferramenta. Esse cadastro corresponde à identificação dos
possíveis tipos de relacionamentos existentes entre os dois tipos de léxicos
encontrados na análise. Caso não seja possível identificar o verbo, na base de
dados existentes, a relação entre o sujeito e o objeto será cadastrada na análise
como sendo do tipo de formação;
• Alteração do texto original. O texto original é alterado com o acréscimo do
símbolo @ antes do sujeito e do verbo da frase. Além desse acréscimo, todos os
léxicos identificados no banco de conhecimento têm o seu texto transformado
em letras maiúsculas. Isso é importante para destacar a identificação efetuada
pela ferramenta;
110
• Identificação do estado. O estado é identificado como um texto encontrado após
a identificação do objeto e antes do ponto final da frase.
O resultado final da análise da história corresponde ao texto alterado e à apresentação da
possível composição da rastreabilidade de todos os léxicos encontrados. O próximo passo deve
corresponder à análise e validação do resultado apresentado.
A análise e a validação deverão ser feitas da seguinte forma:
• Identificação das duplicidades de contexto do léxico.
Os léxicos poderão aparecer duplicados no resultado da análise. Essa duplicidade se
deve ao fato de o léxico poder estar ligado a mais de um tipo de léxico, ou seja, contexto. O
usuário deverá verificar qual tipo de léxico está relacionado à história que está sendo analisada.
Os léxicos/tipos de léxicos que não corresponderem à história deverão ser excluídos. É
importante ressaltar que é possível que todos os léxicos/tipos de léxicos possam ser excluídos.
Isso acontece quando o léxico encontrado estiver em um contexto que ainda não foi tratado nos
cadastramentos anteriores, ou seja, na base histórica de léxico já existente.
• Cadastramento dos léxicos inexistentes.
Os léxicos identificados pela ferramenta e não encontrados no banco de conhecimento e
os léxicos que não foram encontrados, mas foram identificados visualmente pelo usuário,
deverão ser cadastrados na composição da história. Esse cadastramento corresponde à
identificação: do conceito do léxico, do tipo de léxico, da existência de um conceito diferente
em relação ao tipo de léxico, do tipo de relacionamento (verbo de ligação) e do complemento
(estado).
• Análise da composição e do impacto.
Após o cadastramento é possível fazer a análise da composição e do impacto da história.
Essa análise é importante para as atividades de previsão e validação da implementação da
história.
• Atualização do banco de conhecimento.
Uma vez aprovada a análise da história, o usuário deverá confirmar a sua realização.
Essa confirmação é necessária para atualizar o banco de conhecimento e disponibilizá-lo para
os demais usuários.
A figura 31 apresenta a interface para efetuar a formatação do texto da análise da
história. A interface é dividida em duas partes, a parte de identificação e a parte do resultado. A
primeira parte consiste na identificação do nome do léxico que corresponde à história e à
descrição do texto relativo à história. A segunda parte é constituída das interfaces de Voz Ativa,
Formatação Atual e Acertar Formatação. Essa segunda parte é preenchida após a solicitação
111
da análise da história. A interface formatação atual apresenta a rastreabilidade gerada após a
execução da análise de acordo com o processo discutido. A interface acertar a formatação
permite ao engenheiro de software fazer os acertos na composição gerada. A interface voz ativa
corresponde à análise final da história após os acertos efetuados. No exemplo apresentado na
figura 32, a história digitar rapidamente é formada pelas classes Atendimento e Procedimento,
pelas tabelas Atendimento e Procedimento e pelo ator Faturista. O exemplo foi montado para
apresentar o resultado de que para o mesmo léxico Atendimento é possível identificar e listar
todos os contextos em que ele aparece (classe e tabela). O usuário que está fazendo a análise da
história deverá verificar esta composição e efetuar os devidos acertos.
Figura 32 – Tela de formatação do texto da análise
112
7 ANÁLISE DE RESULTADOS
As propostas apresentadas neste trabalho foram implementadas numa pequena empresa
e o resultado qualitativo da sua aplicação foi medido e analisado. Primeiramente, apresenta-se a
análise da aplicação da modelagem de metas para a aquisição do conhecimento a partir das
necessidades do usuário e depois, discute-se o resultado da manipulação do conhecimento
utilizando a rastreabilidade baseado em léxico.
7.1 Análise de Resultados da Modelagem de Metas
Os resultados obtidos, nesse trabalho, confirmam algumas das vantagens e conclusões
apontadas por Lamsweerde, (2001). Dentre eles, destacam-se:
• A modelagem de metas fornece uma base de apoio que ajuda a melhorar o
entendimento, interpretação e a documentação dos requisitos. Essa base de apoio
funciona como sendo a razão da existência dos requisitos;
• O processo de refinamento das metas ajuda na transmissão do conhecimento e
fornece um suporte para os stakeholders tomarem as decisões sobre os requisitos a
serem desenvolvidos;
• O modelo gráfico utilizado para efetuar a modelagem de metas mostrou-se eficiente
para visualizar a rastreabilidade entre as metas (nível estratégico) e os requisitos
(nível técnico). Essa visualização facilita a documentação e a leitura do modelo por
parte dos envolvidos.
113
O quadro 2 apresenta um resumo dos resultados em relação à modelagem de Metas para
a manipulação do conhecimento.
Item Analisado Resultado
Manipulação do conhecimento para
pequenos projetos.
Melhorou o entendimento, a comunicação e a
criação do escopo.
Manipulação do conhecimento para grandes
projetos.
Inadequado para o projeto como um todo.
Transmissão do conhecimento entre os
envolvidos.
Melhora a assimilação por parte do
engenheiro de requisito. Ajuda na
comunicação através da modelagem visual.
Implantação do processo colaborativo para
a modelagem de metas.
Gerou latência, no desenvolvimento, para o
engenheiro de software.
Utilização das perguntas como e por que no
apoio ao entendimento do problema,
durante a atividade de elicitação.
Ajuda o engenheiro de requisitos a identificar
as falhas no levantamento e no entendimento
das necessidades dos usuários.
Utilização das perguntas como e por que
durante o processo de entrevista.
Pode interromper o raciocínio lógico do
usuário.
Manipulação do conhecimento na fase de
concepção, ou seja, modelagem do
problema.
Útil para o entendimento do problema e para
a criação do escopo.
Manipulação do conhecimento na fase de
elaboração, ou seja, modelagem da solução.
Não foram identificados benefícios diretos
para a modelagem da solução.
Manipulação do conhecimento na fase de
construção
A modelagem de metas não forneceu
subsídios para apoiar o desenvolvimento nesta
fase.
Manipulação do conhecimento na fase de
Transição
Não foi viável vincular o aceite do sistema
com a conformidade das metas, ou seja,
garantir a qualidade pela conformidade do
sistema em relação às metas a serem
atingidas.
Redução do tempo na atividade de
elicitação de requisitos
Não foi possível efetuar nenhum tipo de
medição para comprovar.
Quadro 2 – Resumo dos resultados da modelagem de metas
114
Os resultados apresentados no quadro 2 são avaliados e analisados detalhadamente a
seguir:
a) Desenvolvimento do diagrama do modelo de metas.
Após a aplicação da modelagem de metas em projetos de portes distintos, isto é,
projetos de grande e pequeno porte, verificou-se que nos projetos de pequeno porte o processo
de modelagem foi realizado sem maiores problema. O modelo visual permitiu a identificação
rápida dos requisitos, a elaboração do escopo e a melhoria na comunicação entre os envolvidos.
A confecção do modelo de metas foi feito na atividade de elicitação de requisitos sem a
necessidade de efetuar vários refinamentos. A comunicação foi beneficiada devido à descrição
dos requisitos estarem apoiadas por um modelo visual. O modelo visual agilizou as reuniões
entre o engenheiro de requisitos e os integrantes da equipe. Cabe ressaltar que se considera
como projetos de pequeno porte aqueles que consistem em alterações nos sistemas já
implantados. Essa alteração consistia em mudança de requisitos ou inclusão de novos módulos.
Normalmente o tempo médio dessas alterações foi de no máximo 45 dias.
Mas, para projetos de maior porte, teve-se muita dificuldade em criar o modelo de metas
eficaz. O modelo criado ficou muito grande e sem a identificação clara das metas e seus
requisitos. Esse modelo não permitiu a comunicação visual entre os integrantes dificultando o
seu entendimento. Além desses fatores, gastou-se muito tempo para validar o modelo. Como o
engenheiro de software não tinha condição de completar todas as metas e requisitos, verificou-
se a necessidade de um maior número de refinamentos. Todos esses fatores inviabilizaram a
transmissão do conhecimento, uma vez que esses dificultaram o acompanhamento do
refinamento, a rastreabilidade das metas e a interligação existente entre as metas. Os requisitos
vinculados às metas ficaram com um formato muito abstrato, dificultando, assim, a sua
interpretação.
A solução do problema foi a subdivisão do projeto em módulos, agrupando as
metas/requisitos de acordo com as suas macro funcionalidades. Essa divisão foi feita após a
elaboração do diagrama de contexto. Para cada módulo identificado no diagrama de contexto
fez-se o modelo de metas dos módulos. Esses modelos ficaram menores e mais fáceis de serem
acompanhados, tanto pela equipe de desenvolvimento, quanto pelo usuário, uma vez que o
modelo ficou mais claro de ser lido, pois diminuiu o número de ligações existentes entre os
requisitos e os conjuntos de metas. A equipe de desenvolvimento conseguiu fazer a
115
rastreabilidade entre as metas e requisitos de uma forma mais rápida e eficiente. Os requisitos
obtidos durante o refinamento dos módulos foram mais facilmente identificados e alocados às
metas.
b) Implantação do processo de modelagem colaborativa com o usuário
Um das propostas dessa dissertação foi a implantação da modelagem de metas efetuada
de forma colaborativa entre o desenvolvedor e o usuário. Nesse sentido algumas tentativas
foram efetuadas para essa implantação. As tentativas consistiram na modelagem de metas para
alterações de requisitos de um projeto em andamento, um novo projeto de pequeno porte e, o
desenvolvimento de um projeto de maior porte.
Tanto nas alterações de requisitos como nos projetos de pequeno porte não foi possível
usar o processo colaborativo descrito no capítulo 3.1. Isso porque, durante o processo de
levantamento de dados junto ao usuário, o desenvolvedor, praticamente, criou o modelo de
metas. Ou seja, o objetivo da transmissão do conhecimento para a interpretação das
necessidades por parte do engenheiro de software, já havia sido atingido. Dessa forma, não foi
possível verificar se processo colaborativo auxiliaria a transmissão do conhecimento de forma
eficiente.
Para caracterizar o processo colaborativo em um projeto de maior porte, utilizou-se um
projeto que consistia de um número maior de iterações entre o levantamento de requisitos, a
análise por parte do desenvolvedor e a necessidade de refinamento do entendimento. A
tentativa de implantação neste projeto não foi bem sucedida, pois se obteve uma latência para o
desenvolvedor, ou seja, não se pode afirmar onde ocorreu o problema, se no processo
colaborativo ou na confecção do modelo.
Durante a fase de concepção desse projeto, não foi possível testar o processo
colaborativo uma vez que o tempo para apresentação da proposta do projeto era escasso. O
engenheiro aplicou o modelo de metas sem a presença física do usuário, ou seja, utilizou apenas
os resultados obtidos em reuniões para o levantamento inicial.
Durante a fase de elaboração do projeto efetuou-se uma tentativa de implantação do
processo colaborativo. Nessa tentativa, durante os refinamentos, obteve-se uma latência para o
desenvolvedor. Acredita-se que essa latência tenha sido gerada por dois motivos:
• Dificuldades obtidas na confecção do modelo durante a fase de concepção. Essas
dificuldades geraram um grau de desconfiança, que se transferiu para a implantação
do processo na fase de elaboração;
116
• Dificuldade de alocar tempo para fazer o refinamento por parte do usuário. Acredita-
se que o problema não foi a falta de vontade de usuário em desenvolver o modelo, e
sim, a falta de tempo e, principalmente, pela criação do modelo não ser uma
atividade diária do usuário. As prioridades do usuário são as atividades relacionadas
com o seu negócio.
Desta forma, obteve-se maior sucesso para a modelagem de metas quando o
desenvolvedor realizou todo o modelo. Ou seja, o usuário se fazia necessário apenas na
validação do que deveria ser desenvolvido. Essa validação consistia na efetivação do
conhecimento transmitido ao desenvolvedor. O desenvolvedor, exercitando o trabalho de
identificar as metas e liga-las aos requisitos ajudou a dominar o problema de uma forma mais
rápida. Não foi possível quantificar o que vem a ser mais rápido, pois não foi possível efetuar
um comparativo devido à falta de projetos semelhantes. No entanto, obteve-se uma redução do
retrabalho na entrega dos produtos de algumas alterações.
Durante a implantação do processo colaborativo de metas, observou-se um entrave na
forma de posicionar os conceitos relativos à modelagem para os usuários. A modelagem de
metas foi testada em três empresas diferentes. Antes de iniciar-se o levantamento explicava-se a
metodologia proposta e como se atuaria durante o levantamento. Essa explicação foi feita para
os dois níveis: gerencial e operacional. Em duas empresas, que se caracterizavam pelo formato
de gestão baseada em metas de resultados, obteve-se problemas com o entendimento. Num
primeiro momento, os gestores confundiram a modelagem de metas com as metas a serem
atingidas com o processo de desenvolvimento. Ou seja, metas a serem atingidas com relação ao
prazo de entrega, com as metas a serem atingidas com o produto.
c) Processo para implantação da modelagem de metas
Inicio-se a implantação da modelagem de metas internamente na empresa sem a
presença do usuário. Isso acarretou alguns problemas para o desenvolvedor. Os
desenvolvedores, normalmente, identificaram as metas a serem atingidas em relação aos lucros
ou a alguma outra parte financeira. No trabalho, considerou-se que praticamente todo produto a
ser construído, de uma forma ou de outra, deve melhorar a relação custo/resultado da empresa
e, com certeza, são metas a serem atingidas. Mas, as metas que irão ajudar na transmissão do
conhecimento envolvem as regras de negócio e como o usuário manipula essas regras de
negócio para atingir os seus objetivos.
117
Considerou-se que a visão inicial de metas, envolvendo a parte financeira, se justifica
porque os desenvolvedores, geralmente, não são preparados para trabalhar com o processo de
negócio e sim trabalhar técnicas de análise e modelagem de sistema. A partir do momento em
que os desenvolvedores foram forçados a pesquisar as metas a serem atingidas, juntamente com
o usuário, tiveram que pensar no problema separado da solução. E isto foi benéfico para o
desenvolvimento, pois ajudou o desenvolvedor a migrar do mundo técnico para o mundo do
usuário, ajudando na melhoria da interpretação dos requisitos. Assim, o entendimento do
problema foi visto com a visão do usuário e não com a visão do engenheiro de software. A
solução, ou seja, a visão do engenheiro de software a respeito do negócio ficou para a
posteriori, ajudando na criação dos modelos UML do projeto.
A solução para minimizar o trabalho de identificação das metas, sem a presença do
usuário, consistiu na alocação dos requisitos não funcionais como meta. Essa sugestão
melhorou os modelos iniciais de metas criados pelos desenvolvedores.
O modelo de metas ajudou os engenheiros de software a entender o problema de uma
forma esclarecedora, durante as reuniões técnicas. Os engenheiros não discutiam somente a
solução que deveria ser adotada, mas discutiam principalmente o problema. Essa discussão
ampliou o nível de entendimento do domínio, melhorando por conseqüência as soluções para os
projetos.
d) Dificuldade na realização da entrevista focada nas perguntas como e por que
As perguntas como e por que, aplicadas diretamente durante o processo inicial de
entrevistas para o detalhamento de uma meta, interromperam o raciocínio lógico do usuário. O
usuário, durante o relato das suas necessidades, não conseguiu se fixar em apenas um ponto, ou
seja, na meta. As interrupções tornaram as entrevistas cansativas e sem uma coerência lógica.
Portanto, não se obteve o resultado esperado. Mas, as perguntas mostraram-se úteis para a
verificação e validação junto ao usuário. As perguntas como e por que foram úteis na hora de
preencher o modelo de metas na ferramenta. Os engenheiros de software, às vezes tiveram
dificuldades de responder as perguntas, ficando, assim, caracterizada uma falta de entendimento
durante o levantamento de requisito. Isso indicava, portanto, uma necessidade de retornar ao
usuário para fazer a elicitação das dúvidas.
e) Antecipação das possíveis alterações de requisitos
118
A análise do estudo do segundo estudo de caso, apresentado no capítulo 5, seção 5.3,
indica que a modelagem de metas contribuiu na melhoria da atividade de elicitação dos
requisitos, antecipando ou evitando futuras modificações. A análise desse estudo de caso foi
realizada através de uma reunião, onde foram levantados três pontos de vista, que consistiram
em verificar:
• Se o usuário deveria ou não, já ter solicitado tudo que ele necessitava no primeiro
momento. No estudo de caso efetuado, o usuário já deveria ter solicitado a comparação
com o resultado anual, uma vez que, ao final da elicitação do requisito, ficou claro que
ela correspondia a uma necessidade importante para o seu trabalho;
• Se não houve falha do engenheiro de software na identificação das necessidades da
comparação anual, durante a atividade de elicitação. O engenheiro deveria ter a
capacidade de identificar essa necessidade sem nenhum esforço adicional, visto que,
qualquer análise financeira possivelmente envolverá uma análise anual;
• Se as solicitações iniciais deveriam ter sido desenvolvidas e, posteriormente,
identificadas as alterações, as quais seriam tratadas como uma nova iteração do processo
de desenvolvimento pois, esse processo preconiza, exatamente, a possibilidade de
mutabilidade dos requisitos.
O terceiro ponto de vista ocorre, naturalmente, durante todo o ciclo de vida do projeto,
mas, para produzir um projeto com qualidade e dentro dos prazos e custos inicialmente
definidos, faz-se necessário reduzirmos o número de iterações para acertos dos requisitos já
desenvolvidos. O ideal é que as novas iterações tratem da implementação de novas
funcionalidades e para o amadurecimento do conhecimento sobre o produto que está sendo
desenvolvido. Iterações para correções aumentam o custo final do produto. E, a empresa, pode
ter dificuldade em repassar esse custo para o cliente.
Com relação aos outros dois pontos de vista, considera-se que, a modelagem de metas
pode ajudar tanto o usuário a definir melhor a sua necessidade, quando o engenheiro, a perceber
situações incompletas com relação às necessidades do usuário. Se o engenheiro já tivesse algum
entendimento do domínio, com certeza ele poderia detectar a falta do requisito de comparação
anual. Mas, se com a utilização da modelagem de metas o requisito anual foi devidamente
identificado, então pode-se dizer que houve a transferência do conhecimento e da experiência
no domínio do problema para o engenheiro de software;
f) Transmissão de conhecimento fases do processo
119
Os engenheiros de software, durante o desenvolvimento dos projetos e, principalmente,
na fase de concepção, realizaram reuniões técnicas para elaborar a proposta e verificar soluções
para os projetos em desenvolvimento.
As reuniões da fase de concepção demonstraram ter maior efeito na transmissão do
conhecimento. A modelagem visual e o preenchimento das respostas como e por que ajudaram
na transmissão do conhecimento, visto que, primeiro era apresentado o modelo de metas e,
depois, efetuada a leitura dos requisitos desejados pelo usuário. Durante a leitura, detectou-se
um entendimento mais rápido por parte das pessoas envolvidas na reunião.
Os resultados da transmissão do conhecimento na fase de elaboração devem ser melhor
estudados, para que se possa afirmar que existe a transmissão do conhecimento durante a
solução do problema. Na fase de concepção, apenas um integrante da equipe efetua o
levantamento e é necessária a transmissão do conhecimento para a construção da proposta. Nas
reuniões da fase de elaboração, já existia um conhecimento do assunto por toda a equipe.
Assim, o conhecimento já fora adquirido não havendo, portanto, a necessidade da aquisição
durante essa fase. Como não ocorreu alteração da equipe na fase na elaboração, não se pode
afirmar que haverá a transmissão do conhecimento no mesmo nível da fase de concepção. A
avaliação da eficácia da transmissão do conhecimento poderia ser verificada com a mudança de
algum membro da equipe. Portanto, pode-se dizer que a modelagem de metas ajuda a transmitir
o conhecimento do problema do domínio.
De acordo com a proposta, os testes das fases de construção e transição deveriam
considerar o modelo de metas, a fim de garantir a qualidade do software. A partir da utilização
da modelagem de metas, os requisitos puderam ser melhor compreendidos. Assim, acredita-se
que os testes ganharam em qualidade, mas em nenhum dos casos avaliados foi possível fazer
uma avaliação da meta, a não ser quando a meta tratava de um requisito não funcional. Não
houve retorno do cliente com relação ao grau de conformidade das metas em relação ao
produto. Ou seja, não foi possível vincular o aceite do projeto com a conformidade da meta,
devido à inadequação do tempo para validação da meta e o faturamento do projeto por parte da
empresa. O retorno obtido foi apenas a indicação de que o software estava de acordo com o
solicitado. Supõe-se que as metas foram atingidas, a partir do momento em que o software foi
considerado adequado. Essa suposição é baseada na rastreabilidade entre os requisitos e as
metas a serem atingidas.
120
g) Transmissão de conhecimento em relação ao tempo da atividade de elicitação
Não foi possível verificar a redução do tempo na atividade de elicitação de requisito.
Em engenharia de software é difícil cronometrar essa atividade para comparar com outra
semelhante do mesmo projeto ou de um novo. Ou seja, a falta de similaridades, a capacidade de
transmitir do usuário e a capacidade de recepção do engenheiro de software dificultam qualquer
comparação de tempo. No entanto, considera-se que a modelagem de metas melhorou a
qualidade do levantamento e agilizou o ganho de experiência no domínio. Acredita-se que, para
haver uma real redução do tempo, deveria existir um aumento de investimentos no processo
colaborativo. O usuário investiria um tempo na sua especificação da metas/requisitos e o
desenvolvedor poderia investir um maior tempo na análise dessas metas/requisitos.
121
7.2 Análise dos resultados da Rastreabilidade baseada em Léxico
Ramesh (2002), apresenta como fatores críticos para o sucesso da transferência do
conhecimento entre os integrantes da equipe a forma da apresentação da rastreabilidade, a
capacidade de absorção e o valor que as pessoas dão para o conhecimento. Estes critérios
devem ser bem observados e trabalhados na pequena empresa devido às suas características e,
principalmente, à dificuldade de implementar e impor novos processos. Os resultados obtidos
neste trabalham mostram que:
• O problema do formato da apresentação é possível resolver, através de reuniões técnicas
e da implementação do resultado das reuniões nos programas desenvolvidos;
• A capacidade de absorção normalmente não é problema devido, ao pequeno número de
pessoas e na existência de um certo padrão de formação acadêmica dos sócios;
• O valor que as pessoas dão ao conhecimento está diretamente relacionado com a
utilização da rastreabilidade e com o reflexo dessa rastreabilidade nos projetos. Em uma
grande empresa existe uma hierarquia de poder. Essa hierarquia facilita a tarefa de criar
a atividade de atualizar o resultado do trabalho em um banco de conhecimento. Na
pequena empresa, essa hierarquia não é bem definida, principalmente quando a maioria
dos integrantes é sócia. O poder é dividido e o interesse nos projetos e nos resultados
influenciam na motivação da atualização da base de conhecimento.
A partir do desenvolvimento e da manipulação da ferramenta de rastreabilidade baseada
em léxico, como apoio à manipulação do conhecimento, chegou-se aos seguintes resultados
(quadro 3):
122
Item Analisado Resultado
Formatação do banco de conhecimento
para a manipulação do conhecimento.
Apóia a manipulação do conhecimento a partir da
implementação integrada das visões técnicas,
gestão e de processo.
Utilização do léxico na manipulação do
conhecimento.
O registro da variação dos conceitos do léxico
possibilita a transmissão do conhecimento e apóia o
reuso de conceitos em projetos diferentes.
Formatação da rastreabilidade baseada
em sujeito, verbo, objeto e estado.
Ajuda na manipulação do conhecimento a partir da
leitura textual da rastreabilidade.
Utilização da ferramenta na manipulação
do conhecimento.
Ajuda a partir do foco estar na forma de
recuperação e navegação.
Transmissão do conhecimento entre os
integrantes da equipe.
Minimiza a dependência de conhecimento entre as
pessoas envolvidas no desenvolvimento dos
projetos.
Análise de impacto da alteração dos
requisitos.
O formato da apresentação utilizado pela
ferramenta ajudou na análise de impacto das
alterações dos requisitos.
Análise da história dos requisitos. Pouca eficiência na manipulação do conhecimento
de histórias relatadas pelos usuários. Muito
utilizado para efetuar consulta à base de
conhecimento para análise de impacto.
Dificuldade na atualização do banco de
conhecimento.
A ferramenta não ajuda na atualização em tempo
real das visões de processo e gestão. A visão
técnica demonstra ser de fácil atualização, tanto a
partir da ferramenta, quanto a partir de módulos de
integração entre as ferramentas utilizadas pela
empresa.
Quadro 3 – Resumo dos resulados da rastreabilidade de requisitos baseado em léxico
123
Os resultados apresentados no quadro 3 são avaliados e analisados detalhadamente a
seguir:
a) Banco de Conhecimento
Um dos objetivos desta dissertação é demonstrar a capacidade da modelagem do
banco de conhecimento na implementação da rastreabilidade baseada em léxico. Esse banco de
conhecimento deveria possibilitar a manipulação do conhecimento para a empresa estudada. De
acordo com os testes efetuados, durante a elaboração dos projetos, o banco modelado
demonstrou ser capaz de armazenar as informações necessárias para a manipulação do
conhecimento. A sua modelagem abrangeu todas as visões relativas ao desenvolvimento do
software: processo, gestão e técnica. Foi possível trabalhar informações históricas das
atualizações dos léxicos.
O formato da rastreabilidade baseada no léxico ajudou na transmissão do
conhecimento entre os integrantes da empresa, devido à:
• Implementação das variações dos conceitos de um determinado léxico de acordo com o
contexto usado.
O conhecimento está balizado na experiência que uma determinada pessoa tem sobre
um determinado assunto. No domínio do desenvolvimento de sistema surgem conceitos
diferentes para o mesmo léxico, ou seja, um determinado léxico pode variar o seu conceito de
acordo com a utilização e de acordo com o domínio do projeto que está sendo desenvolvido. A
implementação dessa variação de conceitos, para um mesmo léxico, ajudou na solidificação do
conhecimento adquirido. O engenheiro de software pôde comparar os conceitos diferentes do
léxico em projetos diferentes e em situações diferentes dentro do mesmo projeto. Essa
comparação permitiu ao engenheiro de software validar o domínio do problema.
O léxico, por ser único, possibilitou uma melhoria na análise da história, visto que, são
apresentadas para o engenheiro de software todas as situações em que o léxico poderá aparecer.
O engenheiro de software pode fazer uma análise de qual léxico/conceito seria usado na
história. Para exemplificar essa análise, tem-se: o léxico procedimento tem o seu conceito
variado de acordo com o do domínio e de acordo com o tipo de uso dentro do mesmo domínio.
O conceito dicionarizado do léxico procedimento é o modo de proceder, de portar-se,
comportamento. No projeto de controle de obras o léxico procedimento se refere às etapas que
uma determinada empresa tem que cumprir para habilitar-se a desenvolver uma determinada
obra. No projeto de faturamento médico o procedimento tem as seguintes variações: referir-se
124
ao procedimento realizado pelo médico no atendimento a um paciente, por exemplo, a
realização de uma cirurgia; referir-se aos procedimentos que um determinado faturista deve
realizar para efetuar o faturamento dos procedimentos médicos, e referir-se a uma tabela de
banco de dados ou classes que façam parte da solução do software.
• A formatação sujeito, verbo, objeto e estado.
Um léxico se relaciona a outro a partir da identificação do tipo de relacionamento que
existe entre eles e não somente com a indicação de que eles se correlacionam. Essa formatação
demonstrou ser eficiente no sentido de permitir uma leitura textual da rastreabilidade. A leitura
textual facilitou o entendimento por ser mais completa e conter todos os elementos que
envolvem a formatação de uma idéia. Pode-se fazer uma analogia da leitura da rastreabilidade
com a leitura de um texto. Quando um texto é apresentado na ordem direta (sujeito, verbo,
objeto e estado), a compreensão das idéias que o autor pretende transmitir é facilitada. Dentro
desse contexto, a rastreabilidade foi beneficiada pela organização textual da informação a ser
pesquisada.
• Implementação das visões diferentes em um mesmo modelo de apresentação.
A implementação favoreceu a extração das informações do banco. A possibilidade de
visualizar todos os elementos de uma forma única, ou combinada, permitiu ao usuário da
rastreabilidade fazer comparações entre os elementos. Sempre que se faz comparações, é
possível melhorar a manipulação do conhecimento, pois a mesma passa por processo de
raciocínio.
• A implementação histórica das alterações do banco.
A implementação histórica possibilitou um amadurecimento dos usuários da
rastreabilidade. As pessoas adquirem experiências a partir dos trabalhos já realizados. Esses
trabalhos servem como base para uma análise crítica de novas situações. A experiência é uma
análise histórica da vivência das pessoas em um determinado assunto. A implementação
histórica no banco de conhecimento permitiu o armazenamento dessa experiência vivida. A sua
recuperação, através da análise da rastreabilidade, colaborou na interpretação das novas
funcionalidades.
b) Análise da Rastreabilidade baseada em léxico.
125
Conforme os objetivos dessa dissertação, a ferramenta proposta deveria apoiar a
manipulação do conhecimento. Durante o processo de criação da ferramenta observo-se que,
para efetuar a manipulação do conhecimento existiam dois fatores críticos: a forma de
recuperação do conhecimento e a forma de navegação no conhecimento recuperado.
O formato, desenvolvido para a recuperação dos léxicos, demonstrou ser eficiente para
a análise da rastreabilidade, devido à agilidade na seleção de um léxico para pesquisa. Os
formatos desenvolvidos foram: seleção pontual de um léxico e seleção conjunta dos léxicos a
partir da descrição de uma história.
O ponto chave para o sucesso da manipulação do conhecimento consistiu na navegação
da ferramenta. A possibilidade de navegar em árvore no formato composição e impacto gerou
ganhos na pesquisa dos léxicos. Foi possível fazer a análise de impacto, tanto diretamente na
composição do léxico, quanto nos seus possíveis reflexos. Esses possíveis reflexos são
apresentados através da apresentação da composição dos níveis hierárquicos superiores, e/ou
inferiores, do léxico analisado. A comparação simultânea da voz ativa e voz passiva, também,
colaborou na identificação dos impactos diretos e indiretos. O apoio ocorreu a partir do
momento em que se obteve visualização simultânea, sem a necessidade de realização de uma
nova pesquisa.
A possibilidade de navegar, na análise, a partir do clique com o mouse no léxico,
otimizou o tempo de pesquisa. Como uma análise poderá abranger vários léxicos, foi necessária
a implementação da lista de léxico consultada. A lista foi incorporada para indicar, ao usuário
da rastreabilidade, a seqüência de consulta e assim permitir retornar a qualquer ponto da
análise. A possibilidade de navegar apenas com a utilização do mouse e o registro da seqüência
da análise agilizou o processo de busca do conhecimento, uma vez que essa ação não
interrompe o raciocínio do usuário durante a análise.
A forma utilizada para verificar a manipulação do conhecimento, pela análise da
rastreabilidade, consistiu na redução da transmissão do conhecimento face a face entre as
pessoas envolvidas no processo. Na pequena empresa é mais fácil obter uma resposta
diretamente com um pergunta do que fazer uma consulta em uma ferramenta, devido ao número
de pessoas envolvidas. Para efetuar o teste de transmissão do conhecimento, primeiramente a
pessoa deveria utilizar a ferramenta e analisar a rastreabilidade. A partir dessa análise, o
entendimento era formatado e depois validado com a pessoa que tinha o conhecimento e que
originalmente responderia a pergunta. Isso forçou as pessoas a buscarem o conhecimento em
fontes de documentação e não com as pessoas que já trabalhavam em um determinado projeto.
O formato final da apresentação da rastreabildiade da ferramenta foi obtido a partir das críticas
126
e sugestões surgidas durante o processo de teste da transmissão do conhecimento. Como
resultado final a ferramenta apoiada na rastreabilidade baseada em léxico demonstrou eficiência
na manipulação do conhecimento.
Os integrantes da empresa estudada trabalham em mais de um projeto ao mesmo tempo.
Daí a necessidade de cada membro da equipe trabalhar o conhecimento necessário para o
desenvolvimento do projeto, independentemente de quem tenha feito e quando tenha feito a
atividade do projeto. A necessidade consistiu em agilizar o processo de agregação de valor ao
conhecimento para a tomada decisão, a partir das atividades e artefatos já produzidos.
Trabalhando sob essa perspectiva, observou-se uma minimização da dependência de
esclarecimentos ou dúvidas em relação à pessoa que fez o projeto. Não se pode quantificar essa
minimização, no entanto, observou-se uma maior independência na tomada de decisões.
c) Análise da História
A análise da história demonstrou eficiência na formatação de uma consulta geral na
base de conhecimento. Essa consulta geral foi feita para verificar o impacto e a possível
composição de vários léxicos já existentes na base de conhecimento. O usuário tinha a
necessidade de visualizar um conjunto de léxicos que não fazia parte de nenhuma composição
imediata (história), assim o usuário criava uma história com todos os léxicos e solicitava a
análise. O resultado da análise da história é uma possível composição de todos os léxicos. O
resultado obtido da composição, muitas vezes, não tinha nenhum objetivo de manipulação
direta do conhecimento. Mas, como a ferramenta mostra o impacto, através da composição
hierárquica dos relacionamentos dos léxicos, e a partir da navegação em árvore, foi possível
fazer uma análise geral mais rápida, sem ter que pesquisar a formatação de léxico a léxico.
A análise da história, a partir de uma historia real, não apontou o resultado esperado. O
processo utilizado pela empresa não contribuiu para a criação da história. Isso implicou em uma
etapa a mais na elaboração do produto, uma vez que a atividade de análise dos requisitos já
contemplava a rastreabilidade dos requisitos em relação ao modelo de classe. Outro problema
que se percebe consistia no resultado insatisfatório da análise da história. Essa não foi capaz de
manipular o conhecimento de uma história completamente nova e/ou de histórias com um grau
de complexidade maior. A análise somente obteve algum sucesso na identificação e
manipulação do conhecimento de histórias com menor grau de complexidade e de histórias que
relatavam alguma alteração de requisito já desenvolvido.
127
A única vantagem verificada foi a possibilidade de se efetuar a documentação do
sistema. Essa documentação possibilitou a recuperação futura do conhecimento por parte dos
demais integrantes. No entanto, como manipulação do conhecimento imediato não demonstrou
o valor esperado e acredita-se que isso se deve ao fato de não ter nenhum resultado imediato
para o desenvolvedor.
d) Atualização do banco de conhecimento
O sucesso da manipulação do conhecimento está vinculado à capacidade de
manutenção do banco de conhecimento. Os processos de atualização a partir da modelagem das
tabelas no banco de dados (SGBD – Sistema Gerenciador de Banco de Dados), e a partir do
arquivo XML, demonstraram ser eficientes para manutenção do banco do conhecimento.
Portanto, a visão técnica foi mantida atualizada para o seu uso posterior.
Os processos de atualização das atividades, que correspondiam ao processo,
normalmente ficaram atrasados em relação aos artefatos. Não ocorreram problemas de
atualização na fase de planejamento. A atividade de planejar já tinha incorporado o tempo
necessário para atualização na ferramenta. Mas a indicação da realização da atividade não
demonstrou eficiência. A atualização da realização da atividade foi atrasada e ficou dependente
de esforços individuais. Isso porque a atualização é manual e havia necessidade da agilização
das respostas junto aos clientes.
O atraso na atualização foi impactante para a análise imediata da rastreabilidade. Esse
não foi um grande problema para a empresa, devido ao número de integrantes da equipe. O
atraso não teve impacto na análise histórica da rastreabilidade, pois o atraso na atualização não
foi maior que o tempo de entrada de novos projetos.
O processo de atualização da visão da gestão, nas atividades realizadas, não obteve
nenhum resultado positivo. O fato ocorreu devido à dificuldade de registro das lições
aprendidas ou dos motivos da decisão por atividade ou artefato. Normalmente, o engenheiro de
software, que estava desenvolvendo uma atividade ou artefato, considerou óbvia a solução
empregada. Esse fato se justificou pela padronização dos métodos de análise e de
documentação do desenvolvimento de sistema.
As lições aprendidas com o projeto foram fáceis de ser atualizadas, visto que, foram
obtidas a partir de reuniões com a equipe. Entretanto, não se pôde fazer uma relação direta dos
problemas com as atividades realizadas na época. Normalmente, os problemas consistiram em
um relato de um conjunto de atividades e foram atualizadas para o projeto como um todo.
128
8 CONCLUSÃO E TRABALHOS FUTUROS
8.1 Conclusão
Diante das discussões postas neste trabalho, chega-se à conclusão que tanto a
modelagem de metas quanto a rastreabilidade baseada no léxico podem ajudar na manipulação
do conhecimento e na melhoria do processo de desenvolvimento de uma pequena empresa. A
modelagem de metas mostrou-se eficiente para o entendimento das necessidades do usuário,
principalmente na atividade de elicitação de requisito e, a rastreabilidade mostrou-se eficiente
na manipulação histórica e na manipulação da visão técnica.
A modelagem de metas apresentou um resultado satisfatório na manipulação do
conhecimento em projetos e/ou módulos menores. Para projetos maiores, a solução, entretanto,
deve ser a subdivisão da modelagem das metas em módulos funcionais menores, de forma a
possibilitar a interpretação e a rastreabilidade dos requisitos com as metas entre os
desenvolvedores. Para efetivar a comunicação e a transmissão do conhecimento é necessário
que o modelo tenha uma fácil leitura. Considera-se o tempo de leitura um fator importante para
a transmissão do conhecimento na empresa estudada.
A ferramenta de modelagem de metas, apesar de simples em relação ao Objectiver
(2006), demonstrou ser uma ferramenta eficiente para a documentação da elicitação de
requisitos. Como a ferramenta exporta arquivo XML, ela foi integrada ao banco de
conhecimento. Assim, a ferramenta contribuiu para a documentação e a transmissão do
conhecimento entre os integrantes da equipe.
A ferramenta de rastreabilidade, desenvolvida, mostrou-se satisfatória para a
recuperação e a manipulação do conhecimento registrado no banco de conhecimento. O modelo
do banco criado implementou todas as necessidades de registro do desenvolvimento do sistema.
Além disso, o formato desse banco, sugerido neste estudo, apresentou a vantagem de ajudar na
leitura da rastreabilidade dos elementos envolvidos no desenvolvimento de um sistema,
reconhecidos como léxicos.
Considera-se que a manipulação do conhecimento feita pela modelagem de metas e pela
rastreabilidade baseada em léxico ajuda, de um modo geral, a qualidade de software, tendo em
vista o produto final. Isso foi possível porque, segundo a proposta dessa dissertação, a
129
ferramenta apóia a manipulação do conhecimento entre os integrantes a partir do momento que
o engenheiro de software tem à sua disposição as informações referentes ao desenvolvimento.
O modelo proposto de rastreabilidade baseado em léxico para a manipulação do
conhecimento ajudou na tomada de decisão devido aos seguintes fatores:
• Agilidade na análise de impacto de mudança nos produtos em desenvolvimento ou já
desenvolvidos;
• Diminuição do tempo da manutenção de software, principalmente na correção de um
erro, a partir da agilização da análise de impacto;
• Apoio na atividade de identificar o tempo e o custo de um novo projeto ou de uma
alteração de um produto já existente, a partir do registro na rastreabilidade das atividades
do previsto e do realizado em relação ao custo e ao tempo;
• Melhoria na identificação da possibilidade de reuso de algum artefato já produzido. E na
identificação dos artefatos que devem ser utilizados para a implementação de um novo
requisito, a partir da unificação do léxico a da separação dos conceitos.
Conclui-se que o estudo proposto pôde contribuir para a manipulação do conhecimento
em uma pequena empresa produtora de software, devido à diminuição da dependência de
conhecimento em relação a um profissional específico, tanto na elicitação dos requisitos,
quanto na parte técnica relativo ao desenvolvimento.
130
8.2 Trabalhos Futuros
Em trabalhos futuros, pretende-se estudar aspectos relevantes na manipulação do
conhecimento e que não foram tratados ou resolvidos neste estudo. Dentre eles destaca-se:
• Implementação do processo colaborativo para modelagem de metas. Acredita-se que o
processo colaborativo otimiza a transmissão do conhecimento entre os envolvidos e a
redução do tempo da atividade de levantamento de requisitos. Para as empresas de
pequeno porte que não possuem mão de obra especifica para trabalhar cada atividade do
processo de desenvolvimento, esse fato pode tornar-se relevante;
• Melhoria do processo de analisar a história. Acredita-se que se forem implementadas
regras de análise do léxico, aliadas a métodos de inteligência artificial, pode-se
recuperar e gerar um conhecimento para o engenheiro de software. O conhecimento
gerado facilitará a elaboração dos modelos que representariam a história analisada, o
que acarretaria um ganho de produtividade e aumentaria a motivação das pessoas para
manter o banco de conhecimento atualizado;
• Melhoria da atualização do registro das decisões relativas ao projeto. Acredita-se que as
lições aprendidas na realização das atividades do projeto solidificam o conhecimento.
Seria interessante estudar mecanismos que motivem as pessoas a registrar as suas
decisões, com ganho de produtividade no trabalho;
• Desenvolvimento de classes, para efetuar a integração com outros sistemas de controle
de produção de software utilizados pelas empresas, com a finalidade de motivar o uso
da rastreabilidade baseada em léxico;
• Melhoria na ferramenta, para permitir, que além de rastrear o requisito, se possa avaliar
a situação da sua implementação e satisfação quanto às necessidades do usuário em
relação aos pontos de controle da gestão do projeto.
131
REFERÊNCIAS
ANTONIOL, Giuliano et al.; Recovering Traceability Links between Code and Documentation,
IEEE Transactions on Software Engineering, vol. 28, no. 10, October 2002.
BECK, Kent, Programação extrema explicada: acolha as mudanças / Kent Beck; trad. Adriana
P.S. Machado e Natália N.P. Lopes. – Porto Alegre: Bookman, 2004.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar, UML, guia do usuário / Grady
Booch, James Rumbaugh, Ivar Jacobson; tradução de Fábio Freitas da Silva, Rio de Janeiro:
Elsevier, 2000, 13ª reimpressão.
BORGES, Ligia da Motta Silveira; FALBO, Ricardo de Almeida; Gerencia do Conhecimento
sobre processo de Software; Anais do VIII Workshop de Qualidade de Software, XV Simpósio
Brasileiro de Engenharia de Software, pp. 27-38, Rio de Janeiro, Brasil, Outubro 2001.
C&L, Cenários e Léxicos; Grupo de Engenharia de Requisitos PUCRio; Disponível em <
http://www.rawu.dk/pes/cel/>, acessado em 14 de setembro de 2006.
CAMPOS, M.L.A. A Organização de Unidades do Conhecimento em Hiperdocumentos: o
modelo conceitual como um espaço comunicacional para a realização da autoria. Tese de
Doutorado em Ciência da Informação. IBICT-UFRJ/ECO, Rio de Janeiro, 2001.
CMMI - Capability Maturity Model Integration, 2005.
DARDENNE, Anne; FICKAS, Stephen; LAMSWEERDE, Axel Van; Goal-Directed Concept
Acquisition in Requirements Elicitation; IEEE, 1991.
DICK, Jeremy; Design Traceability; IEEE Software, Published By The Computer Society;
November/December 2005.
132
FANO, Andrew et al; Acquisition of Knowledge Sources For Natural Language Processing; in:
Tools for Artificial Intelligence, 1989. Architectures, Languages and Algorithms. IEEE
International Workshop.
FELICÍSSIMO, Carolina Howard; Geração de Ontologia Subsidiada pela Engenharia de
Requisito; Workshop em Engenharia de Requisitos 2003: Piracicaba-SP, Brasil.
FERREIRA, Aurélio Buarque de Holanda, Novo Dicionário Aurélio – Século XXI, Rio de
Janeiro, Ed. Nova Fronteira, 1999.
GOGUEN, Joseph A.; LINDE, Charlotte; Techniques for Requirements Elicitation;
Proceedings, Requirements Engineering; IEEE Computer Society, 1993, pages 152-164.
GOTEL, Orlena C. Z.; FINKELSTEIN, Anthony C. W.; An Analysis of the Requirements
Traceability Problem; Proc. Of First International Conference on Requirements Engineering,
1994, pages 94-101.
IBGE, Instituto Brasileiro de Geografia e Estatística; As Micros e Pequenas Empresas
Comerciais e de Serviços no Brasil, 2001. Disponível em
<http://www.ibge.gov.br/home/estatistica/economia/microempresa/default.shtm >, acessado em
18 de novembro de 2006.
KEAN, Liz; Requirements Tracing--An Overview; Software Engineering Institute; Disponível
em < http://www.sei.cmu.edu/str/descriptions/reqtracing_body.html>, acessado em 30/06/2006.
KELLY, Declan, P., CULLETON, Bill; Process Improvement for Small Organizations; IEEE
Computer, Volume 32, number 10, October 1999.
KRUCHTEN, Philippe; Introdução ao RUP – Rational Unified Process, Rio de Janeiro: Editora
Ciência Moderna Ltda, 2003.
LAMSWEERDE, Axel Van; Goal-Oriented Requirements Engineering: A guided Tour. August
2001, 5th IEEE International Symposium on Requirements Engineering, Toronto, August 2001,
249-263.
133
LARMAN, Craig; Utilizando UML e Padrões – Uma Introdução à Análise e ao Projeto
Orientado a Objetos e ao Processo Unificado. Tradução Luiz Augusto Meirelles Salgado e João
Tortello; 2.ed. Porto Alegre: Editora Bookman 2004.
LEITE, Júlio César Sampaio do Prado; FRANCO, Ana Paula M.; A Strategy for conceptual
Model Acquisition; In: International Symposium on Requirements Engineering, 1., SanDiego,
Ca. Proceedings… IEEE Computer Society Press, p. 243-246. 1993.
LEITE, Júlio César Sampaio do Prado; ROSSI, Gustavo; BALAGUER, Federico;
MAIORANA, Vanesa; KAPLAN, Gladys HADAD, Graciela OLIVEROS, Alejandro;
Enhancing a Requirements Baseline with Scenarios; Requirements Engineering, pp. 184-198,
Springer-Verlag London, 1997.
MARTINS, José Carlos Cordeiro; Gerenciando projetos de desenvolvimento de software com
PMI, RUP e UML / José Carlos Cordeiro Martins, - 2. Ed. Rev. Rio de Janeiro : Brasport,
2005.
MCT – Ministério da Ciência e Tecnologia; Caracterização das Organizações; Pesquisa Censo
SW, Agosto de 2001 Disponível em
<http://www.mct.gov.br/index.php/content/view/15517.html > acessado em 01/12/2006.
MONTONI, Mariano; Uma Abordagem de Garantia de Qualidade de Processos e Produtos de
Software com Apoio de Gerência de Conhecimento na Estação TABA; V Simpósio Brasileiro
de Qualidade de Software; SBQS 2006.
MPS/BR, Melhoria de Processo de Software Brasileiro, Guia de Geral, Disponível em
<http://www.softex.br/mpsbr/_guias/default.asp>, acessado em 18 de novembro de 2006.
NASCIMENTO, Hugo A D., FERREIRA, Cristiane B R.; Visualização de Informações – uma
Abordagem Prática, XXV Congresso da Sociedade Brasileira de Computação, XXIV JAI,
Unisinos, 22 a 29 de Julho , 2005.
134
NATALI, Ana Candida Cruz; FALBO, Ricardo de Almeida; Uma Infra-estrutura para Gerência
de Conhecimento em ODE; Anais da X Sessão de Ferramentas do Simpósio Brasileiro de
Engenharia de Software - SBES'2003, p.13-18, Manaus - Amazonas, Outubro 2003.
NI TSCHE, Raquel; BORTOLI, Lis Ângela de; E-LAL: Um Editor Para o Léxico Ampliado da
Linguagem; Revista de Ciência da Computação, Volume 5, Número 3, Setembro de 2006.
NUSEIBEH, Bashar; EASTERBROOK, Steve; Requirements Engineering: A Roadmap;
Proceedings of International Conference on Software Engineering (ICSE-2000), 4-11 June
2000, Limerick, Ireland.
OBJECTIVER; Software Objectiver 1.5.1 e Objectiver User Guide, CEDITI, 2003. Disponível
em <http://www.objectiver.com>, acessado em 20 de maio de 2006.
PADUA, Wilson Paula Filho; Engenharia de Software – Fundamentos, Métodos e Padrões. 2ª
edição. Rio de Janeiro, LTC, 2003.
PIETROBON, Carlos Alberto Marques Pietrobon, Projeto Discovery, Relatório Técnico, RT
01/2007, PPGEE, 2007.
PMBOK, Project Management Body of Knowledge; Terceira Edição, 2004 Project
Management Institute.
PRESSMAN, Roger S. Engenharia de Software. 5 ed. Rio de Janeiro; McGraw-Hill, 2002.
RAMESH, Balasubramaniam; Factors Influencing Requirements Traceability Practice;
Communications of The ACM, December 1998 / Vol. 41. número 12.
RAMESH, Balasubramaniam; Process Knowledge Management with Traceability; IEEE
Computer Society Press , May/June 2002.
135
RAMESH, Balasubramaniam; JARKE, Matthias; Toward Reference Models for Requirements
Traceability; IEEE Transactions on Software Engineering, vol. 27, número 1, January 2001.
SAYÃO, Miriam; LEITE, Julio Cesar Sampaio do Prado; Rastreabilidade de Requisitos;
Revista de Informática Teórica e Aplicada, Volume XII, Número 1, 2005.
SEBRAE, Serviço Brasileiro de Apoio às Micro e Pequenas Empresas; Critérios de
Classificação do Porte da Empresa; Disponível em <
http://www.sebrae.com.br/br/aprendasebrae/estudosepesquisas.asp>, acessado em 20 de
novembro de 2006..
SILVA, Lyrene Fernandes; LEITE, Julio César Sampaio do Prado; Silva, BREITMAN, Karin
Koogan; C&L: Uma Ferramenta de Apoio à Engenharia de Requisitos; Revista de Informática
Teórica e Aplicada; volume XII, número 1, página 23, junho 2005.
SOMMERVILLE, Ian; Engenharia de Software; Tradução André Maurício de Andrade
Ribeiro; revisão técnica Kechi Hirama; São Paulo; Editora Pearson Addison Wesley; 6a edição;
2003.
SPECIA, Lucia; RINO, Lucia Helena Machado; O Desenvolvimento de um léxico para a
geração de estruturas conceituais UNL; Série de Relatórios do Núcleo Interinstitucional de
Lingüística Computacional; NILC-TR-02-14; USP; Setembro, 2002.
TOGNERI Denise F., FALBO, Ricardo de Almeida, MENEZES, Crediné S., WERNESBACK,
Bernando S., ALMEIDA, Diogo Q; CÔRTES, Marina F. Utilizando Conhecimento
Organizacional no apoio à Engenharia de Requisitos Cooperativa, II Workshop de Tecnologia
de Informação e Gerência de Conhecimento, III Simpósio Brasileiro de Qualidade de Software
- SBQS'2004, Brasília, Brasil, Junho 2004.
TORANZO, Marco; CASTRO, Jaelson F. B.; MELLO, Elton; Uma Proposta para Melhorar o
Rastreamento de Requisitos; V Workshop de Engenharia de Requisitos; Valencia, Espanha,
11-12, Novembro de 2002.
136
TUOMI, Iikka; Date Is More Than Knowledge: Implications of the Reversed Knowledge
Hierarchy for Knowledge Management and Organizational Memory; System Sciences, HICSS-
32. Proceedings of the 32nd Annual Hawaii International Conference on
1999.
137
APÊNDICE A - XML do modelo de meta do estudo de caso 1
<?xml version="1.0" encoding="ISO-8859-1"?>
<DIAGRAM>
<PROJECT>
<ID>0</ID>
<ACRONYM></ACRONYM>
<CAPTION>Licenciados</CAPTION>
<NAME>obj0</NAME>
<TOP>28</TOP>
<LEFT>376</LEFT>
</PROJECT>
<GOALS>
<GOAL>
<NAME>obj1</NAME>
<TOP>172</TOP>
<LEFT>271</LEFT>
<CAPTION>Gerenciamento</CAPTION>
<HOW>Controlar melhor a distribuição das sementes.
Controlar a comercialização das sementes.
Controlar o faturamento a ser cobrado a título de royalty</HOW>
<WHY>O negócio da empresa é a pesquisa e não a produção e comercialização de sementes para plantio, desta
forma é de vital importância conhecer as informações de negócio para o planejamento e o futuro da
empresa.</WHY>
<DESCRIPTION>Melhorar o gerenciamento da distribuição de sementes entre os licenciados</DESCRIPTION>
<COLOR>clBlack</COLOR>
</GOAL>
<GOAL>
<NAME>obj2</NAME>
<TOP>280</TOP>
<LEFT>129</LEFT>
<CAPTION>Controle</CAPTION>
<HOW>Através da confecção dos planos de comercialização, produção e marketing.</HOW>
<WHY>É necessário o controle da distribuição para conhecer e efetuar o planejamento do que tem que ser
produzido e identificar as técnicas a serem utilizadas no plantio. Melhorando o gerenciamento.</WHY>
<DESCRIPTION>Controlar a distribuição de sementes.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</GOAL>
<GOAL>
138
<NAME>obj3</NAME>
<TOP>286</TOP>
<LEFT>338</LEFT>
<CAPTION>Comercialização</CAPTION>
<HOW>Recolhendo mensalmente as informações de comercialização dos licenciados através da fatura.
Recolher informações de comercialização dos concorrentes através de um levantamento de mercado.
</HOW>
<WHY>Através das informações de comercialização consegue-se visualizar se o planejado foi alcançado e fazer o
cálculo do royalty. Permiti também idenfificar o foco de maior potencial agrícola e de mercado. </WHY>
<DESCRIPTION>Controlar a comercialização das vendas da sementes feitas pelos
licenciados.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</GOAL>
<GOAL>
<NAME>obj9</NAME>
<TOP>168</TOP>
<LEFT>530</LEFT>
<CAPTION>Redução de Custos</CAPTION>
<HOW></HOW>
<WHY></WHY>
<DESCRIPTION></DESCRIPTION>
<COLOR>clYellow</COLOR>
</GOAL>
</GOALS>
<REQUERIMENTS>
<REQUERIMENT>
<NAME>obj4</NAME>
<TOP>409</TOP>
<LEFT>29</LEFT>
<CAPTION>Plano de Produção</CAPTION>
<DESCRIPTION>Permitir cadastrar o plano de produção solicitado pelo licenciado, com os dados técnicos
relativo a produção da semente.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj5</NAME>
<TOP>412</TOP>
<LEFT>252</LEFT>
<CAPTION>Plano de Marketing</CAPTION>
<DESCRIPTION>Permitir cadastrar o plano de marketing contendo as informações de mercado da região a qual
se pretende atuar.</DESCRIPTION>
139
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj6</NAME>
<TOP>411</TOP>
<LEFT>141</LEFT>
<CAPTION>Pl. Comercialização</CAPTION>
<DESCRIPTION>Permitir cadastrar os dados relativos aos valores de previsão de venda das sementes produzidas,
bem como as regiões e as formas de comercialização.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj7</NAME>
<TOP>414</TOP>
<LEFT>371</LEFT>
<CAPTION>Receber Fatura</CAPTION>
<DESCRIPTION> Permitir cadastrar os dados da fatura emitida pelo licenciado na venda dos produtos licenciados
para comercialização.
</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj8</NAME>
<TOP>502</TOP>
<LEFT>371</LEFT>
<CAPTION>Calcular Royalty</CAPTION>
<DESCRIPTION> Calcular o valor do Royalty a ser pago pelo licenciado a partir dos dados da fatura e do tipo de
produto comercializado. </DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
</REQUERIMENTS>
<ASSOCIATIONS>
<ASSOCIATION>
<OBJINI>obj1</OBJINI>
<OBJFIM>obj0</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj2</OBJINI>
<OBJFIM>obj1</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
140
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj3</OBJINI>
<OBJFIM>obj1</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj4</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj5</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj2</OBJINI>
<OBJFIM>obj6</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj7</OBJINI>
<OBJFIM>obj3</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj5</OBJINI>
<OBJFIM>obj3</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj8</OBJINI>
<OBJFIM>obj7</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj9</OBJINI>
<OBJFIM>obj0</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
141
</ASSOCIATIONS>
</DIAGRAM>
142
APÊNDICE B - XML do modelo de meta do estudo de caso 2
<?xml version="1.0" encoding="ISO-8859-1"?>
<DIAGRAM>
<PROJECT>
<ID>0</ID>
<ACRONYM></ACRONYM>
<CAPTION>Estatística</CAPTION>
<NAME>obj0</NAME>
<TOP>16</TOP>
<LEFT>285</LEFT>
</PROJECT>
<GOALS>
<GOAL>
<NAME>obj1</NAME>
<TOP>126</TOP>
<LEFT>171</LEFT>
<CAPTION>Conhecer Fatur.</CAPTION>
<HOW>Apresentando a estatística de faturamento da empresa. </HOW>
<WHY>Para melhorar a gerência da empresa com relação aos recursos disponíveis para o trabalho.</WHY>
<DESCRIPTION>Conhecer a característica do faturamento no período.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</GOAL>
<GOAL>
<NAME>obj2</NAME>
<TOP>124</TOP>
<LEFT>387</LEFT>
<CAPTION>Disp. de Recursos.</CAPTION>
<HOW>Comparar o faturamento mensal com o mesmo período do ano anterior.
Comparar o faturamento mensal com o faturamento total do ano anterior e com o ano atual</HOW>
<WHY>Para verificar as sazonalidades do faturamento.</WHY>
<DESCRIPTION>Melhorar a alocação dos recursos de acordo com as característica do faturamento mensal e
anual.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</GOAL>
</GOALS>
<REQUERIMENTS>
<REQUERIMENT>
<NAME>obj3</NAME>
<TOP>234</TOP>
143
<LEFT>136</LEFT>
<CAPTION>Fat. Mensal.</CAPTION>
<DESCRIPTION>Totalizar o faturamento mensal da empresa com relação ao mes analisado e com relação ao ano
anterior.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj4</NAME>
<TOP>239</TOP>
<LEFT>276</LEFT>
<CAPTION>Fat. Anual</CAPTION>
<DESCRIPTION>Totalizar o faturamento anual da empresa com relação ao ano analizado e ao ano
anterior</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj5</NAME>
<TOP>241</TOP>
<LEFT>398</LEFT>
<CAPTION>Com. Faturamento</CAPTION>
<DESCRIPTION>Comparar e calcular o percentual do faturamento mensal, mês analisado em relação ao mesmo
mês do ano anterior. Calcular a relação do faturamento mensal com o faturamento total do ano.
</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
<REQUERIMENT>
<NAME>obj6</NAME>
<TOP>340</TOP>
<LEFT>276</LEFT>
<CAPTION>Gráfico</CAPTION>
<DESCRIPTION>Fazer um gráfico das relações calculadas.</DESCRIPTION>
<COLOR>clBlack</COLOR>
</REQUERIMENT>
</REQUERIMENTS>
<ASSOCIATIONS>
<ASSOCIATION>
<OBJINI>obj1</OBJINI>
<OBJFIM>obj0</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
144
<OBJINI>obj1</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj2</OBJINI>
<OBJFIM>obj0</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj3</OBJINI>
<OBJFIM>obj1</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj3</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj4</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj5</OBJINI>
<OBJFIM>obj2</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj6</OBJINI>
<OBJFIM>obj5</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj6</OBJINI>
<OBJFIM>obj4</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
<ASSOCIATION>
<OBJINI>obj6</OBJINI>
145
<OBJFIM>obj3</OBJFIM>
<CONTRIBUTION>INC</CONTRIBUTION>
</ASSOCIATION>
</ASSOCIATIONS>
</DIAGRAM>
146
APÊNDICE C – Formação do banco de conhecimento
• Léxico: Esta classe contém tudo do sistema. Ou seja, é um grande dicionário de
qualquer atividade, artefato, gestão, situação, regra de negócios.
o Exemplo:
Atendimento
Fatura
Pagamento
Itens Pagamento
Atividade
Fases
• Domínio: Classificação dos domínios do conhecimento a ser trabalhado no sistema.
o Exemplo:
Médico
Contábil.
Recursos Humanos.
• Léxico domínio: é o agrupamento dos léxicos em um determinado domínio. Ou seja, o
dicionário de um domínio.
o Exemplo:
Médico :
• Atendimento.
• Procedimento.
Contábil:
• Grupo de Contas.
• Conta de crédito.
• Contra Partida
Recursos Humanos
• Folha de pagamento.
• Recrutamento
• TipoLéxico:
• Classe que irá conter todos os tipos de léxico do projeto. Um léxico poderá
existir em mais de um tipo. Podemos ter o léxico Atendimento (registro dos
atendimentos médicos), este Atendimento poderá ser uma classe e também uma tabela.
147
Para que possamos representar, por exemplo: A classe atendimento é mapeada para a
tabela atendimento.
o A classe atendimento: Sujeito.
o é mapeada : ação.
o A tabela atendimento: Objeto
• Exemplo:
o Meta
o Requisito
o Ator
o Classe
o Caso de Uso
o Tabela
o Campos
o Regras de negócio.
o História.
o Estado ou condição (tabelas descritivas).
• LéxicoTipo:
• Classe que irá agrupar os léxicos em seus tipos.
o No Exemplo anterior o léxico Atendimento estará ligado ao tipo de
léxico classe e e ao tipo de léxico atendimento.
o A importância deste tipo de modelagem é permitir para um
determinado léxico ter um conceito geral independente do tipo de léxico que
pertencer, e ainda, poder ter um conceito diferente de acordo com o tipo de
léxico. Irá facilitar também a consulta uma vez que na rastreabilidade pode-se
verificar todas as situações que um determinado léxico poderá ter.
• Conceito:
• Classe que irá permitir conter tanto o conceito do léxico, quanto o conceito
do léxico de acordo com o seu tipo.
• Conhecimento:
• Classe que contém todo o conhecimento armazenado no sistema. Representa
a relação entre o léxicoTipo de acordo com o relacionamento existente entre eles, dentro
do contexto, sujeito (LexicoTipo pai), verbo (relacionamento), Objeto (lexicotipo filho)
e se for o caso estado (lexicoTipo Estado).
148
• Relacionamento:
• Classe que irá conter todos os tipos de relacionamento que poderão existir
entre os léxicos. Para cada tipo de relacionamento tem-se a voz ativa e a voz passiva.
Estes relacionamentos são os verbos ou ação na ligação do sujeito e objeto. Exemplo:
o No repasse deverão ser calculados os impostos para todos os valores
acima de 2000.
Desta história pode-se efetuar duas análises:
1 Análise – feita na história:
• A classe repasse: sujeito.
• Deverá calcular: ação
• Impostos: objeto
• Valores acima de 2000: estado ou condição
2 análise – feita a partir do modelo
• A classe Repasse: Sujeito.
• tem a: ação.
• Classe impostos : Objeto
o A classe impostos: sujeito.
o É formada por: relacionamento.
o O método calcular impostos: objeto
o Valores acima de 2000: estado ou condição
• Exemplo:
o Formação:
Voz Ativa: é formada por
Voz Passiva: foi formada por
o Suporte:
Voz ativa: é suportado.
Voz passiva: foi suportado.
o Mapeamento.
Voz ativa: é mapeada.
Voz passiva: é um mapeamento de:
o Narrativa.
Voz ativa: é narrada por.
Voz passiva: é uma narrativa do:
149
• formação.
• Classe que irá conter todos os possíveis tipos de relacionamento existentes
entre dois tipo de léxico.
• Exemplo:
o O tipo de léxico requisito tem o relacionamento de Narrativa com o
tipo de léxico história. ou seja, Um Requisito é narrado por uma história.
o O tipo de léxico classe tem o relacionamento de mapeamento para o
tipo de léxico tabela: ou seja, uma classe é mapeada para uma tabela.
• Contexto:
• O contexto caracteriza-se por um agrupamento do conhecimento, dentro de
um determinado assunto, de acordo com a necessidade de geração do conhecimento
dentro da empresa:
o Exemplo:
Desenvolvimento.
Processo.
Gestão.
Etc.
• Visão:
• É o agrupamento de conceitos que deverão ser rastreados juntos dentro de
uma determinada necessidade.
o Exemplo:
Visão Gestão.
Visão de Processo
Visão técnica.
• Situação:
• Consiste nas situações que um determinado conhecimento pode passar.
o Exemplo:
Em Estudo (em formação).
Gerado