Agentes no Processo de Requisitos
Miriam Sayão
orientador: Julio Cesar S. P. Leite
Roteiro
•
•
•
•
•
motivação
proposta
estágio atual
contribuições
trabalhos relacionados
Software Engineering Lab (LES) – PUC-Rio
2
Ambientes distribuídos de desenvolvimento
• adotado por muitas multinacionais (HP, Motorola,
Dell, Sonae, ....)
• dificuldades associadas a ambientes distribuídos de
desenvolvimento:
– diversidade cultural e diferenças lingüísticas afetam a
compreensão comum dos requisitos
– delays devidos aos diferentes fusos horários impactam
nas atividades normalmente executadas de forma
presencial (elicitação, priorização e negociação)
– informação inadequadamente compartilhada afeta a
confiança entre equipes e impacta atividades do
processo de desenvolvimento
Software Engineering Lab (LES) – PUC-Rio
3
Processo de Requisitos em ambientes
distribuídos
• processo de requisitos: intensivo em comunicação
• comunicação em projetos distribuídos:
– utiliza por volta de 22% do tempo total do
desenvolvimento [Gorton96]
– atividades de cognitive synchronization* são responsáveis
por aproximadamente 29% do tempo de desenvolvimento
[Cherry04]
– 15 a 41% do tempo total do desenvolvimento [estudos
relacionados em Cherry04]
*
atividades de comunicação entre dois ou mais desenvolvedores, visando confirmar que eles
compartilham o mesmo conhecimento ou a mesma representação do objeto em questão
Software Engineering Lab (LES) – PUC-Rio
4
Processo de Requisitos em ambientes
distribuídos: motivação
• distribuição não atinge processo de requisitos
– a) uma equipe se desloca até os usuários para a aquisição
dos requisitos
– b) essa equipe elabora o documento de requisitos e o
repassa à equipe de desenvolvimento
– c) o mesmo documento é utilizado pela equipe que
prepara e executa a bateria de testes
• isto acontece porque .....
– a) tentativa de diminuir problemas de comunicação
– b) ferramentas existentes são inadequadas para
ambientes distribuídos
Software Engineering Lab (LES) – PUC-Rio
5
Proposta: agentes no processo de requisitos
• objetivo principal: contribuir para a viabilização da
distribuição das atividades no processo de
requisitos
• nossa proposta: uso de agentes de software
– atuando como assistentes dos interessados do processo
de requisitos
– monitorando ocorrência de eventos significativos e
notificando automaticamente os interessados
– auxiliando na sistematização do conhecimento da
organização
Software Engineering Lab (LES) – PUC-Rio
6
Agentes: por quê?
• soluções com agentes são indicadas para:
– problemas complexos
– de natureza distribuída
– naqueles onde atores desempenham diferentes
papéis e interagem visando atingir diferentes
objetivos
• uso de agentes nas atividades de gerenciamento de
requisitos, com ênfase às atividades de verificação
e validação de requisitos
Software Engineering Lab (LES) – PUC-Rio
7
Resultados esperados
• efetiva distribuição do trabalho no processo de
requisitos
• diminuição das tarefas hoje executada por humanos
• diminuição dos problemas derivados de falhas na
comunicação
Software Engineering Lab (LES) – PUC-Rio
8
Processo distribuído de requisitos
• verificação: inspeção do documento de requisitos (SRS)
– inspeção: utilização de uma técnica de leitura aplicável a um
artefato, buscando a localização de erros ou defeitos no mesmo
– exemplo de técnica de leitura onde são consideradas as visões:
Perspective Based Reading
• validação: engenheiro de requisitos e representantes do
cliente e dos usuários avaliam o SRS com o objetivo de
assegurar que os requisitos relacionados no SRS
correspondem ao esperado pelos usuários e cliente
• diferentes visões na validação e verificação do SRS
• diferentes metas e intencionalidades por parte dos atores,
passíveis de modelagem com a notação i*
Software Engineering Lab (LES) – PUC-Rio
9
Processo de requisitos: diagrama SD
Goal
Resource
Softgoal
Agent
Role
Software Engineering Lab (LES) – PUC-Rio
Position
10
Estágio atual
• cada meta dos atores do SD é decomposta em
tarefas e modelada em diagramas SR
• elaboração dos diagramas SR - Strategic Rationale,
para os diversos agentes
• definição e atribuição das tarefas a agentes
• experimentos com uso da linguagem natural para:
– criação de visões dos requisitos
– tratamento da rastreabilidade
– apoio à manutenção do léxico da aplicação
• definição de características da ferramenta de apoio
Software Engineering Lab (LES) – PUC-Rio
11
Ferramenta de apoio
• características de:
– agência: diferentes papéis a serem desempenhados pelos
agentes, na representação dos interessados reais;
– serviços de comunicação: para troca de informações
entre usuários e agentes de software, e para notificação
dos interessados na ocorrência de eventos;
– serviços de monitoramento: para monitoramento de
modificações no ambiente e eventos significativos nesse
contexto;
– persistência de dados:
• base de conhecimento organizacional
• baseline para artefatos de requisitos
• informações relacionadas a projetos
Software Engineering Lab (LES) – PUC-Rio
12
stakeholders
assistentes
assistentes
mensagens
mensagens
Base de
conhecimentos
da
organização
mensagens
Repositório
do projeto
notificações
mensagens
Blackboard para comunicação
Software Engineering Lab (LES) – PUC-Rio
13
Atores e agentes assistentes
• Coordenador do projeto ou administrador - responsável
pelo cadastramento de novos usuários e definição dos
direitos de acesso aos artefatos, pela criação e
acompanhamento de projetos;
• Engenheiro de Requisitos - responsável pelo documento de
requisitos, pela organização dos processos de verificação e
validação;
• Cliente/Usuário - uma das principais fontes para requisitos,
cliente e usuário participam ativamente nos processos de
validação e verificação do documento de requisitos;
• Inspetor - papel a ser desempenhado por diferentes
usuários do sistema no processo de verificação do
documento de requisitos; deve ser parametrizado para
executar diferentes tipos de verificação;
Software Engineering Lab (LES) – PUC-Rio
14
Agentes de software
• Rastreador - responsável pela construção de matrizes de
rastreabilidade, e pela verificação destas matrizes com
aquelas fornecidas pelo engenheiro de requisitos,
apontando as divergências e apresentando a opção de tratar
ou não cada uma das divergências apontadas;
• Construtor do léxico - responsável pela manutenção do
léxico da aplicação, visando à atualização da base de
conhecimentos para o domínio da organização;
• Gerador de visões - responsável pela construção e
apresentação de visões dos requisitos, de acordo com perfil
ou interesse manifestado pelos usuários do sistema;
Software Engineering Lab (LES) – PUC-Rio
15
Agentes de software
• Observador - responsável pela observação dos artefatos e,
em caso de alteração, é o responsável por notificar os
interessados. Também é de sua responsabilidade manter a
consistência de versões entre repositórios;
• Comunicador - envia mensagens e notificações a agentes e
usuários através de diferentes meios de comunicação;
• Verificador - responsável pela coleta e distribuição dos
artefatos para a verificação, envio de notificação aos
envolvidos e consolidação parcial do relatório;
• Validador - responsável pela coleta e distribuição dos
artefatos para a validação, envio de notificação aos
envolvidos e consolidação parcial do relatório;
Software Engineering Lab (LES) – PUC-Rio
16
Agentes: definição de responsabilidades
Papel: Rastreador
Sistema: REDist
Responsabilidades
Serviço: gerar matriz RNF x RF Serviço: gerar matriz
Nome: gerarMatRast
verificacão
Nome: gerarMatTest
Recursos
Dados
Serviços requeridos
Base
Tabela
Driver
redist
Requisitos MySql
Redist
Rastros
MySql
redist
Testes
MySql
Software Engineering Lab (LES) – PUC-Rio
17
Agente gerador de visões dos requisitos
• "Topic maps are a new ISO standard for describing
knowledge structures and associating them with
information resources" - Steve Pepper
• entidades básicas: tópicos e associações
• associações podem ser utilizadas para:
– apresentação de diferentes visões dos requisitos
– mostrar a rede de dependências entre requisitos
– mostrar ligações de requisitos a outros artefatos
• documentos em XML podem ser transformados em
XTM utilizando Stylesheets
Software Engineering Lab (LES) – PUC-Rio
18
Visão dos requisitos associados ao RNF segurança
Software Engineering Lab (LES) – PUC-Rio
19
Visão dos requisitos associados ao RNF segurança
Software Engineering Lab (LES) – PUC-Rio
20
Visão dos requisitos alocados a componentes
Software Engineering Lab (LES) – PUC-Rio
21
Visão dos requisitos verificados por testes
Software Engineering Lab (LES) – PUC-Rio
22
Agente Rastreador: tratamento da rastreabilidade
• pré-rastreabilidade:
– origem do requisito é um dos atributos registrados
• matriz de rastreabilidade RF x RNF: geralmente feita de
forma manual
• para geração automática, definimos algumas heurísticas:
– análise de documentos de requisitos de uma organização que
desenvolve em ambientes distribuídos
– identificação de termos ou expressões associados a requisitos nãofuncionais
– varredura do documento de requisitos e identificação dos requisitos
funcionais associados ao requisito não-funcional
Software Engineering Lab (LES) – PUC-Rio
23
Agente Rastreador: tratamento da rastreabilidade
• matriz de rastreabilidade RF x RNF
– uso de uma das taxonomias já publicadas, associando a
cada RNF palavras ou expressões utilizados na
organização
– RNF segurança: associado às expressões logon ou login,
logoff, senha ou password, perfil de usuário, controle de
acesso, ...
Software Engineering Lab (LES) – PUC-Rio
24
Tratamento da rastreabilidade
PROJETO EXIT - MATRIZ DE RASTREABILIDADE
RF X RNF
REQUISITOS NÃO FUNCIONAIS
REQUISITOS
FUNCIONAIS NFR1 NFR2 NFR3 NFR4 NFR5 NFR6
RF1
X
X
........
RF14
X
RF15
X
RF16
X
RF17
X
X
X
.......
Software Engineering Lab (LES) – PUC-Rio
25
Tratamento da linguagem natural
• experimentos com tratamento da linguagem
natural:
– a) identificação de palavras ou expressões próprias do
domínio da aplicação, visando à construção do Universo
de Informações (offshore insourcing)
– b) explicitação das diferenças culturais entre
interessados
Software Engineering Lab (LES) – PUC-Rio
26
Tratamento da linguagem natural
• comparação de palavras e expressões com
"dicionário" resulta em:
– diferenças culturais entre Brasil e Portugal explicitadas
•
•
•
•
•
•
•
por defeito representando por default
aceder ao invés de acessar
sinalética ao invés de ícone
multibanco para tipo de pagamento
ecrã ao invés de monitor ou tela
villas significando resort
utilizador, aluguer, telemóvel, ficheiro
Software Engineering Lab (LES) – PUC-Rio
"dicionário
de
viagem"
27
Agentes verificador e construtor do léxico
• Construtor:
– identificação de palavras que deveriam constar do léxico da
aplicação
• ACE, BIZTALK, RESTEL, SAP ......
• cofidis, dossier, markup, .......
– verificação de inconsistências com o léxico existente
• Verificador:
– RNF segurança(logon ou login, logoff, password ou
senha): deve haver ao menos um requisito associado a
cada expressão do RNF segurança
Software Engineering Lab (LES) – PUC-Rio
28
Contribuições
• uso de agentes de software como assistentes dos
stakeholders, visando à automação parcial de atividades do
processo de requisitos e diminuição dos problemas de
comunicação entre sites em ambientes distribuídos
• tratamento da rastreabilidade: técnica para geração e
verificação de matrizes de rastreabilidade
• técnica para geração de visões dos requisitos, apoiando
tarefas de gerenciamento e desenvolvimento
• técnica para recuperação e sistematização do conhecimento
organizacional (UdI)
• criação de um ambiente flexível e extensível para
atividades de Gerenciamento de Requisitos
Software Engineering Lab (LES) – PUC-Rio
29
Trabalhos relacionados
• visam à criação de MTF´s para ambientes distribuídos
• abordam aspectos pontuais e não utilizam agentes
• priorização de requisitos:
– uso distribuído da técnica Quality Function Deployment (QFD) para
definição dos requisitos; comunicação entre os interessados
realizada com o uso de equipamentos de teleconferência [Hrones93]
– priorização distribuída, com objetivo de avaliar diferentes
segmentos do mercado para definir os requisitos [Regnell01]
Software Engineering Lab (LES) – PUC-Rio
30
Trabalhos relacionados
• negociação de requisitos:
– uso de um facilitador para a condução de processos de negociação
de requisitos envolvendo interessados geograficamente separados
[Damian01] [Damian03]
• verificação do documento de requisitos:
– inspeção segundo a técnica PBR, apoiada pela ferramenta IBIS. IBIS
armazena o documento a ser inspecionado, possibilita o cadastro e a
seleção dos inspetores, fornece checklists e formulários e registra os
problemas detectados por cada um deles [Lanubile03]
Software Engineering Lab (LES) – PUC-Rio
31
Trabalhos relacionados
• evolução de requisitos:
– uso de agentes móveis para controle da evolução de requisitos em
ambientes distribuídos [Chang03]
• gerenciamento de processos distribuídos:
– projeto GENESIS: uso de agentes de software, de técnicas de
workflow e de gerenciamento de documentos para gerenciamento de
projetos e comunicação entre engenheiros de software
– agentes: responsáveis pela manipulação de exceções, pela
sincronização de processos entre os sites distribuídos e pela
monitoração e coleta de informações relacionadas a processos
– uso de agentes: abordagem menos invasiva para atividades de
coordenação e controle entre sites
Software Engineering Lab (LES) – PUC-Rio
32
Conclusões
• paradigma de agentes: apropriado para o processo de
requisitos em ambientes distribuídos
• agentes atuando como assistentes de usuários, clientes,
engenheiro de requisitos, projetistas, engenheiros de
software e desenvolvedores
• pró-atividade dos agentes diminuindo parte dos problemas
decorrentes de falhas na comunicação em ambientes
distribuídos
• agentes e atores atuando visando atingir seus próprios
objetivos, e colaborando visando atingir um objetivo
comum: um documento de requisitos de qualidade e que
reflita as necessidades de clientes e usuários
Software Engineering Lab (LES) – PUC-Rio
33
Bibliografia
Chang, C.; Cai, L. "Agent based Requirements Evolution over the Internet".
In: IEEE Workshop on Software Engineering on the Internet, The IEEECS/IPSJ 2001 Symposium on Applications and the Internet (SAINT 2001),
Jan. 8-12, 2001, pp. 83-88.
Cherry, S. & Robillard, P. "Communication Problems in Global Software
Development: Spotlight on a New Field of Investigation". In: Third
International Workshop on Global Software, May 24, 2004, Edinburgh,
Scotland. Proceedings. http://gsd2004.uvic.ca/
Damian, D.; Eberlein, A.; Woodward, B.; Shaw, M. & Gaines, B. "An
empirical study of facilitation of computer-mediated distributed
requirements negotiations". In: Fifth IEEE International Symposium on
Requirements Engineering (RE '01), August 27 - 31, 2001. Toronto,
Canadá. Proceedings. pp. 128-135.
Software Engineering Lab (LES) – PUC-Rio
34
Bibliografia
Damian, D.; Eberlein, A.; Shaw, M. & Gaines, B. "Facilitation in Distributed
Requirements Engineering". Requirements Engineering Journal, 8(1),
2003, pgs 23-41.
Gorton, I. & Motwani, S. “Issues in Co-operative Software Engineering Using
Globally Distributed Teams”. In: Information and Software Technology
Journal ,vol 38(10), 1996. págs. 647-655.
Hersleb, J. & Mockus, A. "An empirical study of speed and communication in
globally distributed software development". IEEE Transactions on
Software Engineering, vol 29(6), pags. 481-494
Lanubile, F.; Mallardo, T. "Preliminary Evaluation of Tool-based Support for
Distributed Inspection". In: 26th Annual International Computer Software
and Applications Conference (COMPSAC’02). Proceedings.
Software Engineering Lab (LES) – PUC-Rio
35
Bibliografia
Leite, Julio C. S. P. – Engenharia de Requisitos – notas de aula, 1994
Leite, J. C. S. P. et al. "Enhancing a Baseline Requirements with Scenarios".
In: Third International Symposium on Requirements Engineering, 1997.
IEEE Computer Society. Proceedings. pags. 44-53
Regnell,B.; Höst, M.; Natt,J.; Beremark, P. & Hjelm, T. "An industrial case
study on distributed prioritization in market-driven requirements
engineering for packaged software". Requirements Engineering Journal
6(1), 2001, pgs. 51-62.
Sayão, M. & Leite, J. C. S. P. – Rastreabilidade de Requisitos – relatório
técnico 20/05, série Monografias em Ciência da Computação, DI/PUCRio, 2005.
Software Engineering Lab (LES) – PUC-Rio
36