BPMN Dissertacao LaisXavier

Integrao de Requisitos No-Funcionais a Processos de Negcio: Integrando BPMN e RNF
Por
Las Xavier D ISSERTAO DE M ESTRADO
Universidade Federal de Pernambuco Centro de Informtica
Recife PE 31 de Agosto de 2009
Universidade Federal de Pernambuco Centro de Informtica
Las Xavier
Integrao de Requisitos No-Funcionais a Processos de Negcio: Integrando BPMN e RNF
Trabalho apresentado ao Programa de Ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Mestre em Cincia da Computao.
A Master Thesis presented to the Federal University of Pernambuco in partial fulllment of the requirements for the degree of M.Sc. in Computer Science.
Orientador: Jaelson Freire Brelaz de Castro Co-orientadora: Fernanda Maria Ribeiro de Alencar
Recife PE 31 de Agosto de 2009
Este trabalho dedicado aqueles que realmente fazem diferena na minha vida: Gerino, Anglica Isa e Mano. Obrigada.
Agradecimentos
Meus sinceros agradecimentos a todos, que direta ou indiretamente, contriburam para a concluso deste trabalho e de uma importante fase da minha vida. Aqui comea uma nova etapa com muito entusiasmo, perspectivas, esperanas, projetos e sonhos. Agradeo minha famlia - em especial minha me, meu pai e minha irm - pelo amor, pacincia e apoio a mim dedicados. Mano, pelo amor, companheirismo, fora, pelas aventuras, sonhos e planos. E aos meus amigos, em especial Dudu e Clarissa, que sempre estiveram ao meu lado. Com vocs, compartilho mais essa conquista to importante. Aos que fazem parte do grupo de pesquisa LER do Centro de Informtica, tenho um agradecimento especial pelos seminrios, trocas de experincia, momentos de descontrao, e acima de tudo pelo suporte acadmico, tcnico e emocional. Em particular, agradeo ao meu orientador o Professor Jaelson Castro pelo apoio e conana e a minha Co-orientadora Fernanda Alencar pela ateno e fora. Aos meus amigos e companheiros pra toda vida (Jordo, Menezes, Ricardo e Teoria) pelo apoio em uma fase decisiva desta jornada. E aos colegas da Mdias educativas (em especial Cynthia), pois vocs so mais que colegas de trabalho e me acompanharam sempre dispostos nesta jornada.
And as we let our own light shine, We unconsciously give other people permission to do the same. As were liberated from our own fear, Our presence automatically liberates others. MARIANNE WILLIAMSON
Resumo
A Engenharia de requisitos tem sido amplamente reconhecida como um fator crtico de sucesso de projetos de Software. Se no forem devidamente elicitados, os requisitos podem levar o projeto ao fracasso. A elicitao equivocada dos requisitos pode estar relacionada com a falta de compreenso do negcio pelo analista de sistemas, a falta entendimento dos objetivos do sistema, bem como a falta de comunicao entre analistas de negcio e analistas de sistema. A existncia de uma lacuna entre os domnios do negcio e da computao podem causar desequilbrios entre o que os usurios nais precisam e o que os analistas de sistema desenvolvem. Uma das razes para o problema de comunicao que os modelos de requisitos utilizados para interagir com os usurios nais podem ser difceis de serem compreendidos e validados em funo da alta complexidade das notaes. Alm disso, os erros provocados por no lidar com requisitos, especialmente os no-funcionais, convenienetemente so apontados como os mais caros e difceis de corrigir. O problema tratado nesta dissertao a integrao dos requisitos no-funcionais aos modelos de processos de negcio, atravs de notaes intuitivas para todos os usurios envolvidos no processo. Para isso, uma pesquisa baseada em anlise de requisitos no-funcionais e modelagem de processos de negcio apresentada. Portanto, propomos uma abordagem para inserir os requisitos no-funcionais na notao Business Process Modeling Notation (BPMN). A abordagem utiliza catlogos para requisitos no-funcionais, descritos na natoo Non-Functional Requirement (NFR), que orientam a descoberta das suas operacionalizaes. Esta abordagem validada com um estudo de caso real. Palavras-chave: Engenharia de Requisitos, Requisitos no-funcionais, BPMN, NFRFramework.
Abstract
Requirements engineering has been widely recognized as a critical factor for success of software projects. If not properly addressed, the requirements may cause the project to fail. The inappropriate elicitation of requirements can be related to a lack of understanding of the business by the systems analyst, the lack of understandment of the purpose of the system, and lack of communication between business analysts and system analysts. The existence of a gap between the elds of business and the computer can cause mistakes between what the end users need and what system analysts provide. One reason for the problem of communication is that the requirements models used to interact with end users may be difcult to be understood and validated due the inhibit. Furthermore, errors caused by not dealing with requirements, especially non-functional, are indicated as the most expensive and difcult to correct. The problem addressed in this dissertation is the integration of non-functional requirements with business process models, through a more intuitive notation for all users involved in the process. Therefore, are search based the on analysis of non-functional requirements and modeling business processes is presented. We propose an approach to embed the non-functional requirements in the BPMN notation. The approach catalogs of non-functional requirements, decribed in the NFR notation, to guide the discovery of their operacionalizations. This approach is validated with a real case study. Keywords: Requirements Engineering, Non-functional Requirements, BPMN, NFRFramework
vii
Sumrio
Introduo 1.1 1.2 1.3 1.4 1.5 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 4 4 5 6 7 7 8 9 10 11 12 12 14 15 17 18 22 22 24 24 25 25 27 28 28 28 31 33
Modelagem de processos de negcio 2.1 2.2 2.3 2.4 Modelos de Negcio . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelos de processos de negcio . . . . . . . . . . . . . . . . . . . . . Notaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 Histria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetos de Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . Objetos de Conexo . . . . . . . . . . . . . . . . . . . . . . . Swimlane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requisitos No-Funcionais 3.1 3.2 Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NFR-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.3 3.4 Aquisio ou acesso a conhecimentos . . . . . . . . . . . . . . Decomposio dos requisitos no-funcionais . . . . . . . . . . Identicao das operacionalizaes . . . . . . . . . . . . . . . Lidar com Ambigidades, Prioridades e Interdependncias entre requisitos no-funcionais e operacionalizaes . . . . . . . . . Escolher as operacionalizaes . . . . . . . . . . . . . . . . . . Apoiar decises com concepo lgica . . . . . . . . . . . . . Avaliar os impactos das decises . . . . . . . . . . . . . . . . .
Identicao dos requisitos no-funcionais particulares do domnio 25
Operacionalizao de requisitos no-funcionais . . . . . . . . . . . . . Catlogo de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 3.4.2 3.4.3 3.5 4
A Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . O catlogo proposto . . . . . . . . . . . . . . . . . . . . . . . Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . .
33 36 41 41 42 42 43 46 46 48 50 53 53 54 54 54 55 55 57 57 58 59 59 59 61 61 63 63 65 67 67 70 70 78
Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abordagem BPMNFR 4.1 A abordagem BPMNFR . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3 Construo do Business Process Diagram (BPD) . . . . . . . . Caso de exemplo . . . . . . . . . . . . . . . . . . . . . . . . . Rtulos de requisitos no-funcionais no BPD . . . . . . . . . . Detalhamento do requisito no-funcional . . . . . . . . . . . . Insero das operacionalizaes no BPD . . . . . . . . . . . . i* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La Vara, Snchez e Pastor . . . . . . . . . . . . . . . . . . . . Brito e Moreira . . . . . . . . . . . . . . . . . . . . . . . . . . Pavloviski e Zou . . . . . . . . . . . . . . . . . . . . . . . . . Abordagem BPMNFR . . . . . . . . . . . . . . . . . . . . . .
Anlise comparativa com outras abordagens . . . . . . . . . . . . . . .
Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estudo de caso 5.1 5.2 5.3 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos do estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Modelagem do processo de desenvolvimento do produto . . . . Elicitao de requisitos . . . . . . . . . . . . . . . . . . . . . . Validao de requisitos . . . . . . . . . . . . . . . . . . . . . . Desenvolvimento dos componentes do sistema . . . . . . . . . Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 5.3.3 Insero dos requisitos no-funcionais atravs dos rtulos . . . Operacionalizaes dos requisitos no-funcionais . . . . . . . . Renamento do Catlogo de Usabilidade . . . . . . . . . . . . Identicao das operacionalizaes . . . . . . . . . . . . . . . Insero das operacionalizaes no BPD . . . . . . . . . . . . 5.4 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
Concluso 6.1 Concluses e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . .
79 79
Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
Figura de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Fluxo de Sequncia . . . . . . . . . . . . . . . . . . . . . . . Figura de Fluxo de Mensagem . . . . . . . . . . . . . . . . . . . . . . Figura de Associao . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Lane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Objetos de Dados . . . . . . . . . . . . . . . . . . . . . . . .
13 13 14 14 15 15 16 16 17 17 18 19 20 25 26 27 29 30 32 33 37 38 39 40
2.10 Figura de Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Figura de Anotao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12 Figura de Exemplo do uso da notao BPMN . . . . . . . . . . . . . . 2.13 Figura 2 de Exemplo do uso da notao BPMN . . . . . . . . . . . . . 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Figura do Softgoal Interdependency Graphs (SIG) inicial . . . . . . . . Figura da decomposio por tipos . . . . . . . . . . . . . . . . . . . . Figura de Identicao de um softgoal como prioridade . . . . . . . . . Figura de seleo de operacionalizaes . . . . . . . . . . . . . . . . . Figura de Claim-Softgoal . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Identicao de possveis operacionalizaes para requisito no-funcional Softgoal . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Operacionalizaes . . . . . . . . . . . . . . . . . . . . . . . Figura do catlogo de usabilidade - Ecincia e Eccia . . . . . . . . Figura do catlogo de usabilidade - Utilidade . . . . . . . . . . . . . .
3.10 Figura do catlogo de usabilidade - Segurana no uso . . . . . . . . . . 3.11 Figura do catlogo de usabilidade - Fcil de aprender e usar . . . . . . . 4.1 4.2 4.3 4.4 4.5 5.1 Figura da Abordagem BPMNFR inicial para insero de requisito nofuncional em BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura de Abordagem BPMNFR Final . . . . . . . . . . . . . . . . . . Figura do BPD com rtulos . . . . . . . . . . . . . . . . . . . . . . . . Figura do BPD com operacionalizaes . . . . . . . . . . . . . . . . . Figura do macro processo do estudo de caso . . . . . . . . . . . . . . .
44 45 49 52 60
Figura do Processo geral de desenvolvimento um objeto de aprendizagem 47
xi
5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15
Figura subprocesso de elicitao de requisitos . . . . . . . . . . . . . . Figura subprocesso de validao de requisitos . . . . . . . . . . . . . . Figura subprocesso de implementao da interface . . . . . . . . . . . Figura subprocesso de testes . . . . . . . . . . . . . . . . . . . . . . . Figura do diagrama do lampejo rotulado . . . . . . . . . . . . . . . . . Figura do catlogo de usabilidade renado - Fcil de aprender e usar . . Figura do catlogo de usabilidade novo softgoal - Entender domnio do usurio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura das operacionalizaes dos requisitos no-funcionais no BPD do lampejo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura das operacionalizaes dos requisitos no-funcionais no BPD de elicitao de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . Figura do detalhamento da operacionalizao prototipao . . . . . . Figura das operacionalizaes dos requisitos no-funcionais no BPD de validao de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . Figura das operacionalizaes dos requisitos no-funcionais no BPD de desenvolvimento da interface . . . . . . . . . . . . . . . . . . . . . . . Figura da operacionalizaes do desenho dos cones . . . . . . . . . . . Figura da operacionalizao dos testes . . . . . . . . . . . . . . . . . .
62 63 64 65 66 68 69 71 72 74 75 76 77 77
xii
Lista de Tabelas
4.1 5.1
Tabela de correspondncias de operacionalizaes . . . . . . . . . . . . Tabela de correspondncias de operacionalizaes . . . . . . . . . . . .
53 73
xiii
Lista de Abreviaturas
BPD Business Process Diagram BPEL4WS Business Process Execution Language for Web Service BPMI Business Process Management Initiative BPML Business Process Modeling Language BPMN Business Process Modeling Notation BPMN-WG Business Process Modelling Notation Working Group CETE Centro de Experimentao em Tecnologia Educacional MEC Ministrio da Educao NFR Non-Functional Requirement OMG Object Management Group RNF Requisito No-Funcional SD Strategic Dependency SEAD Secretaria de Ensino a Distncia da UFPE SEED Secretaria de Educao a Distncia SIG Softgoal Interdependency Graphs SR Strategic Rationale UFPE Universidade Federal de Pernambuco UML Unied Modeling Language XML eXtensible Markup Language
Programmers Drinking Song sung to the tune of 100 Bottles of Beer": 99 little bugs in the code, 99 bugs in the code, x one bug, compile it again, 101 little bugs in the code. 101 little bugs in the code.... (Repeat until BUGS = 0) Anonymous
1
Introduo
Neste captulo sero descritos a motivao para realizao do trabalho, a caracterizao do problema encontrado, o objetivo desta dissertao, as contribuies principais e secundrias, bem como a estrutura deste trabalho.
1.1
Motivao
A Engenharia de Requisitos tem sido amplamente reconhecida como um fator crtico de sucesso de projetos de Software (Group, 1995). Se no forem devidamente elicitados, os requisitos podem levar o projeto ao fracasso. Os problemas na fase de requisitos esto relacionados falta de compreenso do negcio pelo analista de sistemas, mal entendimento da nalidade do sistema, e a falhas de comunicao entre analistas de negcio e analistas de sistemas. Uma vez que esses problemas geralmente dicultam o alinhamento entre negcios e tecnologia da infomao (Luftman et al., 1999; Reich and Benbasat, 2000), os sistemas de informao podem no satisfazer s necessidades da organizao. Da forma como os requisitos tm sido denidos nas solues orientada ao negcio eles no reetem o ambiente de negcios. Normalmente consistem apenas de um modelo de dados na forma de um diagrama de entidade-relacionamento ou modelo de classes. Como soluo, a comunidade de Engenharia de Requisitos tem reconhecido a importncia do uso de preocupaes relativas ao negcio para direcionar a elicitao de requisitos (Sommerville and Sawyer, 1997). Trata-se, mais especicamente, da importncia da modelagem organizacional durante a anlise de requisitos (Kirikova and Bubenko, 1994) fazendo com que os analistas de sistemas desempenhem o papel de analistas de negcio (of Business Analysis, 2009). Modelos organizacionais descrevem a estrutura e o comportamento de uma organizao e so muito teis para ajudar analistas de sistema a
1.1. MOTIVAO
compreenderem corretamente o ambiente de negcios e os requisitos do sistema. Dentre outras abordagens, a Modelagem de Processos de Negcio foi declarada como uma boa abordagem para a modelagem organizacional, pois considerada um instrumento fundamental para a anlise e projeto de sistemas de informao voltados para processos, documentao e reengenharia organizacional, e o projeto de arquiteturas orientadas a servios (Erl, 2005) e tem sido muito importante para o desenvolvimento de sistemas de informao (Dumas et al., 2005). Um outro fator, a boa comunicao entre analistas de negcio e analistas sistema, essencial na fase requisitos (Holtzblatt and Beyer, 1995). No entanto, pode ser difcil de ser alcanada devido existncia de uma lacuna entre os domnios de negcio e de computao (Taylor-Cummings, 1998). Essa lacuna pode causar desequilbrios entre o que os usurios nais verbalizam e o que os analistas de sistema compreendem. Uma das razes para a falta de comunicao que os modelos de requisitos utilizados para interagir com os usurios nais podem ser difceis de serem compreendidos e validados. Isso se deve falta de conhecimento das notaes utilizadas para descrever os requisitos em computao. Portanto, conclui-se que modelos que facilitem a comunicao durante a anlise de requisitos devam ser utilizados. Observando o contexto descrito acima, foi escolhida neste trabalho uma notao para modelagem de processos de negcio, a BPMN (Business Process Modelling Notation) (BPMI.org, 2008). Esta foi escolhida por ser uma notao intuitiva, que usa construes familiares e um conjunto de regras comuns em processos de negcio (Dubray, 2004). Contudo, apesar da utilizao de modelos de processos de negcio facilitar a interao entre os analistas de negcios, analistas de sistemas e usurio nais, esse tipo de modelo ainda no consegue abranger tudo o que os usurios nais desejam de um sistema de informao. Segundo (Recker et al., 2006) BPMN tem algumas limitaes relacionadas construo dos modelos, sugerindo assim, que os usurios nais no esto aptos a descreverem atravs dela todos os fenmenos encontrados em situaes reais. O autor observou nas suas pesquisas que os usurios que tinham um maior conhecimento na rea de computao sentiam a necessidade da incluso de mais smbolos notao BPMN para que se tornasse mais expressiva. Em (Pavlovski and Zou, 2008) identicado que uma dessas decincias da notao est na no existncia da descrio dos requisitos nofuncionais. Os requisitos no-funcionais (Requisito No-Funcional (RNF)s) de software em geral se relacionam com padres de qualidade como conabilidade, performance, robustez, etc. Estes requisitos so importantes, pois denem se o software ser eciente e adequado para a tarefa que se prope a fazer ou no. Segundo (Kirner and Davis, 1996),
CAPTULO 1. INTRODUO
os requisitos no-funcionais representam requisitos adicionais que denem as qualidades globais ou atributos a serem atendidos pelo sistema resultante. Portanto a falta da descrio dos requisitos no-funcioanis na notao BPMN foi o fato motivador deste trabalho de pesquisa uma vez que os requisitos no-funcionais so peas chaves dentro da modelagem e elicitao de requisitos. Segundo (Cysneiros, 2001) erros provocados por no se lidar convenientemente, ou simplesmente no lidar com requisitos no-funcionais so apontados entre os mais caros e difceis de corrigir.
1.2
Objetivo
Este trabalho apresenta uma pesquisa baseada na anlise de requisitos no-funcionais e na modelagem de processos de negcio, onde proposta uma abordagem, chamada BPMNFR, para integrar os requisitos no-funcionais notao BPMN, como forma de solucionar sua decincia de expressividade desses requisitos. Assim, proposta a criao de novos smbolos para que esta notao possa contemplar os requisitos no-funcionais. O analista de sistemas, no papel de analista de negcios, usa a abordagem BPMNFR para deixar de forma clara a todos os envolvidos no processo, os requisitos no funcionais que devero ser utilizados para alcanar a qualidade esperada para aplicao. Esses requisitos no-funcionais devem ser elicitados levando-se em considerao o domnio da aplicao e os atributos de qualidade que so de maior importncia para a mesma. A abordagem BPMNFR mostra como explorar, com elementos da notao de negcio, a qualidade esperada para a aplicao. Utiliza catlogos para requisitos no-funcionais que orientam a descoberta das operacionalizaes destes requisitos. O resultado desta pesquisa um processo que viabiliza a insero das operacionalizaes dos requisitos no-funcionais nos diagramas de processos de negcio. Trata da natureza subjetiva dos requisitos no-funcionais e contribui com mais uma evidncia do uso da modelagem de processos de negcio como um passo inicial do processo de Engenharia de Requisitos.
1.3
Contribuies
Uma extenso de BPMN para a modelagem de requisitos no-funcionais o principal resultado dessa dissertao. A viabilidade de aplicao da abordagem BPMNFR proposta foi vericada atravs do estudo de caso, que demonstrou a possibilidade de utilizao da 4
1.4. METODOLOGIA
mesma. O estudo e a apresentao dos conceitos e aspectos bsicos relacionados aos requisitos no-funcionais e notao para modelagem de processos de negcio foi outra contribuio deste trabalho. A apresentao da importncia da modelagem dos processos de negcios na fase de Engenharia de Requisitos para o desenvolvimento de uma aplicao de software tambm foi uma contribuio importante deste trabalho. Alm da criao e detalhamento de um catlogo do requisito no-funcional Usabilidade.
1.4
Metodologia
A pesquisa em Engenharia de Software pode ser conduzida atravs de quatro mtodos: o cientco, o de engenharia, o experimental e o analtico (Wohlin et al., 2000). Sousa, em seu trabalho (Sousa, 2004), descreve os mtodos da seguinte maneira: o mtodo cientco foca na observao de um ambiente e na tentativa de extrair dele algum modelo ou teoria que possa explicar o fenmeno estudado. O mtodo de engenharia, por sua vez, baseado na observao de solues existentes, na identicao de problemas nessas solues e na sugesto de abordagens para melhorar as solues analisadas. J o mtodo experimental pretende fornecer um modelo novo para soluo de um problema e tenta estudar o impacto desse modelo. Por m, o mtodo analtico oferece uma base analtica (ou matemtica) para o desenvolvimento de modelos. Este trabalho de pesquisa seguiu o mtodo de engenharia. Inicialmente foi feito uma reviso bibliogrca dos principais trabalhos sobre modelagens de processos de negcio e a utilizao de modelagens de processos de negcio e outras modelagens juntas. Os principais trabalhos estudados foram (de La Vara et al., 2008) que mostrava Utilizao de BPMN e MAPS (Rolland, 2007), uso do BPMN com Casos de Controle e Condies de Operaes, do ingls, Control Cases e Operation Conditions, visto em (Pavlovski and Zou, 2008). Esses trabalhos serviram para identicar pontos que precisavam ser melhorados na modelagem de processos de negcio. O passo seguinte foi fazer um estudo aprofundado sobre o BPMN, a notao de modelagem de processos de negcio escolhida. O ponto identicado para melhoria da modelagem foi a insero dos requisitos no-funcionais na notao. Na modelagem de processo de negcio, quando era necessrio modelar requisitos no-funcionais, no existia a modelagem explcita desses requisitos, isto a modelagem no oferecia informaes sucientes para deixar claros esses requisitos.
CAPTULO 1. INTRODUO
Propomos a utilizao do NFR-Framework (Mylopoulos et al., 1992; Chung et al., 2000; Mylopoulos et al., 2001) para decompor preocupaes no-funcionais em operacionalizaes que indicariam como de fato elas deveriam ser concretizadas na modelagem. Sendo assim, na nossa abordagem BPMNFR, a insero feita com as operacionalizaes e no com atributos abstratos e subjetivos. Portanto, nesta dissertao so denidas algumas adaptaes no BPMN para que possa suportar a modelagem dos requisitos no-funcionais. Por m, como forma de avaliar o trabalho, realizamos um estudo de caso no qual aplicamos a nossa proposta numa aplicao real na rea de educao.
1.5
Estrutura do trabalho
Alm do captulo de introduo, este trabalho apresenta mais cinco captulos. So eles: Captulo 2 - Modelagem de Processos de Negcio: neste captulo apresentado um resumo sobre modelos de negcios e sua aplicao em desenvolvimento de sistemas; apresenta-se tambm a modelagem de processos de negcio e algumas abordagens existentes; alm de uma introduo sobre a notao BPMN, sua utilizao e aceitao no mercado e na academia. Finalmente, apresentada a evoluo desta notao e o que motivou sua criao. Captulo 3 - Requisitos No-Funcionais: neste captulo, inicialmente, introduz-se a noo de requisitos no-funcionais, e algumas denies bsicas. Posteriormente, apresentado o NFR-Framework e sua utilizao. Depois mostrada de forma mais detalhada a obteno de operacionalizaes no NFR-Framework. Captulo 4 - Abordagem BPMNFR: neste captulo mostrado e detalhado o processo proposto para integrar os requisitos no-funcionais modelagem de processos de negcio, bem como os passos para utilizao do mesmo. Esses passos so demonstrados com um caso de exemplo. Captulo 5 - Estudo de caso: neste captulo feita a modelagem de uma aplicao real para testar a efetividade do uso da abordagem BPMNFR criada. Captulo 6 - Concluso: neste captulo so apresentadas as concluses obtidas no desenvolvimento desta dissertao, bem como descritos alguns possveis trabalhos futuros.
Snowakes are one of natures most fragile things, but just look what they can do when they stick together. Vesta M. Kelly
Modelagem de processos de negcio
O objetivo deste captulo apresentar um resumo sobre modelos de negcio e sua aplicao em desenvolvimento de sistema; apresentar a modelagem de processos de negcio e mostrar brevemente algumas abordagens; alm de mostrar de forma mais detalhada a BPMN, notao escolhida para este trabalho.
2.1
Modelos de Negcio
Modelos de Negcio so compostos por um conjunto de modelos que representam uma abstrao da realidade de uma organizao sob o ponto de vista do negcio, e representam o ambiente no qual a organizao est inserida (Davenport and Stoddard, 1994; Davenport, 1994; Eriksson and Penker, 2000; Berio and Vernadat, 2001; Paim, 2007; Bittencourt, 2009). Os modelos de negcio podem ser utilizados na disseminao do conhecimento dentro de uma organizao; no planejamento de melhorias e mudanas nos processos; na automao de processos; no desenvolvimento de sistemas (Knight, 2004; de La Vara et al., 2008; Wei et al., 2008; of Business Analysis, 2009; Sharp and McDermott, 2009); na implantao de sistemas integrados de gesto; na identicao de indicadores de desempenho; na anlise organizacional; na implantao de sistemas de workow; e na gerncia de documentos (Paim, 2007). Em relao tecnologia da informao, os modelos de negcio permitem compreender as interfaces organizacionais e o uxo de informaes atravs das unidades de negcio; contribuem para evitar sistemas redundantes; contribuem para integrao de base dados; e permitem descrever o processo de desenvolvimento de um produto. Para esta dissertao importante a aplicao dos modelos de negcio no desenvolvimento de sistemas, pois permitem unicar o conhecimento dos envolvidos e entender as necessidades que o
CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO
sistema (Knight, 2004). Particularmente, os modelos de processos de negcio tm sido vistos como uma forma de integrar as linguagens dos prossionais que tm viso de negcios e dos prossionais com viso tecnolgica (Paim, 2007; de La Vara et al., 2008).
2.2
Modelos de processos de negcio
No incio da dcada de 1990, corporaes e empresas em todo o mundo, comearam a adotar um novo conceito, o de reengenharia de processos de negcio. Como o nome sugere, este conceito tem foco em processos de negcio. Davenport (1993) dene um processo de negcio da seguinte maneira: (. . . ) um processo simplesmente um conjunto de atividades estruturadas e medidas destinadas a resultar num produto especco para um determinado cliente ou mercado (. . . ) uma ordenao especca das atividades de trabalho no tempo e no espao, com um comeo, um m, e entradas e sadas claramente identicados (. . . ). Seguindo a denio de Davenport (1993), pode-se concluir que um processo deve ter fronteiras claramente denidas, ter comeo e m, ter atividades seqenciais, que esto ordenadas no tempo e no espao, que deve haver um receptor do resultado do processo um cliente - e que a transformao em curso no mbito do processo deve agregar valor ao cliente. Outra denio de processo foi encontrada em (Rummler and Brache, 1995) que abrange claramente um foco em clientes externos da organizao, ao armar que Um processo de negcio uma srie de medidas concebidas para produzir um produto ou servio. (. . . ) A maioria dos processos so transversais, abrangendo o espao branco entre as caixas sobre o organograma. Alguns processos resultam em um produto ou servio que recebido por uma organizao externa do cliente(. . . ) Outros processos produzem produtos que so invisveis para o cliente externo, mas essencial para a gesto ecaz do negcio(. . . ). A denio acima distingue dois tipos de processos, dependendo se o processo est diretamente envolvido na criao de valor dos clientes, ou preocupado com as atividades internas da organizao. A caracterstica de processos de abranger o espao em branco no organograma indica que os processos esto integrados em algum tipo de estrutura organizacional e que permeiam esta estrutura. Finalmente, vamos considerar a denio de processo de Johansson and Pendlebury (1993). Eles denem um processo como: Um conjunto de atividades conexas que tenham uma entrada e que ser transformada 8
2.3. NOTAES
para gerar uma sada. Idealmente, a transformao que ocorre no processo deve agregar valor entrada e criar uma sada que mais til e ecaz para o destinatrio (. . . ). Esta denio enfatiza tambm a constituio de vnculos entre as atividades e a transformao que ocorre dentro do processo. Esta dissertao dene e explora o conceito de processo constitudo por um conjunto de atividades iniciadas em resposta a um evento, ordenadas no tempo e no espao, com entradas e sadas claramente identicados, gerando produtos, servios ou informao. Um processo cumpre um objetivo, seja da organizao ou da aplicao que ser gerada, e deve ser executado levando-se em considerao o escopo em que est inserido e suas particularidades. De acordo com os conceitos para modelos de processos acima citados, destacam-se os elementos utilizados no modelo de processo de negcio: atividades, atores, eventos, regras, recursos, artefatos de entradas e sadas. Os elementos de negcio so conceitualmente as informaes utilizadas para a especicao de um sistema de informao: as atividades se traduzem em funcionalidades; artefatos que so transformados pelas atividades e se transformam em entidades de informao manipuladas pelo sistema; e atores que representam os elementos (cargos, organizaes, sistemas equipamentos) que interagem com o sistema (Bittencourt, 2009).
2.3
Notaes
Algumas notaes so utilizadas para representar a modelagem dos processos de negcios tais como: BPMN - Business Process Modelling Notation (BPMI.org, 2008), Unied Modeling Language (UML) - Unied Modeling Language (Booch et al., 1998), i* (Yu, 1995). Essas notaes permitem representar processos oferecendo meios para se entender o contexto da organizao. BPMN uma notao desenvolvida pelo Business Process Management Initiative (BPMI) (Business Process Manegement Initiative) que dene um BPD (Business Process Diagram), modelo grco para processos de negcio, baseada na tcnica de uxograma (Harrington, 1991). O objetivo principal oferecer uma notao padro e compreensvel aos usurios do negcio; aos analistas de negcio responsveis pela diagramao dos processos; aos desenvolvedores, responsveis pela implementao da tecnologia que executar os processos; s pessoas do negcio que gerenciam e monitoram os processos. Uma pesquisa (Harmon and Wolf, 2008) realizada no mercado abrangendo EUA, Europa e Amrica do Sul aponta que a preferncia, com 41% dos votos dentre as empresas
entrevistadas, est na adoo do BPMN como padro para modelar processos enquanto UML cou com 30% dos votos. A notao i* centrada na modelagem das dependncias entre os atores organizacionais a m de alcanar objetivos organizacionais (Yu, 1995). Tem sido utilizada em vrios mtodos de desenvolvimento, tais como Tropos (Castro et al., 2002) ou RESCUE (Jones and Maiden, 2004). A tcnica i* faz uma anlise a partir dos objetivos relativos ao estado do negcio que um ator deseja alcanar, mas tambm dos softgoals relativos s condies, que o ator deseja obter, delineadas pelas suas intenes e razes. Todavia, a seqencialidade das atividades ou a temporalidade no o foco dessa abordagem. Alm disso, em alguns trabalhos (Estrada et al., 2006) comenta-se que os diagramas i* podem se tornar muito complexos quando for necessria uma maior granularidade e renamento dos processos na modelagem. Algumas abordagens usam UML para modelagem organizacional e processo de negcio (Eriksson and Penker, 2000). Estas abordagens usam elementos que esto prximos aos elementos utilizados na rea do desenvolvimento do software. Este fato uma desvantagem, porque apesar dos modelos serem de fcil compreenso e utilizao pelos analistas de sistemas, podem ser demasiado complexos para serem validados pelos usurios nais. Os autores (Eriksson and Penker, 2000) apresentaram em seu trabalho uma exteno para UML para que esta abordagem pudesse suportar todos os conceitos de modelos de processos de negcio. Essa extenso foi chama de Eriksson-Penker Business Extensions e foi criada baseada em alguns elementos j existentes na prpria UML. Neste trabalho, a notao BPMN foi escolhida por ser a notao com a maior preferncia do mercado e ser uma notao mantifa pela Object Management Group (OMG). Como resultado, BPMN considerada o padro, de fato, para a modelagem de processos de negcio.
2.4
BPMN
Segundo (White, 2006), o BPMN, Business Process Modeling Notation, trata-se de uma notao padro para o desenho de uxogramas em processos de negcios e web services. Na prtica trata-se de um conjunto de regras e convenes que determinam como os uxogramas devem ser desenhados. BPMN foi desenvolvido pelo Business Process Management Initiative (BPMI) e agora mantido pela Object Management Group (OMG) desde que as duas organizaes foram fundidas em 2005. O BPMN est na verso 1.1 e est sendo proposta a verso 2.0. 10
2.4. BPMN
O principal objetivo do BPMN, como dito em (Owen and Raj, 2003), prover uma notao que seja entendida por todos os usurios envolvidos no negcio. Isto inclui desde os analistas de negcio que criam o primeiro esboo dos processos at os desenvolvedores responsveis pela implementao da tecnologia que ir realizar esses processos. Outro e igualmente importante objetivo assegurar que linguagens baseadas em eXtensible Markup Language (XML) para execuo de processos como a Business Process Execution Language for Web Service (BPEL4WS) (Business Process Execution Language for Web Service) e Business Process Modeling Language (BPML) (Business Process Modeling Language) possam ser visualmente expressadas com uma notao comum. A notao do BPMN usada para produzir um diagrama, chamado Business Process Diagram (BPD). O BPD concebido a partir de um conjunto de elementos grcos que compem diagramas simples para desenvolver e de serem compreendidos. A especicao completa BPMN dene mais de 50 atributos, agrupados em quatro categorias bsicas de elementos. Um modelo de processo de negcios, portanto, uma rede de objetos grcos, com atividades (i.e. trabalho) e controladores de uxo que denem a ordem que eles so executados. Segundo (Dubray, 2004), o BPMN vem tentando achar a melhor maneira para a criao de uma notao intuitiva, usando construes familiares e um conjunto de regras comuns em processos de negcio. A seguir sero apresentados os principais conceitos e construtores relacionados notao. Para mais informaes sobre o BPMN consultar (BPMI.org, 2008).
2.4.1
Histria
Com o objetivo de criar padres e uma arquitetura comum para gerenciamento de processos de negcio, foi criada a Business Process Management Initiative (BPMI, http://www.bpmi.org), uma organizao sem ns lucrativos, iniciada pela Intalio Inc. em 2000 e que recebeu imediatamente o suporte de gigantes da indstria como a IBM, SAP, BEA, Fujitsu, WebMethods e IDS Scheer. Em agosto de 2001, o Business Process Modeling Notation Working Group (Business Process Modelling Notation Working Group (BPMN-WG)), da BPMI.org, foi formado por 35 empresas e iniciou os trabalhos para criar a BPMN. A verso 1.0 da especicao escrita por Stephen White da IBM saiu em maio de 2004. Em junho de 2005, a BPMI anunciou sua juno a OMG (Object Management Group). Segundo a OMG, at abril de 2009, existem cinqenta e trs fornecedores que suportam a notao e mais quatro esto em fase de implementao. A ltima especicao da BPMN (verso 1.1) de fevereiro
11
de 2008, mas uma nova verso (verso 2.0) provavelmente surgir at o nal de 2009. O BPMN vem recebendo no s ateno do mercado, mas tambm da academia, em (Wahl and Sindre, 2005) observa-se que praticamente todas as contribuies foram feitas em um nvel analtico e conceitual. Ainda assim existem tambm alguns estudos empricos de como BPMN utilizado na prtica (Muehlen and Recker, 2008; de La Vara et al., 2008; Recker et al., 2006). Alguns grupos de pesquisa que estudam BPMN tm a preocupao de colher dados referentes a real utilizao do BPMN no mercado, tal como dito em (Recker, 2008; Recker et al., 2006; Muehlen and Ho, 2008).
2.4.2
Elementos
Um BPD composto de um conjunto de elementos grcos. Esses elementos permitem uma criao de um diagrama simples que familiar para a maioria dos analistas de negcio. Os elementos foram escolhidos para ser distinguveis entre eles e para utilizar formatos que fossem familiares para a maior parte dos usurios. Por exemplo, atividades so retangulares e as decises so losangos. Como ressaltou (White, 2006) uma das premissas para o desenvolvimento do BPMN criar um mecanismo simples para fazer modelos de processos de negcio e ao mesmo tempo ser capaz de lidar com a complexidade inerente aos processos de negcio. A abordagem adotada para lidar com esses dois requisitos conitantes se baseia na organizao de aspectos grcos da notao em categorias especcas. Isto fornece um pequeno conjunto de categorias de notao de modo a que o leitor de um BPD possa reconhecer facilmente os tipos bsicos de elementos e compreender o diagrama. Dentro das categorias bsicas de elementos, variaes e informaes adicionais podem ser inseridas para suportar os requisitos de complexidade sem, contudo, mudar muito o objetivo de olhar e entender o diagrama. As quatro categorias bsicas de elementos so: Objetos de Fluxo (do ingls, Flow Objects) Objetos de conexo (do ingls, Connecting Objects) Swimlanes Artefatos Tambm permitido no BPD que o usurio faa o seu prprio Objeto de Fluxo ou um Artefato para que seja mais fcil de compreender. 12
2.4. BPMN
Objetos de Fluxo Um BPD tem um pequeno conjunto de (trs) elementos fundamentais, que so os Objetos de Fluxo, de forma que os analistas no tm de aprender e reconhecer um grande nmero de formas diferentes. Os trs Objetos de Fluxo so: Eventos (Figura 2.1) - representado por um crculo e algo que acontece no decurso de um processo de negcio. Eventos afetam o uxo do processo e, geralmente, tm uma causa (gatilho) ou um impacto (resultado). Eventos so crculos com centros abertos para permitir que sejam diferenciados. Existem trs tipos de eventos, com base em quando eles afetam o uxo: Incio, Intermedirio e Final.
Figura 2.1 Eventos.
Atividades (Figura 2.2) - Termo genrico para o trabalho a ser realizado. Uma atividade representada por um retngulo arredondado. Uma atividade pode ser atmica ou no atmica (composta). Atividades atmicas podem ser do tipo: servio, enviar, receber, tarefa de usurio (workow), tarefa de script ou tarefa manual. Uma tarefa de usurio deve ter um responsvel. BPMN permite especicar uma regra de negcio do tipo para cada (traduo livre - do ingls, for-each) em cada atividade. BPMN suporta tambm atividades em looping que outra construo freqentemente utilizada em processos de negcio, mas, como dito em (Dubray, 2004), ausentes em linguagens de execuo. Os requisitos funcionais de uma aplicao podem ser mapeados como atividades dentro de um BPD. Os tipos de atividades so: Atividades e Sub-processos. O Sub-processo distinguido por um pequeno sinal de mais na parte inferior central do desenho.
13
Figura 2.2 Atividades.
Gateways (Figura 2.3) - Representado por um losango, usado para controlar a divergncia e convergncia de seqncias. Assim, ir determinar decises tradicionais, assim como forking, fuso e juno dos caminhos. Marcadores internos iro indicar o tipo de comportamento do controle. Como exemplicado em (Owen and Raj, 2003) um gateway pode ser pensado como uma questo num determinado ponto do uxo do processo. Esta questo tem um conjunto denido de respostas, que so na realidade opes.
Figura 2.3 Gateways.
Objetos de Conexo Os Objetos de Fluxo so conectados em um diagrama para criar a estrutura bsica de um processo de negcio atravs dos Objetos de Conexo. Existem trs diferentes Objetos de Conexo, estes conectores so: Fluxo de Sequncia (Figura 2.4) - Representado por uma linha slida com uma seta slida e usado para mostrar a ordem (a seqncia) que as atividades sero realizadas em um processo. 14
2.4. BPMN
Figura 2.4 Fluxo de Sequncia.
Fluxo de Mensagem (Figura 2.5) - Representado por uma linha tracejada com uma seta aberta e usada para mostrar o uxo de mensagens entre dois processos distintos (entidades de negcio ou papis de negcio) que envia e recebe essas mensagens.
Figura 2.5 Fluxo de Mensagem.
Associao (Figura 2.6) - Representada por uma linha pontilhada com uma seta e usada para associar dados, texto e outros artefatos com uxo de objetos. Associaes so usadas para mostrar as entradas e sadas das atividades.
Figura 2.6 Associao.
Swimlane Muitas metodologias de modelagem de processos utilizam o conceito de swimlanes como um mecanismo para organizar atividades em categorias visuais distintas, a m de ilustrar diferentes responsabilidades ou capacidades funcionais (White, 2006). O BPMN suporta swimlanes com duas principais construes, elas so: Pool (Figura 2.7) - Representa um participante em um processo. Como exemplicou (Owen and Raj, 2003), um pool pode representar outras coisas alm de uma
15
organizao, tais como uma funo (algo que a organizao atua, como marketing ou vendas), uma aplicao (ou software de computador), um local (um local fsico na empresa), uma classe (um mdulo de software orientado a objeto), ou uma entidade (que representa um quadro lgico em um banco de dados).
Figura 2.7 Pool.
Lane (Figura 2.8) - uma sub-partio dentro de um Pool e se estender por todo o comprimento do Pool, tanto horizontal como verticalmente. Lanes so usadas para organizar e categorizar as atividades. Permite agrupar atividades que so logicamente relacionadas entre si (por exemplo, quando so realizados pelo mesmo departamento). As Lanes organizam Objetos de Fluxo, Objeto de Conexo e Artefatos mais precisamente.
Figura 2.8 Lane.
Tipicamente, um Pool representa uma organizao, e uma Lane representa um departamento dentro dessa organizao. Ao tomar os processos e colocar em Pools ou 16
2.4. BPMN
Lanes, especicam-se quem faz o qu, para os eventos deve-se especicar onde ocorrem, e gateways para especicar onde as decises so tomadas, ou quem as toma. Como mostrado em (Owen and Raj, 2003) a analogia entre essa representao e piscinas pertinente. Imagine um processo natao nadando numa raia, e alterando raias quando necessrio para realizar uma atividade, dentro de uma piscina. Um Pool pode ser considerado uma piscina de recursos. H ocasies em que o processo tem de saltar para outro grupo, porque ele tem diversos recursos necessrios para completar a atividade.
Artefatos BPMN foi projetada para permitir modelos e ferramentas de modelagem com exibilidade para estender a notao bsica. Qualquer nmero de Artefatos pode ser adicionado a um esquema conforme apropriado para o contexto dos processos de negcio a ser modelado. Artefatos permitem aos usurios (tais como analistas de negcios e desenvolvedores) colocarem mais algumas informaes no modelo/esquema. Desta forma, o modelo/esquema torna-se mais legvel. H trs pr-denidos e Artefatos, so os seguintes: Objetos de Dados (Figura 2.9) - Artefatos so principalmente objetos de dados. Os dados so digitados e objetos representam a entrada e sada de atividades. Objetos de Dados um mecanismo para mostrar como os dados so exigidos ou produzidos por atividades. Eles esto ligados a atividades atravs de associaes. Objetos de Dados so artefatos que podem representar muitos tipos diferentes de itens fsicos ou eletrnicos.
Figura 2.9 Objetos de Dados.
Grupo (Figura 2.10) - Representado por um retngulo arredondado com uma linha tracejada. O agrupamento pode ser utilizado para a documentao ou anlises nais do diagrama pelos analistas, pois eles no alteram o BPD.
17
Figura 2.10 Grupo.
Anotao (Figura 2.11) - Utilizada para dar ao leitor do modelo/diagrama um entendimento maior. BPMN tem uma anotao textual que pode ser colocada em qualquer modelo, descrevendo detalhes sobre o elemento em linguagem natural.
Figura 2.11 Anotao.
A gura 2.12 exemplica o uso de alguns elementos apresentados juntos. Nela possvel observar eventos de incio e m, atividades e artefatos que so representados por objetos de dados. Um exemplo de atividade mostrado na gura Construo de um BPD e de um objeto de dado, BPD. J a gura 2.13 exemplica o uso de atividades, sub-processos, gateway e eventos juntos. Uma das atividades da gura 2.13 Integrao e um dos sub-processos Testes.
2.5
Consideraes nais
O levantamento bibliogrco sobre Modelos de Negcio e modelagem de processos de negcio mostra a importncia do conhecimento da organizao e sua estrutura para o desenvolvimento de algum sistema de tecnologia da informao. Algumas notaes foram consideradas, i*, UML e BPMN. Dentre elas a BPMN a notao mais bem aceita no mercado e por isso escolhida para o desenvolvimento deste trabalho. 18
2.5. CONSIDERAES FINAIS
Figura 2.12 Exemplo do uso da notao BPMN.
19
20
Figura 2.13 Exemplo 2 do uso da notao BPMN.
A notao BPMN tem como principal vantagem a fcil compreenso de seus modelos por todos os atores envolvidos no processo de desenvolvimento de um sistema. Os diagramas gerados podem ser entendidos desde o analista de sistemas e o pessoal do desenvolvimento at o analista de negcios e usurios nais. Para modelar os requisitos funcionais do sistema, a notao prov um elemento que pode ser diretamente associado a esse tipo de requisito, a Atividade. Portanto, os requisitos funcionais cam explcitos durante a fase de requisitos. Porm, no so demonstrados de forma explcita os requisitos de qualidade (no-funcionais) atravs do diagrama gerado por esta notao. Apesar dos requisitos no-funcionais no serem explicitamente tratados pela BPMN, a abordagem direta seria associar anotaes textuais como artefatos para atividades em que tais requisitos se aplicam. Isto pode ser considerada uma abordagem desestruturada para iniciar a captura desses requisitos. Alm disso, anotaes textuais no so naturalmente interpretadas por mquinas. Por isso, ser proposta no captulo 4 uma abordagem, chamada BPMNFR, para que os requisitos no-funcionais sejam mostrados explicitamente no diagrama gerado.
21
Vision without action is a daydream. Action without vision is a nightmare. Japanese Proverb
Requisitos No-Funcionais
Neste captulo sero apresentados alguns conceitos de requisitos no-funcionais. O NFR-Framework ser mostrado, assim como o passo a passo para sua utilizao. Posteriormente ser apresentado um catlogo de usbilidade elaborado neste trabalho. Por m, as consideraes nais sero feitas.
3.1
Conceito
Os requisitos no-funcionais (RNFs) de software em geral se relacionam com padres de qualidade como conabilidade, performance, robustez, etc. Estes requisitos so importantes, pois denem se o software ser eciente e adequado para a tarefa que se prope a fazer ou no. Segundo (Kirner and Davis, 1996), os requisitos no-funcionais representam requisitos adicionais que denem as qualidades globais ou atributos a serem atendidos pelo sistema resultante. Segundo (Cysneiros and do Prado Leite, 1998), os requisitos no-funcionais, ao contrrio dos funcionais, no expressam nenhuma funo a serem realizados pelo software, e sim comportamentos e restries que este software deve satisfazer. Acessibilidade, segurana, condencialidade, performance, portabilidade, consistncia, manutenabilidade, ecincia, robustez, so alguns exemplos de requisitos nofuncionais. (Chung et al., 2000) tambm considera a usabilidade como um requisito no-funcional, apesar de no ser catalogada no seu framework. Ser dada uma nfase em usabilidade numa seo deste captulo, pois este o requisito no-funcional que ser utilizado para instanciar o processo desta dissertao. No h como desconsiderar a importncia dos requisitos funcionais e no-funionais para o processo de desenvolvimento de software. Entretanto, a maioria das linguagens existentes incidem sobre os requisitos funcionais, negligenciado ou esquecendo os requi-
3.1. CONCEITO
sitos no-funcionais (RNFs) durante a concepo do software. Os atributos de qualidade de software (requisitos no-funcionais), por exemplo, so vistos como conseqncia destas decises e no como algo que foi pensado. Para mudar este quadro e trat-los coerentemente, necessrio no apenas mtodos e representaes, mas tambm como promover a reutilizao de conhecimento sobre esses requisitos. Os requisitos no-funcionais desempenham um papel crtico durante o desenvolvimento de sistemas. Erros devido falta de elicitao ou a elicitao incorreta destes requisitos esto entre os mais caros e difceis de corrigir, uma vez que um sistema tenha sido implementado (Brooks, 1987; Davis, 1993). De acordo com (Cysneiros and do Prado Leite, 1998), para satisfazer um requisito no-funcional possvel que sejam criados conitos, tanto com outros requisitos no-funcionais, como com requisitos funcionais. Conseqentemente, a ausncia de tratamento dos requisitos no-funcionais durante o desenvolvimento do software pode ocasionar que esses conitos s apaream tardiamente na implementao do software. Segundo (Chung et al., 2000), no existe uma denio formal ou lista completa de requisitos no-funcionais. Tambm no existe algum esquema de classicao nico e universal que acomode todas as necessidades de aplicaes de diferentes domnios. Por conta disso para cada aplicao e domnio diferentes classicaes so feitas. Vrios trabalhos foram desenvolvidos com classicaes diferentes como visto em (Boehm, 1988; Sommerville and Sawyer, 1997; Davis, 1993). Pesquisas indicam que tcnicas baseadas em metas so mais adequadas para requisitos no-funcionais, pois possibilitam (Chung et al., 2000; Kavakli and Loucopoulos, 2003): Examinar a utilidade dos requisitos; Ter uma viso vertical desde a estratgia de alto nvel at o detalhe; Usar operadores lgicos E e OU que ajudam a uma melhor tomada de deciso; Utilizar formalizaes, que permitem provar a correo e completude dos requisitos no-funcionais. O NFR-Framework proposto por Chung e Mylopoulos uma abordagem muito representativa, pois se ajusta a todos os tipos de requisitos no-funcionais, desde as primeiras etapas do processo de desenvolvimento de software (Chung et al., 2000; Chung and Nixon, 1995; Mylopoulos et al., 1992). Por este motivo ser utilizado nesta dissertao.
23
CAPTULO 3. REQUISITOS NO-FUNCIONAIS
3.2
NFR-Framework
Mylopoulos, Nixon e Chung desenvolveram alguns trabalhos sobre requisitos nofuncionais tais como (Mylopoulos et al., 1992; Chung and Nixon, 1995; Chung et al., 2000).A evoluo desses trabalhos resultou em um framework, onde os requisitos nofuncionais so tratados como metas possivelmente conitantes, devendo ser identicados em sua forma mais geral e renados at que se chegue a um conjunto de requisitos que satisfaam ao requisito geral. A abordagem NFR-Framework (Chung et al., 2000) orientada a metas foi concebida para ser intuitiva e suportar a lgica dos desenvolvedores. Foi baseada nas rvores E/OU usadas na resoluo de problemas. Entretanto, essas metas, que representam requisitos no-funcionais podem raramente ser consideradas como totalmente satisfeitas. Diferentes decises de projeto podem contribuir positiva ou negativamente em direo a uma meta particular. Essas metas podem ser avaliadas. Essa avaliao determina se um conjunto de requisitos no-funcionais est sendo alcanado por um projeto especco. Este framework oferece uma estrutura para representar e registrar a concepo e raciocnio dos processos em grafos, chamados Softgoal Interdependency Graph (SIG). Alm disso, ele tambm oferece um catlogo de conhecimento, incluindo tcnicas de desenvolvimento. O NFR-Framework pode ser usado para denir os requisitos no-funcionais tais como segurana, exatido, performance e custo. De acordo com (Chung et al., 2000), existem passos importantes neste processo de concepo que sero visto nas sees seguintes.
3.2.1
Aquisio ou acesso a conhecimentos
Inicialmente importante que o desenvolvedor, ou analista adquira conhecimento sobre: O domnio em questo e o sistema que ser desenvolvido; Requisitos funcionais do sistema em questo; Tipos especcos de requisitos no funcionais e associado com tcnicas de desenvolvimento. Estes conhecimentos devem ser adquiridos atravs de documentos (de natureza variada) da organizao, informao sobre a prpria organizao e suas operaes. 24
3.2. NFR-FRAMEWORK
3.2.2
Identicao dos requisitos no-funcionais particulares do domnio
O desenvolvedor ou analista de sistemas estima inicialmente quais as prioridades para a organizao e o sistema. Um SIG inicial construdo apenas com os principais requisitos no funcionais estimados. Esses requisitos so os softgoals. Softgoals so todos os objetivos no-funcionais que so difcies de ser avaliados (Goldsby et al., 2007). Esses softgoals posteriormente sero compreendidos, priorizados e tratados. Na gura 3.1 existe um SIG inicial e dois NFR-softgoals, representados atravs de nuvens. Esta gura adaptada do livro de (Chung et al., 2000). Nela se ver os requisitos no-funcionais good performance for accounts e secure accounts, onde good performance e secure so os requisitos no-funcionais e accounts o domnio da aplicao (tema, tpico).
Figura 3.1 SIG Inicial (Chung et al., 2000).
3.2.3
Decomposio dos requisitos no-funcionais
Segundo (Chung et al., 2000) a decomposio dos requisitos no-funcionais se divide em tipo e tpico. Na decomposio por tipo so usados os mtodos de decomposio existentes neste framework, que indicam quais so as decomposies possveis para um determinado requisito no-funcional. A decomposio por tpicos trata da decomposio estrutural do problema. A Figura 3.2 mostra um exemplo de decomposio por tipo apresentada em (Chung et al., 2000).
3.2.4
Identicao das operacionalizaes
Em seguida se deve conceber possveis alternativas para satisfazer os requisitos nofuncionais no sistema em questo. Este tpico ser detalhado na seo 3.3.
25
Figura 3.2 Decomposio por tipos (Chung et al., 2000).
26
3.2. NFR-FRAMEWORK
3.2.5
Lidar com Ambigidades, Prioridades e Interdependncias entre requisitos no-funcionais e operacionalizaes
Um SIG pode crescer e car muito grande e complexo. Por isso necessrio lidar com ambigidades, prioridades e interdependncia de operacionalizaes. As prioridades organizacionais ou carga de trabalho que fazem parte do domnio da aplicao devem ser analisadas. Alm disso, requisitos podem ser identicados como prioridades durante vrias fases do desenvolvimento. Os softgoals prioritrios so identicados como crticos e vitais para o sucesso do software ou organizao. Esses requisitos prioritrios so identicados por um sinal de exclamao, como na gura 3.3.
Figura 3.3 Identicao de um softgoal como prioridade (Chung et al., 2000).
Contudo tambm necessrio observar de que forma as operacionalizaes de um requisito no-funcional pode inuenciar positivamente ou negativamente em outro. Essas interaes so importantes, pois tm um impacto nas decises de projeto. As interdependncias implcitas s so identicadas medida que o grco construdo, as explcitas aparecem de forma direta atravs da decomposio. Na gura 3.4 as interdependncias explcitas so as setas slidas e as implcitas so as tracejadas.
27
3.2.6
Escolher as operacionalizaes
O processo de renamento continua at o desenvolvedor ou analista de sistemas considerar que as solues possveis para aquele domnio especco foi sucientemente detalhada e no h mais nenhuma alternativa a ser considerada. Como os softgoals foram renados e o desenvolvedor ou analista j os detalharam sucientemente, agora chega o momento de aceitar ou rejeitar essas operacionalizaes para fazerem parte da aplicao. Existem opes de operacionalizaes de softgoals no grafo, ver gura 3.4. Algumas sero aceitas (indicadas por um v) e outras rejeitadas (indicadas por um x). Como mostrado na gura 3.4 foram identicadas trs possveis formas de autenticar o acesso dos usurios: Use Pin, Compare Signature e Require additional ID. A operacionalizao aceita foi Compare Signature e por outro lado Require additional ID foi rejeitada, quanto nenhum ao foi tomada em relao a Use Pin.
3.2.7
Apoiar decises com concepo lgica
Uma premissa desse framework que as decises de concepo devem ser suportadas com argumentos bem justicados, ou, como (Chung et al., 2000) chama, deve registrar o design rationale. As razes podem ser indicadas para que haja renamentos, para selecionar alguma alternativa de operacionalizao para a aplicao especca. O rationale representado atravs do claim-softgoal. Quando uma declarao utilizada para argumentar a favor ou contra alguma coisa, que constitui um argumento, isto um claim-softgoal. O claim-softgoal representado por uma nuvem tracejada, como visto na gura 3.5. As argumentaes devem ser expressas para fazer o renamento, selecionar alternativas de operacionalizaes, denirem as priorizaes em qualquer fase do processo.
3.2.8
Avaliar os impactos das decises
Para determinar o impacto das decises, tanto as decises atuais quanto as anteriores so consideradas. O processo de avaliao pode ser visto como bottom-up. Portanto pode ser considerado como trabalho de baixo para cima, comeando com as decises, que muitas vezes so as folhas do grafo, e, muitas vezes, esto na sua parte inferior. Em seguida, o processo de avaliao trabalha para a parte superior do grco, determinando o impacto sobre o nvel mais alto, os principais softgoals. Estes softgoals globais reetem os 28
3.2. NFR-FRAMEWORK
Figura 3.4 Seleo de operacionalizaes (Chung et al., 2000).
29
Figura 3.5 Claim-Softgoal (Chung et al., 2000).
30
3.3. OPERACIONALIZAO DE REQUISITOS NO-FUNCIONAIS
requisitos no-funcionais previstos pelo desenvolvedor ou analista para a qual a aplicao est sendo desenvolvida. No necessrio que esses passos sejam seqenciais, alm disso, alguns podem iterar mais vezes durante o processo de concepo.
3.3
Operacionalizao de requisitos no-funcionais
O processo de renamento de um requisito no-funcional prov uma melhor interpretao do signicado do mesmo, porm ainda no fornece um meio de alcanar um requisito no-funcional renado. Conforme Chung em (Chung et al., 2000), quando um requisito no-funcional sucientemente renado ser possvel identicar vrias tcnicas de desenvolvimento que possam ser utilizadas para executar este requisito no-funcional, depois ser feita a escolha da soluo especca para o sistema em questo. Todavia, importante frisar que existe uma lacuna entre um softgoal e as tcnicas de desenvolvimento. Para romper esta lacuna necessrio observar algumas questes tais como anlise de performance, ambigidades, prioridades, informaes do domnio da aplicao. Esses fatores devero ser observados em vrios passos no processo da operacionalizao. Segundo Chung em (Chung et al., 2000), as operacionalizaes no so limitadas a operaes e funes. Como alternativa, operacionalizaes podem ser correspondentes a dados e restries da aplicao. Assim como os softgoals, as operacionalizaes podem tambm ter contribuies positivas ou negativas. De acordo com (Chung et al., 2000) as operacionalizaes podem ser denidas a partir de catlogos de tcnicas de desenvolvimento. Os catlogos podem ajudar a procurar por possveis operacionalizaes. A transio de requisito no-funcional para operacionalizao um passo crucial no processo, pois o requisitos no-funcionais precisam ser convertidos em algo que seja implementvel. Contudo, inicialmente pode no ser possvel converter requisitos em uma operacionalizao concreta em apenas um passo, sero necessrios renamentos. No NFR-Framework as operacionalizaes so tratadas como softgoals que podem novamente ser renados em outros softgoals e decompostos em operacionalizaes mais especcas. Os catlogos tambm mostram possibilidades de decomposio de operacionalizaes em operacionalizaes mais especializadas. Eles tambm mostram as contribuies dessas operacionalizaes em outras.
31
Figura 3.6 Identicao de possveis operacionalizaes para requisito no-funcional Softgoal (Chung et al., 2000).
32
3.4. CATLOGO DE USABILIDADE
As contribuies AND e OR so arcos, as direes das contribuies so setas nas pontas dos traos, as contribuies so sinais de mais (+) e menos (-). As operacionalizaes so destacadas com um contorno mais escuro .
Figura 3.7 Operacionalizaes (Chung et al., 2000).
3.4
Catlogo de Usabilidade
O requisito no-funcional utilizado no estudo de caso e no caso de exemplo desta dissertao usabilidade, por este motivo, se faz necessria a utilizao de um catlogo deste requisito. Este catlogo refere-se usabilidade para interfaces. O trabalho de (Chung et al., 2000) no prev nenhum catlogo para este requisito, nem foi encontrado nenhum catlogo que utilizasse o NFR-Framework como base. Em (Cysneiros, 2007) havia um catlogo para usabilidade, porm esse catlogo utiliza o i* para model-lo e como este estudo baseia-se no NFR-Framework, no iremos utiliz-lo.
3.4.1
A Pesquisa
Para o desenvolvimento do catlogo usamos como base trs conceitos de usabilidade, metas, princpios de design e heursticas. As metas esto num nvel de abstrao mais alto, so fatores de satisfao e estabelecem critrios de usabilidade para aceitabilidade de um sistema (Preece et al., 2005). Os princpios de design so lembretes do que fornecer e do que evitar durante o design da interface (Norman, 1988). Heursticas so princpios da usabilidade utilizados na prtica, servem para avaliar a aceitabilidade das interfaces (Nielsen, 1994). Preece em seu livro (Preece et al., 2005) descreveu seis metas de usabilidade baseandose na idia de que usabilidade geralmente considerada como o fato que assegura que os produtos so fceis de usar, ecientes e agradveis. So elas: Ser ecaz no uso - refere-se a quanto um sistema bom em fazer o que se espera dele;
33
Ser eciente no uso - refere-se maneira como o sistema auxilia os usurios na realizao das tarefas; Ser seguro no uso - implica proteger o usurio de condies perigosas e situaes indesejveis; Ser de boa utilidade - refere-se medida na qual o sistema propicia o tipo certo de funcionalidade, de maneira que os usurios possam realizar aquilo de que precisam ou que desejam; Ser fcil de aprender - refere-se quo fcil e aprender a usar o sistema; Ser fcil de lembrar como se usa - refere-se facilidade de lembrar como utilizar o sistema. J os princpios de design descritos por Norman em (Norman, 1988) tratam de abstraes generalizveis, destinadas a orientar designers a pensar sobre aspectos diferentes. Os princpios mais conhecidos referem-se a como determinar o que os usurios devem ver e fazer quando realizam tarefas. Os princpios de Norman so: Visibilidade - refere-se maneira que as funes esto dispostas numa determinada interface ou produto. Quanto mais visveis forem as funes, mais os usurios sabero como proceder; Feedback - refere-se ao retorno de informaes a respeito da ao que foi feita e do que foi realizado. Est relacionado ao conceito de visibilidade; Restries - refere-se determinao das formas de delimitar o tipo de interao que pode ocorrer em um determinado momento; Mapeamento - refere-se relao entre os controles e os seus efeitos no mundo; Consistncia - refere-se a projetar interfaces de modo que tenha operaes semelhantes e que utilizem elementos semelhantes para a realizao de tarefas similares; Affordance - Termo utilizado para se referir ao atributo de um objeto que permite s pessoas saber como utiliz-lo. Dentre os princpios de design descritos por (Norman, 1988), o ltimo no ser utilizado para a criao do catlogo, pois este se trata de um catlogo para interfaces. 34
O prprio autor argumenta que no faz sentido tentar projetar affordances reais para interfaces. Seguindo o detalhamento dos trabalhos citados para a elaborao do catlogo, Nielsen em seu trabalho com usabilidade (Nielsen, 1994), criou dez heursticas para este requisito no-funcional. So elas: Visibilidade do status do sistema - o sistema mantm os usurios sempre informados sobre o que est acontecendo, fornecendo um feedback adequado, dentro de um tempo razovel; Compatibilidade do sistema com o mundo real - o sistema fala a linguagem do usurio utilizando palavras, frases e conceitos familiares a ele, em vez de termos orientados ao sistema; Controle do usurio e liberdade - fornece maneiras de permitir que os usurios saiam facilmente dos lugares inesperados em que se encontram, utilizando sadas de emergncia claramente identicadas; Consistncia e padres - evita fazer com que os usurios tenham que pensar palavras, situaes ou aes diferentes que signicam a mesma coisa; Preveno de erros - onde possvel, impede a ocorrncia de erros; Reconhecimento em vez de memorizao - tornar objetos, aes e opes visveis; Flexibilidade e ecincia de uso - fornece aceleradores invisveis aos usurios inexperientes, os quais, no entanto, permitem aos mais experientes realizar tarefas com mais rapidez; Esttica e design minimalista - evita o uso de informaes irrelevantes ou raramente necessrias; Ajuda e documentao - fornece informaes que podem ser facilmente encontradas e ajuda mediante uma srie de passos concretos que podem ser facilmente seguidos; Ajuda os usurios a reconhecer diagnosticar e recuperar-se de erros - utiliza linguagem simples para descrever a natureza do problema e sugere uma maneira de resolv-lo.
35
Alm de pesquisar as heursticas que Nielsen criou, as metas de Preece e os pricpios de Norman, foi consultada tambm a existncia de algum outro catlogo para o requisito no-funcional usabilidade. No trabalho de (Cysneiros, 2007), o autor elabora um catlogo utilizando a notao i*.
3.4.2
O catlogo proposto
Todos os trabalhos citados anteriormente foram observados para a criao do novo catlogo de usabilidade que utiliza o NFR-Framework. Este catlogo ser mostrado por partes, pois a visualizao dele em apenas uma gura no apropriada por ser demasiado grande. No catlogo, as metas do trabalho de (Norman, 1988) se transformaram nos quatro softgoals que esto imediatamente abaixo do requisito Usabilidade. Esse softgoals so: ecincia / eccia, utilidade, segurana no uso e fcil de aprender e usar. Esses so os softgoals que esto na parte mais alta do SIG, pois tem um nvel de abstrao mais alto e ainda no so operacionalizveis. A gura 3.8 est focada na dimenso de ecincia / eccia. Visibilidade, que se refere maneira que as funes esto dispostas numa interface, e restries, que se refere determinao das formas delimitaro tipo de interao, (do trabalho de (Norman, 1988)) so os softgoals imediatamente abaixo que contribuem para atingir a meta ecincia / eccia. Visibilidade deriva para Feedback, ajuda e design minimalista, enquanto Restries deriva para o design minimalista. As operacionalizaes destes softgoals foram criadas baseadas nas heursticas de (Nielsen, 1994) e seus detalhamentos. Relacionadas utilidade (vide gura 3.9) a exibilizao e o livre controle do usurio so softgoals que contribuem para atingir esta meta principal e esto relacionadas ao trabalho de Nielsen. Restries um softgoals que foi associado ecincia e eccia e que tambm est associado meta de utilidade, porm neste caso ele contribui negativamente. As operacionalizaes destes softgoals tambm foram criadas baseadas nas heursticas de (Nielsen, 1994) e seus detalhamentos. J o softgoals segurana no uso engloba a heurstica de Nielsen Tratamento de erros, vide gura 3.10. Esta heurstica subdividida em duas partes, preveno de erros e restabelecer de erros. Essas partes so detalhadas e operacionalizadas seguindo orientaes do trabalho de (Nielsen, 1994). Por m, na gura 3.11 o softgoals fcil de aprender e usar que une duas metas de (Preece et al., 2005) em um softgoal s. Esse softgoal expandido para outros softgoals, consistncia e mapeamento, que esto relacionados ao trabalho de (Norman, 1988). Como 36
Figura 3.8 Catlogo de usabilidade - Ecincia e Eccia
37
38
Figura 3.9 Catlogo de usabilidade - Utilidade
Figura 3.10 Catlogo de usabilidade - Segurana no uso
39
aconteceu em outras partes, as operacionalizaes destes softgoals foram criadas baseadas nas heursticas de (Nielsen, 1994) e seus detalhamentos.
3.4.3
Consideraes
Este catlogo no tem a pretenso de esgotar todas as possibilidades de operacionalizaes que satisfaam o requisito no-funcional usabilidade, nem muito menos dita de forma inexvel os grupamentos que foram feitos. Este catlogo tem objetivo de dar um passo inicial na criao de um catlogo genrico e mais completo para este requisito utilizando como base o NFR-Framework. Conforme dito neste captulo, os catlogos gerados pelo NFR-Framework podem e devem ter renamentos at que se chegue num ponto em que satisfaa quem ir utiliz-los.
3.5
Consideraes Finais
Acredita-se que para este trabalho a utilizao do NFR-Framework dentro do contexto da modelagem de processos de negcio ir contribuir para uma melhoria na qualidade da especicao, modelagem, anlise e decises tomadas ao longo do processo de desenvolvimento do sistema de informao. O NFR-Framework torna explcitas as ligaes e as solues entre as softgoals e as operacionalizaes coerentes em cada projeto. Isto permite uma visualizao clara dos objetivos e, por conseguinte, analisar sistematicamente, o quanto o projeto esta alinhado com as especicaes do usurio. A sua utilizao combinada, juntamente com a modelagem de processos de negcio, ir ajudar a melhorar a comunicao com entre os analistas de negcios e analistas de sistema, alinhando assim suas expectativas de maneira completa.
40
Figura 3.11 Catlogo de usabilidade - Fcil de aprender e usar
41
Making the simple complicated is commonplace; making the complicated simple, awesomely simple, thats creativity. Charles Mingus
Abordagem BPMNFR
As notaes de modelagem de processos de negcio podem capturar as funcionalidades de um software, porm no capturam ou identicam requisitos no-funcionais (vide captulo 2). A notao BPMN, portanto no suporta requisitos no-funcionais explicitamente. Todavia, os requisitos no-funcionais so peas chaves dentro da modelagem e elicitao de requisitos (vide captulo 3). Erros provocados por no se lidar convenientemente, ou simplesmente no lidar com requsitos no-funcionais so apontados como estando entre os mais caros e difceis de corrigir. Neste captulo proposta uma abordagem, chamada BPMNFR, para integrar requisitos no-funcionais modelagem dos processos de negcio. Esta abordagem foi elaborada para manter a legibilidade da notao BPMN e incorporar, alm de tratar os requisitos no-funcionais. Assim, prope-se estender a notao BPMN e prover em nvel de negcio a modelagem dos requisitos no-funcionais, atravs da insero das operacionalizaes de requisitos no-funcionais nos diagramas de processos de negcio. Para explicar a abordagem BPMNFR ser utilizado um pequeno caso de exemplo relacionado ao processo de desenvolvimento de objetos de aprendizagem.
4.1
A abordagem BPMNFR
A abordagem BPMNFR foi elaborada para que mantivesse a legibilidade da notao utilizada, BPMN, bem como considerar os requisitos no-funcionais ausentes na notao original. A primeira tentativa de solucionar o problema (vide gura 4.1) tinha os seguintes passos:
4.1. A ABORDAGEM BPMNFR
Criao de um BPD com a modelagem da aplicao; Utilizao, extenso ou criao de catlogos dos requisitos no-funcionais; Insero de maneira direta dessas operacionalizaes dentro do primeiro BPD gerado. Desta forma cobriria a decincia da notao, porm no deixaria assinalado a que requisito no-funcional quela operacionalizao se referia. Como numa modelagem podem existir vrios requisitos no-funcionais que precisam ser tratados, no haveria como saber a qual requisisito no-funcional a operacionalizao se tratava. Desta forma ainda existia uma passo que precisava ser dado para que houvesse essa correspondncia. Depois da primeira tentativa, chegou-se na evoluo da abordagem BPMNFR. A nova abordagem elaborada consiste em quatro fases, so elas: Construo do BPD; Insero de rtulos nas atividades do BPD que representam os requisitos nofuncionais identicados para aquela atividade; Utilizao, extenso ou criao de catlogos dos requisitos no-funcionais; Insero das operacionalizaes no BPD, agrupadas no grupo lgico rotulado. A gura 4.2 representa gracamente o processo que envolve a abordagem BPMNFR, o uxo de atividades alm dos artefatos que so gerados a cada atividade. Durante o processo, ao todo, so gerados 4 artefatos como resultado de cada atividade. Esses artefatos sero detalhados nas sees seguintes. As atividades deste processo podem iterar mais vezes durante o processo de modelagem, portanto no necessariamente os primeiros artefatos produzidos sero os artefatos denitivos na modelagem.
4.1.1
Construo do BPD
Na primeira fase, feita a modelagem dos processos de negcio. Esses processos de negcio podem estar relacionados a um processo de desenvolvimento de uma aplicao, ou estarem de fato relacionados diretamente com a modelagem da prpria aplicao, onde as funcionalidade da mesma so tratadas como atividades dentro da notao e os atores como lanes dentro de um pool. Independentemente do tipo de modelagem que for feita, o diagrama de processos gerado dever ser validado pelo analista de negcios e analista de sistemas a m de
43
CAPTULO 4. ABORDAGEM BPMNFR
44 Figura 4.1 Figura da Abordagem BPMNFR inicial para insero de requisito no-funcional em BPMN.
Figura 4.2 Figura da Abordagem BPMNFR Final.
45
garantir que o processo foi adequadamente modelado e entendido. Esta primeira fase pode ter mais de uma interao com a nalidade de renar o diagrama de processos. O artefato gerado desta atividade dentro do processo da abordagem BPMNFR um BPD. Caso de exemplo Um caso de exemplo foi utilizado para exemplicar o uso da abordagem BPMNFR. Esse caso de exemplo trata do processo de desenvolvimento de Objetos de Aprendizagem. Objetos de Aprendizagem so quaisquer recursos digitais que possam ser reutilizados e ajudem na aprendizagem (Wiley, 2002). Para os objetos de aprendizagem algumas caractersticas so essenciais, tais como: devem ser adaptveis s necessidades, habilidades e estilos cognitivos do aprendiz; devem ser acessveis de qualquer lugar a qualquer hora. Para que o se obtenha esse resultado, importante que haja uma equipe multidisciplinar no desenvolvimento dos objetos de aprendizagem. A integrao de equipes multidisciplinares fator necessrio para a produo de componentes de aprendizagem. Faz-se necessria a integrao de diversos prossionais especialistas em vrias reas do conhecimento: como pedagogos, jornalistas, designers, por exemplo. Estes precisam comunicar-se e trabalhar colaborativamente (Gomes et al., 2006). O caso de exemplo foi modelado utilizando a notao de BPMN, sendo gerado desta forma o BPD da gura 4.3. Neste BPD, foram levados em considerao os macro-processos de desenvolvimento de Objetos de Aprendizagem utilizado por uma empresa especializada neste tipo de desenvolvimento. Este processo um renamento do processo criado por (Gomes et al., 2006). Nele possvel observar os macro-processos de Elaborao dos textos Tcnicos, Elaborao do material didtico, Elaborao do roteiro, Criao dos elementos grcos e Desenvolvimento. Existem tambm dois gateways que vericam a necessidade ou no de mais uma iterao com o sub-processo anterior. No iremos detalhar cada subprocesso, j que este caso apenas um exemplo para atestar apenas as atividades do processo da abordagem BPMNFR. As prximas fases sero descritas e detalhadas nas subsees seguintes.
4.1.2
Rtulos de requisitos no-funcionais no BPD
Nesta fase, o artefato de entrada o digrama (BPD) gerado na fase anterior. Os analistas de negcios iro identicar os requisitos no-funcionais pertinentes aplicao, pois o 46
Figura 4.3 Processo geral de desenvolvimento um objeto de aprendizagem
47
que determina a existncia ou no de um requisito no-funcional na aplicao o seu domnio. O trabalho de (Bittencourt, 2009) mostra uma sistematizao para identicao dos requisitos no-funcionais. Aps a identicao dos requisitos no-funcionais relevantes para o determinado domnio necessrio relacionar as atividades do BPD com os requisitos no-funcionais. As atividades que forem relacionadas com determinado requisito no-funcional devero ser rotuladas com a inicial do requisitos no-funcionais a que ela est associada. Se existir mais de um requisito no-funcional que deve ser associado a uma atividade dentro do BPD, devem-se colocar tantos rtulos quanto a quantidade de requisitos no-funcionais associados. No nosso caso de exemplo, usaremos o requisito no-funcional mais crtico para a aplicao, j que a nalidade neste momento apenas apresentar os processos da abordagem BPMNFR, como dito anteriormente. O requisito no-funcional identicado como crtico e mais relevante para a aplicao foi usabilidade. Desta maneira, o requisito no-funcional de usabilidade foi associado a algumas atividades dentro do BPD utilizando os rtulos como mostra a gura 4.4. As atividades que tiveram a usabilidade como requisito no-funcional associado foram elaborao do roteiro, criao dos elementos grcos e desenvolvimento. Nestas trs atividades a preocupao com usabilidade crtica e por isso o requisito no-funcional foi associado. O artefato gerado nesta atividade um BPD rotulado com os requisitos no-funcionais associados a atividades. Identicados os requisitos no-funcionais e associadas as atividades com seus devidos rtulos, o prximo passo descobrir quais as operacionalizaes desse(s) requisito(s) no-funcional(ais). Isso mostrado na prxima seo.
4.1.3
Detalhamento do requisito no-funcional
Os artefatos de entrada para esta atividade so os requisitos no-funcionais identicados na etapa anterior. Com os requisitos no-funcionais identicados e relacionados s atividades do BPD necessrio que sejam descobertas as operacionalizaes destes requisitos no-funcionais. Para detalhamento dessas operacionalizaes usa-se o NFR-Framework que j foi apresentado no segundo captulo. Se j existir algum catlogo em (Chung et al., 2000) para o requisito no-funcional em questo, ele poder ser utilizado. Porm deve ser adaptado para levar em considerao as particularidades do domnio da aplicao. Se o catlogo no existir, deve-se cri-lo a partir do NFR-Framework, tambm observando o 48
Figura 4.4 BPD com rtulos
49
domnio da aplicao. Quando houver mais de um requisito no-funcional envolvido, necessrio que se tenha uma maior ateno na criao do catlogo. Essa ateno maior importante, pois podem existir interdependncias entre os requisitos, ocasionando desta forma uma interferncia, ou no, positiva ou negativa numa operacionalizao ou softgoal de outro requisito diretamente. Esta interferncia pode ajudar ou prejudicar a satisfazer este outro requisito. Para o caso de exemplo deste captulo e o estudo de caso utilizado no captulo 5 desta dissertao, foi necessria a criao de um catlogo do RNF utilizado, usabilidade (vide captulo 3), j que (Chung et al., 2000) no prev nenhum catlogo para este requisito, nem foi encontrado nenhum catlogo que utilizasse o NFR-Framework como base. Esta atividade gera um artefato de sada que o catlogo dos requisitos no-funcionais. Com o catlogo do requisito no-funcional criado e/ou renado o prximo passo identicar quais operacionalizaes desse catlogo sero relevantes para o domnio da aplicao, pois no necessrio o uso de todas as operacionalizaes sempre. Para exemplicar, utilizaremos apenas duas operacionalizaes do catlogo de usabilidade genrico visto na gura 3.11, a prototipao e o teste de usabilidade.
4.1.4
Insero das operacionalizaes no BPD
Os artefatos de entrada para esta atividade do processo da abordagem BPMNFR so o BPD modelado na primeira atividade e os catlogos dos requisitos no-funcionais gerados a partir do passo anterior. Finalmente o BPD, previamente modelado, dever ser modicado, isto , alguns elementos devem ser removidos ou introduzidos de acordo com as operacionalizaes identicadas. Nem todas as operacionalizaes devero estar neste ltimo passo, cabe ao analista de negcios juntamente com o analista de sistemas decidir quais as operacionalizaes sero pertinentes aos domnio. Como dito antes, j existem trabalhos, como por exemplo o de (Bittencourt, 2009), que mostram como identicar essas operacionalizaes com o envolvimento dos stakeholders. As operacionalizaes escolhidas se transformaro em atividades ou macro-processos dentro do BPD. Essas atividades/macro-processos devem estar agrupadas num grupo lgico que ser rotulado com a letra inicial do requisito no-funcional a que ele se refere. Esse grupo lgico pode estar no macro-processo denido ou dentro dos subprocessos. O grupo lgico deve estar associado atividade que estava antes rotulada. Essa associao pode ser feita atravs do elemento de associao, ou pode estar dentro de um subprocesso 50
da atividade antes rotulada. Aplicando ao exemplo, a gura 4.5 mostra o novo processo de negcio. As operacionalizaes escolhidas para integrarem este BPD foram prototipao e teste de usabilidade. Estas operacionalizaes devero estender esse BPD a partir da dos rtulos criado no segundo passo da abordagem BPMNFR. Estes rtulos esto no macro-processo de Elaborao do roteiro do objeto de aprendizagem, Criao dos elementos grcos e Desenvolvimento. A primeira operacionalizao est associada ao macro-processo de Elaborao do roteiro do objeto de aprendizagem e ser o teste de usabilidade. Ele est associado ao macro-processo atravs de um objeto de um uxo de seqncia e est envolto no grupo lgico rotulado. A prxima operacionalizao adicionada foi a Prototipao. Esta operacionalizao est associada ao macro-processo de Criao dos elementos grcos atravs de um uxo de seqncia e tambm est envolto no grupo lgico. A ltima operacionalizao inserida foi o Teste de usabilidade novamente e est associada ao macro-processo de desenvolvimento atravs de um uxo de seqncia e novamente envolto num grupo lgico. O diagrama foi modicado como o resultado da introduo do grupo lgico. Novas tarefas foram denidas (como resultado das operacionalizaes dos requisitos nofuncionais) e nenhuma tarefa foi retirada. Os macro-processos novos como teste de usabilidade e prototipao esto envoltas pelo grupo lgico. Note que o grupo lgico est associado atividade que o gerou atravs do elemento associao. Para facilitar o entendimento, foi criada a tabela 4.1 com quatro colunas. Na primeira colocada a tarefa que foi rotulada na segunda fase da abordagem BPMNFR, na segunda colocado o requisito no-funcional que se refere tarefa rotulado, na terceira coluna se ver as operacionalizaes que foram encontradas para o requisito e que esto diretamente ligadas a tarefa que foi rotulada, na quarta coluna se ver as classicaes das operacionalizaes. Atravs desta tabela possvel fazer a correspondncia entre as tarefas rotuladas do BPD e as operacionalizaes que foram criadas a partir do requisito no-funcional. Nesta tabela as operacionalizaes tm duas classicaes. A primeira classicao est relacionada ao lugar que as operacionalizaes ocupam dentro do BPD obtido atravs da execuo do ltimo passo da abordagem BPMNFR. Essas operacionalizaes podem ser de dois tipos:
51
52
Figura 4.5 BPD com operacionalizaes
4.2. ANLISE COMPARATIVA COM OUTRAS ABORDAGENS
A - so as operacionalizaes que esto associadas atravs de um uxo de seqncia tarefa anteriormente rotulada; S - so as operacionalizaes fazem parte do sub-processo da tarefa anteriormente rotulada, estando, portanto dentro do sub-processo desta tarefa. A segunda classicao est relacionada natureza da operacionalizao, isto , se a operacionalizao se tornou uma tarefa ou um macro-processo dentro do BPD. T - Se a operacionalizao se tornar uma tarefa nica; MP - Se a operacionalizao se tornar um macro-processo com tarefas internas.
Tabela 4.1 Correspondncias de operacionalizaes
Depois da insero das operacionalizaes em forma de tarefas dentro de um BPD e agrupadas atravs de um grupo lgico a abordagem BPMNFR sugere uma maneira explcita de prover em nvel de negcio a modelagem dos requisitos no-funcionais.
4.2
Anlise comparativa com outras abordagens
Nesta seo so apresentados alguns trabalhos que tambm fazem a modelagem dos processos de negcio e de requisitos no-funcionais.
4.2.1
i*
Yu prope o framework i* - denominao associada a intencionalmente distribudo. uma tcnica de modelagem que faz uso dos conceitos do NFR-Framework (Chung et al., 2000), especialmente dos softgoals, que so utilizados nos dois modelos: Dependncias Estratgicas Strategic Dependency (SD) e Razes Estratgicas Strategic Rationale (SR) para elaborar modelos de negcio e auxiliar o redesenho de processos(Chung et al., 2000). No framework i* (Yu, 1995), as organizaes constituem-se de atores sociais que dependem uns dos outros para satisfazer um softgoals, alcanar objetivos, executar tarefas
53
e fornecer recursos. A tcnica i* faz uma anlise a partir dos objetivos relativos ao estado do negcio que um ator deseja alcanar, mas tambm dos softgoals relativos s condies, que o ator deseja obter, delineadas pelas suas intenes e razes. Todavia, a seqencialidade das atividades ou a temporalidade no o foco dessa abordagem. Alm disso, em alguns trabalhos comenta-se que os diagramas i* podem se tornar muito complexos quando for necessria uma maior granularidade e renamento dos processos na modelagem. Alm de ser uma notao pouco utilizada no mercado, em contraponto notao BPMN estendida nesta dissertao.
4.2.2
La Vara, Snchez e Pastor
O trabalho de (de La Vara et al., 2008) descreve uma abordagem baseada em modelagem de processos de negcios e prope uma anlise feita atravs de BPMN e Maps (Rolland, 2007) (uma abordagem em objetivo / estratgia). O ambiente de negcio modelado na forma de diagramas de processo de negcio. Os diagramas so validados pelos usurios nais, assim a nalidade do sistema analisada a m de decidir sobre o efeito que o sistema de informao deve ter sobre os processos de negcio. Depois, requisitos so especicados por meio da descrio das tarefas dos processos de negcio que devem ser suportadas pelo sistema. Paralelamente a abordagem BPMNFR! (BPMNFR!), esta abordagem tambm utiliza rtulos, porm os rtulos nessa abordagem servem para identicar as atividades que podero ser automatizadas. O seu foco no se encontra na identicao e integrao de NFR.
4.2.3
Brito e Moreira
Brito e Moreira apresentam, em seu trabalho (Brito and Moreira, 2004), uma separao de concerns durante a fase de engenharia de requisitos, adicionando duas ideias principais. Primeiro, prope a utilizao de catlogos para ajudar na identicao e especicao de concerns. O catlogo usado baseado principalmente em NFR-Framework. Em seguida, explora um renamento das regras de composio, usando um conjunto de operadores com base nos principais operadores de LOTOS. O trabalho est voltado para concerns e no leva em considerao as preocupaes relativas ao negcio, enquanto na abordagem BPMNFR! os processos de negcio so o principal foco considerando no s a atulizao de catlogos existentes, mas a esteno e/ou a criao de novos catlogos. 54
4.2. ANLISE COMPARATIVA COM OUTRAS ABORDAGENS
4.2.4
Pavloviski e Zou
O objetivo identicar requisitos no-funcionais a partir de restries do negcio identi cadas atravs da modelagem de processo de negcio. (Pavlovski and Zou, 2008) utiliza BPMN para modelar processos e propem uma extenso notao para representar requisitos no-funcionais atravs da condio de operao que descrita atravs do control case. A condio de operao representa uma restrio associada a uma atividade no modelo de processo de negcio. O control case uma descrio textual da condio de operao onde so descritos os riscos ao negcio e os controles que so aplicados para mitigar os riscos. De acordo com os autores possvel identicar, durante o processo de modelagem, os seguintes requisitos no-funcionais em alto nvel: desempenho de tarefas, polticas de segurana, disponibilidade das atividades ou processos, tempo de resposta das atividades ou processos, restries organizacionais e regulatrias e a qualidade da interao do usurio com a atividade. O foco durante a anlise do negcio identicar os riscos que possam ameaar os objetivos do negcio e que tm origem nas restries do negcio. O mtodo proposto oferece um meio de considerar as restries durante a modelagem de processos como provveis fontes de requisitos no-funcionais e prope que o control case seja um canal que facilite a comunicao sobre requisitos no-funcionais entre o analista e os stakeholders. A identicao destes requisitos permanece em alto nvel, no h representao do rationale ou a decomposio dos mesmos.
4.2.5
Abordagem BPMNFR
A abordagem BPMNFR apresentada nesta dissertao utiliza o BPMN para a descrio e modelagem dos processos de negcio e o NFR-Framework como base para obteno das operacionalizaes dos requisitos no-funcionais. O objetivo identicar requisitos no-funcionais a partir de restries do negcio identicadas atravs da modelagem de processo de negcio. Esta abordagem tambm deixa modelados de forma explcita os requisitos nofuncionais durante todo o seu processo, deste quando esses requisitos so pensados em alto nvel, at quando eles so operacionalizados. Existe inclusive um mapeamento para identicar qual requisito no-funcional de alto nvel se tornou numa operacionalizao.
55
4.3
Consideraes Finais
A abordagem BPMNFR proposta visa a insero de requisitos no-funcionais durante a fase de modelagem de negcio, porm com a facilidade de uso de uma notao que seja de fcil entendimento entre TI e clientes/usurios, conseguindo, desta forma, que os objetivos de negcio sejam melhor alcanados. Para descobrir as operacionalizaes dos requisitos no-funcionais usa-se um framework baseado em metas que, como visto no captulo 3, mais adequado para este tipo de requisito. A desvantagem de uso desta abordagem BPMNFR a utilizao de dois modelos, um que utiliza o BPMN e outro que utiliza o NFR-Framework, durante seu processo. Portanto o analista de sistemas dever conhecer e utilizar duas ferramentas durante o processo de modelagem. Outra limitao desta abordagem se d em relao aos catlogos, pois se no existirem catlogos genricos que utilizem o NFR-Framework para um determinado requisito nofuncional, o analista de sistemas ter de criar um. O captulo seguinte apresentar um estudo de caso aplicado em uma situao real para avaliar a eccia da abordagem BPMNFR.
56
Life is about not knowing, having to change, taking the moment and make the best of it. Gilda Radner
5
Estudo de caso
Este captulo apresenta uma aplicao prtica da abordagem BPMNFR proposta em um ambiente de desenvolvimento real. Sero descritos o contexto do ambiente no qual o experimento ocorreu, a sua realizao e as consideraes nais. importante observar, porm, que este estudo aconteceu aps a aplicao car pronta, portanto foi feita a modelagem do estudo de caso sem os requisitos no-funcionais e depois eles foram inseridos.
5.1
Contextualizao
O Ministrio da Educao (Ministrio da Educao (MEC)) tem iniciado diversos projetos na rea de tecnologia na educao com o intuito de incentivar a modernizao do ensino e das tcnicas pedaggicas. O MEC tem percebido que a instrumentao da sala de aula com mtodos e ferramentas mais modernas uma necessidade e prioridade para o sistema de ensino brasileiro. Esta modernizao est sendo pautada em diversas inciativas como os programas de laboratrio de informtica nas escolas - ProInfo; o Portal do Professor que possibilita o compartilhamento de contedo digital entre educadores; dentre outras. Neste contexto, partindo de testes j iniciados pelo Centro de Experimentao em Tecnologia Educacional - Centro de Experimentao em Tecnologia Educacional (CETE), da Secretaria de Educao a Distncia - Secretaria de Educao a Distncia (SEED) do MEC, foi desenvolvida uma prova de conceito, um prottipo tecnolgico de uma soluo porttil multimdia que agrega funcionalidades de "projetor, ou display inteligente", de baixo custo e uso simplicado, focado na dinmica e uso de sala de aula. A combinao de funcionalidades de sistema de projeo e computador permite a conexo com a Internet, portabilidade, manipulao de contedo multimdia, desenvolvimento de tarefas colaborativas, apresentao de contedos educacionais, entre
57
CAPTULO 5. ESTUDO DE CASO
outras funes. Assim, o MEC convidou a Universidade Federal de Pernambuco (Universidade Federal de Pernambuco (UFPE)), atravs do Secretaria de Ensino a Distncia da UFPE (SEAD) (Secretaria de Ensino a Distncia da UFPE), que conjuntamente com o Centro de Informtica da UFPE, aceitaram o desao de propor e desenvolver um prottipo que atendesse aos anseios do MEC. Dentro deste contexto, representantes do MEC apresentaram para a coordenao do projeto na UFPE um prottipo inicial que serviu como referncia para o desenvolvimento de tal tecnologia. O prottipo nal deveria ser validado pelo MEC e industrializado. O estudo de caso deste trabalho ocorreu no contexto desta parceria entre o MEC e a UFPE. Para realizao do projeto seria necessrio desenvolver um prottipo de um equipamento que reunisse as caractersticas especicadas pelo MEC bem como um software robusto que pudesse suportar estas caractersticas e uma interface que suportasse as necessidades especcas do usurio. Portanto, congura o desenvolvimento de um sistema de hardware, software e interface, ambiente perfeito para aplicao da abordagem BPMNFR, proposta no captulo 4 deste trabalho. Durante um ano uma equipe tcnica formada por 20 pessoas trabalhou dedicada ao projeto, que foi denominado Lampejo. O grupo era totalmente heterogneo e multidisciplinar e foi organizado de acordo com suas especialidades nos diversos subsistemas do projeto, como ser descrito nas sees posteriores.
5.2
Objetivos do estudo de caso
Como dito no captulo 1, a anlise de requisitos tem sido amplamente reconhecida com um fator crtico de sucesso de projetos de software (Group, 1995). Se no forem devidamente elicitados, os requisitos podem levar o projeto ao fracasso. No entanto, a experincia prtica demonstra que os problemas podem facilmente ser identicados nesta fase. H diculdade em elicitar e avaliar os requisitos no-funcionais de uma forma estruturada e compreensiva, principalmente quando envolve vrios stakeholders (Wagner et al., 2008). Adicionalmente, os modelos de requisitos propostos pelos analistas de sistemas (representando a tecnologia da informao) e utilizados para interagir com os usurios podem gerar diculdades de compreenso, j que os usurios nais no dominam a linguagem de representao de tecnologia da informao (de La Vara et al., 2008). Para tentar resolver este problema, os analistas de sistemas tm utilizado notaes que so de fcil entendimento pelo usurio, pois elas so intuitivas, tais como BPMN. Porm mesmo utilizando esta notao ainda no possvel expressar todas as necessidades dos 58
5.3. ESTUDO DE CASO
usurios, pois a notao no suporta a modelagem de requisitos no-funcionais. Portanto, tendo em vista o contexto e o problema apresentado este estudo de caso tem o objetivo de validar se a abordagem apresentada no captulo 4 obtm sucesso numa aplicao real, que foi descrita na seo anterior, sob o ponto de vista da modelagem de requisitos no-funcionais dentro da modelagem de negcios.
5.3
Estudo de caso
Nas subsees seguintes, sero apresentados e detalhados todos os passos para a utilizao da abordagem BPMNFR descrita no captulo 4 atravs do estudo de caso. Apesar dessas aplicao ser real, no caber a este estudo mostrar todos as atividades de todos os processos desta aplicao, ou corre-se o risco de perder o foco desta dissertao.
5.3.1
Modelagem do processo de desenvolvimento do produto
Nesta primeira etapa, foi feito o diagrama de processos para o desenvolvimento da aplicao que foi entregue ao MEC. Este processo modelado utilizando a notao de BPMN, mostrada no captulo 2. Os macro-processos identicados foram: elicitao de requisitos, validao dos requisitos, desenvolvimento dos componentes do sistema e Testes. Existem tambm atividades, tais como: Denio de arquitetura e Integrao. Uma viso geral sobre os processos de desenvolvimento do lampejo (aplicao desenvolvida para o MEC) apresentada na gura 5.1. Para um melhor entendimento, os macro-processos de elicitao de requisitos, validao dos requisitos, implementao da interface e testes sero detalhados e mostrados a seguir. Uma viso detalhada desses macro-processos importante para que se entenda todo o contexto e faa sentido nos prximos passos da validao da abordagem BPMNFR. Elicitao de requisitos Este macro-processo o primeiro na lista de atividades no desenvolvimento da aplicao e de suma importncia para o bom entendendimento das funcionlidades e das necessidades do usurio. As atividades identicadas para esse macro-processo podem ser vistas na gura 5.2 e foram: anlise de competidores, conversa com o stakeholder (no caso professores e pedagogos), uma anlise qualitativa dos dados colhidos nas duas atividades anteriores,
59
60
Figura 5.1 Macro processo de desenvolvimento do lampejo.
5.3. ESTUDO DE CASO
a identicao das principais funcionalidades da aplicao usando como base a anlise qualitativa e nalmente a elaborao da verso preliminar do documento de requisitos. O macro-processo de Elicitao de Requisitos gera como artefato o documento de requisitos. Este processo linear e no tem muitos pontos de deciso, pois ainda existir a etapa de validao dos requisitos, apresentados no artefato que foi gerado. Com a gura 5.2 foi possvel entender o detalhe das atividades do macro-processo de elicitao de requisitos e passar para o prximo macro-processo. Validao de requisitos Este macro-processo de muita importncia para o andamento do projeto, j que nele que se tem a conrmao se o que foi levantado de requisitos foi suciente e se atende s expectativas dos usurios. Na validao de requisitos foi identicada a necessidade da presena dos usurios. Portanto, a tarefa de validar com usurios e elaborar documento de requisitos consolidado fazem parte deste macro-processo (vide gura 5.3). No processo de validao, o documento de requisitos s precisar ser evoludo, se as funcionalidades identicadas anteriormente no forem aceitas pelo usurio. Se isso acontecer ser gerado tambm um artefato, o documento de requisitos validado pelo usurio. Desenvolvimento dos componentes do sistema Como mostrado na gura 5.1, os componentes do sistema so interface, software e hardware. Cada uma dessas trs partes tm um subprocesso interno, porm para este trabalho s detalharemos o subprocesso de desenvolvimento da interface. As atividades identicadas para o desenvolvimento da interface foram: levantamento da infra-estrutura de hardware, levantamento das necessidades especcas do usurio, desenho das telas, desenho dos cones, aprovao do layout e desenvolvimento (vide gura 5.4). Durante a etapa de desenvolvimento da interface, tambm existe a interao com o usurio nal, atravs da atividade de aprovao do layout. O layout desenvolvido precisa ser validado por ele e se for necessria alguma modicao esse layout volta a ser trabalhado at que chegue num ponto que seja satisfatrio para o usurio. Desta forma se encerra a apresentao e detalhamento dos subprocessos mostrados na gura 5.1.
61
62
Figura 5.2 Subprocesso de elicitao de requisitos.
5.3. ESTUDO DE CASO
Figura 5.3 Subprocesso de validao de requisitos.
Testes Este macro-processo o ltimo da cadeia de processos, ele de suma importncia pois nele so feitos os testes da aplicao como um todo e a partir dele que possvel detectar os erros que ainda precisam ser consertados ou dar como encerrado o desenvolvimento. Nos testes primeiro se faz o teste individual do hardware que foi construdo, quando os erros forem encontrados, o processo nalizado. Se no houver erros, a atividade de testar a aplicao iniciada. Encontrando erros ou no a atividade nalizada (vide gura 5.5). Quando o processo nalizado, existe um ponto deciso no macro-processo que encerra o desenvolvimento ou no, a dependncia est relacionado ter encontrado erros ou no no processo de testes. Consideraes Durante a elaborao do macro-processo mostrado na gura 5.1e de seus subprocessos, visto nas guras 5.2, 5.3, 5.4 e 5.5, ainda no foi possvel modelar com clareza os requisitos no-funcionais. O processo de desenvolvimento do produto foi modelado e a partir disto ser dado incio a prxima fase da abordagem BPMNFR, a fase de rotulao das atividades.
63
64
Figura 5.4 Subprocesso de implementao da interface.
5.3. ESTUDO DE CASO
Figura 5.5 Subprocesso de Testes.
5.3.2
Insero dos requisitos no-funcionais atravs dos rtulos
Os diagramas gerados na fase anterior serviro de artefato de entrada para esta nova fase. Durante a elicitao de requisitos os requisitos no-funcionais foram identicados e nesta fase sero associados de forma explcita s atividades dentro dos processos. No projeto lampejo, os requisitos no-funcionais identicados foram: mobilidade, acessibilidade, usabilidade, auto-contido, robustez, facilidade no transporte, baixo custo de manuteno, baixo custo com infra-estrutura. Dentre esses requisitos no-funcionais, os mais crticos so usabilidade, mobilidade e acessibilidade. Neste trabalho, usaremos o requisito usabilidade para o estudo de caso. Levando-se em considerao a usabilidade, as atividades que esto relacionadas so elicitao de requisitos, implementao da interface, validao dos requisitos e testes do produto, conforme gura 5.6. Se, aps a identicao das operacionalizaes, o analista notar que cou faltando rotular alguma tarefa, esta rotulao ainda poder ser feita, levndo-se em considerao que a abordagem BPMNFR prope um processo incremental. Depois de identicadas as atividades que so relacionadas aos determinados requisitos no-funcionais, isto , as atividades que foram rotuladas, poderemoas dar incio a prxima etapa.
65
66
Figura 5.6 Diagrama do lampejo rotulado.
5.3. ESTUDO DE CASO
5.3.3
Operacionalizaes dos requisitos no-funcionais
Aps os requisitos no-funcionais serem identicados, necessrio que sejam descobertas as operacionalizaes desses requisitos para que se transformem em atividades dentro do BPD. Essas operacionalizaes podem ser descobertas analisando um catlogo baseado em NFR-Framework j existente, como os catlogos encontrados em (Chung et al., 2000), ou extendendo um catlogo j existente para adptar a um domnio especco, ou, se o catlogo no existir, denindo-o usando a notao do NFR-Framework de (Chung et al., 2000). No estudo de caso, o requisito no-funcional que est sendo trabalhado usabilidade. Como mostrado no captulo 4 foi criado um catlogo para usabilidade baseado nas dez heursticas criadas por Nielsen em (Nielsen, 1994). O catlogo criado ainda foi extendido para atender s particularidades deste domnio e desta aplicao. O detalhe do renamento do catlogo ser mostrado na prxima seo.
Renamento do Catlogo de Usabilidade Utilizando o NFR-Framework, mostrado no captulo 3, e as heursticas de (Nielsen, 1994) chegou-se ao catlogo de usabilidade mostrado nas guras 3.8, 3.9, 3.10, 3.11 que esto no captulo 3. Este primeiro catlogo criado serviu como referncia para a extenso do catlogo utilizado no estudo de caso, que tem as operacionalizaes especcas para essa aplicao, neste domnio. Com este catlogo genrico pronto, para o estudo de caso foi necessrio detalhar um pouco mais as operacionalizaes alm de criar um novo softgoal para o entendimento especco do domnio no usurio. A gura 5.7 mostra o renamento da sub-rvore de Fcil de aprender e usar. Esta foi a parte do catlogo que foi renada. Na gura 5.7 a operacionalizao Seguir convenes da plataforma foi mais detalhada e derivou uma nova operacionalizao chamada Cores adequadas ao projetor. Outra operacionalizao derivada foi Instrues visveis que agora tem mais um detalhamento com a operacionalizao cones grandes. Finalmente a ltima operacionalizao que foi expandida foi a Prototipao que recebeu quatro operacionalies que contribuem para seu cumprimento, so elas: Modelar navegao, Desenhar esboo de telas, Preparar prottipo e Aplicar prottipo. O novo softgoal criado serviu para o entendimento nas necessidades especcas do domnio do usurio. O softgoal Entender o domnio do usurio j aparece com trs operacionalizaes (vide gura 5.8): Observaes em sala, Sesso de tarefas e
67
Figura 5.7 Catlogo de usabilidade renado - Fcil de aprender e usar.
68
5.3. ESTUDO DE CASO
Entrevistas com pedagogos.
Figura 5.8 Catlogo de usabilidade novo softgoal - Entender domnio do usurio.
Com o catlogo baseado no NFR-Framework devidamente adaptado ao domnio da aplicao podemos identicar quais operacionalizaes faro parte do BPD. Identicao das operacionalizaes Depois de ter o catlogo do requisito no-funcional com todas as operacionalizaes possveis, cabe ao analista de negcios identicar quais dessas operacionalizaes devero
69
fazer parte do BPD. Essa escolha dever ser norteada pelo domnio da aplicao, pois depende dele a existncia ou no de uma operacionalizao no BPD. No estudo de caso, as operacionalizaes que fazem sentido para o domnio da aplicao so Desenhar cones grandes, Escolher cores que se adequem ao uso do projetor, Observaes em sala de aula, Sesses de tarefas com os alunos, Entrevistas com pedagogos e professores, Modelar navegao das telas, Desenhar esboo das telas, Preparar a aplicao do prottipo, Aplicar prottipo com os usurios, Teste de usabilidade. Insero das operacionalizaes no BPD Com a escolha das operacionalizaes do requisito no-funcional que iro fazer parte do BPD j feita, nalmente pode-se inseri-las a partir do ponto de marcao feito no comeo, os rtulos. Neste estudo de caso, as atividades que tinham operacionalizaes associadas foram elicitao de requisitos, implementao da interface e testes do produto, apresentada na gura 4.4. Em cada atividade as operacionalizaes foram associadas e identicadas atravs do grupo lgico. Cada atividade, que teve os requisitos no-funcionais associados, sero mostradas nas guras seguintes. Na gura 5.9, inserido um processo a mais, o de prototipao, referente operacionalizao prototipao que aparece no catlogo de usabilidade renado. Esta operacionalizao est ligado com a elicitao de requisitos, pois era esta atividade que antes estava rotulada. Na gura 5.10, so inseridas as operacionalizaes Observaes em sala de aula, Sesses de tarefas com os alunos e Entrevistas com pedagogos e professores. Essas operacionalizaes esto relacionados ao novo softgoal que precisou ser criado no renamento do catlogo de usabilidade. Estas operacionaizaes foram inseridas dentro do macro-processo de elecitao de requisitos. A atividade de conversa com professores foi substituda pela entrevista. Na gura 5.11, relacionada validao de requisitos, so criadas atividades que representam o detalhamento da operacionalizao prototipao. Essas atividades so Modelar navegao das telas, Desenhar esboo das telas, Preparar a aplicao do prottipo, Aplicar prottipo com os usurios. Na gura 5.12, inserida uma atividade a mais que s existe por conta da operacionalizao prototipao, essa atividade Colher resultados da prototipao. 70
5.3. ESTUDO DE CASO
Figura 5.9 Operacionalizaes dos requisitos no-funcionais no BPD do lampejo].
71
72 Figura 5.10 Operacionalizaes dos requisitos no-funcionais no BPD de elicitao de requisitos.
5.3. ESTUDO DE CASO
Figura 5.11 Detalhamento da operacionalizao prototipao.
73
74 Figura 5.12 Operacionalizaes dos requisitos no-funcionais no BPD de validao de requisitos.
5.3. ESTUDO DE CASO
O sub-processo de implementao da interface descrito na gura 5.4 tambm revista na gura 5.13, onde criada atividades que representam o detalhamento da operacionalizao do desenvolvimento da interface. Essa atividade Escolher cores que se adequem ao uso do projetor. Alm dessa atividade, tambm criada uma nova atividade que surgiu a partir da operacionalizao de prototipao, que a Criao das telas baseadas na prototipao. Outro ponto importante que desenhar cones deixou de ser apenas uma atividade para representar um processo que ser detalhado na gura 5.14. Na gura 5.14, so criadas atividades que representam as operacionalizao no desenho dos cones. Essas atividades so Escolha de imagens que se assemelhem com o mundo real e Desenho de cones grandes. Na gura 5.15, criada a atividade Teste de usabilidade dentro do processo de testes que representa uma das operacionalizaes escolhidas no catlogo. Para facilitar a anlise, a tabela 5.1 foi criada e com ela possvel fazer a correspondncia entre as tarefas rotuladas do BPD e as operacionalizaes que foram criadas a partir do requisito no-funcional usabilidade.
Tabela 5.1 Correspondncias de operacionalizaes
Todas as tarefas que foram rotuladas, tinham o mesmo requisito no-funcional associado, Usabilidade. A elicitao de requisitos derivou cinco operacionalizaes da usabilidade que foram associadas posteriormente, so elas: Observaes em sala de aula, sesso de tarefas com alunos e entrevistas com professores que foram alocadas dentro do sub-processo de elicitao e foram inseridas como tarefas, assim como Prototipao que uma atividade que est associada ao requisito de elecitao por meio de um uxo associao e um macro-processo. A validao de requisitos teve apenas uma operacionalizao associada atravs de uma atividade dentro de seu sub-processo, essa operacionalizaes foi Colher resultados da prototipao.
75
76 Figura 5.13 Operacionalizaes dos requisitos no-funcionais no BPD de desenvolvimento da interface.
5.3. ESTUDO DE CASO
Figura 5.14 Operacionalizaes do desenho dos cones.
Figura 5.15 Operacionalizao dos testes.
77
Na implementao da interface trs operacionalizaes foram associadas, duas (Criao de telas baseadas na prototipao e Escolha das cores que se adequem ao projetor) dentro do seu subprocesso em forma de atividades. A ltima operacionalizao, Desenho de cone, foi colocada dentro do sub-processo de implementao de interface, na forma de um macro-processo. E nalmente na tarefa de Teste, foi inserida a operacionalizao Teste de Usabilidade na forma de macro-processo e localizado dentro do sub-processo de Teste. Desta forma, os requisitos no-funcionais foram colocados num diagrama de modelagem de processos de negcio de forma explcita.
5.4
Consideraes nais
Este Captulo apresentou a utilizao da abordagem BPMNFR na modelagem do desenvolvimento de uma aplicao real. Os resultados obtidos nesta utilizao foram animadores pois atingiram os objetivos deste trabalho, que foi apresentar uma pesquisa baseada na anlise de requisitos no-funcionais e na modelagem de processos de negcio, onde foi proposta a abordagem BPMNFR para integrar os requisitos no-funcionais notao de BPMN, como forma de solucionar sua decincia de expressividade desses requisitos. Assim, foi proposta a criao de novos smbolos para que esta notao pudesse contemplar os requisitos no-funcionais. Evidentemente, este foi um caso e precisaramos aplicar a abordagem BPMNFR em outros domnios e com outros requisitos no-funcionais para que tivssemos posies mais slidas acerca das suas contribuies e limitaes, entretanto foi possvel, com o estudo de caso, fazer a crtica da abordagem BPMNFR e pensar em aspectos que contribuiro para a evoluo posterior do modelo.
78
I ought to be testing myself daily, and asking myself what I am really archieving. Margot Asquith
6
Concluso
Neste captulo sero apresentadas as concluses obtidas no desenvolvimento desta dissertao, bem como descritos alguns trabalhos futuros que podero ser desenvolvidos.
6.1
Concluses e Trabalhos Futuros
A Engenharia de Requisitos ainda uma fase do desenvolvimento de software onde erros e enganos so comuns. Portanto, pode ser a fonte de problemas nas prximas fases do desenvolvimento, podendo assim, no satisfazer as reais necessidades da organizao onde o software for implantado. Alguns dos erros detectados na prtica so a falta de compreenso do negcio da empresa pelo analista de sistemas, a falta de foco no escopo do software e falta de comunicao entre os stakeholders e o analista de sistema. Este trabalho descreveu uma abordagem para tentar evitar esses tipos de problemas baseando-se na modelagem dos processos de negcio por meio de BPMN, que uma notao padro, e dos requisitos no-funcionais descritos utilizando o NFR-Framework. A abordagem BPMNFR tenta possibilitar que analistas de sistema compreendam e analisem corretamente a organizao, suas necessidades e os atributos de qualidade que a ela so importantes. Analistas de negcio e analistas de sistema compartilham uma linguagem que seja compreensvel a ambos graas ao BPMN. BPDs so a base para os usurios, para validar se a estrutura organizacional e de comportamento tm sido adequadamente entendida pelo analista de sistemas. Alm disso, a abordagem BPMNFR tenta atenuar as decincias da utilizao apenas do BPMN sem a utilizao de nenhuma abordagem para detalhar requisitos no-funcionais. Sendo assim propomos a utilizao do NFR-Framework para modelar e facilitar a descoberta das operacionalizaes de requisitos no-funcionais. O resultado desta pesquisa foi um processo que viabiliza a insero das operacional-
79
CAPTULO 6. CONCLUSO
izaes dos requisitos no-funcionais nos diagramas de processos de negcio. Tratou da natureza subjetiva dos requisitos no-funcionais e contribui com mais uma evidncia do uso da modelagem de processos de negcio como um passo inicial do processo de engenharia de requisitos.Uma extenso de BPMN para a modelagem de requisitos no-funcionais foi o principal resultado deste trabalho. A viabilidade de aplicao da abordagem BPMNFR proposta foi vericada atravs da aplicao a um caso real, que demonstrou a possibilidade de utilizao da mesma. A apresentao da importncia da modelagem dos processos de negcios na fase de Engenharia de Requisitos para o desenvolvimento de uma aplicao de software tambm foi uma contribuio importante deste trabalho. Alm da criao e detalhamento de um catlogo do requisito no-funcional usabilidade. O catlogo de usabilidade criado neste trabalho foi um passo inicial para elaborao de um catlogo de usabilidade mais completo, ele utilizou conceitos de trs autores, portanto possvel o aprimoramento, principalmente atravs da utilizao da norma ISO/IEC 9126-1:2001 para qualidade de produto de software. Para validar de forma mais denitiva a abordagem proposta, se faz necessrio considerar todos os demais requisitos no-funcionais para o domnio considerado, bem como sua aplicao a outros domnios e relacionando outros requisitos no-funcionais. Poderemos explorar os requisitos que j tm algum catlogo no NFR-Framework, como outros que ainda no foram catalogados. Alm da utilizao em outras aplicaes, domnios e requisitos no-funcionais, tambm importante, para a evoluo deste trabalho, que uma ferramenta seja implementada para suportar a nova notao que estende o BPMN.
80
Referncias Bibliogrcas
Berio, G. and Vernadat, F. (2001). Enterprise modelling with cimosa: functional and organizational aspects. Production Planning & Control: The Management of Operations,2001, Vol. 12, 128 136. Bittencourt, R. M. V. (2009). Identicando Expectativas de Qualidade de SIs com o Apoio de Modelos de Negcio. Masters thesis, Universidade Federal do Estado do Rio de Janeiro - Centro de Cincias Exatas e Tecnologia. Boehm, B. W. (1988). A spiral model of software development and enhancement. A spiral model of software development and enhancement, pages 61 72. Booch, G., Rumbaugh, J., and Jacobson, I. (1998). The Unied Modeling Language User Guide. Addison Wesley. BPMI.org (2008). Business Process Modeling Notation, OMG Available Specication. Object Management Group, 1.1 edition. Brito, I. and Moreira, A. (2004). Integrating the nfr framework in are model. In Early Aspects 2004, 3rd Aspect-Oriented Software Development Conference (AOSD ), Lancaster, UK. Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE computer, Vol. 20, 1019. Castro, J., Kolp, M., and Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: The tropos project. Information Systems, Vol. 27, 365389. Chung, L. and Nixon, B. A. (1995). Dealing with non-functional requirements: three experimental studies of a process-oriented approach. In ICSE 95: Proceedings of the 17th international conference on Software engineering, pages 2537, New York, NY, USA. ACM. Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J. (2000). Non-Functional Requirements in Software Engineering. Springer. Cysneiros, L. M. (2001). Requisitos No Funcionais: Da Elicitao ao Modelo Conceitual. Ph.D. thesis, PUC/RJ.
81
REFERNCIAS BIBLIOGRFICAS
Cysneiros, L. M. (2007). Evaluating the effectiveness as using catalogues to elicit non-functional requirements. In 10th Workshop in Requirements Engineering. Cysneiros, L. M. and do Prado Leite, J. C. S. (1998). Utilizando requisitos no funcionais para anlise de modelos orientados a dados. Workshop de Engenharia de Requisitos-XII SBES. Davenport, T. H. (1993). Process Innovation: Reengineering work through information technology. Harvard Business Press. Davenport, T. H. (1994). Reengenharia de processos: como inovar na empresa atraves da tecnologia da informacao. Editora Campus. Davenport, T. H. and Stoddard, D. B. (1994). Reengineering: Business change of mythic proportions? MIS Quarterly, Vol. 18(2), 121127. Davis, A. M. (1993). Software requirements: objects, functions, and states. Prentice-Hall, Inc. de La Vara, J. L., Snchez, J., and scar Pastor (2008). Business Process Modelling and Purpose Analysis for Requirements Analysis of Information Systems, pages 213227. Springer-Verlag, Berlin, Heidelberg. Dubray, J.-J. (2004). Business process modeling notation. ebPML.org. Dumas, M., van der Aalst, W., and Hofstede, A. T. (2005). Process-aware information systems. John Wiley and Sons. Eriksson, H.-E. and Penker, M. (2000). Business Modeling With UML: Business Patterns at Work. John Wiley & Sons. Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River, NJ, USA. Estrada, H., Rebollar, A. M., Pastor, O., and Mylopoulos, J. (2006). Advanced Information Systems Engineering, chapter An Empirical Evaluation of the i* Framework in a ModelBased Software Generation Environment, pages 513 527. Springer. Goldsby, H. J., Konrad, S., and Cheng, B. H. (2007). Goal-oriented patterns for uml-based modeling of embedded systems requirements. In Proceedings of the 10th IEEE High Assurance Systems Engineering Symposium, Dallas, TX, USA. 82
Gomes, A. S., de Arajo, C. R., de Arruda, D. A., Sultanum, N. B., de Paiva, L. J., and de Albuquerque Menezes, L. (2006). Participao de professores de matemtica no desenvolvimento de aplicaes educativas computacionais para o ensino de estruturas aditivas. In VI EPEM- Encontro Pernambucano de Educao Matemtica, volume Vol. 1, pages 113, Caruaru. Group, T. S. (1995). Chaos reports. Technical report, The Standish Group. Harmon, P. and Wolf, C. (2008). The state of business process management. Technical report, Business Process Trends. Harrington, H. J. (1991). Business process improvement. McGraw-Hill Professional. Holtzblatt, K. and Beyer, H. R. (1995). Requirements gathering: the human factor. Commun. ACM, Vol. 38(5), 3132. Johansson, H. J. and Pendlebury, A. (1993). Business Process Reengineering: BreakPoint Strategies for Market Dominance. John Wiley & Sons. Jones, S. and Maiden, N. (2004). Requirements Engineering for Sociotechnical Systems, chapter RESCUE: An Integrated Method for Specifying Requirements for Complex Socio- Technical Systems. Information Science Publishing. Kavakli, E. and Loucopoulos, P. (2003). Goal driven requirements engineering: Evaluation of current methods. In Eighth International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design, Klagenfurt/ Velden, Austria. Kirikova, M. and Bubenko, J. A. (1994). Enterprise modelling: Improving the quality of requirements specications. In Information systems Research seminar In Scandinavia, Finland. Kirner, T. G. and Davis, A. M. (1996). Nonfunctional requirements of real-time systems. Advances in Computers, Vol. 42, 137. Knight, D. (2004). Elicitao de Requisitos de Software a partir do Modelo de Negcio. Masters thesis, UFRJ/NCE. Luftman, J. N., Papp, R., and Brier, T. (1999). Enablers and inhibitors of business-it alignment. Communications of AIS, page p. 1.
83
Muehlen, M. Z. and Ho, D. T. (2008). Service process innovation: A case study of bpmn in practice. 41th Annual Hawaii International Conference on System Sciences, Vol. 0, 372. Muehlen, M. Z. and Recker, J. (2008). How much language is enough? theoretical and practical use of the business process modeling notation. In Advanced Information Systems Engineering, volume Volume 5074/2008, pages 465479. Springer Berlin / Heidelberg. Mylopoulos, J., Chung, L., and Nixon, B. (1992). Representing and using non-functional requirements: A process oriented approach. IEEE Transactions on Software Engineering, vol. 18(n. 6), 483 497. Mylopoulos, J., Chung, L., Liao, S. S., Wang, H., and Yu, E. (2001). Exploring alternatives during requirements analysis. In IEEE Software, volume Vol. 18, pages 9296. Nielsen, J. (1994). Usability Inspection Methods, chapter Heuristic evaluation, pages 413414. ACM, New York, NY, USA. Norman, D. A. (1988). The Design of Everyday Things. Basic Civitas Books, New York. of Business Analysis, I. I. (2009). A Guide to the Business Analysis Body of Knowledge. Owen, M. and Raj, J. (2003). Bpmn and business process management - introduction to the new business process modeling standard. Popkin Software. Paim, R. (2007). As Tarefas para Gesto de Processos. Ph.D. thesis, Universidade Federal do Rio de Janeiro. Pavlovski, C. J. and Zou, J. (2008). Non-functional requirements in business process modeling. In APCCM 08: Proceedings of the fth on Asia-Pacic conference on conceptual modelling, pages 103112, Darlinghurst, Australia, Australia. Australian Computer Society, Inc. Preece, J., Rogers, Y., and Sharp, H. (2005). Design de Interao: Alm da Interao Homem-Computador. Bookman. Recker, J. (2008). Bpmn modeling who, where, how and why. BPTrends, 5, 18. Recker, J., Indulska, M., Rosemann, M., and Green, P. (2006). How good is bpmn really? insights from theory and practice. In Proceedings 14th European Conference on Information Systems, pages 15821593, Goeteborg, Sweden. 84
Reich, B. H. and Benbasat, I. (2000). Factors that inuence the social dimension of alignment between business and information technology. MIS quarterly, Vol. 24(No. 1), pp. 81113. Rolland, C. (2007). Conceptual Modelling in Information Systems Engineering, chapter Capturing System Intentionality with Maps, pages 141158. Springer Berlin Heidelberg. Rummler, G. A. and Brache, A. P. (1995). Improving Performance: How to manage the white space on the organizational chart. Jossey-Bass Publishers, San Francisco, CA. Sharp, A. and McDermott, P. (2009). Workow Modeling: Tools for Process Improvement and Application Development. Artech House. Sommerville, I. and Sawyer, P. (1997). Requirements engineering: a good practice guide. Sousa, G. M. C. (2004). Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento de Software Orientado a Aspectos. Masters thesis, Universidade Federal de Pernambuco. Taylor-Cummings, A. (1998). Bridging the user-is gap: a study of major information systems projects. Journal of Information Technology, Vol. 13, 29 54. Wagner, S., Deissenboeck, F., and Winter, S. (2008). Managing quality requirements using activity-based quality models. In WoSQ 08: Proceedings of the 6th international workshop on Software quality, pages 2934, New York, NY, USA. ACM. Wahl, T. and Sindre, G. (2005). Advanced Topics in Database Research, chapter Captulo 6 - An Analytical Evaluation of BPMN Using a Semiotic Quality Framework, pages 94 105. Idea Group Inc. Wei, D., Leukel, J., and Kirn, S. (2008). A method for aligning business process modeling and software requirements engineering. In Process Innovation with Business Software. White, S. A. (2006). Introduction to bpmn. IBM Corporation. Wiley, D. A. (2002). The Instructional Use of Learning Objects. Association for Instructional Technology.
85
Wohlin, C., Hst, M., Runeson, P., and Ohlsson, M. (2000). Experimentation in software engineering, volume Vol. 6. Springer. Yu, E. (1995). Modeling Strategic Relationships for Process Reengineering. Ph.D. thesis, Department of Computer Science, University of Toronto.
86

BPMN Dissertacao LaisXavier

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

BPMN Dissertacao LaisXavier

Enviado por

Direitos autorais:

Formatos disponíveis

Integrao de Requisitos No-Funcionais a Processos de Negcio: Integrando BPMN e RNF

Las Xavier D ISSERTAO DE M ESTRADO

Universidade Federal de Pernambuco Centro de Informtica

Recife PE 31 de Agosto de 2009

Universidade Federal de Pernambuco Centro de Informtica

Integrao de Requisitos No-Funcionais a Processos de Negcio: Integrando BPMN e RNF

Recife PE 31 de Agosto de 2009

Identicao dos requisitos no-funcionais particulares do domnio 25

Operacionalizao de requisitos no-funcionais . . . . . . . . . . . . . Catlogo de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1 3.4.2 3.4.3 3.5 4

A Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . O catlogo proposto . . . . . . . . . . . . . . . . . . . . . . . Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . .

Anlise comparativa com outras abordagens . . . . . . . . . . . . . . .

Concluso 6.1 Concluses e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

Figura do Processo geral de desenvolvimento um objeto de aprendizagem 47

Tabela de correspondncias de operacionalizaes . . . . . . . . . . . . Tabela de correspondncias de operacionalizaes . . . . . . . . . . . .

Modelagem de processos de negcio

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Modelos de processos de negcio

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Figura 2.1 Eventos.

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Figura 2.2 Atividades.

Figura 2.3 Gateways.

Figura 2.4 Fluxo de Sequncia.

Figura 2.5 Fluxo de Mensagem.

Figura 2.6 Associao.

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Figura 2.7 Pool.

Figura 2.8 Lane.

Figura 2.9 Objetos de Dados.

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Figura 2.10 Grupo.

Figura 2.11 Anotao.

2.5. CONSIDERAES FINAIS

Figura 2.12 Exemplo do uso da notao BPMN.

CAPTULO 2. MODELAGEM DE PROCESSOS DE NEGCIO

Figura 2.13 Exemplo 2 do uso da notao BPMN.

2.5. CONSIDERAES FINAIS

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

Aquisio ou acesso a conhecimentos

Identicao dos requisitos no-funcionais particulares do domnio

Figura 3.1 SIG Inicial (Chung et al., 2000).

Decomposio dos requisitos no-funcionais

Identicao das operacionalizaes

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

Figura 3.2 Decomposio por tipos (Chung et al., 2000).

Lidar com Ambigidades, Prioridades e Interdependncias entre requisitos no-funcionais e operacionalizaes

Figura 3.3 Identicao de um softgoal como prioridade (Chung et al., 2000).

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

Apoiar decises com concepo lgica

Avaliar os impactos das decises

Figura 3.4 Seleo de operacionalizaes (Chung et al., 2000).

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

Figura 3.5 Claim-Softgoal (Chung et al., 2000).

3.3. OPERACIONALIZAO DE REQUISITOS NO-FUNCIONAIS

Operacionalizao de requisitos no-funcionais

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

3.4. CATLOGO DE USABILIDADE

Figura 3.7 Operacionalizaes (Chung et al., 2000).

CAPTULO 3. REQUISITOS NO-FUNCIONAIS

3.4. CATLOGO DE USABILIDADE