A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Agentes no Processo de Requisitos

Apresentações semelhantes


Apresentação em tema: "Agentes no Processo de Requisitos"— Transcrição da apresentação:

1 Agentes no Processo de Requisitos
Miriam Sayão orientador: Julio Cesar S. P. Leite

2 trabalhos relacionados
Roteiro motivação proposta estágio atual contribuições trabalhos relacionados Software Engineering Lab (LES) – PUC-Rio

3 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 Mesmo interessados que falam uma mesma língua (portugues, por exemplo) podem interpretar de forma diferente uma mesma expressão Mesmo existindo um repositório centralizado, cada equipe acaba mantendo sua própria base de informações que nem sempre são compartilhadas Software Engineering Lab (LES) – PUC-Rio

4 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 são mais intensas em ambientes distribuídos; vários estudos realizaram experimentos e medições visando identificar o quanto a comunicação representa no desenvolvimento de um software Gorton: 22% do tempo total de desenvolvimento de um sistema são utilizados em comunicação Cognitive synchronization: comunicação com o único propósito de confirmar se dois ou mais desenvolvedores compartilham o mesmo conhecimento ou a mesma representação do objeto em questão * 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

5 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 Observações em duas empresas e relatos da literatura pesquisada indicam que a distribuição não atinge diretamente o processo de requisitos Comum: requisitos são levantados por uma equipe que depois repassa o documento para ser implementado por outra(s) equipe(s). Testes podem ser realizados por uma terceira equipe Software Engineering Lab (LES) – PUC-Rio

6 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 Paradigma de agentes: relativamente novo paradigma na engenharia de software (desde década de 80) Decomposição do problema em problemas menores Metáfora para partes do problema Software Engineering Lab (LES) – PUC-Rio

7 soluções com agentes são indicadas para:
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 Paradigma de agentes: relativamente novo paradigma na engenharia de software (desde década de 80) Decomposição do problema em problemas menores Metáfora para partes do problema Software Engineering Lab (LES) – PUC-Rio

8 efetiva distribuição do trabalho no processo de requisitos
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 Agente como um assistente ou auxiliar do ator humano – vai agir em nome de alguém Automação será PARCIAL Proposta: mais um passo no sentido de conseguir a efetiva distribuição no processo de requisitos e diminuição dos problemas de comunicação Software Engineering Lab (LES) – PUC-Rio

9 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* Identificamos PBR (Perspective Based Reading) como sendo adequada aos nossos propósitos. PBR considera as diferentes perspectivas (visões) dos atores do processo e utiliza diferentes checklists para guiar a leitura e análise do artefato Na PBR, os participantes são selecionados de acordo com a utilização que farão do artefato. Numa inspeção do documento de requisitos, podem ser selecionados, por exemplo: usuário final, projetista, programador, representante da equipe de manutenção, executor de testes e outros. O documento de requisitos será visto através de diferentes visões: o usuário final deseja ver ali refletido o conjunto de funcionalidades a ser atendido pelo software; o projetista irá utilizá-lo como base para a criação da estrutura do software, considerando as funcionalidades e restrições descritas, e o testador verá o documento de requisitos como fonte primeira para a geração dos testes, que deverão assegurar que o mesmo atende às necessidades (funcionais e não funcionais) registradas. Na nossa proposta, a cada ator corresponderia um agente que agiria em seu nome, executando ações em acordo com a perspectiva de seu papel e seguindo o estabelecido em um plano pré-definido. Parte das tarefas da inspeção seria automaticamente realizada, com tratamento da linguagem natural utilizada no SRS. Na validação, engenheiro de requisitos e representantes do cliente e dos usuários avaliam o SRS e interagem com o objetivo de assegurar que os requisitos relacionados pelo engenheiro de requisitos no SRS correspondem ao esperado pelos usuários e cliente. Cada representante dos usuários trará a visão do grupo ao qual ele pertence: operacional, gerencial, decisório. Neste processo visualizamos agentes com o propósito de identificar se as intenções do ator a quem ele representa estão refletidas no documento sendo avaliado. Software Engineering Lab (LES) – PUC-Rio

10 Processo de requisitos: diagrama SD
Agent Position Role Goal Softgoal Resource Modelo i* é o modelo de papéis e reflete a intencionalidade dos atores atores: cliente, usuário, profissionais de software Posições ocupadas: representante de cliente e usuário, engenheiro de requisitos, desenvolvedor, gerente de projeto Papel: de inspetor: desempenhado por desenvolvedor, engenheiro de requisitos, representantes dos clientes e usuários Dependencias entre atores: Por metas: um ator depende (depender) de outro (dependee) para atingir determinados objetivos concretos Por SoftGoals: um ator depende do outro para satisfazer desejos ou intenções Por recursos: um ator depende de outro para conseguir determinado recurso Software Engineering Lab (LES) – PUC-Rio

11 definição e atribuição das tarefas a agentes
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

12 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

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

14 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

15 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

16 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

17 Agentes: definição de responsabilidades
Papel: Rastreador Sistema: REDist Responsabilidades Serviço: gerar matriz RNF x RF Nome: gerarMatRast Serviço: gerar matriz verificacão Nome: gerarMatTest Recursos Dados Serviços requeridos Base Tabela Driver redist Requisitos MySql Redist Rastros Testes Software Engineering Lab (LES) – PUC-Rio

18 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

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

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

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

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

23 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

24 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

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

26 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

27 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

28 Agentes verificador e construtor do léxico
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

29 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

30 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] trabalhos de pesquisa e experimentação visando busca de métodos, técnicas e ferramentas para o processo de Requisitos em ambientes distribuídos Software Engineering Lab (LES) – PUC-Rio

31 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

32 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

33 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

34 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 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. 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 , Toronto, Canadá. Proceedings. pp Software Engineering Lab (LES) – PUC-Rio

35 Bibliografia Damian, D.; Eberlein, A.; Shaw, M. & Gaines, B. "Facilitation in Distributed Requirements Engineering". Requirements Engineering Journal, 8(1), 2003, pgs Gorton, I. & Motwani, S. “Issues in Co-operative Software Engineering Using Globally Distributed Teams”. In: Information and Software Technology Journal ,vol 38(10), págs 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 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

36 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, IEEE Computer Society. Proceedings. pags 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 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


Carregar ppt "Agentes no Processo de Requisitos"

Apresentações semelhantes


Anúncios Google