Agentes no Processo de Requisitos

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

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

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

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

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

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

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

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 leituraonde 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

Goal Softgoal Resource Agent Role Position Processo de requisitos: diagrama SD Software Engineering Lab (LES) – PUC-Rio

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

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

Base de conhecimentos da organização Repositório do projeto stakeholders assistentes assistentes mensagens mensagens mensagens notificações mensagens Blackboard para comunicação Software Engineering Lab (LES) – PUC-Rio

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

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

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

Agentes: definição de responsabilidades Software Engineering Lab (LES) – PUC-Rio

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

Visão dos requisitos associados ao RNF segurança Software Engineering Lab (LES) – PUC-Rio

Visão dos requisitos alocados a componentes Software Engineering Lab (LES) – PUC-Rio

Visão dos requisitos verificados por testes Software Engineering Lab (LES) – PUC-Rio

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ão-funcionais • varredura do documento de requisitos e identificação dos requisitos funcionais associados ao requisito não-funcional Software Engineering Lab (LES) – PUC-Rio

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

Tratamento da rastreabilidade Software Engineering Lab (LES) – PUC-Rio

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 (offshoreinsourcing) • b) explicitação das diferenças culturais entre interessados Software Engineering Lab (LES) – PUC-Rio

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 "dicionário • sinalética ao invés de ícone de • multibanco para tipo de pagamento viagem" • ecrã ao invés de monitor ou tela • villas significando resort • utilizador, aluguer, telemóvel, ficheiro Software Engineering Lab (LES) – PUC-Rio

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

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

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

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

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

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

Bibliografia Chang, C.; Cai, L. "Agent based Requirements Evolution over the Internet". In: IEEE Workshop on Software Engineering on the Internet, The IEEE-CS/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

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

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/PUC-Rio, 2005. Software Engineering Lab (LES) – PUC-Rio

Agentes no Processo de Requisitos