• Nenhum resultado encontrado

RISYS Considerando a análise de riscos e os elementos de contexto em um ambiente colaborativo de gestão de projetos

N/A
N/A
Protected

Academic year: 2021

Share "RISYS Considerando a análise de riscos e os elementos de contexto em um ambiente colaborativo de gestão de projetos"

Copied!
6
0
0

Texto

(1)

RISYS – Considerando a análise de riscos e os elementos de

contexto em um ambiente colaborativo de gestão de projetos

Trabalho de Mestrado

Marcio Passos Lima (Aluno)1, José Maria N. David (Orientador)2

Programa de Pós-Graduação em Sistemas e Computação - UNIFACS 1

Universidade Salvador (UNIFACS), Salvador - BA - Brasil. 2

Universidade Federal de Juiz de Fora (UFJF), Juiz de Fora - MG – Brasil.

marcio.lima@reconcavotecnologia.org.br, jmndavid@gmail.com

Ano de Ingresso no Programa de Mestrado: 2009 Época esperada de conclusão: 2011.2

Etapas já concluídas: (i) Definição do tema, problema e objetivos; (ii) análise dos trabalhos relacionados; (iii) definição da arquitetura do sistema; (iv) elaboração de diagramas UML; (v) construção de ontologias; (vi) implementação

do serviço de comunicação com as ontologias; (vii) avaliação preliminar dos resultados obtidos.

Resumo. Eventos incertos, denominados riscos, podem ocorrer durante o desenvolvimento de software. A identificação dos riscos e os seus impactos podem ser determinados a partir de elementos de contexto no qual o projeto está inserido, assim como, a fase do ciclo de vida do software. O WGPMS (Web-based Groupware on Project Management System) é uma infraestrutura que tem como objetivo apoiar as atividades colaborativas de projeto. O objetivo deste trabalho é apresentar as modificações realizadas na ferramenta RISYS, integrante ao ambiente WGPMS, para ampliar o tratamento de riscos dos projetos através da utilização de ontologias.

Palavras-chave: Análise de riscos, Colaboração, Contexto, Ontologia, Modelo RUP.

1. Introdução

Durante o desenvolvimento de projetos, eventos incertos podem ocorrer resultando oportunidades ou ameaças. De acordo com o guia Project Management Body of

Knowledge - PMBOK® desenvolvido pelo Project Management Institute - PMI, esses eventos incertos são denominados riscos (PMI, 2009). As oportunidades podem gerar benefícios para o projeto. Por exemplo, a experiência da equipe na área do projeto pode facilitar as atividades de levantamento e detalhamento de requisitos. As ameaças podem ocasionar impactos negativos para o projeto. Nessa situação, a não validação dos requisitos pode ocasionar retrabalhos, insatisfação da equipe de desenvolvimento, atrasos no cronograma, aumento de custos, dentre outros impactos.

(2)

Os processos de identificação e análise de riscos são razoavelmente complexos devido aos eventos que afetam tanto as atividades de desenvolvimento de software quanto as atividades colaborativas. Nesse sentido, é fundamental que o gerente do projeto perceba prontamente os eventos que caracterizam os riscos, assim como as suas intensidades de acordo com o contexto no qual o projeto se encontra. A partir dos riscos identificados, o planejamento das respostas é fundamental para que os objetivos do projeto sejam atingidos. Nesse trabalho, as exceções decorrentes dos desvios de planejamento do projeto não são tratadas como riscos. Consideramos contexto como o conhecimento sobre as atividades, as suas circunstâncias e eventos que caracterizam um projeto colaborativo de desenvolvimento de software (Rittenbruch, 2002).

Dantas et al (2009) afirmam que, além das variáveis de riscos de projetos, outras devem ser levadas em consideração em um ambiente colaborativo de desenvolvimento de software, tais como: a motivação e a participação dos envolvidos, a frequência de utilização de ferramentas colaborativas, bem como as contribuições ocorridas durante o desenvolvimento de software. Todas essas variáveis podem estar associadas a riscos que compõem o contexto de desenvolvimento de software. Dessa forma, os riscos estão relacionados ao contexto no qual eles ocorrem. Além disso, as variáveis de riscos de projeto e de colaboração podem ser relacionadas. Por exemplo, uma comunicação não adequada com o cliente pode contribuir para a não validação dos requisitos. Considerando o modelo de desenvolvimento de software RUP (Kroll e Kruchten, 2003), a análise qualitativa dos riscos pode ser diferenciada nas fases definidas no modelo. Por exemplo, o risco de requisitos não validados pode ter impacto baixo na fase de iniciação e um impacto alto na fase de construção.

O ambiente WGPMS (Web-based Groupware on Project Management System) (Dantas et al, 2008) foi definido com o intuito de apoiar o gerenciamento de projetos de desenvolvimento colaborativo de software. O RISYS é um módulo pertencente a este ambiente que possui um mecanismo inteligente para a identificação e a análise de riscos de forma a facilitar as atividades dos gerentes de projetos no âmbito do gerenciamento de riscos. No entanto, a primeira versão do RISYS (Dantas et al, 2009) não contempla os requisitos: relacionamento entre os riscos de projeto e os riscos relacionados à colaboração; identificação e análise de riscos de acordo com os elementos de contexto; e análise de riscos de acordo com a fase do ciclo de vida do desenvolvimento do software.

O objetivo desse artigo é apresentar os principais elementos da nova versão da ferramenta RISYS. Ele está organizado da seguinte forma: a Seção 2 descreve algumas definições mais importantes, a Seção 3 descreve as contribuições identificadas, a Seção 4 informa o estágio atual do trabalho, a Seção 5 apresenta alguns trabalhos relacionados e, por fim, a Seção 6 apresenta a avaliação preliminar dos resultados.

2. Fundamentação teórica

Essa seção apresenta algumas definições referentes à taxonomia de riscos de software e o modelo RUP, bem como as justificativas quanto às decisões deste trabalho.

2.1. Taxonomia de riscos de software

Algumas taxonomias foram definidas com o intuito de sistematizar a identificação de riscos que podem ocorrer durante o desenvolvimento de software (Carr et al, 1993;

(3)

Karolak, 1996). Este trabalho considera a taxonomia de riscos definida por Carr et al (1993) devido a sua abordagem contemplar tanto as variáveis de projeto de software quanto as variáveis de colaboração. Adicionalmente, um questionário é apresentado pelos autores para auxiliar a elicitação dos riscos o qual contribuiu para a definição de regras de análise de riscos desse trabalho.

2.2. O Modelo RUP

Conforme Kroll e Kruchten (2003), o RUP é um modelo de processo de engenharia de

software guiado por casos de uso, é iterativo, incremental e adaptativo. A sua arquitetura

é organizada em duas dimensões. Na dimensão vertical são destacadas as disciplinas, engenharia de software e suporte, que representam os aspectos estáticos do modelo. Na dimensão horizontal são destacadas quatro fases (iniciação, elaboração, construção e transição) as quais determinam o seu aspecto dinâmico. A escolha desse modelo deve-se a possibilidade de investigar as intensidades dos riscos de projeto e os relacionados à colaboração ocorridos nas diferentes fases do ciclo de vida do software.

3. Caracterização da contribuição

A primeira versão da ferramenta RISYS implementou as regras para a identificação e análise dos riscos utilizando a lógica de primeira ordem. Tais regras poderiam ser estendidas para atender os requisitos mencionados na introdução desse artigo. Entretanto, essas modificações demandariam bastante esforço e poderiam prejudicar a flexibilidade da aplicação. Esse trabalho optou, inicialmente, por utilizar ontologias devido ao fato de proporcionar maior flexibilidade para a aplicação de forma que se possa substituir o modelo de desenvolvimento RUP por outro modelo, assim como permitir a verificação da consistência das regras e a realização de inferências durante o desenvolvimento. No entanto, existem outras formas de representação de contexto, tais como: tuplas atributo-valor, orientação a objetos, banco de dados relacionais, lógica de primeira ordem, entre outras representações (Dey, Abowd e Salber, 2001; Kindberg et

al, 2000; Henricksen, Indulska e Rakotonirainy, 2002; Ranganathan e Campbell, 2003).

Certamente, essa solução é uma primeira tentativa de se representar os diferentes contextos e relacioná-los às etapas do desenvolvimento de software incremental.

Conforme ilustra a figura 1, foram desenvolvidas três ontologias utilizando a linguagem OWL (Web Ontology Language) para a representação dos seguintes conceitos: (i) contexto de desenvolvimento de software; (ii) modelo RUP e (iii) análise qualitativa dos riscos. A ontologia referente ao contexto de desenvolvimento de

software tem como objetivo representar os principais elementos de contexto referentes

ao cliente, o ambiente de desenvolvimento e as características intrínsecas ao projeto de

software. Os elementos contextuais foram baseados (i) no framework conceitual para as

aplicações de groupware proposto por Rosa, Borges e Santoro (2003), (ii) na análise da ontologia CoMGroup-Ont desenvolvido por Vieira, Tedesco e Salgado (2005), e (iii) na análise dos questionários elaborados por Carr et al (1993). A ontologia referente ao modelo RUP restringe-se na representação de suas fases. Por fim, a ontologia referente à análise qualitativa dos riscos foi baseada na mPRIME Ontology (Gusmão, Moura e Lins, 2009). As regras definidas nessa ontologia levam em consideração os elementos de contexto de desenvolvimento de software e as fases definidas pelo modelo RUP. Após a execução do motor de inferência, a ontologia indica os riscos e a sua intensidade

(4)

de impacto (alto, médio ou baixo). Esses resultados são exibidos na ferramenta RISYS possibilitando que os gerentes de projetos possam planejar as respostas necessárias.

Figura 1. Elementos do sistema proposto (adaptado de (Lima, David e Dantas, 2010)).

4. Estado atual do trabalho

As ontologias foram desenvolvidas na ferramenta Protégé conforme descritas em (Lima, David e Dantas, 2010). Adicionalmente, serviços foram desenvolvidos para capturar as informações de projeto mantidas pelo ambiente WGPMS, assim como as inferências realizadas pela ontologia de análise de riscos. O framework Jena (Dickinson, 2009) é utilizado para possibilitar a leitura das classes ontológicas. Para finalizar a fase de implementação do RISYS, resta apenas a exibição desses resultados na camada Web. Após isso, avaliações da ferramenta RISYS serão realizadas no ambiente de produção a partir dos elementos de contexto devidamente atualizados nas fases do modelo RUP.

5. Trabalhos relacionados

Ferramentas e métodos têm sido propostos na literatura para apoiar a análise de riscos (Carvalho, Coelho e Falbo, 2007; Fontoura e Price, 2008; Gusmão, Moura e Lins, 2009; Persson et al, 2009; Mudumba e Lee, 2010). Foram analisados os seguintes critérios: (i) identificação sistemática de riscos; (ii) análise de riscos nas fases do ciclo de vida do

software; (iii) suporte ao ambiente de colaboração; (iv) representação de contexto para o

domínio de desenvolvimento de software; e (v) relacionamento entre riscos de projeto e riscos de colaboração. Devido às restrições de espaço, esse artigo destaca apenas dois trabalhos.

Fontoura e Price (2008) desenvolveram um ambiente denominado PRiMA (Project Risk Management Approach) compostos por ferramentas que auxiliam o gerenciamento de riscos dos projetos de software através de adaptações dos processos organizacionais e inserções de padrões de processos. Da mesma forma que a ferramenta RISYS, PRiMA adota a identificação sistemática de riscos e utiliza o conceito de contexto para a caracterização do projeto. Quanto aos elementos de colaboração, ela trata, na sua representação de contexto, se as pessoas envolvidas no projeto colaboraram. No entanto, a identificação e a análise dos riscos não são automáticas e, ainda, a análise dos riscos não contempla as fases do ciclo de vida do software.

A mPRIME Ontology é uma ontologia que realiza inferência de riscos (Gusmão, Moura e Lins, 2009). Da mesma forma que o RISYS, esse método utiliza a identificação sistemática de riscos, bem como mecanismos inteligentes para a análise de riscos. Além disso, considera alguns elementos de colaboração e estabelece relacionamento entre riscos de projeto e riscos de colaboração. No entanto, mPRIME não contempla a análise dos riscos de acordo com as fases do ciclo de vida do software e não aborda o conceito de contexto para representar o domínio do desenvolvimento. A ontologia de análise de

(5)

riscos utilizada pela ferramenta RISYS leva em consideração as informações referentes aos elementos de contexto e as fases do modelo RUP.

6. Avaliação dos resultados

Para a avaliação preliminar dos resultados, algumas instâncias nas classes ontológicas foram criadas na ferramenta Protégé para verificar as inferências das regras de análise de riscos. Após a execução do motor de inferências, algumas instâncias nas classes da ontologia de análise de riscos foram criadas. Essas inferências indicaram que os riscos se comportam de forma diferenciada nas fases do ciclo de vida do software, assim como que os elementos de colaboração influenciam nos riscos de projeto. Dessa forma, os gerentes de projetos poderão priorizar e planejar as respostas aos riscos. Entretanto, novas avaliações precisam ser conduzidas em um ambiente de produção.

Referências

Carr, M., Konda, S., Monarch, I., Ulrich, F. and Walker, C. (1993) “Taxonomy based risk identification”, In Technical Report CMU/SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University.

Carvalho, V., Coelho, A. and Falbo, R. (2007) “Apoio Automatizado à Gerência de Riscos Cooperativa”. In X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS'07), Isla de Margarita, Venezuela, p. 297-310.

Dantas, B., David, J., Neto, G., Menezes, R. and Santos, A. (2008) “Uma ferramenta Web de apoio à coordenação de projetos em um ambiente colaborativo”, In Proceeding of the 2008 Simpósio Brasileiro de Sistemas Colaborativos (SBSC’08), Vila Velha-ES, Brazil, IEEE, p. 146-157.

Dantas, B., David, J., Avelar, A., Ferreira, L. and Jesus, L. (2009) “RISYS – Uma Ferramenta de Apoio à Gerência de Riscos em um Ambiente Colaborativo de Gestão de Projetos”, In VI Simpósio Brasileiro de Sistemas Colaborativos (SBSC’09), Fortaleza-CE, Brazil, p. 90-98.

Dey, A., Abowd, G. and Salber, D. (2001) “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications”, In Human-Computer Interaction Journal, v. 16(2-4), p. 97-166.

Dickinson, I. (2009) “Jena Ontology API”,

http://jena.sourceforge.net/ontology/index.html, April/2011.

Fontoura, L. and Price, R. (2008) “Systematic Approach to Risk Management in Software Projects through Process Tailoring”. In Proceedings 20th International Conference on Software Engineering and Knowledge Engineering (SEKE’08), San Francisco, CA, USA, p. 179-184.

Gusmão, C., Moura, H. and Lins, F. (2009) “Utilizando Ontologia na Identificação de Riscos de Projetos de Software”, Disciplinarum Scientia, Série Ciências Naturais e Tecnológicas, v. 7, p. 97-106.

Henricksen, K., Indulska, J. and Rakotonirainy, A. (2002) “Modeling Context Information in Pervasive Computing Systems”, Proceedings of the First International Conference on Pervasive Computing, p. 167-180.

(6)

Karolak, D. (1996) “Software Engineering Risk Management”, IEEE Computer Society Press.

Kindberg, T., Barton, J., Morgan, J., Becker, G., Caswell, D., Debaty, P., Gopal, G., Frid, M., Krishnan, V., Morris, H., Schettino, J., Serra, B. and Spasojevic, M. (2000) “People, Places, Things: Web Presence for The Real World”, Technical Report HPL-2000-16, HP Labs.

Kroll, P. and Kruchten, P. (2003) “The Rational Unified Process made easy: a practitioner’s guide to the RUP”, Addison Wesley.

Lima, M., David, J. and Dantas, B. (2010) “Risk Management and Context in a Collaborative Project Management Environment for Software Development”, In Simpósio Brasileiro de Sistemas Colaborativos (SBSC’10), Belo Horizonte, Brazil, IEEE, p. 95-102.

Mudumba, V. and Lee, O. (2010) “A New Perspective on GDSD Risk Management: Agile Risk Mangement”. In Proceedings International Conference on Global Software Engineering (ICGSE’10), Princeton, New Jersey, USA, IEEE, p. 219-227 Persson, J., Mathiassen, L., Boeg, J., Madsen, T. and Steinson, F. (2009) “Managing

Risks in Distributed Software Projects: An Integrative Framework”. In Proceedings IEEE Transactions on Engineering Management, v. 56, n. 3, p. 508-523.

PMI (2009) “A guide to the project management body of knowledge”, 4th ed., USA. Ranganathan, A. and Campbell, R. (2003) “A Middleware for Context-Aware Agents in

Ubiquitous Computing Environments”, USENIX International Middleware Conference, p. 143-161.

Rittenbruch, M. (2002) “ATMOSPHERE: A Framework for Contextual Awareness”, In International Journal of Human-Computer Interaction, v. 14(2), p. 159-180.

Rosa, M., Borges, M. and Santoro, F. (2003) “A conceptual Framework for Analyzing the Use of Context in Groupware”, In Proceedings of the 9th International Workshop on Groupware (CRIWG’03), LNCS, v. 2806, Springer-Verlag, Austrans, France, p. 300-313.

Vieira, V., Tedesco, P. and Salgado, A. (2005) “Towards an Ontology for Context Representation in Groupware”, In Proceedings of the 11th International Workshop on Groupware (CRIWG’05), LNCS, v. 3706, Porto de Galinhas-PE, Brazil, p. 367-375.

Referências

Documentos relacionados

Desta forma, existem benefícios para os clientes que possuem melhores controles internos, como, agilidade na elaboração dos demonstrativos contábeis e até mesmo

Segundo [HEXSEL (2002)], há indicações de que o número de técnicos qualificados é pequeno frente à demanda e, portanto, estes técnicos tornam-se mão-de-obra relativamente

The levels of potential acidity (HAl) also influence the soil pHBC. As OM and HAl reflect the soil pHBC, we hypothesize that they are reliable predictor variables for estimating

blemas referentes à diferenciação de serviços absoluta penalizando demasiadamente algumas classes de serviço, não garantem espaçamento de qualidade entre as classes de serviço,

After analyzing Orlando’s characterization and realizing the conflict between transgressive text and normatizing subtext, my tentative hypothesis was adapted to the following:

A visualidade do infográfico torna-se relevante no processo de atração do leitor para a informação, porém, serão as possibilidades e caminhos disponibilizados que terão

Algumas características dos sistemas políticos dos países membros também não apontam para a funcionalidade do Parlamento, herdeiro das instituições nacionais e da cultura

Há de afirmar, que com as alterações causadas pela Lei 12.683/2012 ocorreu uma maior abrangência no referente aos crimes antecedentes a lavagem de bens, direitos e valores,